How to build an
agentic software factory
The goal: don't write any code by hand.
The skills, rules and guardrails, not the theory.
This is how we write code now.
Same person. Same repo. The agents showed up in January.
Stop writing code. Not a single line, by hand.
Five levels of using agents.
What's missing between
step 3 and step 4?
Documentation
Nothing tells the agent how your codebase works, so it invents its own answer.
Guardrails
Nothing stops it when it's wrong. No lint rule, no test, no review that fails.
Everything in this talk serves one loop.
- Before it writes → the rules. Where files go, which components exist, what a change comes with.
- Before it opens the PR → a local review, from a model that didn't write the code.
- When CI goes red → it has to read why. A lint rule, a test, a screenshot that moved.
Five pillars.
CLAUDE.md rules
The entry point. "Whenever you do X, do Y."
Architecture docs
How the data actually flows.
Deterministic guards
Linter rules. The law.
Tests
The most important pillar. Eyes on every change.
The review loop
Bots that catch what tests can't.
CLAUDE.md - the agent's entry point.
# CLAUDE.md When you add a UI component: → check the component library first, reuse it → use our state hook, never raw useState → add a Storybook story for every new state When you change a backend service: → add an integration test (service → DB → assert)
Architecture docs - how the system works.
Draw the main journey, not every table.
The spine of your app, so the agent knows where things live and why. Link it from CLAUDE.md and the agent reads two files instead of twenty to learn how your app works. That is context it gets to spend on your actual problem.
CLAUDE.md is a suggestion.
The linter is law.
Everything so far is a polite request: "please use this component, please name it that way." Some of it will not land. And mechanical rules don't belong in CLAUDE.md anyway - every line you put there is context the agent pays for on every task. The linter is the shortcut: it never has to learn the rule, it just finds out when it breaks one.
Five kinds of guard.
We have 20 custom ones.
Use our component, not the raw one
The tooltip prop on Button, never a Tooltip wrapper. Durations from the animation enum.
React footguns types miss
Render <Foo/>, never call Foo(). AnimatePresence children need a key.
Effects & server components
Every useEffect carries a why-comment. An await in an RSC must be wrapped in try/catch.
Bundle & import boundaries
No barrel @repo/ui/icons imports. Heavy components load dynamically. No Node lib on the
client.
Drift
CI regenerates the API client and fails if the diff isn't empty. No circular imports. No unused
eslint-disable.
Every guard is a mistake
that already happened.
# three real rules from our frontend @repo/prefer-tooltip-prop → use the Button tooltip prop, not a Tooltip wrapper @repo/no-runtime-identifier-name → minifiers mangle function names in production no-restricted-imports: @repo/ui/icons → import the icon directly, barrels bloat the bundle
Nobody could review their way to these. They're bugs we shipped once, and now they're impossible. And the agent fixes them alone - a red check needs no context, only the error.
Tests are the
most important
pillar
Without them, you can't let go. And letting go is the whole point.
You are the biggest bottleneck now.
Six agents finished at once - and every one still needs a human to click through it. Tests are how you stop being the thing that checks.
The test mix that actually scales.
Backend integration
Call the service, hit the real DB, assert the logic.
Storybook interaction
Click the button, the modal opens, submit, it closes.
Visual
Does it still look right? A screenshot of every state.
A little end-to-end
Very little. Slow and flaky, so keep CI fast.
And the agent writes all of them.
"We tried Storybook.
Nobody maintained it."
I know. That was true for me too, at two companies. But you don't write them any more - the agent does, because a CLAUDE.md rule says so. It's the same argument as types: "why write types when I could write plain JavaScript?" Because it's nearly free now.
Stories are your best line of defence on the UI.
10 PRs.
How do you know the UI didn't break?
Every one of them touched a shared component. Traditionally you'd open the app, find each page that uses it, and get each one into the exact state where you can see it. You are not doing that ten times.
A second model, reviewing every PR.
Same context as the coding agents - CLAUDE.md, the architecture docs - plus "go deep on the logic." If it's clean, the bot approves and it can merge.
/review-loop
Two models review the same diff. You triage and fix. It re-reviews - round and round until a clean pass finds nothing new.
/e2e-verify
Ten agents, ten isolated stacks - no port collisions. This is what catches the ones that only say they're done.
/babysit-pr
Opens the PR, then babysits CI - it polls, and fixes whatever goes red. Never approves, never merges.
The run makes the next run better.
A correction becomes a CLAUDE.md line and, when it's mechanical, a lint guard that goes red the next time.
Grades the finished run cold - a fresh model that never saw it asks how well the loop actually ran, and what to tighten.
/factory
There's always something
to improve.
Wherever you are on this, there is a next step. Go take it.
Your gift, LondonJS.
The skills
Every skill from this talk - the deck-builder included. Free to install.
UI Verify
The whole platform. Free for early adopters.
These slides
The deck itself, yours to keep and steal from.
Let's connect
Igor Luchenkov on LinkedIn - in/igor-luchenkov
in/igor-luchenkov · Igor Luchenkov · LondonJS 2026 · thank you 🙏