This is the first post in a two-part series on how we build software with autonomous AI agents at Strike. Part I explores the shift from ad-hoc prompting to building a structured software factory, managing review bottlenecks, and using upfront alignment to deliver vertical slices. For our deep dive into deterministic gates, eval frameworks, and long-term repository maintenance, read Optimising the Strike Software Factory

As underlying models become more capable, our relationship with AI shifts from using it as an ad-hoc coding assistant to building software factories that construct features for us. By a software factory, we mean the complete environment surrounding the model: structured specifications, custom agent skills, automated review councils, and deterministic CI gates that reliably turn requirements into working software. We are promoting agents to first-class team members.

We spend heavily on alignment upfront, and heavily on human review at the end. The middle - the actual writing of code - compresses from days to hours.

The New Bottleneck: Correctness and Review

If writing code is no longer the bottleneck, what is? When an agent can run overnight, the constraint shifts entirely to review burden and correctness.

If the output is too large, the team bogs down in context switching. If the output is low quality, we spend too long modifying it. Setting an agent running overnight on a probabilistic build only to find it built the wrong thing burns our most limited resource: human time. To maintain velocity, agent output needs to be right-sized and largely correct.

If the team is spending days refining agent output, the solution isn't to work harder on human code review - it's to improve the factory. To protect human time, we baked rigorous review directly into the refinement loop:

• The Agent Council: A human is no longer assigned to review a pull request until it has survived an automated multi-agent review cycle checking spec adherence, correctness, and security.
• Codified Seniority: By analysing historical pull request feedback from domain experts, we codified those patterns into a custom review skill - a structured package of instructions, rules, and domain context - that evaluates features through the exact lens of senior team members.
• Smart Orchestration: We use stronger models as coordinators and weaker models for simpler tasks, running multiple agents in parallel to handle the heavy review burden efficiently.
• Deterministic Guardrails: Because our codebase enforces semantic correctness at build time, we invest heavily in adding deterministic guardrails like custom static analysers and linters to catch issues before the agent even commits.

Alignment: The "Grilling" Process

If you want 90% correctness on the first pass, you can't throw a vague issue at an agent. Agents can't read your mind; unspecified details become inferred assumptions.

To prevent this, we lean heavily into "grilling" (a nod here to Matt Pocock, who popularised the term). It's an intense, iterative discovery process where the agent interrogates the team to tease out hidden requirements, edge cases, and architectural constraints. We get the knowledge out of our heads and onto paper before a single line of code is written.

We get the rigour of deep, upfront design combined with the fast feedback loops of Agile: when the build phase compresses to hours, the cost of iterating on a spec plummets.

This demand for upfront alignment is expanding upstream. Because writing code is no longer the long pole, the cost of entering a project with unclear information is magnified by agent rework. The product team now uses agentic sessions from conception to grill stakeholders, convert unknown unknowns into knowns, and gain deep alignment before engineering even begins.

Structure: Vertical Tracer Bullets

Once alignment is locked, we structure execution using thin, end-to-end vertical slices - often called tracer bullets. While this isn't a net-new concept, our norm has usually been building horizontally across layers and integrating later. In an agentic workflow, vertical slicing becomes paramount.

Instead of building horizontal components, we build fully baked features end-to-end. A vertical slice extends through every part of the system, from unit tests up to the CLI.

This is crucial because it allows the agent to test its own work. The agent doesn't just write code; it runs the deployed application and interacts with it like a user. The agent is the feedback loop. By experiencing the system in the flesh, it discovers what works and iterates until the feature functions as designed. When human team members finally review, we can experience and verify the product the exact same way.

Friction and Adaptation

Moving fast as a solo dev is one thing, but operating enterprise financial software at scale is another. We're not offloading understanding to our agents; we're offloading grunt work. We want to take out the middle layer so we can focus on building solutions and making decisions.

To make this work across a larger team, we have to continuously adapt:

• Strict WIP Limits over Parallelisation: Running multiple slices concurrently fails. When agents encounter issues, they autonomously suggest or make improvements to our factory. Running parallel slices means agents build from the same flawed base and miss each other's learnings. A strict WIP limit of one ensures the next slice benefits from the absolute latest environmental upgrades. It's "one-piece flow": doing one thing start-to-finish is faster than doing many things at once.
• Group Reviews over Solo Handoffs: A solo engineer reviewing agent output creates a slow loop of pinging domain experts. Moving to group reviews - getting on a call, reviewing the PR together, and writing actionable comments for the agent - resolves ambiguities immediately.
• Agents for Understanding: We still read and review every line, but we also leverage agents to generate HTML visualisations and concise one-pagers that explain high-level concepts, helping onboard engineers to unfamiliar domains.
• Right-Sizing Tasks: Mapping backend features into oversized slices creates review bottlenecks overnight. We right-size tasks into tighter, self-contained chunks, continuously adjusting slice boundaries based on lessons from previous runs.

The Strategy is Continuous Adaptation

These adaptations work. As we right-size our tasks, move to group reviews, and enforce strict WIP limits, the pace picks up and the review burden drops. The trajectory becomes clear: building the factory is the natural output of the learning process, followed by a sharp ramp in velocity once the refinement loop clicks into gear.

The biggest takeaway is that we need to treat the "software factory" as a first-class product. We are still in the proving process, but our energy is shifting from writing feature code to improving the system that writes it.

We don't know exactly what the Strike software factory will look like in three or six months, and that is the point. The agentic environment changes rapidly, and trying to predict its exact long-term shape in advance rarely holds up. Our focus is adapting alongside it - evaluating new tools, adjusting workflows, and continuously refining our way of building. The strategy is continuous adaptation rather than a rigid, locked-in process.