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

July 5, 2026<br>How we run 100% agentic coding at a €2M ARR healthcare SaaS<br>The operating model behind appointmed's agentic coding workflow: how we shape work, supervise agents, review code, and keep release risk owned by humans.<br>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.<br>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...