Every few weeks someone asks me whether AI is going to replace engineers. It is the wrong question, and answering it honestly matters more to me than usual, because I spend my days building a platform whose entire job is to run AI agents in production.
I founded Capellaris in March 2025. It is a multi-tenant platform for managing AI agents specialised in different business areas — marketing, finance, legal. The agents talk to each other, form squads on demand, and keep learning from what they are given. Underneath there is an orchestration layer built on CrewAI and MCP, hybrid retrieval over pgvector and BM25, and a unified abstraction sitting in front of Claude, OpenAI and Gemini so no single model vendor owns the product.
I have every commercial reason to tell you these systems are close to autonomous. They are not, and the gap is not the kind that closes with a bigger model.
What agents are genuinely good at
The honest answer is throughput. Agents are very good at the work that is well specified and tedious: pulling the right five documents out of ten thousand, drafting the first version of something, triaging a queue, translating an intent into an API call, holding more context than a person can hold at once.
That is not a small category. A large share of knowledge work is exactly this. When you automate it properly the effect is real — not "the AI did my job" but "the eight hours of preparation before the decision became forty minutes."
The interesting part is what happens to the forty minutes that are left. They get harder.
Where they stop
A model will happily generate ten plausible directions for a product. It cannot tell you which one is worth building, because that judgement is loaded with context that never makes it into the prompt: what this particular customer actually meant as opposed to what they asked for, which internal team will quietly refuse to adopt it, what you will regret having committed to in two years, whether the thing is honest.
This is the part people call taste, and calling it taste makes it sound decorative. It is not. It is the load-bearing decision. Producing options is now nearly free; choosing between them is the entire job, and it is the one part that has not got cheaper.
AI collapsed the cost of producing options. It did nothing to the cost of choosing between them.
There is a second failure that is quieter and more dangerous. Agents optimise for what you measured. If your evaluation rewards answers that look complete, you will get answers that look complete. Nobody in the loop is asking whether the user is better off — that question has no gradient.
The evaluation trap
On Capellaris I run the full MLOps lifecycle: prompt versioning, model evaluation, observability through Cloud Logging, continuous delivery on GitLab CI/CD. This machinery is not optional. If you ship LLM features without it you are flying blind, because a prompt change can degrade quality in a way no unit test will catch.
But it is worth being precise about what evaluation buys you. It catches regression — the new version is worse than the old one on cases you already thought about. It does not catch wrongness of direction — the whole feature is a well-executed answer to a question nobody asked.
Evaluation tells you whether the system got better at the thing you told it to do. It has nothing to say about whether that was the right thing. Only a person who understands the customer can answer the second question, and no amount of tooling removes them from the loop.
What this means for how you build
Once you accept that, the architecture follows. You put humans at the two boundaries and let the agents own the middle.
- Scoping in. A person decides what problem the agent is pointed at, and what "good" means for this customer. That framing is the highest-leverage decision in the whole system and it is made before any token is generated.
- Execution. The agents run. Retrieval, tool-calling, drafting, chaining. This is where you want maximum throughput and minimum human involvement, and where the orchestration layer earns its keep.
- Accepting out. A person decides whether the output actually helps somebody. Not whether it is well formed — whether it helps. This is where most AI products quietly fail, because it is the step teams are most tempted to automate away.
Note that agent orchestration and agent autonomy are different things, and the industry uses them interchangeably. Orchestration means many specialised agents coordinating on a task you defined. Autonomy means nobody defined the task. I build the first one on purpose.
What that looks like in practice
Capellaris has a pilot enterprise customer running in production. The most useful thing I do for that account is not model work. It is sitting with them to scope requirements, supporting the integration, and iterating the product on what they tell me afterwards — technical account management, in plain terms.
The platform is the accelerator. The relationship is where the product actually gets decided. If I removed myself from that loop and let the agents infer what the customer needed, I would ship faster and build the wrong thing faster.
So, will it replace engineers
It will replace the part of engineering that was already mechanical, and that part was never where the value was. What it leaves behind is a job that is more concentrated and less forgiving: deciding what to build, judging whether it worked, and taking responsibility for the answer.
That is a harder job than the one it replaces. It is also a better one.