The rift, of course, is whether you’re building load-bearing software or not.
Line-by-line comprehension is not going anywhere in load-bearing software. Just like it's going nowhere in law, gene editing, or structural engineering.
Sure, many lines of software are boilerplate/ceremonial. But other lines carry all the weight. The `if` clause that determines if the user has permission to operate on the record. The math behind the withdrawal. The `org_id` filter in the SQL statement. Grabbing a mutex before operating on a shared data structure.
“Codex did it” in the incident post-mortem will not fly with your customers. Ultimately, a person needs to be responsible. This would be the case even if the LLMs weren’t as jagged as they are; they have no skin in the game. A person does.
In some software, the stakes and dependencies are low. A Rails blog is fungible across the board. All that really matters is that it looks good, the articles load, the user can navigate the site and make comments. An LLM or a person can achieve each of those things a thousand different ways. Human or machine verification is relatively trivial.
But in most load-bearing software, the stakes and dependencies are high. Precision is paramount. And verification is often difficult; there are just too many possible states and transitions.
Claude can help you change that function to support the new requirement. It can even help you change all its call sites, a previously tedious task. But a person *absolutely* needs to understand what change has taken place, how dozens or hundreds of dependencies will be affected, whether a rollout plan is necessary, etc.
The agent can sum up the change for you. But often for important lines, simply *seeing the code* is the highest-bandwidth way to transmit information about the change. Let alone the most precise.
The lines of code were always a means to an end. The important part has always been the business logic.
And logic is incompressible beyond a point. The reason programming languages will never go away is that your system needs contractual statements an organization can agree on: “this user shall be able to do X, but only if Y and Z.” Those statements often need to be highly precise and deterministic.
Perhaps the right mental model, then: this leap is like going from writing a web app in assembly to writing it in Rails. Rails eliminated a ton of ceremony. But it did not eliminate the need to understand the important bits of your code. LLMs likewise give us incredible ability to operate on these codebases, often akin to using an excavator instead of a shovel. But the contracts are still there, they're still very important, and we're still very responsible for them.
this thread is what mass cope from legacy devs looks like.
i talked to
@FastCompany about why
@garrytan's "AI slop" is actually the future of software engineering.
the mass code review. the line-by-line gatekeeping. the "craftsmanship" that was really just slow iteration disguised as rigor - that era is over.
and the engineers who built their entire identity around it are panicking.
@gregorein brags about burning 3 billion tokens last year while dunking on garry for flexing lines of code. i've burned 6.6 billion in the past three months on codex alone. by his own logic, i'm 8x as credible.
see how silly that sounds?
yes, he found real issues. yes, they got fixed. that's exactly the point.
karpathy's autoresearch proved this already - AI agents can solve very complex problems just by operating inside feedback loops, iterating to optimize a loss function.
this is what software engineering is now - gradient descent.
ship, measure, self-correct, repeat.
all by the agent itself.
this is the new startup playbook.
your job isn't to review every line before deploy. your job is to build systems where agents observe outcomes - mrr, analytics, error rates, user behavior - and self-improve.
the engineer's role shifts from gatekeeper to building the machine that builds the machine.
you could run this level of audit (using AI) on any production site and find the same issues - most just don't have a billionaire CEO attached for virality.
mocking the people who adapted is easier than adapting.
but the craft is evolving whether you like it or not.