Build Wide, Ship Narrow

A bit bewildering but a small variation of this work: do a ton of experimental branches that you just don't merge.

It's amazing how the AI can learn from branches that ran up against a wall.

I don't think that you need to make wild iterations on the real product, just do it scratch space and 'merge the lessons not the code'

This whole 'design up front' never worked well because it baked in to many bad assumptions.

The experimental efforts help you work through those.

Once you've worked through it - toss them aside and then let the AI plan based on the scratch work.

The tangled stuff is in scratch space, that's what it's for.

And critically: it costs almost nothing.

The power of AI is not the 'nits and small bugs' - it's the firehose of scratch branches it can let loose in where it doesn't have to worry about PRs, reviews.

Once it's all figured out, then the path to the solution is actually relatively clear - and it can be 'planned out' and just done.

I see references to Pascal intensifying these days. Something like "Sorry I didn't have time to make it shorter".

Producing massive changes in a codebase has never been impressive. LoC has always been a bad measure of progress, and yet, modern frameworks, popular tooling and haphazard business logic almost dictates that you blurt out as many LoC as possible. Software engineering wasn't supposed to be this verbose.

That was hard to understand. So the idea if I'm not mistaken is to iterate without constraint/move fast and break things (build wide).

Demo the work, keep changing. Don't worry about the amount of changes, don't worry about nice commits. You are free to explore and produce as much changes as required.

Then use AI agents to clean up the history and produce a nice change set that you can ship in a more traditional way, small clean commits.

That is an interesting idea I guess. AI agents can be used to clean up git histories, not only produce large amounts of code.

Somehow, I think heavy LLM users don't really care about a clean git history / changesets? May be if the project or existing workflow you are bound to requires it you will do the extra steps but really I don't see it being done much.

Are you really going to review these small changes? So far the example I saw from agents are terrible. Full of drive-by, unrelated changes here and there. Mostly harmless or OK changes, but not focused.

Lots of good advice in here for those who want to ship big stuff without slop.

Great round up of the meat and potatoes of engineering in a mature codebase without giving in to entropy.

I never understand why companies post AI-written articles like this on their blog and why authors are okay having it attributed to them.

Authors: If you actually put deep thought into the content and then have an AI do the final writing, it immensely devalues your final product. I think this author actually has some good content here but the AI-generated prose does it no favors.

Companies: If your blog is for recruiting purposes (which is often one major motivation), AI slop articles are going to be a big turn off for the best talent.