AI Regression Is a Software Problem
When an AI workflow suddenly behaves worse after weeks of success, the problem is rarely mood. It is usually missing ...
Software Has Always Moved Up the Stack
9 min read
The Work Did Not Vanish. It Moved.
29.08.2026, By Stephan Schwab
AI coding agents extend a long history of abstraction. They make syntax, scaffolding, search, and first-draft changes cheaper, but they do not remove the difficult questions: what should change, what must remain true, which exceptions matter, how the result is tested, and who owns the consequences in production. As systems gain power, judgment above the new layer becomes more valuable, not less.
The idea that software development is mainly typing has always been a misunderstanding caused by looking at the wrong layer.
Typing used to be much more painful, certainly. There were physical switches, machine instructions, punched media, fixed-width fields, compiler complaints that made no attempt to be charming, and enough accidental complexity to turn a small mistake into an afternoon. Removing that friction mattered.
It still does.
But every successful abstraction removed a class of work so people could make more consequential decisions above it. The details did not disappear. They became somebody else’s reliable machinery, until they leaked again and demanded attention.
AI coding agents are the latest example. They are neither a supernatural rupture nor a fancy autocomplete. They are a new interface to the stack. That distinction matters, especially for companies now treating a successful demo as evidence that software responsibility has become optional.
Zuse Started With the Machine Itself
The abstraction that made the Z1 useful was simple: a machine could follow a program at all.
Konrad Zuse completed the Z1 in 1938. It was a freely programmable mechanical machine built around binary switching elements, with an arithmetic unit, memory, input and output, and a program reader. The reconstructed machine at Berlin’s Deutsches Technikmuseum is a useful corrective to the smooth history people tell themselves about computing: before software became invisible, it was painfully physical. The museum’s Z1 history is worth seeing for that reason alone.
At that level, the person programming did not get to pretend that logic was separate from machinery. Data representation, control flow, memory, input, and output were all close enough to touch. A program was not a product brief. It was an explicit instruction sequence for a specific physical apparatus.
That was not a golden age. Nobody sensible wants to go back to it.
It was the baseline. Each following layer pushed some machine detail beneath a more useful vocabulary. That is what abstraction means when it is doing its job: not hiding reality, but making a stable part of reality safe to stop thinking about every minute.
COBOL Put Business Language Into Code
COBOL did not eliminate programming. It made business logic legible enough to become infrastructure.
The committee that formed in 1959 to create COBOL wanted a common business language with readable programs and as much machine independence as possible. That was an ambitious and practical aim, not a naïve one. The Computer History Museum’s account makes the intention clear: business data processing needed a language that could outlive one machine and one vendor.
COBOL moved the conversation upward. Instead of speaking mainly in machine operations, a program could talk about records, reports, accounts, and payroll. Grace Hopper helped define that direction. The result became one of the most successful languages in business computing, because businesses do not run on algorithms in the abstract. They run on names, categories, rules, exceptions, and ledgers that somebody eventually has to encode.
The important part is what did not happen.
COBOL did not make business systems simple. It made it possible to express vastly more business logic, on a scale that outlived teams, hardware generations, and management fashions. The source could look closer to the business while the actual system grew into a dense dependency that paid salaries, moved money, and kept governments functioning.
The abstraction worked. The responsibility moved. A developer did not need to manage every machine instruction, but still had to understand the business rule that would be wrong for ten thousand customers if one field were interpreted badly.
That is the pattern that keeps coming back.
Object Orientation Gave Structure a Name
Objects promised a way to talk about a system through its responsibilities instead of its exposed machinery.
By the time Simula and then Smalltalk shaped object-oriented programming, the problem had shifted again. Programs were no longer only difficult because machines were awkward. They were difficult because the software itself had become large enough to defeat a single person’s working memory.
Simula made classes and objects central concepts. Smalltalk pushed the idea further through objects, messages, and a live environment. That did not solve design. It gave design a better language.
A well-chosen object can hold state and behavior together. It can reveal what a part of the system is responsible for while hiding implementation details that other parts should not casually depend on. That is a useful abstraction. It lets a developer reason about a customer, an invoice, a booking, or a pricing rule without constantly dragging every database column and control branch into view.
And, because people are people, object orientation also produced oceans of decorative class diagrams, inheritance hierarchies shaped like family trees from a bad royal drama, and abstractions whose only responsibility was making a simple change take three meetings.
The abuse does not invalidate the idea. It proves the point. Higher abstraction gives people more leverage, including the leverage to create elaborate nonsense faster. The scarce skill was never knowing the word “encapsulation.” It was deciding which boundary clarified the system and which one merely hid confusion behind a respectable noun.
Ward Cunningham’s work on shared understanding sits in this tradition. The goal was not to produce more vocabulary. It was to make the vocabulary answer to the work.
Frameworks Retired Repetition, Not Judgment
Once languages, operating systems, libraries, and object models had absorbed more of the old mechanical work, frameworks went after repetition.
Do not wire every request by hand. Do not build every database mapping from scratch. Do not write the same authentication scaffolding for the twentieth time. Do not make every team rediscover how to package, deploy, log, and monitor an ordinary service.
Good. That is what mature tools are for.
The framework era sometimes produced the same delusion that now surrounds AI: if the tool handles more, perhaps the people can understand less. That logic gave us companies that bought a stack before defining the product, architecture diagrams treated as a substitute for operational ownership, and teams who could create services at speed but could not explain where a business rule lived.
The useful response was never to reject frameworks and write everything from scratch like a historical reenactment society. The response was to recognize where the work had moved.
If Spring handles routine enterprise plumbing, the developer’s question becomes whether the service boundary makes sense. If a cloud platform handles infrastructure primitives, the question becomes what must be observable, recoverable, secure, and owned. If a web framework handles rendering and routing, the question becomes whether the workflow helps a real person get something done.
The stack rises. The decisions get fewer, larger, and more expensive to get wrong.
AI Agents Move the Interface Above Code
An AI coding agent changes a repository from something you only edit into something you can interrogate, direct, and verify.
Code completion was already a small abstraction: a tool guessed the next few tokens so the developer typed less. An agent is qualitatively different because it can work across a task. Modern coding agents can read files, search a codebase, consult documentation, edit code, run checks, and adjust when a check fails. VS Code’s agent documentation describes that loop plainly.
The new working unit is no longer only a line or a function. It is an intention plus constraints plus evidence.
“Add support for this customer rule, keep the existing contract, update the tests, and show me what changed” is not a request for syntax. It is a request to operate at a higher level of the stack. The agent carries out a chunk of the translation work between that request and the repository.
That is real leverage.
It is also why the phrase “AI writes the code, so we no longer need developers” is so childish. The hard part has moved further away from typing, not disappeared into the model. Someone still has to decide whether the customer rule is coherent, whether the existing contract is worth preserving, whether the test proves behavior instead of ceremony, and whether the change belongs in the system at all.
The agent can propose answers. It cannot make the organization responsible for them.
Tests beat instructions for AI coding agents for exactly this reason. A long prompt can describe what the team hopes will happen. An executable test gives the agent a boundary it cannot talk its way around.
The New Failure Is Faster Confidence
The old failure mode was slow development. A company could spend months translating vague intent through meetings, documents, tickets, handoffs, and code before anyone saw that the premise was incoherent.
AI makes a different failure easier.
Now an operations lead can describe a workflow in a chat window, receive a working screen, connect a real data source, and demonstrate a happy path before the steering committee has finished naming its subgroups. That is impressive. It is also the moment when an organization is most tempted to confuse visible output with understood behavior.
A workflow does not stop being software because it began as an operations request. Once it joins real data, changes a customer record, or triggers an approval, somebody owns its behavior in production.
What happens when the data is incomplete?
Who is allowed to change the rule?
What is the rollback path?
Which action needs approval?
What must be logged?
How does the team know that tomorrow’s version still does the thing the demo did today?
Those questions are not leftovers from an older craft. They are the work that remains after the craft has become more powerful.
The danger is not that AI agents produce rubbish. Often they produce plausible, useful work. The danger is that they produce it so quickly that people without a model of software consequences get promoted from spectator to system owner before they know the difference.
The Stack Needs People Who Can Stand Above It
Every layer in this history carried a promise of relief.
Zuse’s machine turned calculation into repeatable mechanical steps. COBOL turned business processing into a language that could travel. Object orientation gave complex systems names and boundaries. Frameworks turned repeated technical chores into conventions. AI agents turn more of the translation between intent and code into an executable conversation.
Take the relief. Use the tools. Nobody gets a medal for polishing the lower layers by hand.
But stop making the same managerial mistake each time: treating an abstraction as proof that understanding is no longer necessary.
Abstractions do not abolish complexity. They concentrate it at the point where choices become visible. The lower-level detail is still there, waiting for the day an assumption breaks. The organization still needs people who can trace from a business request through code, data, integrations, deployment, and operational consequences without pretending one of those layers is someone else’s problem.
That is what serious developers become more of in the age of agents, not less.
The Z1 operator had to think about the machine. The COBOL developer had to think about business rules. The object-oriented developer had to think about boundaries. The AI-assisted developer has to think about the whole system—and now has fewer excuses to hide behind typing.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
Where Roads Give Up
Mateo announces a drive into the forest. Nobody asks where or for how long. The road becomes a track, the track becomes mud, and the mud becomes a ...
Contrasts
Preston Hale, Graham Whitaker, and Derek Lawson sit behind closed doors turning failure into vocabulary elegant enough to survive their consciences...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- Software Has Always Moved Up the Stack (29.08.2026)
- SPAs Made i18n Harder Than It Had to Be (26.08.2026)
- AI Regression Is a Software Problem (22.08.2026)
- Your Website Must Be Open for Business (20.08.2026)
- The AI Workshop Will Not Ship (18.08.2026)