一家年经常性收入 200 万欧元的医疗 SaaS 如何实现 100% 智能体编程

July 5, 2026

How we run 100% agentic coding at a €2M ARR healthcare SaaS

The operating model behind appointmed's agentic coding workflow: how we shape work, supervise agents, review code, and keep release risk owned by humans.

The most common misunderstanding about agentic coding is that it replaces engineering judgment. It doesn't.

At appointmed, a healthcare SaaS with about 3,500 customers and roughly €2M ARR, production code is written through agents by default. We did not stop doing engineering. The typing moved. The responsibility stayed.

The interesting part is not that an agent can generate code. Everyone has seen that. The interesting part is that agents can carry real implementation work once the system around them is precise enough: the ticket, the repo, the tests, the review, the release discipline. That surrounding system is where the learning lives, and it is why AgenticPrime exists.

What 100% agentic coding means

Production changes get implemented through agents rather than typed line by line. The agent does not decide what should exist. Humans own product direction, architecture, tradeoffs, review depth, and release risk. The agent gets the implementation job.

Skip that line and agentic coding becomes a toy demo or a dangerous shortcut. Hold it, and it becomes an operating model.

The loop is simple: shape context, let the agent implement, verify with tests, review for intent, release carefully, then turn the learning into the next better workflow.

One recent change

Here is a concrete one, from a few days before I wrote this. We added account lockout to the login flow: after enough failed attempts, the account locks itself. Small feature, roughly a hundred lines, but security sensitive.

The agent implemented it and it looked done. Two AI reviewers on the pull request disagreed, and each found a different way it was wrong.

First, a counting bug. The check that counts failed attempts read the current count and then wrote the new one as two separate steps. Two attempts arriving at the same instant could both read the old number and slip past the limit. The fix made the count a single atomic step, so simultaneous attempts can no longer sneak between the read and the write.

Second, the opposite failure. If the check got slow, it could be cut off before it finished, and a cut off security check was being treated as a hard deny. So a slow moment on our side would start locking out legitimate users. The fix put a short deadline on the check that fails open: if it cannot answer in time, the honest user gets in rather than getting punished for our latency.

Same hundred lines. One bug that lets the wrong people in, one that keeps the right people out. Both caught before release, then pinned with tests so they cannot come back quietly.

The point is not the speed. It is that the agent produced something plausible and subtly wrong in two directions at once, and the layered review around it is what turned plausible into safe.

The ticket is the first interface

The first interface with an agent is not the chat box. It is the task.

Bad task shape produces bad agent work. Vague acceptance criteria, hidden product context, missing files, unclear constraints, unspoken edge cases, all of it becomes expensive. The agent makes a plausible choice, and plausible is not correct.

So the work starts before the agent starts. For a production task, I want the ticket to answer:

What exact behavior should change?

What should stay untouched?

Which files, routes, commands, or workflows are likely relevant?

What is the real user risk if this goes wrong?

What proof should exist before we call it done?

This is ordinary engineering discipline. Agents make weak task definition more visible; they do not forgive it.

The repo has to teach the agent

Agents perform much better in a codebase that explains itself.

That does not mean comments on every file. It means the repo has local patterns, tests, naming, scripts, and conventions that are easy to discover. When there is one way to do something, the agent follows it. When there are five half finished ways, it picks the most recent, loudest, or wrong one.

The more we use agents, the more valuable boring repo hygiene becomes:

Clear commands.

Small modules.

Predictable naming.

Tests close to the behavior.

Explicit local conventions.

Documentation that says what matters, not what is obvious.

That is the unexpected benefit: agentic coding pushes the codebase to become more legible for everyone.

Implementation becomes supervision

The agent handles the typing, searching, and mechanical repair. That changes my role while a change is being built. Instead of holding every line in my head, I supervise:

I check whether the agent found the right part of the system.

I look for wrong assumptions early.

I ask for smaller diffs when the blast radius grows.

I push it toward existing patterns.

I require proof before I trust the result.

The best sessions feel less like prompting and more like managing a very fast contributor with no long term memory and no product taste. Extremely useful, but only when the supervising system is strict.

Review is about intent

Code review changed the most. When a human writes every line, review mixes jobs: understanding the implementation, catching mistakes, debating style, inferring intent from the diff.

With agentic coding I separate those. First, does the implemented behavior match the intended behavior? Then architecture and risk. Only then, local cleanup.

The question stopped being "would I have typed this the same way?" It became "is this the right change, in the right place, with the right proof, and no hidden cost we are ignoring?" That is a healthier review question even without agents.

The agent can move implementation forward, but humans still own product intent, architecture boundaries, review depth, and release risk.

Tests become the contract

Agents are good at satisfying the visible contract, so the visible contract has to be real. Cover only happy paths and you get happy path confidence. Encode the actual risk and the agent has something meaningful to satisfy.

For appointmed this is not academic. The product touches healthcare workflows; the cost of a quiet mistake is real. I do not want tests to make a dashboard green. I want them to give the agent a boundary and give me a reason to trust the change. The rule is simple: if a behavior is important enough to ship through an agent, it is important enough to prove.

What actually changed

Implementation is no longer the scarce activity. Clear context is scarce. Good taste is scarce. Knowing what not to change, when a diff is too broad, what proof matters, all scarce. So the effort moved: more time shaping tasks and making the repo navigable, less time on mechanical edits a capable agent does faster. This is not less engineering. It is engineering concentrated somewhere else.

None of it moves the responsibility. If an agent ships a bug, the customer does not care who wrote it. If the architecture rots, the repo does not care the diff was fast. Agents make some work faster and make weak judgment more dangerous, because weak judgment now produces much more code. The answer is not to slow everything down. It is better checks, prompts, workflows, and habits around the speed. That is the work.

Why AgenticPrime exists

AgenticPrime is where I distill these lessons. Not generic AI commentary, not tool hype, not a claim that every team should copy appointmed. The goal is practical:

Share the workflows that survive production.

Publish the prompts and checks that reduce risk.

Build small developer tools where the pattern repeats.

Show what changed in a real SaaS codebase.

Be honest about what still needs human judgment.

The proof source is appointmed. The output should be useful well beyond it.

A practical starting point

If you want to try this, do not start by declaring that agents will write all your code. Start with one recurring workflow that already has clear boundaries: a small bug fix class, a test improvement, a refactor pattern, a docs to code path. Something where you can define context, expected output, and proof.

Then watch what breaks. Was the task clear enough? Did the agent find the right files? Did the tests prove the right thing? Did review catch intent problems? Did the release feel safe? That is where the real learning starts.

The future of agentic engineering will not be won by the team with the flashiest prompt. It will be won by the team that builds the best operating system around the agent. That is what we are building toward.

Get the build log

Every two weeks: what shipped, what broke, what it cost or saved.