Your agents are fast. Is your SDLC?

The first week with a coding agent feels like a superpower. Changes land faster than you can read them, the backlog shrinks, and everybody wants in.

By week three, someone notices the tests stopped keeping up. The docs describe last month's system. And nobody is quite sure which of the forty changes merged since Tuesday broke staging.

That is where the "AI makes you fast and sloppy" story comes from, and it's true as far as it goes. But it isn't describing what agents do. It's describing a process built for humans, running at agent speed.

We build Vectros with agents doing most of the hands-on work, and we've shipped twelve SDK releases in eleven weeks. Over those same eleven weeks, our tests, our docs and the rules we hold ourselves to all got stricter. Here is how.

Why fast usually means sloppy

Agents multiply output. They don't multiply attention.

Every quality practice a team has runs on attention. Someone reads the diff. Someone notices that the new test passes without exercising the fix. Someone remembers that the last time this module was touched, it took down billing. When an engineer produced a few changes a day, that attention roughly kept up. When an agent produces dozens, it doesn't, and the practices quietly turn into rubber stamps.

Asking people to pay more attention doesn't fix it. What has worked for us is to stop depending on attention for anything a system can do instead, and to save people for what only people can do.

Checks that never get tired

The first layer is deterministic: checks in CI and in local tooling that run on every change, cost nothing to repeat, and are never in a hurry.

Some guard the public surface. A change to our API that doesn't bump the SDK version and add a changelog entry fails the build. Code headed for a public repository is scanned for internal references before it gets there.

Others exist because something got through once. Our version gate used to watch the folders where the API is defined. Then a change to a shared class that the API happens to reference altered the published API from outside those folders, and nothing failed. Now the gate checks its list of public sources against the API spec built from the change itself, so a change can't slip in through a side door.

That's the rule for this layer. When a mistake escapes and a machine could have caught it, the fix isn't only the patch; it's a check, so the same mistake can't escape twice. We're at dozens of them now.

Knowledge that shows up uninvited

Plenty of what matters can't be checked mechanically. Don't put a raw value into a key that a lower layer will parse back apart. A queue of unreviewed claims must never be searchable. You can't write a linter for judgment like that, but you can write it down, and we have: more than 400 recorded traps, over a hundred conventions, and nearly a hundred architecture decisions.

Writing it down is where most teams stop, and it's why their process docs don't help much. A thousand pages of guidance is no use to an agent that has to know to go looking, and the agent about to make a mistake rarely knows to look for the rule that would stop it.

So ours doesn't have to look. The whole corpus lives in a knowledge base searchable by meaning and by exact lookup, and before an agent acts, the relevant entries are recalled into its context whether it asked or not. That's how one of our agents caught a bad key design halfway through a change, before any reviewer had seen it.

Reviewers whose job is to disagree

Self-review mostly confirms. An agent reviewing its own change reads it with the same assumptions that wrote it, and finds the same things fine.

So our changes also get reviewers that weren't there when they were written. They get the change and a fresh context, not the author's reasoning, and their instructions are to find what's wrong: the edge case, the caller nobody updated, the test that passes without testing anything. The riskier the change, the more of them it gets, and the riskiest get one more cold read from outside the session that produced it.

None of this is a new idea. What's new is the cost. A human adversarial review is expensive enough that teams save it for the scary changes. An agent's is cheap enough to run on all of them, and plenty of bugs hide in changes nobody thought were scary.

People keep the merge, and the taste

None of the above merges anything. A person reads the change and makes the call, every time, and no agent can.

That's also where taste lives. The checks and the reviewers will confirm that a screen does what the spec says; they rarely tell you it's confusing to use. An agent will implement the architectural pattern you asked for, correctly and thoroughly, and not mention that a simpler one would have done. Those calls stay with people, and once everything checkable is handled, they're the calls that matter most.

That's the division of labor: machines for everything that can be checked, people for what can't.

Controls you follow by default, and can prove

Most teams treat controls as a tax: a policy document nobody reads while doing the work, and a scramble to reconstruct evidence whenever someone asks for it.

Built this way, the SDLC turns that around, because the machinery that keeps quality up is also what enforces the controls. A rule that a public API change needs a version bump and a changelog entry is enforced by a gate the change can't get past. A rule that every change is reviewed leaves its own record: the findings are posted on the change itself, where anyone can see what was checked and what was fixed. Every change states how it was verified. The merge is a person's recorded decision, every time. And the controls themselves live as records in the same knowledge base, linked to what enforces them and where their evidence lives.

None of that evidence is assembled after the fact. It's the history of the work.

The ratchet

Put the layers together and the system starts working in your favor. Every mistake that gets through becomes a check, a recorded trap or a sharper instruction for the reviewers, so the process gets stricter at the same pace it gets faster.

That's why our tests, docs and controls have risen with speed instead of competing with it. Tests come along because reviewers check whether they exercise the change. Docs stay current because they are what the agents run on, and a stale entry misleads the next agent, so it gets fixed. Controls hold because the ones that can be gates are gates, and the rest leave evidence just by being followed.

Try it

Your agents are already fast. Whether your SDLC keeps up comes down to what it remembers and what it refuses to let through.

The knowledge layer is the part that runs on Vectros. The same agentic-SDLC knowledge base runs our own engineering org (here's how we set it up), and it's a bundled blueprint you can stand up yourself:

npm i -g @vectros-ai/cli
vectros login
vectros bootstrap --blueprint agentic-sdlc --no-seed

Vectros is invite-only right now. Request early access if you don't have a key yet.