Several developers use agents.
Prompts and output should rely on repository rules rather than individual experience.
All services
Introducing Claude Code
Your team now writes three times as much code. The question is who still reviews it.
Claude Code is already there in many teams, usually without a decision. Output rises immediately, and with it something that only shows up later: no single commit is obviously wrong, but after three weeks a domain object imports from the infrastructure layer and a module boundary your team spent half a year on has a silent hole. Better prompts do not fix that. Structure does.
Spec layerArchitecture rulesTests as a conditionFrom 2,400 €
What you get
- A spec layer for your repository, not for a sample project
- Architecture rules the agent cannot work around
- Tests as a condition in the workflow, not an intention in the prompt
- One worked example from spec to merged branch
- A session with your team, on your code
- What applies afterwards, in writing: who reviews what, and how to spot drift
Scope & working together
Fixed price entry on your repository. No licence sales, no tool training: this is about the structure the tool works in.
Remote from Germany. Straight with me, no agency in between.
The starting point
The problem is not the model.
Most teams optimize the wrong thing when they bring in agents. They want faster generation, so they write longer prompts, add more context and hope the output lands closer to what is needed. If it does not, they fix it by hand and try again. The pattern is familiar from twenty years of development and holds for people as much as for agents: an undisciplined process produces unpredictable output.
The failure nobody talks about is not a crash. The agent produces working code, the tests pass, the linter is happy, it gets merged. Three weeks later a domain object reaches straight into the infrastructure layer. A payment handler makes database calls it should know nothing about. No single step was obviously wrong, but the sum has hollowed out the architecture.
That is also why satisfaction and output can move apart: teams ship more and trust the result less. The structure that helps does not sit in the prompt but a layer above it, in what the agent is allowed to do at all and what its result is measured against.
Does any of this sound familiar?- Output is up, but review no longer keeps pace.
- Nobody can say which part of the code came from whom, or from what.
- Architecture decisions from last year are quietly dissolving.
- Everyone on the team works with the agent differently, with very different results.
- Tests appear after the code, if at all, and check what is there instead of what was asked for.
- An audit asks how AI is used in the development process, and nobody has an answer.
Who this is for
For engineering teams that want AI speed without losing control of the codebase.
For CTOs, engineering managers and tech leads whose developers already use Claude Code or will adopt it as a team. The constraint is not model access but a shared quality system.
The codebase has real constraints.
Architecture, security and tests cannot become personal interpretations as output accelerates.
Adoption must survive daily work.
The team needs specs, checks and workflows that continue on real tickets after the engagement.
What I do
What happens along the way
01
The current state first, the tool second
How does your team work with the agent today, where does most of the rework come from, and which architecture boundaries have already become porous. That is the baseline to compare against later.
02
The spec layer
Between intent and generation comes a layer that records what is to be built, within which boundaries, and how the result is measured. Three types for three sizes, as templates in your repository, not as theory.
03
Architecture rules the agent cannot work around
Module boundaries, permitted dependency directions and layering rules belong in the spec, not in the prompt. A prompt is a request, a rule in the workflow is a condition. Only the second holds when twenty runs happen in a day.
04
Tests as a condition, not an intention
The agent writes the test before the implementation, and the test has to fail first. That is not a matter of preference but the one condition that prevents a test describing what the code happens to do.
05
One run from start to finish
Instead of training, a real run on your code: from spec through implementation to the merged branch, together with the people who will work with it afterwards. Whatever comes up goes into the templates.
06
What applies afterwards
Who reviews what, which rules apply to merged branches, and how to spot drift before it is three weeks old. In writing, short, and somewhere it actually gets read.
Is your team writing faster than it can review?
Send me the key details. You get an assessment of what the structure would mean for you, before you commission anything.
How it runs
How this runs
Four steps, and after the second something sits in your repository that keeps working without me.
STEP 01
A 30 minute conversation
How many people work with the agent, on which code, and what has gone wrong so far. After that I tell you whether the effort pays off for you. If it does not, I say so.
STEP 02
Baseline and spec layer
Access to one repository is enough. The templates are built on your code, with your module boundaries and your conventions, not on a sample.
STEP 03
One run together
A real task from spec to merged branch, with the people who will work with it afterwards. Recorded on request.
STEP 04
Write the rules down and hand over
What applies goes into the repository in writing. From then on it runs without me, and I only look in again if you want me to.
The other side
What the current state costs you.
The total is not printed below, because I do not know it. I do know the items, and with agents they accrue faster than with people, because more code appears in less time.
- 01ReworkHow much time goes into fixing generated code today, and how much of that was the saving?
- 02Review that cannot keep paceHow many merges go through because nobody has time to really read them?
- 03Drift in the architectureWhat did it cost last time to restore a module boundary that had gone soft?
- 04Different ways of workingHow far apart are the results of two people on the team, and what does closing that gap cost?
The entry package below costs about as much as two weeks of rework on generated code. It replaces none of these figures, but it stops them from growing.
Entry offer
Spec layer in your repository. Fixed price 2,400 €
Fixed price. Further repositories or teams are quoted by scope before they start.
Not a talk about agents but a structure in your code: after a week the spec layer sits in your repository, the architecture rules hold, and one run has gone through together.
What you get
- A baseline: how your team works today and where the rework comes from
- Spec templates for three sizes, created in your repository
- Architecture rules from your module boundaries, as a condition in the workflow rather than a request in the prompt
- Tests set up as a condition, failing before the implementation
- One real run together, from spec to merged branch
- Review rules and signs of drift, in writing in the repository
What you do not get
- No licence advice and no procurement, you settle that with the vendor directly
- No training in operating the tool, the documentation covers that
- No assessment of whether AI in the development process is legally permissible
- No implementation of your features, this is about the structure
- No ongoing support without an agreement of its own
- Access to one repository and one or two sessions with the people who work with it daily
- What is produced sits in your repository and belongs to you, even if you work differently afterwards
- Price net, plus VAT
- For several repositories or teams larger than eight people the scope is agreed beforehand
- You are committed to nothing. Some teams carry the templates over to further projects themselves, and that is a valid outcome
The outcome
What is different afterwards
The architecture holds
Dependency directions and module boundaries are a rule in the workflow, not a request in the prompt. A violation shows up at merge time, not three weeks later.
The same results across the team
Whether someone has worked with agents for a year or a week matters less to the result than before. The structure carries it, not the practice in phrasing prompts.
Tests that mean something
A test written before the implementation, that failed first, checks the requirement. One written afterwards checks the code. The difference shows up at the first real bug.
An answer for the audit
How AI is used in the development process, who reviews and against what, is written down. That answers the question before it is asked.
Technologies I use
Technologies I use
Agents
- Claude Code
- Superpowers
- MCP
- Subagents
Spec layer
- Spec templates
- Acceptance criteria
- Architecture constraints
Tests
- Test first
- PHPUnit
- Vitest
- Go testing
Analysis
- PHPStan
- Psalm
- Rector
- Static analysis
Languages
- PHP 8
- Golang
- Python
- TypeScript
Pipeline
- GitHub Actions
- GitLab CI
- Checks as conditions
Enforcement
- Dependency rules
- Module boundaries
- Review rules
Operations
- Docker
- AWS
- Terraform
- OpenTelemetry
Further reading
Article · Agentic coding
Agentic coding with spec-driven development: why your AI agent needs structure
The failure mode nobody talks about, the spec layer with three templates, why architecture rules belong in the spec rather than the prompt, and where the limits of the approach are. The method behind this page, written out in detail.
Read the articleAlso from real projects
Article
An agent is only as good as its context
The layer beneath the spec layer: how I filed my own knowledge so that agents can work with it. With the two lessons this page rests on: a rule no mechanism checks does not hold, and a check that reports green in silence is worse than none.
Read the article
Who you are talking to
Directly with me as a freelancer. No agency in between.
I am Tim Rutte. More than 20 years in software development, and I work with agents myself every day, on systems that run in production. You talk to the person who touches your code, from the first call to the handover.
- 20+years in software development
- 50+successful projects
- 2003working remotely since then
Common questions
Common questions about the introduction
We already use Claude Code. Is this still for us?
That is the normal case. The tools are usually there already, often without a decision, and the question only comes up afterwards: output is up, review cannot keep pace, and the architecture shows places nobody decided on. That is where this starts, not at the installation.
Why are better prompts not enough?
Because a prompt is a request. It works for one run, not for twenty a day, and it works for the person who wrote it, not for the whole team. What holds are conditions in the workflow: a spec with acceptance criteria, architecture rules that get checked, and a test that has to fail before the implementation.
Does this only work with Claude Code?
The approach does not, the templates partly do. Spec layer, architecture rules and the test condition are independent of the tool; how they are wired in differs. If you have several tools in use, say so beforehand and it gets cut accordingly.
What does introducing Claude Code cost?
The entry package costs 2,400 euros net at a fixed price. Within one week, the spec layer is in place in one repository, including a run through together. Further repositories or larger teams are quoted by scope before they start. For comparison: that is about two weeks of rework on generated code, and those come back every month.
Will this not slow our developers down?
Generation does not get faster, and that is not the goal. What gets faster is the path from generation to merged branch, because there is less rework and review finds less. Measuring only the time to the first result measures the wrong thing.
How do we measure whether it helped?
On three things recorded beforehand: how much time goes into rework, how many comments a review produces on average, and how often an architecture rule is violated. The third is the most interesting, because it usually is not measured at all.
What about code we are not allowed to expose?
The work happens in your environment, on your repository, with your access. If certain areas are off limits for external tools, that belongs in the rules that come out of this. What leaves your systems and what does not is part of the baseline, not an afterthought.
Do you also do the implementation with the agents?
Yes, but as a project of its own. In a modernization or a handover I use the same structure; there it is part of the work rather than a separate offer. This page is for teams that want to carry on themselves.
Other services
What else I help with.
AI in production
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreMCP server development
MCP servers that hold up in production: the identity of the user instead of a shared technical account, tools with limits, a complete audit trail and a cost cap per use case.
Learn moreReducing LLM costs
FinOps for inference: make cost per operation and per user visible, choose the model by task, keep context and repetition in check. Measure first, then act.
Learn more