AI Gave Me Everything I Asked For, or How I Overengineered My Way into Building Forever

Over the past few days, I have spoken with dozens of people who are trying to understand what to do with artificial intelligence.

Some are students. Some have jobs. Some want to start a business. Many say they want to build an agent or a second brain. But when I ask what the agent should actually accomplish, the answer often becomes vague.

They have seen the videos. They know the vocabulary. They can talk about agents, memory, automation and orchestration. They are excited by the architecture of a future project, but they do not yet have a problem they are determined to solve.

At first, I thought this was simply the usual gap between consuming content and doing the work. Then I realised I recognised the behaviour because I had spent the previous month and a half doing my own, much more sophisticated version of it.

I was not watching tutorials and imagining a project. I was building real systems. I had code, infrastructure, tests and working software. I was shipping almost every day.

And I was still stuck.

That is the uncomfortable part. The trap does not always look like procrastination. Sometimes it looks exactly like serious work.

AI removed the friction, not the responsibility

Before AI coding tools, complexity had a natural cost. Every new abstraction, validation layer and automated check required enough manual effort that you were forced to ask whether it was worth building.

That friction has largely disappeared.

Now I can describe a sophisticated mechanism and watch it become code. I can ask for another test, another safeguard, another agent, another recovery path. Each request may be reasonable. Each addition may improve the system in isolation. And because the work is happening so quickly, it feels like progress.

But AI did not remove my responsibility to decide what the product needed.

It only removed many of the practical limits that used to stop me from building too much.

This creates a new failure mode: we can now construct unnecessary systems at a speed that feels productive.

The static website I could not add a company to

I ran into this while building Agent Company Index, a directory of companies working with AI agents.

The basic product is not difficult to explain. A company should be able to submit its website and services, pass the necessary checks, and appear in the directory.

At some point, however, that simple path became surrounded by more than a thousand automated checks. There were validations, hashes, integrity rules, tests for tests, and safeguards for situations that had not happened yet. Every layer made sense when I looked at it individually.

Then I tried to onboard my own company.

It took me two days, and I still could not make it work on the first attempt.

This was a static directory. I was the owner. I understood the code. I had built the process. Yet the architecture had become so demanding that I could not perform the product’s most basic action.

That is when the contradiction became impossible to ignore.

I had built a system that was increasingly good at protecting its own structure and increasingly bad at letting a person use it.

The architecture was no longer supporting the product. The product was servicing the architecture.

The AI did not make the mistake

It would be convenient to blame the coding agent.

I cannot.

The AI did what I asked. More precisely, it did what I repeatedly approved.

It knew how to build validations. It knew how to increase test coverage. It knew how to make the pipeline more rigorous. When I requested a new protection, it could explain why that protection was a good engineering practice and implement it competently.

The problem was not that the AI produced the wrong answer.

The problem was that I had not defined the boundary of the answer.

An AI system can be excellent at answering “How do we make this more robust?” while never asking the more important question: “Is this already sufficient to help one person complete the job?”

That remains the operator’s responsibility.

AI knows an enormous amount about how software can be built. It does not automatically know how much software your idea deserves today.

The missing skill is knowing where to stop

People often describe AI literacy as knowing how to write prompts, choose models or connect tools. Those skills are useful, but I increasingly think the more important skill is learning to define “enough.”

What must be true before a first version can meet reality?

Which failure would be genuinely dangerous, and which one would merely be inconvenient?

What evidence are we waiting for before adding another layer?

At what point does improving the system produce less value than showing it to a user?

These are product questions, not coding questions. AI can help us examine them, but it cannot take ownership of them.

If I do not know what done looks like, the model will not run out of ways to continue. There is always another edge case. There is always a cleaner abstraction. There is always a more complete test suite, a more flexible architecture, a more autonomous agent.

The construction can continue forever.

The same trap exists before the first line of code

The people I spoke with are often at an earlier point in the same loop.

They want an agent, but have not chosen a task. They want a second brain, but have not built a habit of producing or using knowledge. They are collecting tools for a version of themselves who will begin serious work later.

This is not stupidity. It is a predictable response to the way AI is presented online.

The most visible content shows possibility. It gives us the exhilarating sense that one person can build a company, automate a profession or create a digital workforce. What it rarely shows is the ordinary work of choosing one problem, testing one outcome and discovering that the impressive architecture was not necessary.

Hype makes preparation feel like participation.

You can spend weeks learning about agents without delegating one useful task. You can design a knowledge system without having knowledge you need to retrieve. You can watch people build businesses while remaining a permanent student of business.

There is nothing wrong with learning for its own sake. The problem begins when learning becomes a convincing substitute for deciding and doing.

A better order of operations

I am not abandoning Agent Company Index. I still believe in the idea. I have already started removing the things that do not help the central action, and I will continue developing it.

But I am changing the order in which I earn complexity.

For my own work, the sequence now looks like this:

Name the human result. Not “build an agent,” but “a company can submit its information and appear in the directory.”
Complete one real path. Not a mock, not a diagram, not a successful test in isolation. A real person reaches the intended result from beginning to end.
Notice the actual failure. Let reality show where the system breaks before designing protection against every imaginable future.
Add the smallest correction. Fix the observed problem without turning it into a platform for all possible problems.
Repeat only while the result improves. Architecture is justified by what it enables, not by how professional it sounds.

This does not mean removing all tests or ignoring security. Some risks deserve protection before the first user arrives, especially when money, personal data or irreversible actions are involved.

It means matching the protection to the evidence and the stage of the product.

A prototype needs to answer whether the idea is useful. A production system needs to remain dependable under real use. Confusing those stages can make the prototype so elaborate that it never gets the chance to teach us anything.

Use AI to shorten the distance to reality

I still think artificial intelligence is one of the most powerful technologies available to an individual.

It allows us to turn an idea into something testable with extraordinary speed. It can help a person cross disciplines, challenge assumptions and produce work that once required a team. I have experienced that leverage directly, and I do not want to go back.

But speed only helps when it shortens the distance to reality.

If it shortens the distance to another abstraction, another internal system or another month of preparation, it can make us more efficient without making us more effective.

That is the trap of eternal development. You are always moving. The commits accumulate. The system becomes more intelligent. The work becomes harder to explain. Yet the first useful result remains exactly where it was.

The hardest question in AI-assisted building is no longer “Can we make this?”

For a growing number of ideas, the answer is yes.

The harder questions are: “What is this supposed to change, and how will we know when it has changed?”

Without those answers, AI gives us the ability to build forever.

With them, it gives us something much more valuable: the ability to find out what is worth building.

If you want more field notes about using AI in real work, without turning every new tool into a new religion, join the newsletter below.

← All notes