Every few weeks someone asks me whether AI is going to replace engineers. I spend my days building a platform that runs AI agents in production, so I have a stake in the answer, and I think the question is framed wrong.
I founded Capellaris in November 2024. It's a multi-tenant platform for managing AI agents specialised in different business areas, such as marketing, finance and legal. The agents talk to each other, form squads on demand, and keep learning from what they're given. Underneath there's an orchestration layer built on CrewAI and MCP, hybrid retrieval over pgvector and BM25, and one abstraction in front of Claude, OpenAI and Gemini so that no single model vendor owns the product.
I have every commercial reason to tell you these systems are close to autonomous. They aren't, and I don't think a bigger model closes the gap.
What agents are good at
Throughput. Agents handle well-specified, tedious work very well: pulling the right five documents out of ten thousand, drafting a first version, triaging a queue, turning an intent into an API call, holding more context than a person can keep in their head.
A large share of knowledge work looks like this, and automating it properly has a real effect. The eight hours of preparation before a decision become forty minutes. What's left in those forty minutes is harder than before.
Where they stop
A model will happily generate ten plausible directions for a product. It can't tell you which one is worth building, because that judgement depends on context that never makes it into the prompt: what this customer meant as opposed to what they asked for, which internal team will refuse to adopt it, what you'll regret committing to in two years, whether the thing is honest.
People call this taste, which makes it sound decorative. In my experience it's the decision everything else rests on. Producing options is now nearly free. Choosing between them costs what it always did, and that's most of the job.
AI made producing options cheap. Choosing between them costs as much as it ever did.
The second failure is harder to see and more dangerous. Agents optimise for what you measured. If your evaluation rewards answers that look complete, you get answers that look complete, and nobody in the loop asks whether the user is better off. That question has no gradient.
What evaluation can and can't tell you
On Capellaris I run the full MLOps lifecycle: model integration, prompt versioning, evaluation, observability, and CI/CD with GitHub Actions. You need this machinery. A prompt change can degrade quality in ways no unit test catches, and without evaluation you won't see it happen.
Evaluation catches regression, where the new version does worse than the old one on cases you already thought about. It doesn't catch a wrong direction, where the whole feature is a well-executed answer to a question nobody asked.
Evaluation measures whether the system got better at the task you gave it. Whether that was the right task is a question for someone who understands the customer, and no tooling removes the need for that person.
What this means for how you build
Once you accept that, the architecture follows. People sit at the two boundaries and the agents own the middle.
- Scoping in. A person decides what problem the agent works on and what "good" means for this customer. It's the highest-leverage decision in the system, and it happens before any token is generated.
- Execution. The agents run retrieval, tool calls, drafting and chaining. Here you want maximum throughput and as little human involvement as possible. This is the work the orchestration layer exists for.
- Accepting out. A person decides whether the output helps somebody. Checking that it's well formed is easy; checking that it's useful isn't, and this is the step teams are most tempted to automate away. I think it's where most AI products fail.
The industry uses agent orchestration and agent autonomy interchangeably, and they're different things. Orchestration is many specialised agents coordinating on a task you defined. Autonomy means nobody defined the task. I build orchestration on purpose.
What that looks like in practice
Capellaris was piloted with three small businesses (an independent consultancy, a restaurant and an art atelier) plus internal use. The most useful work I do for those customers has little to do with models. I sit with them to scope requirements, support the integration, and change the product based on what they tell me afterwards. In plain terms, it's technical account management.
The platform speeds things up, and the product gets decided in that relationship. If I stepped out of the loop and let the agents infer what the customer needed, I'd ship faster and build the wrong thing faster.
So, will it replace engineers?
It will replace the part of engineering that was already mechanical, which was never where most of the value sat. What's left is a smaller and less forgiving job: deciding what to build, judging whether it worked, and owning the answer. I find it harder than the job it replaces, and I like it more.