As software engineers, we continuously evolve how we build. This is as true in the age of AI as it was in the past. As underlying models become more capable, our relationship with AI is shifting - from using it as a tool to write code, to building software factories that build features for us. We are promoting agents to a first-class core part of the team.

The core challenge is simple: how can we drastically reduce effort and do more with less? By isolating early experiments, we create sandboxes to refine this factory model without disrupting existing workflows.

The Core Shift: What we’re finding is a fundamental shift in where we spend our time. We spend heavily on alignment upfront, and heavily on human-in-the-loop 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: We tasked an agent to analyse months of historic PR comments from our domain experts. Now, a custom skill reviews the feature using the exact same lens as our 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 new Roslyn analysers to catch issues before the agent even commits.

As a result, the team's focus shifts. Instead of just writing feature code, we also spend an time on continuous improvement of the factory that builds the code - refining agent instructions, building new skills, and using evals to rigorously verify quality.

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.

Waterfall design, Agile feedback Like Waterfall, we spend heavily upfront to write deep, end-to-end specifications. But because the build phase compresses from weeks to hours, the cost of mistakes plummets. If we build the wrong thing, we throw the code away, adjust the spec, and have the agent rebuild it while we sleep. We get the rigour of deep design combined with the fast feedback loops of Agile.

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 vertical slices. While this isn't a net-new concept, our norm has usually been building horizontally 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: Solo engineers reviewing agent output leads to a slow loop of pinging domain experts. We adapt by moving to group reviews - getting on a call, going through the PR together, and writing actionable comments for the agent to fix.
• Agents for Understanding: We still read and review every line, but we also leverage agents to generate HTML artifacts and one-pagers that explain high-level concepts, helping break people into new domains.
• Right-Sizing Tasks: We initially mapped backends into large slices, but quickly realized they are often too big to digest efficiently overnight. We move to right-sizing, breaking them into smaller, tighter chunks. There is no one-size-fits-all; we adjust boundaries continuously based on lessons from previous slices.

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 has successfully shifted 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 shape is a losing game. Our job is to adapt with it - picking up new tools, adjusting our workflows, and continuously defining our own way of building. The strategy isn't a locked-in process; the strategy is continuous adaptation.