We Don't Write Code Anymore — Now What?

Every time someone announces the end of programming, they reveal how much of programming they thought was typing.

Writing code was always the small part. If you keep an honest tally of a normal week —understanding the problem, arguing with product, reading someone else’s code, designing, reviewing PRs, chasing a data bug, writing the migration, watching dashboards after the deploy— the stretch with your hands on the keyboard producing new lines is a modest fraction. We automated it and everything else was left exposed, and none of it was ever optional.

The bottleneck moved, it didn’t disappear

Before: producing the implementation was expensive, reviewing was cheap.

Now: producing is almost free, and reviewing is the new bottleneck. An agent hands you 800 lines in four minutes and the team takes three days to trust them. The overall speed of the system isn’t set by whoever writes, it’s set by whoever approves.

This has uncomfortable practical consequences: giant PRs are no longer a sin of personal discipline, they’re the tool’s default mode. If your process depended on writing being slow, your process is already broken and you haven’t noticed yet.

The three things that now concentrate the value

Specifying. An ambiguous requirement used to produce two wasted weeks; now it produces two wasted weeks in half the time. People who know how to turn “we want something like Uber but for bookings” into verifiable acceptance criteria are worth more than ever, because those criteria are now literally the machine’s input.

Verifying. Tests, types, contracts, invariants, staging environments that look like production. Everything that turns “seems correct” into “is correct without me reading all of it”. Teams with good verification sped up; the ones reviewing by eye sank into review.

Deciding. What to build, what not to, what to delete, which debt is acceptable, what couples to what. None of those questions has an answer that can be generated without knowing the business, the people and the three previous attempts that failed.

Architecture matters again (ironically)

When code is cheap, structure is the expensive part. A system with clear boundaries lets an agent work in one module without breaking four others; a tangled monolith turns every change into roulette.

Put another way: modularity stopped being an aesthetic preference and became an operating condition. The blast radius of an automated change is exactly the size of your worst coupling.

What didn’t change at all

Somebody is still responsible when the system goes down. That person can’t say “the model wrote it” and sleep easy. Delegating the writing doesn’t delegate the responsibility, the same way an architect doesn’t blame the excavator.

So, what do we do now?

The same thing we always said we did and rarely had time to do well: understand the problem, define the contract, design the solution, verify it and operate it.

The joke is that the industry spent twenty years calling “software engineering” writing code, and right when writing code got automated, we had to learn software engineering.