Agentic Engineering
Before you start the next AI pilot
You want AI agents in production? Good idea, because this is where a lot is being decided right now.
Agentic engineering means AI agents take over entire steps of software work, not just single code suggestions. They read a legacy system, write a specification, generate code inside defined limits and check the result against rules a human set beforehand.
What most people underestimate: the model is rarely the problem. The problem is deciding which work you hand to agents at all, who defines the guard rails, and how your team works with them without losing control over its own codebase.
I come from product management and have worked as an interim and fractional product manager since 2024. My own projects run on a setup of several AI agents, and together with two partners I am building a proof of concept for agentic legacy rewrites. So I am not writing about agentic engineering, I work with it every day.
TL;DR:
- Agentic engineering is not a tool, it is a way of working: clarify, set rules, let it generate, validate.
- The bottleneck is rarely the model. It is the missing specification and the missing guard rails.
- I bring product leadership instead of slides: I work inside your team's daily routine.
- Start with one bounded use case, not with a transformation agenda.
- For implementation I bring in development capacity from my network.
What is agentic engineering?
Agentic engineering is building software with AI agents that carry out multi-step tasks on their own while staying inside rules a human owns.
The difference to a chat assistant: an agent gets a goal instead of a question. It plans the steps, uses tools like editor, terminal, repository and test suite, and delivers something you can verify. An assistant suggests code. An agent builds, tests and corrects.
In practice this runs in four phases. The order is the actual trick: start at phase three and you get a lot of code very fast that nobody wants to own.
This approach has a name: spec driven development. The specification is the deliverable the code grows out of, not documentation written afterwards. A person stays at every handover in the process, which is what human in the loop means. How much autonomy an agent gets is therefore not a technical setting but a question of how much review you can actually sustain.
The four phases in practice
- Clarify: understand what the existing system really does and turn that into a specification.
- Define: set architecture and guard rails before a single line is generated.
- Generate: produce code in small, testable units.
- Validate: check at every transition, not only at the end.
Agentic engineering, vibe coding, prompt engineering: what is the difference?
Prompt engineering optimises a single request to a model. Useful, but it ends after one answer.
Vibe coding is building fast by conversation, without a specification. Great for a weekend prototype, risky for anything somebody has to maintain afterwards.
Agentic engineering is the counter-model: agents work in multiple steps, but inside guard rails a human has set, and every result is checked against the specification.
Short version: vibe coding creates speed. Agentic engineering creates speed you can still maintain in two years.
Agentic engineering, vibe coding and classic development compared
| Classic development | Vibe coding | Agentic engineering | |
|---|---|---|---|
| Specification | ticket or PRD | emerges in conversation | explicit, often reconstructed from the legacy system |
| Who writes the code | humans with autocomplete | the model, on request | agents inside guard rails |
| Validation | code review and tests | a look at the result | at every transition, against the specification |
| Speed in week one | normal | very high | slow, because clarification comes first |
| State after twelve months | maintainable | usually not maintainable | maintainable as long as the rules are kept up |
| Good for | anything business critical | prototypes and throwaway code | legacy systems, migrations, repetitive work |
From practice: my own setup
My own projects run on a Mac mini that stays on around the clock. It runs several Claude Code sessions in separate project contexts, controlled through Discord so I can hand over a task while I am out and pick it up at my desk later.
What I learned from it is in no vendor brochure: the work shifts from typing to reviewing. And the hard question is not whether an agent produces code, but how it knows that it is done. That is exactly where my first setup failed.
I wrote the whole thing up, including the mistakes: I gave my Mac mini a Discord account. What worked when rebuilding legacy systems and what did not is here: Rebuilding legacy software with AI agents.
Where agentic engineering holds up today and where it does not
It holds up for: repetitive work with clear rules, migrations and rewrites with a defined target, catching up on test coverage, generating documentation from existing code, analysing large codebases.
It does not hold up for: product decisions, anything without a specification, systems with no test coverage that nobody understands any more, and any task where a wrong result costs more than the time saved.
My assessment after several months: the gain is real, but it does not come from generating. It comes before that, from clarifying, and after that, from validating. Speed up only the middle part and you move the bottleneck instead of removing it.
Who benefits from agentic engineering
- Software companies with legacy systems where the knowledge sits in a few heads and every change is expensive.
- Product teams under delivery pressure whose backlog grows faster than their capacity.
- Mid-sized companies with in-house development that want AI beyond the marketing department.
- Executives who need a solid assessment before releasing a larger budget.
- Teams already experimenting, but without shared rules.
What you get out of it
- An honest assessment: which of your tasks are worth it today and which are not.
- Guard rails instead of sprawl: rules that agents and humans both follow.
- A team that comes along: I work in the daily routine instead of handing over a recommendation and leaving.
- Traceable results: every generation is documented and reviewable.
- No lock-in: the way of working stays with you after I am gone.
What a first engagement looks like
- Readiness check, 1 to 2 weeks: I look at codebase, processes and team and tell you which two or three use cases are worth it and which ones you can skip.
- Pilot with one team, 4 to 8 weeks: one bounded use case, together with your developers, including guard rails and documentation.
- Legacy rewrite as a proof of concept: one module of your legacy system rebuilt along the four phases, implemented together with my partners.
- Interim product leadership: I take product responsibility for a defined period and introduce the way of working while the business keeps running. More on my interim product manager page.
Frequently asked questions about agentic engineering
What is agentic engineering?
Agentic engineering is building software with AI agents that carry out multi-step tasks on their own while staying inside defined guard rails. An agent gets a goal instead of a question, plans the steps, uses tools like editor, terminal and test suite, and delivers a verifiable result. Humans own the specification, the rules and the sign-off.
What is the difference between agentic engineering and vibe coding?
Vibe coding means building by conversation, without a specification. That is fast and perfectly fine for prototypes. Agentic engineering sets specification and guard rails first and checks every result against them. The difference does not show up in week one. It shows up the moment somebody has to maintain the result.
Does agentic engineering replace our development team?
No. It moves the work. Experienced developers write the architecture and the guard rails, review generated code and step in when agents get it wrong. Less typing, more deciding. Without people who understand the system, an agentic setup becomes a liability.
Do we need our own developers to start?
Not for a readiness check, access to the codebase and a few conversations are enough. For a pilot yes: you need at least one person who knows the legacy system and can sign off results. If development capacity is missing, I bring it in from my network.
How long does a first pilot take?
Four to eight weeks for one bounded use case. The larger part goes into understanding and specification, not into generation. Skip that part and you are further along after two weeks and back at the start after three months.
What does agentic engineering cost with you?
Model cost is the smallest item, usually a low three-digit amount per person per month. The real effort sits with people: writing the specification, defining guard rails, reviewing generated code. Anyone who only counts token cost is counting the wrong thing.
With me the readiness check runs at a fixed price, everything after that on a day rate. After a free 30-minute call you get a proposal with scope, duration and price. Any number before that would be guesswork.
What happens to our code and our data?
We settle that before the first prompt. There are setups that run entirely inside your own infrastructure, and there are providers that do not train on your data. Which one fits depends on your industry, your compliance requirements and your codebase. That decision belongs at the beginning, not at the end.
What is the difference between agentic AI and generative AI?
Generative AI produces a piece of content on request: text, image, code. Agentic AI pursues a goal across several steps, makes decisions along the way, uses tools and checks intermediate results. The difference is not the model, it is the loop around it: plan, act, observe, correct.
What is the difference between an AI agent and a chatbot?
A chatbot answers. An agent acts. The chatbot hands you a code suggestion that a human pastes in. The agent creates files, runs the tests, reads the error and fixes it. That is why an agent needs access to tools and clear limits, and a chatbot does not.
How long until a team works productively with agents?
First usable results within days, a reliable way of working within weeks. The time is not spent on tooling but on agreeing which rules apply and who signs off generated code. Teams that settle this up front are there after four to eight weeks. Teams that just start need that time twice.
How are you different from a classic AI consultancy?
I am not in the slide business. As an interim manager I take responsibility in the daily routine: I sit in the sprints, see the resistance myself and introduce the new way of working instead of recommending it. I wrote down my position on that in my article about digital transformation consultants.
Which tools do you actually use?
Claude Code as the agent, an always-on server running several sessions in parallel, and MCP servers connecting to the systems where the work actually happens: WordPress, project management, calendars, SEO tools.
MCP stands for Model Context Protocol. It is the standard an agent uses to address external systems directly, instead of someone carrying results back and forth by copy and paste. This is where it is decided whether an agent produces text or gets work done.
Which tools make sense in your case depends on your stack. I do not arrive with a shopping list.
How much autonomy does an agent get?
As much as you can review. That is not a technical setting, it is a capacity question.
The term for this is human in the loop: a person stays at the handovers in the process and signs off. The limit is not the technology, it is review capacity. Once more output is produced than anyone can seriously read, quality drops even though throughput rises. It is the most common mistake when starting out.
In practice: write access only inside a defined area, clear boundaries on which systems an agent never touches, and every change passes a review before it goes live.
Who writes the specification?
You and I together. This is where the real work sits, and where it is decided whether the result is usable.
With a legacy system it starts by finding out what the system actually does today, rather than what the documentation claims. An agent supports that well, but someone with domain knowledge from your side has to own it.
My part is the product side: phrasing requirements so they are unambiguous. A specification a human still interprets correctly but an agent does not will reliably produce code that misses the point.
Have a Project in mind?
I can bring clarity to your goals and move the required solutions from ideation to implementation. Let's talk about your plans and become partners in crime.
