Week 1: Measure Twice. Build Once. Let the Agents Do the Rest.

A master bricklayer spends a disproportionate amount of time on the first course. Before any mortar is mixed, they’re snapping chalk lines, dry-laying bricks, checking the level on every single one. To an outsider, it looks slow. It looks like nothing’s happening.

But every bricklayer knows: if that first course isn’t true, every course above it amplifies the error. A millimetre off at the base becomes a centimetre by the tenth row. Get the first course right, and everything after is just repetition — brick on mortar, tap, check, next.

This week was about laying our first course.

The pragmatic choices

Last week I wrote about the why and the plan. This week: what actually happened when we stopped talking and started building.

First decision: go pragmatic, not shiny.

Cloud: AWS. We’re already there. Our team knows it. Our clients are on it. No migration tax.

Coding tool: Kiro. We evaluated the options and landed on Kiro. Not because it’s the newest or most hyped, but because it’s genuinely good, integrates with IAM (security baked in, not bolted on), is controllable (proper guardrails), and observable (good logging, clear audit trails right in our AWS account). When you’re building AI agents that access sensitive or proprietary data, these things matter enormously.

We didn’t pick the fanciest trowel. We picked the one that’s balanced right and won’t let us down halfway through the wall.

The team

A core of engineers who are genuinely passionate about AI — not “interested in AI” in the LinkedIn bio sense, but people who’ve been deep in this for months, years. Already experts. Already building.

Alongside them: members of our Executive Leadership Team. Not passengers — active contributors. They’re already using Claude, GPT, Copilot daily. They get it. And they’re full of ideas. Their role is crucial: they’ll carry the message outward as we scale beyond the core.

You don’t put the apprentice on the first course. You put your best people on it.

Don’t let Doug chase squirrels

There’s a brilliant Quora post by Terry Lambert that nails the reality of working with AI coding tools. The gist: these tools are like an extremely eager junior developer who completely lacks self-discipline. Instead of an LLM named Claude, think of it as a dog named Doug — and there are a lot of squirrels.

“…and then we iterate over the linear array with the check function, from which we are able to determine… SQUIRREL!”

Anyone who’s used these tools has felt this. You ask for something and the tool just goes — building before it’s understood the problem, backtracking, burning tokens in a doom loop.

The human’s job is to be the discipline the tool lacks.

Context engineering: three rules

The quality of your output is directly proportional to the quality of your input. Not your prompt — your context.

1. Plan. Then plan again. Doom loops happen because people let the tool run before defining what “done” looks like. Kiro has plan mode for exactly this reason. Spend time on the spec. Dry-lay your bricks before committing mortar. This isn’t vibe coding. This is engineering.

2. Context is everything. Give the tool the right skills, steering, and data access (MCP tools, knowledge bases). Don’t throw a prompt at a naked LLM and hope. You wouldn’t hand a bricklayer bricks without a string line and a level.

3. Plan + context = one-shot development. Plan the ticket properly, open a fresh thread with clean context, give it the right role, implement. One shot. No doom loops. The bricklayer who measured properly doesn’t pull bricks back up.

From tips to a system: PatternOps

When you systematise this discipline — planning, context, one-shot execution, review — you end up with a fundamentally new SDLC.

We’re calling it PatternOps, many others have their own names, fundamentally it is what we are all aiming for. The vision: an AI development factory where the human is above the loop, not in it.

• Plan the work. Requirements, design, task breakdown — AI-assisted but human-directed.
• Press play. Agents execute. An executor builds. A critic reviews. If it doesn’t meet the standard, it goes back.
• Review the output. Human review of the runs. Did it meet the spec? Ship it.

The human provides intent and quality gates. The agents provide the labour. We’re not fully there yet — but the foundations are being laid.

What we actually shipped

Seven days. Here’s the commit history:

• 12+ knowledge bases — FCA handbook, PRA rulebook, UK legislation, Citizens Advice, Shelter, Refuge, Women’s Aid, and more. Each with CI, testing, and automated publishing.
• 12+ MCP tool servers — standardised interfaces, Dockerised, multi-platform.
• Reusable CI/CD infrastructure — shared pipeline library with semver, lint/test gates, Docker builds. Build once, apply everywhere.
• Token optimisation — compacted tool descriptions saving ~53% token budget. Context engineering in practice. Thank you caveman!
• MCP orchestrator — wiring all specialist tools into a coherent system.
• Regulatory reporting agent — multi-model, bounded loops, timeouts. A real agent doing real work.
• LLM Wiki system — based on the Karpathy LLM Wiki pattern, a Slack/Telegram bot backed by a 27-tool MCP server that ingests URLs, files, and images into a structured, interlinked knowledge base. Organisational memory that builds itself. Designed so we can roll out at scale for individuals, teams, and ultimately a company-wide instance.
• Fraud investigator persona — refactored and structured for scale.

That’s not a proof of concept. That’s a first course of bricks — level, true, and ready for the next row.

What’s next

The first course is down. The string line is set. Week 2: building upward — more agents, more workflows, and proving out PatternOps on real work.

Article 2 in a series documenting bigspark’s AI-native transformation. Article 1: Staff Augmentation Is Dead. Next week: PatternOps in action.