"Build me a great contact manager." What the AI then builds, and why that is not the system.

So, try it: type into any agent "build me a great contact manager". Five minutes later you have something that looks great. A list, a search, a form, an export, nice colours, all responsive. Show that to a decision-maker, and he says: why did that take three months with us? I work with these tools every day, and I do not want anyone to draw the wrong conclusion from it. What you get in the five minutes is not the system. It is a photo of what most contact managers on the net look like.

The sentence

"Great contact manager" says nothing. For whom? For a salesman with fifty customers or for a company with twenty thousand that sit in three systems? Which CRM does it have to talk to? What happens when two people change the same contact at the same time? Who may see what? What about data protection when someone wants to be deleted? And above all: which process actually runs here, from the first call to the invoice?

The agent does not ask that. It cannot ask, because it does not know these questions exist. It takes the sentence and builds what most probably fits this sentence. And the most probable is what it has seen most often.

What you get: the surface

What you get is a surface. In both senses: a screen that looks good, and a solution that goes no deeper than that screen. The list is there, but the data sits in a table that has nothing to do with the existing CRM. The search works, on a thousand entries, not on twenty thousand with duplicates in three spellings. The form saves, but there is no process behind it: no "who created this, who has to approve it, what happens next". It suggests a finished product. It is a demo dressed up as a product.

The average of everything that was found good

Where does what the agent builds come from? From what it has learned, and that is the net. Thousands of contact managers, tutorials, templates, example projects. The model learned from them what a contact manager typically has, and builds the mix of the best solutions found. I say it as an image, not as a measurement: you get what counts as good on the net more than eighty percent of the time. The average of the successful.

For many things that is exactly right. For a login, a form, an export I want the average of the successful, nobody needs to think about that anymore. But by definition it is no innovation. It is not the process your company needs and no other does. It is not the end-to-end thinking where someone asks what happens before the contact manager and what after, and whether you need the manager at all if you cut the process differently. Innovation is what is not yet on the net a thousand times. Exactly that the model cannot get from the sentence, because it is not in the sentence and not on the net.

Good software begins with architecture

Software development was never just writing code. Whoever has built enterprise applications over years knows the effort rarely lies in the implementation. It lies in understanding business requirements and turning them into an architecture that runs reliably, is secure and can evolve over years.

An application is not a collection of functions and classes. Which business domains are there, where are their boundaries, how do the components talk to each other? Which patterns fit, which dependencies may arise? When synchronous, when asynchronous? How do we deal with transactions, errors, data consistency? And across all boundaries: how do authentication, authorisation, secure data exchange work? Plus modularisation: clearly separated modules with defined responsibilities, so that a change in one module moves as little as possible in the rest. That sounds self-evident. In practice it is the hardest thing in the whole profession.

The hundredth change is the test

Building a system is one thing. Maintaining it over years and extending it constantly is quite another. How fast can a new function be integrated? Do five other components have to be touched for it? Do new dependencies arise? Is there a risk of damaging something else? In a cleanly cut architecture most extensions are targeted and manageable. In a badly structured one, at some point every small change becomes a project.

The AI knows the patterns. Does it stick to them?

Modern models know practically all architecture concepts. They can explain domain-driven design, design microservices, apply patterns. That is impressive. But knowing a concept and consistently adhering to it over the whole lifetime of a system are two different things.

An agent can implement a function correctly and damage the architecture in the process. It creates a direct dependency between two domains that should only talk through an interface. It duplicates a function that already exists, because it does not see it in its excerpt. It builds a solution that works and bypasses a security rule in doing so. The dangerous part: nobody notices. The application runs, the tests are green, the function is there. Only at the next extension do you notice the system has become unnecessarily complicated. I described that with the giant classes, and I saw it live a week ago when an agent overwrote 169 files because it wanted to deliver.

The real problem: the lost context

Here lies, for me, the biggest weakness of today's tools. An agent works with what it currently sees. As long as it knows the connections, it delivers very good results. But an enterprise system consists of far more than the code it is currently analysing: business rules, architecture decisions, historical dependencies, security concepts, integrations with other systems. Much of that is not documented and not in the code.

On top of that, agents do not keep their context unlimited. Information gets summarised, displaced, is gone in the next session. The agent then no longer knows why two domains were strictly separated. It builds a solution that looks sensible for its task and contradicts the overall concept. With every change come dependencies, duplicates, structural problems. That is how AI produces technical debt without anyone noticing, and faster than humans ever could. A big context window does not solve that. The knowledge has to live outside the window.

First understand, then change

I am convinced agents will take over whole work packages in future, from analysis through implementation to tests and documentation. For that to work reliably, you have to proceed differently. It is not enough to give an agent a repository and say, build this in. And it is certainly not enough to give it one sentence and look at the screens.

That is exactly the approach at NeoCoder: not how AI generates code faster, but how agents understand an existing system and keep developing it reliably over years. Only when the knowledge about a system is preserved and the architecture rules are checkable does the foundation for more autonomy hold. Without that, every great contact manager becomes, in two years, the system nobody wants to touch anymore.

What stays

Of course it is impressive when an agent builds in minutes what took a developer hours. But the saving is worth little if you later need a multiple of it to correct the dependencies that arose. That is why we should not measure productivity in lines of code or completed tasks, but by other questions: how fast can new requirements be implemented? How stable does the architecture stay? How high is the maintenance effort? How do quality and complexity develop over time?

Recently I read again that we were never paid to write code but to solve problems. At its core that is true. But the real achievement is not finding a working implementation for a problem. It is building a solution that fits into an existing system, respects its architecture and remains easy to maintain and extend in future. The five minutes cannot do that. Not because the model is bad. Because nobody told it what the system is, and because the sentence did not contain it.