Software Engineering Was Never Just Coding

“Developers will soon become obsolete because AI can write code now.”

You encounter this claim in a surprising number of variations by now. Sometimes it sounds like a forecast, sometimes like a threat, and remarkably often like marketing.

Its starting point is not entirely absurd. AI writes code. And by now it does so well enough, fast enough, and at enough scale to noticeably change software development. Coding agents implement features, generate tests, perform refactorings, search for bugs, analyze existing systems, and move across many files. Tasks that used to take me hours can now sometimes be completed in significantly less time.

I like working with it. Very much, in fact.

But faster code production does not mean that software development has been solved.

The mistake starts much earlier:

Coding is not software engineering.

What was visible was never the whole thing

Code is the most visible part of our work. It lives in the repository, can be counted, diffed, reviewed, and executed. So it is understandable that software development is often equated with writing code.

But that equation has always been wrong.

Before useful code can exist, someone has to understand what problem is actually supposed to be solved. Requirements have to be interpreted, contradictions identified, and domain relationships understood. Systems need boundaries. Data has to originate somewhere, be processed, and be stored. Components communicate with each other, external systems fail, permissions have to work, and existing data eventually needs to be migrated. Maintainability, performance, operations, and failure modes do not disappear just because a function can be implemented faster.

And at some point, someone has to decide which of the possible solutions is actually sensible under the given conditions.

All of that is software engineering.

AI does not suddenly make these things important. They always were.

What changes is something else: as code production becomes faster and cheaper, it becomes increasingly difficult to confuse it with engineering.

AI does not suddenly make software engineering more important. It always was important. It simply becomes harder to confuse software engineering with code production when code production itself keeps getting cheaper.

Perhaps that is one of the more interesting side effects of the current shift.

For decades, we have explained that lines of code are not a useful productivity metric. Now we can generate more of them in an hour than we used to in several days — and yet we are occasionally remarkably tempted to interpret that quantity as productivity all over again.

More code is, first of all, just more code. More agent runs are more agent runs. And a repository that is three times larger in the afternoon than it was in the morning has not thereby demonstrated any additional business value.

Agentic Work compresses time

The productive force of Agentic Work is still very real.

A well-formulated task with useful context, clear constraints, and an appropriate architecture can be implemented with impressive speed. An agent can apply known patterns consistently, coordinate changes across many files, and take over monotonous work where a human eventually starts wondering whether coffee should already be documented as a dependency of the build system.

This works particularly well when the destination is clear.

Unfortunately, the same is true in the other direction.

An agent can implement a false domain assumption just as consistently. It can carry a bad abstraction cleanly through several layers and wrap an architectural decision that was wrong from the start in tests, interfaces, mappers, and remarkably tidy naming.

At that point, the mistake is no longer merely wrong.

It is beautifully structured.

An agent does not protect us from bad decisions. In the worst case, it merely professionalizes their implementation.

The problem itself is not new either. Developers have always implemented incorrect requirements, built poor abstractions, and created local solutions for problems they did not fully understand.

What is new above all is the speed.

Agentic Work compresses time. Good decisions take effect faster — and bad ones do too.

That is exactly why people currently have a clear advantage when they understand more than the code directly in front of them. Someone who understands flows, system boundaries, patterns, data flows, domain relationships, and trade-offs can not only tell an agent more precisely what to do. They can also recognize earlier when its interpretation is heading in the wrong direction.

That already begins with the task itself.

Ask the wrong question, and you can get an excellent answer to the wrong problem.

And that is often more uncomfortable than an obviously bad answer. Obvious errors are noticeable. A plausible, cleanly implemented, well-tested solution to the wrong problem can travel surprisingly far.

Between 10× and “it can’t do anything anyway”

The public discussion does not exactly make it easier to deal with this technology sensibly.

On one side is the now familiar world of “10× developers,” one-person teams, and SaaS products supposedly built in an afternoon. An impressive demo is occasionally promoted straight into a new unit of software productivity.

A nice anecdote circulates on social media: a CTO supposedly proudly shared the link to an application they had just built with AI — and the link pointed to localhost:4200.

I do not know whether that ever really happened. By now it is probably more urban myth than reliable factual report. As a caricature of the current hype, however, it works beautifully.

Something starts in the browser. So apparently the product is finished.

Unfortunately, a substantial part of software engineering begins exactly where the demo ends.

How will the system be operated? What happens under load? Who is allowed to see which data? Is the data even correct? What happens during partial failures? How do we migrate existing information? What happens when the next requirement arrives? Which assumptions are embedded in the generated solution? Will anyone still understand its structures in six months? Which external systems can fail? And does the application actually solve the domain problem it was built for?

A working happy path answers surprisingly little of that.

The opposite extreme is hardly more convincing.

“AI can’t do anything anyway. I’d rather code it myself.”

Of course you can.

You can be critical of providers, consider privacy problematic, question costs, reject poor results, or deliberately do certain tasks yourself. Not every sensible use of AI has to consist of delegating as much work as possible to an agent.

But someone who declares the technology fundamentally worthless without having worked with it seriously and explored both its possibilities and its limitations is not taking a particularly neutral position.

They have simply skipped the experiment and gone straight to the conclusion.

Hallucinations do not prove that AI is irrelevant. Nor does a successful greenfield demo run prove that software engineering has been solved.

Both camps have valid arguments at specific points. The problem begins when the conclusion is fixed before the tool has actually been examined.

Between “software development is solved” and “this thing is useless” lies a much more interesting space.

That is where you actually have to work.

Verify instead of believing

A substantial part of that work is verification.

AI systems are not truth machines. An output does not become correct because it is phrased convincingly or sounds confident. Even a powerful agent can misinterpret assumptions, overlook context, invent a plausible API, or take a wrong turn somewhere along what initially looked like a reasonable decision path.

Good models can be especially convincing when they do this.

That is not an argument against using them. It is an argument for professionalism in how we use them.

Do not be careless. Verify.

Verify requirements and the assumptions derived from them just as carefully as code, tests, security, data flows, and effects on neighboring parts of the system. Above all, verify whether the resulting solution actually solves the original problem.

Generation and verification are different tasks. The fact that we can automate the first more and more does not automatically complete the second.

Tests deserve a degree of healthy suspicion as well. An agent that implements a wrong interpretation can quite easily write matching tests for exactly that interpretation. A green test run then reliably proves that code and test share the same wrong idea.

That is consistency, at least.

Unfortunately, it is not yet domain correctness.

This is why architectural rules, explicit constraints, clear system boundaries, and good tests are so valuable for Agentic Work. Not because they make agents magically infallible, but because deviations become more visible and can sometimes be checked mechanically.

The decisive question, then, is not whether we should trust AI or fundamentally distrust it.

It is: What can we verify?

Curiosity is not a hobby

To find good answers to that question, reading the occasional product announcement is not enough.

You have to use the tools.

That is why I consider curiosity a serious engineering skill. I do not mean chasing every new model name or turning your working day into a permanent benchmark. I mean building practical judgment.

Try different models and observe what happens when they get too little context or too much of it. Let agents take on larger tasks and watch when they start to drift. Compare smaller and larger models, monitor token usage and cost, and find out which tasks are surprisingly stable and which remain fragile despite repeated attempts.

Give them difficult or incomplete requirements as well. Let them fail — ideally, every now and then, in a way convincing enough that you have to look closely before noticing the mistake.

That creates a kind of knowledge no feature list can provide. Over time, you develop a feel for when follow-up questions are necessary, when constraints need to become explicit, when a task is too large, when context is being lost, and which kind of verification fits which kind of task.

Not every boundary is written down in documentation.

Some have to be experienced.

Curiosity is not playfulness in a period of rapid technological change. It is a form of risk management.

Someone who experiments learns not only what a tool can do. They also learn when not to trust it blindly.

I have been programming for almost 30 years. That does not mean I have understood all these relationships for almost 30 years. Quite the opposite: part of experience, for me, is gradually realizing which problems exist behind the visible code.

Many insights that are becoming relevant again in the context of AI are not new to software engineering at all. The discipline understood some things earlier than I did as a developer.

Experience is not simply the number of years that have passed in a career. At its best, it changes the model we have of a system: which relationships we see, which questions we ask, and which consequences of a decision we can recognize.

That kind of system understanding is enormously helpful today when an agent can suddenly accelerate a substantial part of the mechanical implementation.

Build capability, not just tooling

That is also why I do not think waiting for someone to eventually explain the definitive professional way to build software with AI is a particularly good strategy.

That manual does not exist.

Employers will not provide it completely. Universities can only keep up with such a fast-moving development to a limited extent. Certifications do not replace practical experience. Framework vendors do not know your system context. And a LinkedIn timeline is presumably still not a peer-review process.

Developers therefore have to build their own judgment — not out of fear that they might be unemployed tomorrow. That would be the same cheap prediction about the future, merely with a negative sign. Rather, because adaptability is a sensible response to uncertainty.

That means learning, experimenting, checking claims for yourself, and changing working methods when better ones emerge. It also means finding out where automation genuinely helps and where it currently only creates additional complexity.

The same responsibility lies with companies.

The current push to invest in AI is understandable. Licenses are purchased, coding agents introduced, models evaluated, compute provisioned, and agent platforms built. Much of that can make sense.

But tools are a remarkably incomplete description of capability.

Why tooling alone does not create engineering capability, and why spaces for learning are an investment, is something I developed in detail in Article 13 – The Economics of Agentic Work.

People still need opportunities to build domain knowledge, system understanding, technical breadth, and experience.

This explicitly does not apply only to junior engineers.

Ten or twenty years of professional experience do not guarantee deep system understanding. Someone who has spent twenty years working inside a narrow slice does not automatically possess twenty years of architectural competence.

Engineering capability does not emerge from tenure.

It emerges where people are allowed to build knowledge, take responsibility, understand relationships, and learn from decisions.

That is why I see a risk when companies equate investing in the future primarily with investing in automation while training, junior development, technical breadth, or spaces for learning come under cost pressure at the same time. That may improve certain short-term efficiency metrics. Whether it also improves an organization’s long-term ability to understand and evolve its systems is a different question.

An AI license is not yet engineering capability.

Anyone investing in the future of their software should therefore invest not only in models and automation. They should also invest in their organization’s ability to use these tools meaningfully, assess their results, and continue to understand the systems behind them.

Tools are part of that investment.

People are too.

The undiscovered country

And then there is the question hanging over all of this: what does it mean for our work in the long run?

I do not know.

AI is developing quickly, as are robotics and other forms of automation. It is entirely legitimate to think about what that could mean for jobs, companies, and society. But from the current state of coding agents, we can hardly derive the labor market of 2036 with any seriousness.

Perhaps new professions will emerge or entirely different working models. Perhaps some activities will disappear, others will change fundamentally, and new ones will be created. Perhaps social models that still seem utopian today will become ordinary. Perhaps many things will develop far less dramatically.

The future is undiscovered country.

That is precisely why I am more interested in what we can influence today. AI can already accelerate code production massively, and people with system understanding can currently use that leverage particularly well. Reliable agentic workflows still need context, good problem definitions, constraints, and verification. At the same time, there is no sensible reason to assume that models will remain at today’s level in exactly those areas.

All of these things can be true at the same time.

If we cannot seriously predict the future, adaptability may be one of the most sensible investments we can make today.

So I do not want to end this series with a prediction, but with an invitation: try the tools and give them real problems rather than only prepared demos. Observe their limits, understand their costs, and verify their results. Learn to ask better questions and build knowledge about your systems. Do not wait for someone else to eventually present a finished method.

We are only beginning to learn how Agentic Work functions in real software systems. We will probably discard some of today’s methods, while others will become completely normal. New models will open new possibilities — and almost certainly create new ways to take convincingly wrong turns.

So the subject is anything but finished.

Only one thought seems remarkably stable to me after all these experiments:

Software engineering was never just coding. AI did not invent that fact. It merely makes it much harder to ignore.

Perhaps AI does not make software engineering more important.

Perhaps it merely forces us to practice more consciously what has always mattered.

And while we do that, we are not only learning how to work with new models.

We are learning anew how software engineering works with them.