Agentic Development: From assistance to autonomy

We build the scaffolding that guides and checks AI agents. For software that isn't just written quickly, but holds up permanently.
Two federal portals and our own tools are already developed agentically — from the initial concept to release. Discover how autonomous AI takes over complex tasks, freeing developers to focus on architecture and quality assurance.
The hook

The engine is not your competitive advantage

«Power is nothing without control.»

Advertising claim by Pirelli, in use since 1994
Five words from a tyre advert say what this is about. The engine was never the problem. What mattered was always how much of it reaches the road. In software development with AI, the engine is the same for everyone today. Your competitor uses the same model you do, at the same price, starting tomorrow morning. The difference only appears afterwards — in what is built around the model. Who is at the wheel does not change: you drive. We provide the grip — the scaffolding that turns engine power into a track you can hold at speed.
The method

What Agentic Development actually means

Agentic Development means that software engineers do their work together with autonomous AI agents. These tools read code independently, propose changes, run tests, and correct themselves. The human leads, reviews, and stays accountable for the architecture. The speed comes from automating routine tasks. The quality is ensured by a scaffolding that lets no error slip through unchecked. This gives developers valuable time for system design and user value. The question is not whether to start, but where. We distinguish five levels of maturity:
  1. Level 1 · Context Engineering

    What the agent knows and what enters the context window.

  2. Level 2 · Harness Engineering

    What guides and checks agents before a human sees the code.

  3. Level 3 · Spec-based Development

    What is decided beforehand and how deviations become visible.

  4. Level 4 · The agentic flow

    How the flow works and who holds the pen.

  5. Level 5 · Multi-Agent Development

    How many agents work concurrently and where the limits are.

Most teams sit lower than they think. The following sections show what each level delivers.

Who does what

  • The agent works

    Every step stays provable on its own

  • The human decides

    Both held together by the harness

  • The harness secures it

This is how several developers can run several agents at once without getting in each other's way — not because everyone is being careful, but because the harness rules it out.

Level 1 · Context engineering

What the agent knows

What enters the context window is decided per step: what comes in, what gets compacted, what is fetched on demand, what never goes in at all. The unit of work is the token budget, not the prompt.
Data sourceRepositoryGit historyUnstructured filesContext engineeringtoken budgetActive context windowSpecific skillsCompact code excerptCurrent taskAgentprecise performanceFull, unfiltered context windowAgentDegraded performance

«Context engineering is the natural successor to prompt engineering: the question is no longer which words to use but which configuration of context most reliably produces the behaviour you want.»

Anthropic, «Effective context engineering for AI agents», September 2025
The research backs it up: Chroma measured that performance degrades as input grows — independent of the nominal window size. A large context window is a budget, not a capacity.How you notice it is missing: agents that convince in a ten-minute demo and degrade over a long session. The failure gets blamed on the model; the actual cause is an exhausted attention budget and a window full of stale detail.At Quatico this produces something visible: the skills. What an agent needs to know about a repository — conventions, where things live, how we build here — is written down as a reusable working instruction instead of being guessed anew in every task. They are open on GitHub.

What the agent knows only helps if it takes effect at the right moment. That is the next course.

Level 2 · Harness engineering

What guides and checks agents

An agent is model plus harness. The harness has two directions: guides steer before the agent acts. Sensors check after it has acted.
Guides ·feedforwardContext (repo, skills)Model / AI agentSensors · feedbackPre-commitHooks, formatting, lintingminimalBy the secondType checks, fast unit testscheapBy the minuteFull test suite, review agentmediumContinuousDrift sensors, plan-versus-codeongoingAutomated correction

«Feedback alone gives you an agent that repeats its mistakes; feedforward alone gives you one that encodes rules and never learns whether they held.»

Birgitta Böckeler, Thoughtworks, «Harness Engineering for Coding Agent Users», April 2026
Böckeler also sorts the controls by kind and timing: computational controls are fast and unambiguous — type checkers, linters, structural tests. Inferential ones carry semantic judgment — conventions, skills, review agents. They are distributed by cost: cheap ones before the commit, expensive ones after integration, drift sensors running continuously alongside.How you notice it is missing: you are the sensor. Every mistake comes back through a human review, the same one returns next week, and the fix lives in a chat message nobody can version.At Quatico guides take effect at defined points automatically. The sensors form a chain: linting, compiling, unit, mock, integration, UI. Much of this is generic and reusable (like ESLint or Prettier) and does not depend on the domain context. The order is the rule: what a machine can decide unambiguously, a machine decides. AI comes in only where a judgment is needed.

Checking only works against an expectation somebody put in writing first. That is the next level.

Level 3 · Spec-based Development

What is decided beforehand

The plan is no longer a fleeting chat message, but a versioned artifact in the repository. This way of working is called Spec-based Development: specification first, then implementation. We implement this using our own tool, Plot. Plans are proposed, reviewed, approved, and delivered — with the same rigor as code. Because both plan and result live in Git, deviations become immediately visible.
The Plot workflow · Spec-based Development in GitPlan proposedSpecification asplanReview andapprovalApproval withapproverImplementationby agentsImplementation aspull requestDelivery andmergeImplemented planwith changelog!Without specification · uncontrolled path!Scope drifts!Session breaksoff!Knowledge getslost!Decision notreconstructablePlanning is the counterweight to complexity
This is where intent becomes reviewable. And it answers the gap from course 2: the functional specification is the feedforward control for behaviour — the one category with no trustworthy sensor. If you never said clearly what you wanted, no test can tell you whether you got it.How you notice it is missing: scope drifts unnoticed. Nobody can reconstruct why a decision was made three sprints ago. An interrupted session cannot be resumed, and the agent's exploration is bounded by nothing except how much it happens to read.At Quatico it is called Plot — open source under CC0. Plans live as Markdown in the repository, pull requests are the workflow metadata, git is the single source of truth. The strongest proof: we plan this website with it. That is also the precondition for many tasks running at once. An unclear brief used to cost one developer-week; run in parallel it costs as many branches, pull requests and reviews as there are agents on it. Whatever stays undecided at the front multiplies at the back.
Context: Thoughtworks lists spec-driven development in the Technology Radar under «Assess», not «Adopt» — noting that the workflows are elaborate and some tools generate spec files nobody wants to review. Critics call it waterfall in new clothes. The counter-evidence is empirical: a study of 806 repositories found a large but transient velocity gain after Cursor adoption — alongside a lasting rise in warnings and complexity.

An approved plan is the condition for a loop having any stop condition at all.

Level 4 · The agentic flow

How the flow works

Every phase ends with an artefact somebody owns — not with an informal hand-off. That is why the work outlives the single session.
Phase 1DiscoveryApproved storyThe human writes, agentsadviseSignature 1Approved storyPhase 2DesignApproved plans, cut intopackagesThe human decides, theagent phrases itSignature 2Approved planPhase 3DevelopmentImplementation inseparate working areasactread sensorscorrectThe agent builds, thehuman lands itSignature 3PR with green CIPhase 4TestingVerified releaseThe agent writes thescript, the team worksthrough itSignature 4Delivered plan withoutdrift, endgame protocolUnit, integration,E2E — automatedApproval with name and date in the artefact
  1. Discovery

    human-led

    An approved story: this problem gets solved, at this place in the system

    The human writes, agents advise

  2. Design

    human-led

    Approved plans, cut into packages that genuinely run in parallel

    The human decides, the agent phrases it

  3. Development

    agent-led

    Implementation in separate working areas

    The agent builds, the human lands it

  4. Testing

    agent-led

    A verified release

    The agent writes the script, the team works through it

Two places carry a signature with name and date: the approved story and the approved plan. Both sit in the artefact itself — who, when, through which channel.

The endgame

That is what we call the part where we play our own result — not to confirm that the happy path works, but to find what goes wrong to the left and right of it. Automated tests cover what was written down as an expectation beforehand. What lies behind that, the agent writes as a script; the team works through it where only a human can judge: is it usable, is it operable, what is missing in the flow. Focused work in the right place instead of searching the whole.

These four levels carry one agent. The fifth asks what happens when there are several.

Level 5 · Multi-agent development

How many at once

This level is optional. Many teams stop at level four. What they forgo is throughput on tasks that can be parallelized.
Isolation boundaryOrchestrated · AnthropicOrchestratorIsolated taskscontrolled synthesisSubagentFreshcontextwindow (token budget)SubagentFreshcontextwindow (token budget)SubagentFreshcontextwindow (token budget)SubagentFreshcontextwindow (token budget)Separate synthesisCodebaseConflict case · CognitionCodebase!Conflicting codee.g. incompatibleconventionsSharp isolation boundary? Parallelism pays. Overlapping decisions? One agent with more thinking time.

«An orchestrator plans, spins up three to five subagents with fresh context windows, then synthesises with a separate citation pass. Workers never talk to each other.»

Anthropic, «How we built our multi-agent research system», June 2025
Anthropic measures better results this way than with a single agent — and considerably higher token spend. Cognition disagrees, explicitly for coding:

«Parallel agents make independent decisions on a shared problem, and independent decisions produce conflicting output.»

Cognition, «Don't build multi-agents», June 2025
The sober footnote: several 2026 studies qualify both sides. At an equal token budget, a single agent often matches the results. Some of what looks like coordination winning is just more compute time winning.
What follows: Coordination starts during planning. With Plot, work is sliced and marked in the plan so it can be implemented in parallel. Where tasks are sharply separated, parallelism pays off. Where every decision constrains the next, a second agent is just a second author who never read the first one's mind.
The distinction

The three-stage model

Development with AI happens in stages. While classic coding and simple code completion (Copilot) assist the developer with individual lines, Agentic Development takes over complex tasks autonomously. This creates room for architecture and quality assurance.
  • Workflow

    Classic coding: Developer writes every line of code

    Assisted coding (Copilot): AI suggests code snippets or lines

    Agentic Development: AI takes over complex tasks and entire features autonomously

  • Autonomy

    Classic coding: None (fully manual)

    Assisted coding (Copilot): Low (reacts to immediate context)

    Agentic Development: High (plans, executes, and self-corrects)

  • Context

    Classic coding: In the developer's head

    Assisted coding (Copilot): Local file and open tabs

    Agentic Development: Specified: repo conventions, architecture, skills

  • Verification

    Classic coding: Manual testing and review

    Assisted coding (Copilot): Developer checks every suggestion immediately

    Agentic Development: Automated tests, types, CI, and review gates

  • The human's role

    Classic coding: Craftsman (writes code)

    Assisted coding (Copilot): Pilot (steers and corrects)

    Agentic Development: Architect and reviewer (plans and checks)

  • Time gained

    Classic coding: None

    Assisted coding (Copilot): Faster typing of routine code

    Agentic Development: Focus on system design, security, and user value

Real acceleration does not come from faster typing, but from autonomy. A team that leads and checks agents produces reliable software in a fraction of the time.

The mechanism

No surprises

That the result holds — that is easily said. The question is how. For us, through three decisions that all point the same way.
  • The agent builds the system. It is not part of it.

    We do not let agents monitor and steer unsupervised. We use them to build and run the systems that do exactly that — automation, pipelines, metrics, dashboards, release engineering. What runs in production afterwards is deterministic: same input, same result. The agent built it; it does not make decisions inside it.

  • Less code, not more

    Every line of code has bugs. An agent writes ten times faster — which is only a gain if there is not ten times as much code at the end. We do not measure how much was produced, but how little was needed.

  • Faster means more safety net, not less

    When changes land faster, you need more metrics, more monitoring, faster review and deploy processes — to keep up, and to correct mistakes quickly. The agentic setup itself is an investment, so that it delivers predictable results. Doing the same thing faster is not enough; it has to get better.

Where the scaffolding reaches its limit

A ticket from our own platform project: roughly 600 lines across three layers, clean tests, green build, properly documented. Every check was green — and nobody wanted the result anyway. No sensor in the world answers whether what was built is what was meant.

That is why the work moves forward in the process. For us that means around four hours a day spent on markdown instead of code. If the plan is precise enough, the pull request holds no surprises — and the review effort collapses.

In practice

What changes in the craft when agents work alongside you

With the scaffolding in place, we don't just type faster. What changes fundamentally is which work arises at all. Three things we do differently today than two years ago.
  1. We build the prototype instead of the mockup

    The idea used to take shape in Figma or Miro and was rebuilt afterwards. Today the interactive prototype is finished sooner than the picture of it — and you can use it instead of imagining it. Discussions about work in progress get shorter and more honest.

  2. We do not chase 100 % test coverage

    An agent writes tests almost for free, and that is exactly the trap: test everything and you test nothing properly — you end up with checks that only cost effort. The definition of done says what belongs under test. And where an agent judges rather than computes, line coverage measures the wrong thing anyway; that is what evals are for.

  3. We lead agents instead of working through tasks

    The work shifts from writing to scoping, reviewing and deciding. That is more demanding, not more comfortable — and it is why experience matters more, not less.

When the agent leads — and when the human does

Agent-led — the agent leads

  • Similar changes across many files
  • Catching up test coverage where it is missing
  • A migration, step by step
  • Exploring an unfamiliar codebase
  • Building a prototype to settle a question

Human-led — the human leads

  • When the requirement is still unclear
  • When an architectural decision needs experience
  • When a mistake would be expensive
  • When it must be decided what «done» means
  • And that is how it should stay
The evidence

Two federal portals on one platform — and our own tool

Agentic Development is not a theory here. Naturgefahren.ch and MeteoSwiss run on one multi-tenant platform — one data pipeline, one CMS, the same quality gates: what holds for one portal holds for the other. Both carry people when it matters. Alongside them, our own tool, where we found out first whether the scaffolding holds.
  • Naturgefahren.ch

    The natural hazards portal brings together hazard data from several sources and turns it into warnings for the web — accessible, certified to WCAG 2.1 AA.

    Since the project started, every change goes through the agentic workflow.

    During a storm everyone hits it at once — which is why the quality gate in front of it is not negotiable.

    Open naturgefahren.ch
  • MeteoSwiss

    137 weather products, a dedicated mapping framework — for the Federal Office of Meteorology and Climatology.

    Also since January 2026: no change outside the agentic workflow.

    The automated quality gates in this application are no by-product — they are the scaffolding that makes exactly that possible.

    What we built for MeteoSwiss
  • Quote generator

    Our own product, in two stages: we pitch to clients with the prototype — five variants run publicly. If that turns into an engagement, it becomes the production application on the CDS platform, with access control and further generators.

    Both stages run through the agentic workflow — the first prototype was up in March 2026, in a single morning.

    The prototype from the pitch is the basis of the production application, not a throwaway beside it. This is where we started, on ourselves, before recommending it to clients.

    See the quote generator
Hybrid teams

Who actually writes in a project like this

"The agent works, the human decides" is a diagram further up. In a live client project — the portal rebuild for a Swiss fiduciary firm, running since summer 2026 — you can check whether it holds: the commit log is that diagram, just as a list.
  • Almost half the contributions do not come from engineering

    Sales, finance and product ownership write along — not as reviewers on the side, but as authors in the log. Whoever knows the requirements can bring them in without translating them first.

  • The approvals are in the log, by name

    Wherever a human decided, there is an entry with their name on it: plan approved, merge approved. Those entries carry no agent signature — they are the points where someone took responsibility.

  • One agent is a team member with its own account

    In our own company repository, Qubert contributes under its own address — our first autonomously contributing agent. You can see in the history who wrote what, because it does not commit under someone else's name.

That is the point: not that agents type faster, but that a team gets wider. Whoever knows the domain gets closer to the result.

Which level are you missing?

Five levels, and each one already carries on its own. The one below is rarely missing on purpose — usually nobody has named it.
Max

Rather talk in person?

MaxGive us a call or send an email — whichever you prefer.