Allows you to generate 3-7 minutes of video.

Per month.

Writing software begins with a solid design that is defensible. If you don't have that, the AI will produce slop.

Once you're happy with the design, you need a solid plan. If you don't have that, the AI will produce slop.

Once you're happy with the plan, you can set the AI loose, but don't get too complacent! Anything that you missed in the previous phases could very well lead to slop (although likely localized).

And then then, as your project matures and you gain more understanding of the space, you start to notice deficiencies in your model. This is where AI really shines: design and code changes to adapt to reality.

I remember Java coming along, and how much easier it was to build compared to all the crazy linking and cryptic error messages my C compiler gave me once you went beyond a toy program. And god forbid you wanted it to run on BOTH Borland and visual C!

I remember CGI, and then PHP making it trivial to write web apps, and then less trivial webapps, and then webapps that people actually used in serious business.

Then I watched the same thing happen with Javascript.

All those rebuilds of the same foundations, making the same fundamental design mistakes again and again like a wheel of karma, but with prettier UX and less vendor lock-in.

And now, AI makes it even easier to re-make those mistakes. It's gotten "easier", but it's actually gotten harder. Making something that runs has never been more trivial. Making something with a solid architecture and disciplined hygiene has never been harder.

And so we begin round 4 of re-learning the lessons of the 1960s-1970s.

I don't remember this internet. Ever since I got my first modem, I remember the kinds of vitriolic posts that led to the publication of IEN 137 (On Holy Wars and a Plea for Peace).

Whether it was endianness or RISC vs CISC or ZModem vs Kermit or Microsoft or Kirk vs Picard or Kimagure Orange Road, flame wars erupted everywhere. The smaller the stakes, the bigger the war.

- Journaling file structures (telegraph what you're about to write, then write it, then signal completion)

- memmap your important data structures to a file (they will be flushed to disk no matter how your app dies - short of a power loss)

- post-crash dump (put last-minute writers in a crash handler to save it to disk)

A journaling file structure is the most secure, because it's designed with the assumption that writing will eventually fail. memmapped structs are easy and cheap, and get you 99% of the way there (only power loss will lose your data). Crash-time writing is doable with a crash handler like KSCrash, but there are many ways an app can crash without triggering a crash handler (thermal kill, exceeding quota, memory jetsam, etc). You also need to write your data in a signal-safe manner.

It creates its own copy of your workdir for the agent to play in, and then you pull changes out ala git diffs or commits.

    $ yoloai new mybugfix . -a # launch default sandbox in . and also attach the terminal

    # Work with the agent...

    $ yoloai diff mybugfix  # See what it did
    $ yoloai apply mybugfix # Bring out commits and/or uncommitted changes.
    $ yoloai destroy mybugfix

This is what https://github.com/kstenerud/yoloai does.

Sandboxing using Docker, Podman, containerd (linux only), seatbelt (macos only), tart (macos only), apple container (macos 26+ only).

It takes a copy of your workdir, does its thing inside of the sandbox, and you pull the results back using git semantics:

    $ yoloai new mybugfix . -a # launch default sandbox in . and also attach the terminal

    # Work with the agent...

    $ yoloai diff mybugfix  # See what it did
    $ yoloai apply mybugfix # Bring out commits and/or uncommitted changes.
    $ yoloai destroy mybugfix

In most UIs, it feels like they're animated for the sake of being animated. Very rarely do I say "Ah, I'm glad that was animated, because the transition would be confusing otherwise."

Things like this are part of the reason why operating systems that used to measure in the tens of megabytes now measure in the tens of gigabytes, and require chips 1000x more powerful in order to MAYBE reach the same level of snappiness (although usually not).

Not in my sandbox. It gives no direct access to the workdir, no access to my github, my ssh keys, my security tokens or API keys. No access to my home dir or dotfiles. Nothing at all, except for what I explicitly tell it to give access to.

I can restrict network access. I can choose the isolation level: docker containers, Kata VMs, seatbelt, tart, even the new apple containers (which are VERY nice).

Not even ENV leaks through.

And it's FOSS: https://github.com/kstenerud/yoloai

Once that's set up, I spend time laying out the planning for whatever feature or fix is being worked on. For fixes the agent is pretty quick and usually needs little guidance. For new features it's best to have more of a hand on the tiller.

Another thing they tend to do is rely on their own context -> memories -> training data. And if that's wrong then they'll continue with it until you instruct them to research, after which they usually get the right answer.

I've noticed that the newer models keep track of what you type so as to anticipate what you're likely to say. For example, today Opus 4.8 said "You usually don't want me to commit until you've checked, so the change remains uncommitted."

To me, this feels in many ways like a technical manager or team lead's job, where I guide the process along using my knowledge and experience, and then let the agent fill in the rest (to the best of its ability).

The agent can't really learn from its mistakes (at least, not without consuming precious context), so I apply a blameless postmortem process, updating the guardrails whenever it goes astray in the same way more than once.

And really, I'd rather be contemplating the more difficult and interesting questions of architecture, environment, ergonomics and market fit, so it suits me fine.

Generally, I spend anywhere between 15 mins and an hour setting things up (depending on how well the project is set up for AI work), and then set the agent going, coming back in a half-hour to an hour to check its progress. Generally, the tooling keeps it honest (for golang, forbidigo is AWESOME). 80% of the questions the agent asks me require a lot of thought. 20% of what it does needs correction.

The other thing to remember with LLMs is that they are NOT human, and won't react in a human way. So you'll see strikes of "brilliance" followed by the absolutely bizarre. But good guardrails keep that to a minimum.

Yes, because Russia's propaganda, espionage and corruption arm has been focusing on the far-right parties for the past two decades, breaking from their previous focus on the far left.

You've been caricatured into a blind AI-follower rust-rewriter-just-because type, and that's the surface they'll continually attack (you're wasting time, hurting the community, v2-itis, bikeshedding, premature optimization, copyright violation, moustache-twirling-evil-intent-rug-pull-later, etc etc etc).

Just continue in your work. It's good, and we need people like you.

But in such a case I'd argue FOR the ceremony, as a way of declaring from the API "The input is a sequence of bytes that I won't treat as anything other than a sequence of bytes", and declaring from each and every call site: "This is not a mistake; we really are 'converting' this struct to a series of bytes for this function to consume".

Then anyone auditing the code knows the intent by the shape of the types, and would quickly flag any typecasting shenanigans within the receiver function.

But even then, hashing a struct will rapidly bring you into the land of dragons and fairies. Abandon all hope if you have floats or UTF-8 (which have multiple representations for the same values).

Far better to remain type-aware if you value your sanity.