HathawayField Notes
← All concepts

Software Engineering

5notes

Observation·

Engineering in natural language

Since Opus 4.5 arrived late last year, I’ve thought the future of software engineering would be engineers working with AI agents in natural language. The underlying code would increasingly be written and understood primarily by AI. DHH describes that shift in his Rails World opening keynote. Describing what the software should do becomes a larger part of the work, while agents handle more of the implementation.

That could eventually give us entirely new programming languages designed around agents. Rust already hints at the shift. A language can be unpleasant for a human to write and still be a great choice for the resulting software. DHH’s experience with Rust puts that tradeoff into practice: agents handle the code, while the product benefits from its performance and small executables.

I think this leads to better software. More of the effort can go toward making the product work well, including improvements that previously cost too much to justify. Engineers still have to figure out what to build and how it should work, then judge whether the result delivers that experience. Those decisions remain human work even as less of the implementation requires human hands.

Taste becomes even more important when almost any feature is within reach. Being able to build everything makes it easier to produce a product that tries to do everything, and those products tend to be poor. Good products have focus. It takes judgment to choose what belongs and discipline to leave the rest out, even when adding it is cheap.

AISoftware EngineeringProduct DesignCraftFocus
August 2026
Artifact·

A bug becoming a feature (1972 edition)

I could have fixed it, but it turned out to be important, because if you get two good players they could just volley and play the game forever. And the game has to end in about three or four minutes otherwise it’s a failure as a game. So that gap at the top, again – a feature. So that was sort of a happy accident.

“Happy” primarily in the context of the industry – the goal of an arcade game was, after all, to bring in quarters, and this here was the unexpected equivalent of the zero in a casino roulette game. But I wonder if some of this bugginess/randomness also helped the game feel challenging and surprising, even for skilled players.

unsung.aresluna.org
A bug becoming a feature (1972 edition)

A simplified circuit left a gap the Pong paddles couldn't reach. Fixing it would have let two good players volley forever.

Product DesignSoftware EngineeringConstraints
Artifact·

The backlog was always a credit card

An engineer putting a piece of work on their backlog is effectively deferring it to never. It’s important enough to write it down somewhere and document that it exists as a bug or a feature enhancement, but it’s not important enough to act.

Yes, sometimes we ambitiously carve out time to “burn down the backlog”, but do you know what we pick from that list? We pick the interesting work. Interesting to code or interesting because of the impact on the feature. Some kind of interesting briefly elevates this work to relevance. The boring backlog work? You couldn’t pay me.

I’ve avoided keeping backlogs for most of my career because they behave like debt. You put the task on the card, feel good about not losing it, then pay interest every day you don’t do it. Grooming, triage, scrolling past the same broken link for the ninth month: all payment, none of it touching the principal.

Handing the list to an agent changes what the list is for. A backlog became a graveyard because writing work down was cheap and doing it was expensive. Close that gap and it’s a queue again. I still don’t want to keep one, but I’m less sure what I hated was the list rather than the price of acting on it.

randsinrepose.com
R.I.P. Your Backlog

Backlog work is work you've decided not to do. Now there's someone willing to do it.

AISoftware EngineeringTechnical Debt
July 2026
Observation·

The second 90 percent

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

— Tom Cargill, Bell Labs, via the Ninety-ninety rule

This rule is so true it barely reads like a joke. Anyone who has shipped software has watched a project reach “almost done” and then stay there while the real work finally shows itself.

Not even AI can break it. It changes how quickly we can get through the first 90 percent: scaffolding, boilerplate, tests, happy paths, and enough of the shape of the thing that it feels almost done.

But the second 90 percent still requires human judgment. Someone has to know which rough edges matter, which tradeoffs are acceptable, and when the product is actually right.

AISoftware EngineeringCraft