Andrew Crookston

Five constraints on the road from delegating to orchestrating AI agents

Mon, 11 May 2026 00:00:00 +0200

I’ve built four larger software prototypes with AI agents in the last year. Only one made it to production. The others are AI slop. How do we get over that quality hump to feel good about our AI developed software?

So I went looking. I read the skill libraries like GStack and SpecKit. I talked to AI-forward friends about how to make agents run longer and verify their own work. OpenClaw came out and demonstrated what serious investment in verification looks like.

The more I built, the more I noticed something else: I need to put more constraints on my agents. Claude Code, Codex, and Cursor are great generalists. They’ll attempt almost any task and one-shot simple ones! But overall the quality of what comes back is variable. Especially as systems grow. Doesn’t matter how carefully you construct the prompts.

What follows are five moments that taught me what the missing pieces are. Each one started as a frustration. Each one turned into a first principle. Together they pointed at something specific enough that I stopped working on all the other prototypes and put everything into one thing.

1. Tasks not chats

I wrote what should have been one feature as a long chat with Claude Code. Forty-five minutes in, I noticed the model had forgotten a constraint we’d agreed on twenty exchanges earlier. The context had drifted, and so had the work. I’d pushed code that didn’t match what we started building.

Two things were going wrong at once. I was writing feature requests that were too large for one chat to hold. And I wasn’t clearing context between tasks, so old decisions were polluting new ones. The combination meant the model was operating on a context window that was too crowded and too stale. Long chats accumulate context the way a bad meeting accumulates topics. By the end, nobody remembers what decisions were made in the first half. What I needed was Claude working off a ticket.

Tasks (or tickets) force a clean start. When the task is done, you close it and the next task starts fresh. That’s how engineers work in agile: small, scoped, written down. It’s also how the rest of the tooling already works. Jira and Linear are built for this. Tickets, scoped, built, closed, next. Agents fit perfectly into that flow - we don’t need chats, we need scoped tasks.

The other thing tasks unlock is parallelism. I tried the parallel version first in chats — five terminal windows, five Claude sessions, switching between them. Lost my place inside ten minutes. With proper tasks, you spin up ten agents working independently and come back to the outcomes. Tasks aren’t a UI choice. They’re how you scale beyond one of you.

2. Servers not terminals

I was in the garden all day, but I had a big refactor going through review on my laptop. Over fifty rounds of cloud-bot feedback, fixes, test runs, more feedback. I had set the agent up with a /loop command to handle the cycle: read review, fix, test, push, wait for next review, repeat. Then I went outside.

Except I brought the laptop with me. I had to check it every ten minutes to make sure the agent didn’t get stuck on a permission prompt, a failed test, or a question it couldn’t answer. The agent was running. And I was still tethered to it, just from twenty metres away.

Another time I had several agents working on things, closed the laptop and stepped away for an hour. Came back to dead sessions and lost progress.

Both failures point at the same thing. The promise of an agent is that it works while you’re not there. But “not there” turns out to mean “still at the keyboard” — or “still checking every ten minutes.” Close the laptop and the work stops. Stay close enough to monitor and you haven’t actually freed up your time. The agent isn’t independent of you — it’s tethered to your attention. That’s the meme of engineers carrying open MacBooks around the office, balanced on forearms. The tools are fighting the shape of how agents are supposed to work.

3. Async not synchronous

I want a hundred developers working on my ideas in parallel. Not one agent I have to babysit.

I have ideas faster than I can supervise execution. Most engineers do. The bottleneck isn’t generating work; it’s overseeing work. I can only run a few agents at a time because I can only watch so many at once.

Async inverts that. I queue work. The agents run. I come back to outcomes. The interaction shifts from “watch” to “review what’s done.” The supervision cost stops being proportional to the number of agents running.

This is the difference between delegating and pair programming. Pair programming is great. It’s also what every current tool optimises for, because pair programming is what one engineer does with one assistant. Delegating is what a manager does with a team. The shape is fundamentally different. The tools haven’t caught up yet.

4. Fleet not single agent

Five terminal windows. Five Claude sessions. Five worktrees. Different tasks, different repos, different branches.

By window three I’d lost track of which one was working on what. Window four had a question waiting that I never saw because I was answering window two. And then worse: I told agents to commit and push, and they did – to the wrong branches. The agent did what I said. I was the one who couldn’t keep five contexts straight in my head. I’ve committed the wrong work to the wrong branch more than once.

Stacking windows isn’t fleet operation. It’s pretending to be the orchestrator of a system that doesn’t have orchestration built in. The cognitive overhead of tracking five worktrees, five tabs, five branches eats the productivity gain of parallelism. And it produces actual mistakes I have to spend hours cleaning up afterwards.

The orchestration needs to be part of the product. One place to see all running agents; what state each is in, which branch, which need attention. Then the cognitive load goes down. That’s the only way fleet-scale work is possible.

5. Pipeline not freeform

The agent kept skipping steps.

I’d ask it to write tests first. It would write the implementation first and bolt tests on after — or skip them entirely. I’d tell it to verify the output. It would declare the work done without checking anything. I’d put “review your changes against the spec before you finish” in the prompt. It would acknowledge the instruction and then not do it.

I’ve seen this first hand more times than I want to admit. The advice you’ll get is “write better prompts” or “use a system prompt for the rules.” Neither worked reliably for me. The model was optimising for what looked like a good answer in the context window — not for the instruction buried twenty messages ago, not for the system prompt competing with the user’s actual request, not for the rule that contradicted the path it had just committed to. When the structure is words, the words get weighted against everything else.

The fix isn’t a longer prompt. It isn’t louder instructions. It isn’t please for real this time write the tests. The fix is to take the steps out of the prompt and put them in the system. A pipeline runs the stages in the right order. It refuses to advance when a stage doesn’t pass. The agent doesn’t get to skip the verification step because the verification step isn’t a thing the agent decides about — it’s a gate the runtime enforces.

Spec, plan, review, test, ship. Each stage with a verification gate. The agent works inside the stage. The stage is what makes the structure load-bearing.

This is where this piece connects to the last one. The previous Field Note was about closing the loop — the loop has two halves, verification and heartbeat, and both have to be real. A pipeline is what a load-bearing loop looks like in practice. The heartbeat is the pipeline advancing. The verification is the gate at each stage. The flexibility lives at the spec layer, not the execution layer.

I was tired of agents skipping the work. I wanted the system to enforce it.

What this points at

Five moments. Five frustrations. Five principles. They look separate, but they’re angles on the same realisation.

Existing tools are converging on a specific shape — single-task, single-agent, single-screen, synchronous, freeform. Optimised for one engineer at a keyboard, exploring. That shape is genuinely good and getting better. If that’s the work you do, you’re well served.

The shape of the work I actually do is different. Across tasks. Across repos. With memory in the system, not in my head. With agents that keep going when I close the laptop. With outcomes I review, not sessions I watch. That’s the shape that produces quality. Not better prompts. Not bigger models. Better constraints, better structure, better surface for the operator.

That’s the second direction. Tasks instead of chats. Servers instead of terminals. Async instead of synchronous. Fleet instead of single agent. Pipeline instead of freeform. It’s not better than what Claude Code and Codex and Cursor are building. It’s a different answer to a different question. And almost nobody is building it.

That’s what Lotsa (previously Pilot) is. The first version will be open-source — small, focused, local. It’s also the version I’m using to build the next versions. Recursive credibility, or just dogfooding, depending on how generous you’re feeling.

If you've felt any of the five moments above, you're the audience for what I'm building. That's Lotsa.

Try Lotsa →

The next Field Note is in two weeks. If you want it in your inbox, subscribe below.

Close the loop: verification and heartbeat for AI coding agents

Sun, 03 May 2026 00:00:00 +0200

Agents only get useful when they can verify their own work. That’s the bit nobody can skip. Without it, the speed gains evaporate the moment the agent makes a confident mistake. Which it will, and the human has to read every line to catch it. With verification, the agent corrects itself before the human sees the diff.

Peter Steinberger calls this closing the loop. His work on OpenClaw is a clear demonstration of what it looks like in practice. I’ve been working on the same problem from a different angle, building Lotsa (previously Pilot). The principle is universal. The shape of the loop isn’t.

The loop has two halves

The loop is two things, not one. They’re easy to conflate and worth separating.

Verification is what gets checked. Tests run. Linters pass. The compiler is happy. The output matches the spec. Steinberger has invested a lot here. He picks CLI-first services (vercel, psql, gh, axiom) because agents can drive them and read their output. He builds custom CLIs when one doesn’t exist. The verification surface is rich, fast, and machine-readable. That’s the work.

Heartbeat is what advances state. What triggers the agent to act. What decides what happens next. For a solo developer, this is the developer — they prompt, the agent runs, they review, they prompt again. When it’s automated, it’s time-based or run-based. Simple alarms. Generic.

Both halves are right for solo work on personal projects. Tight verification, lightweight heartbeat, no compliance surface, no team coordination, no audit requirement.

The shape of the loop depends on what you’re building

This is where it gets interesting.

If you’re shipping a Twitter analytics tool by yourself, the loop is what Steinberger describes. Tests, lint, compile, eyeball the diff, ship. Anything more is overhead.

Take that same setup and point it at a customer-facing product with a team of eight, and the loop expands. Verification grows to include review — not as advisory, as a gate. The heartbeat gets shape: pipelines, environments, deployment windows. Multiple people need to know what’s happening and when.

Point it at software that touches patient data or financial transactions (DORA, GDPR, MDR, HIPAA, NIS2), and the loop expands again. Verification picks up sandbox isolation, governance review, audit trail capture, signed approvals at specific gates. The heartbeat stops being a clock. It becomes state-aware:

Wake when the spec is approved AND the test suite is green AND a human reviewer has signed off AND the audit log is written

That’s not a cron job. That’s a pipeline.

The principle Steinberger names — close the loop — doesn’t change. The shape of what gets closed does. And the shape isn’t a philosophical choice. It’s a function of what the system touches and who has to answer when something goes wrong.

Generic heartbeat, structured heartbeat

Here’s the part I think doesn’t get said enough.

A generic heartbeat — time-based, run-based, prompt-driven — makes a runner. It executes things. It’s flexible. It’s fast. What you want for exploratory work!

A semantic heartbeat — state-aware, pipeline-driven, fail-closed — makes a workflow. It executes things in a specific order, with specific preconditions, and refuses to advance when those preconditions aren’t met.

Most coding harnesses today — Claude Code, Codex, Cursor, Aider — are runners. That’s not a criticism. It’s a design choice that fits the work most of their users are doing. You can bolt structure on top with hooks, custom slash commands, CLAUDE.md conventions, custom CLIs. The structure is advisory. Nothing fails closed. The guardrails are walls you can paint on, not walls that hold weight.

For solo work, that’s the right default. The flexibility is the feature.

For team-scale work in regulated industries, the default inverts. You want the structure to be load-bearing. You want stages that fail closed. You want the heartbeat to refuse to advance when the spec isn’t approved or the audit log isn’t written. You want flexibility to be the exception you fight for, not the default you fight against.

What the next generation has to answer

The verification has to be real. The loop has to close. Teams not getting the desired results with AI coding agents are likely failing at this layer. Because they haven’t done the investment work. Steinberger has shown what doing it the right way looks like at one end of the spectrum.

The loop a solo developer needs to close looks very different from the one a regulated team needs. Same principle, different physics.

That’s the question the next generation of agent infrastructure has to answer. Not whether to close the loop. What the loop needs to include, given the work, the team, and the risk surface.

It’s the question Lotsa is built around.

My next piece will review what tools start to look like when the loop has to be built in. When the heartbeat is state-aware, the pipeline fails closed, and the flexibility lives at the spec layer instead of the execution layer. There’s a second direction worth taking, and almost nobody is building it.

That one’s filed in two weeks. If you want it in your inbox the day it goes live, subscribe below. Otherwise, see you on LinkedIn.

AI isn't magic dust. It's a multiplier.

Mon, 27 Apr 2026 00:00:00 +0200

Executives want AI gains. They’ve read the headlines. They’ve seen the demos. They’ve watched competitors post wins. Now they want their teams shipping faster. That’s the right direction. But AI isn’t magic dust you can spinkle on a tired codebase. It’s an investment in tooling.

I use AI coding tools every day. I’m building an AI agent orchestration platform. When AI works, it’s extraordinary. I’m not here to downplay that.

When people read “Spotify’s engineers don’t write code anymore” they conclude the answer is to just use AI.

That conclusion is wrong. The data is starting to prove it. The reason has nothing to do with how good the models are. Most AI coding success comes from greenfield work. Most engineers don’t work in greenfield.

Greenfield versus the iceberg

AI works great in greenfield projects. Empty repository. Fresh context. No constraints. No history. The model has everything it needs because there’s nothing it doesn’t have. You ask for a Next.js dashboard with auth and a payment flow. It builds you one in an afternoon. The demos and viral wins come from this mode.

Now look at what most engineering work is.

A legacy codebase is like an iceberg. The code in front of you is the small part above the waterline. The bulk of what matters lives elsewhere. Why this service owns that table. Why we wrap that SDK instead of calling it direct. Which module looks harmless but holds up three downstream consumers. That knowledge sits in senior engineers’ heads. In three-year-old Slack threads. In post-mortems nobody re-read. In decisions that were obvious at the time and are now invisible. The model can read every file in the repo and still miss the one fact that matters.

AI works on icebergs too. It just needs much more upfront work to get there. The context the model gets for free in greenfield has to be built and maintained in legacy. That’s the part nobody talks about in the demos.

That’s why the same AI tool that builds a clean prototype can produce broken code in your production codebase. Same model. Same prompts. Different problem.

What changes when the codebase is real

Three things bite hardest in legacy work.

The AI doesn’t know what your senior engineers know. This is the iceberg problem made operational. Your senior engineers carry the why. What we tried before, what burned us, why this pattern instead of that one. The AI doesn’t have access to any of that. It defaults to the average of its training data, not your conventions. Without strong rules and examples to anchor it, AI produces code that looks plausible but doesn’t match what’s around it. House style drifts. New patterns sneak in alongside old ones. Multiply that across a hundred pull requests and your codebase ends up with two competing styles. Worse for the humans reviewing it, worse for the next round of AI working on top of it.

AI speeds up writing. Everything else stays the same speed. A clean diff in a fresh repository is easy to review. The same diff touching six legacy modules isn’t. Someone has to verify it doesn’t break invariants, regress performance, or trip a regulatory line. Writing was never the bottleneck in legacy work. Reviewing was. AI widens that gap. And the agent itself only gets better when it can run, test, and verify its own work. Which means it’s only as effective as your test infrastructure. If your tests are slow or unreliable, the AI can’t tell when it’s wrong, and a human has to babysit every change.

The cost of being wrong is asymmetric. A mistake in greenfield means a rewrite. A mistake in production legacy means an incident, a rollback, a regulatory finding, a board call. The risk-adjusted cost of an AI error in a mature system is an order of magnitude higher than in a prototype. That’s why the governance overhead — specs, reviews, staged rollouts, audit trails — isn’t friction to remove. It’s friction that exists for reasons.

What Spotify and Stripe built

This is also why the Spotify and Stripe stories get misread.

Spotify didn’t adopt an off-the-shelf coding agent. They built their own. Their engineering team needed a tool they could plug into the rest of their infrastructure. Something that lets them swap models and wrap AI in their own quality controls. None of the tools you can buy could do that.

Think about what that means. One of the most engineering-mature companies in the world looked at the available AI coding tools and decided none of them worked. So they built their own — on top of years of platform investment they’d already made. The AI is the small new piece sitting on top of a much larger system they’ve been building for over a decade.

Stripe’s Minions tell the same story. 1,300+ autonomous pull requests a week sounds impressive. Then you see what sits underneath. Years of investment in developer tooling. Strict guardrails around what the AI can do. A hard rule: if the agent can’t fix a failing test in two attempts, a human takes over.

What Spotify and Stripe did, in effect, is make their existing codebases behave more like greenfield from the AI’s view. Years of platform work made the institutional knowledge legible. The right way to build something became the obvious way. AI plugged into that and turned good practices into great ones.

They didn’t sprinkle AI on their problems. They didn’t even use the AI tools you can buy. They built their own, on top of years of platform work, because that’s what it takes to make AI work at scale.

The data is catching up

A 2026 Harness report surveyed 700 engineers and technical managers across five countries. The headline: 73% of engineering teams have no standardised templates or golden paths. Three quarters of teams are trying to adopt AI on top of bespoke, inconsistent foundations.

Among developers using AI tools multiple times a day, 51% report more quality problems and 53% report more security incidents than before. Not fewer. More.

Sonar’s 2026 State of Code survey backs this from the developer side, with 1,100+ respondents. Adoption has gone mainstream. 72% of developers use AI tools daily. 42% of all committed code is now AI-generated or assisted, on track to hit 65% by 2027.

But look at the trust numbers. 96% of developers don’t fully trust AI-generated code. Only 48% always verify it before committing. We’re shipping huge volumes of code we don’t trust, through verification layers that weren’t built for this speed.

The effectiveness gap is just as telling. 90% of developers use AI for new code. Only 55% rate it effective for that. 72% use it for refactoring. Only 43% find it effective there. AI shines at documentation, test generation, and code review. It struggles with the architectural work where judgement matters most.

The bottleneck didn’t disappear when AI arrived. It moved.

The bottleneck moved — to the bookends

The story most people tell is that AI eliminates work. The reality is that AI moves it. To the two ends of the process most teams have underinvested in for years: specification and review.

Specification. The blank page problem used to be writing the first line of code. Now it’s writing a good enough spec for the AI to work from. An AI agent only produces good code if it understands what “good” means in your context. That needs clear requirements, architectural constraints, defined contracts between services, and someone who knows what the right answer looks like. Vague specs in, bad code out. Now it’s bad code at 10x the volume.

I’m seeing this in my own team. A stakeholder asks for “a dashboard.” The spec gets written. The team builds it. The stakeholder says “that’s not what I wanted.” The spec said absolute numbers. The stakeholder expected funnel metrics. Nobody caught the mismatch. AI or no AI, that’s a specification failure. With AI, the cost of building the wrong thing drops to hours instead of weeks. That makes the mismatch invisible until you’re five iterations deep.

Review. Someone has to verify what AI produced is correct, safe, and maintainable. Sonar’s data suggests most teams skip this. 52% of developers admit they don’t always verify AI code before committing. That’s not laziness. That’s a review process that was never designed for this volume.

Both bookends need investment. Better specification discipline upstream. Stronger review tooling and culture downstream. “Generate code faster” alone just means failing in both directions at higher speed.

What “foundation” actually means

If you’re going to make your codebase the kind of place AI can work, here’s what the work looks like.

Standardised environments. Every engineer should be able to spin up a working dev environment in minutes. Same config, same dependencies. If developer onboarding takes a week of “figure out why it doesn’t build on your machine,” AI agents will hit the same wall.

Golden paths. Templates for how new services and features get built. Not a wiki page nobody reads. Real scaffolding that makes the right way the easy way. Without them, AI produces a new snowflake every time.

Clear ownership. Every service has a specific owner. Not a team-of-everyone. AI can write the code, but someone has to make the architectural calls and live with the consequences.

Real test coverage. Tests that catch regressions, run fast, don’t lie. AI-generated code is only as safe as your ability to verify it. Brittle tests mean you trust blind or review every line by hand. Both are bad.

Working CI/CD. If your deployment pipeline is held together with bash scripts and hope, AI ships broken things faster than you can roll them back.

Tacit knowledge made legible. Architecture decisions in writing. Conventions in linters. House style in rules files. The institutional memory layer needs to become machine-readable, or the AI works blind.

Most engineering organisations have none of this. A few have some. Almost nobody has all of it.

Where most teams actually are

I’ve been writing about AI coding as a spectrum of maturity. Four stages, from prompting to orchestrating.

Stage 1: prompting. Copilot-style autocomplete. Useful but it’s the floor.

Stage 2: assisting. Cursor, Claude Code. The AI is a pair programmer. Still engineer-led.

Stage 3: delegating. Engineers hand off bounded tasks to agents that run semi-autonomously, with review. This is where real productivity gains compound.

Stage 4: orchestrating. Engineers design systems of agents handling parallel work with structure and guardrails. This is Spotify. This is Stripe.

Most teams are between Stage 1 and Stage 2 and think they’re at Stage 3. The gap isn’t about how smart the AI is. It’s how much infrastructure you’ve built to work with it. You can’t delegate if your environments are flaky. You can’t orchestrate at scale without golden paths. Your foundation decides which stage you can reach.

In greenfield, you can skip straight to Stage 3 because there’s no foundation work to do. In legacy, the foundation work is the work.

Why leadership keeps getting this wrong

The pattern: a non-technical leader reads about Spotify on LinkedIn, sees a demo, feels competitor pressure, and tells engineering to “use AI more.”

This misses the point so badly it makes things worse.

AI is a force multiplier. It multiplies whatever you have, including your problems. Solid foundation, real leverage. Platform held together with tape and a team firefighting every week, you now get bad code at unprecedented speed. That’s not a win, even if velocity charts look great for a quarter.

There’s also a governance blind spot most leadership doesn’t see. Sonar found 35% of developers access AI coding tools through personal accounts rather than work-sanctioned ones. A third of AI usage happens outside whatever security, compliance, or quality guardrails the company thinks it has. “Just use AI” without sanctioned tooling is shadow IT in your codebase.

The companies winning with AI aren’t the ones who adopted fastest. They’re the ones who did the unglamorous platform work first. Backstage is ten years old. Fleet Management has been running for three. Stripe’s developer productivity infrastructure predates their AI initiative by years. Not lucky accidents. The point.

What this means if you’re leading

The real question isn’t “why aren’t we using more AI?” It’s “is our foundation ready for what AI will amplify?” If the honest answer is no, the fix isn’t more AI pressure on engineering. It’s investment in the boring infrastructure that makes AI possible.

That means funding platform teams who don’t ship user-facing features. Accepting that “standardise our dev environments” is a quarter of work without obvious output. Trusting your engineering leaders when they tell you the foundation needs attention before AI can help.

It also means investing in the bookends. The specification discipline that tells AI what to build. The review tooling that catches what it builds wrong. Sanctioned tools, clear policies, proper access. Not “figure it out.”

“Faster code generation” isn’t the goal. “Shipping better software faster, safely, at scale” is. AI is one tool for that. It’s not the tool.

Start now anyway

Here’s where executives are right. You can’t wait until your foundation is perfect before letting your team use AI. You won’t know where your foundation fails until you start putting AI through it. The mismatched dashboard spec, the AI agent that produced something off-style, the regression nobody caught — those aren’t reasons to slow down. They’re the diagnostic.

The teams that start now learn faster. They find the gaps in their tests, the missing rules files, the conventions that lived in someone’s head. They feel the review bottleneck and start investing in tooling for it. They notice when specs are too vague to produce good output, and they tighten up.

The teams that wait until they’re “ready” never get ready. The foundation work isn’t visible until AI puts pressure on it.

So: start using AI now. Pay attention to where it produces friction. Then invest in fixing those things — not a generic “platform modernisation” project, but the exact gaps your AI usage exposed. That’s the loop. AI as both the goal and the instrument that tells you what to build.

What you don’t do is mandate AI without giving the team time to do the foundation work. That’s the version that fails. The version that works is: use AI, learn from it, fix what it exposes, repeat.

Why I’m building an orchestration layer

This is why I’m building Lotsa (previously Pilot) — an orchestration layer for AI coding agents.

Not because the world needs more AI hype. It doesn’t. Because the missing piece between “engineers using AI” and “organisations getting real leverage from AI” is structure. Guardrails. A way to enforce the engineering discipline that separates Spotify’s Honk from a team shipping bad code at unprecedented speed.

Companies with Backstage-scale internal investment will build their own. Everyone else needs something they can adopt. Something that gives them the guardrails without a decade of platform engineering first.

This is the gap Lotsa is built for. Still early days, but if any of this resonates, take a look at where it's headed.

Try Lotsa →

Where are you on this?

If you’re trying to make AI coding work for your team and hitting the same walls — I’d love to hear your story. I’m collecting real cases from people navigating this, and happy to help think it through.

Drop me a note.

Sources

Harness, State of DevOps Modernization 2026 — press release
Sonar, State of Code Developer Survey 2026 — report
Spotify Engineering, Honk series — Part 1
TechCrunch on Spotify’s AI coding announcement — article
Stripe Engineering, Minions — blog post

How I Work With AI Agents — A "Stage 3" Field Guide

Tue, 07 Apr 2026 00:00:00 +0200

I wrote about the four stages of AI coding — from prompting to orchestrating. That article mapped the progression. This one is the field guide for Stage 3. The stage where you stop assisting the AI and start delegating to it.

You’ve asked ChatGPT for code. Maybe you use autocomplete in your editor. That’s Stage 1 and 2 — and they work. But there’s another gear. It changes how you spend your time.

If you delegate work to AI agents already, I want to hear your experience. Compare notes with me. Here’s what 72 sessions, 735 messages, and 118 commits taught me. All while building an agent orchestration platform to solve the very problems this article describes. How I’m using Stage 3 to build Stage 4. More on that soon.

The mindset shift

Here’s what surprised me most. The value of AI agents isn’t speed. It’s that scoping and verification become the main activity. Code becomes the byproduct.

I spend more time scoping the work than the implementation takes. That sounds inefficient. The results say otherwise — far better than when I let the agent just run.

This flips the developer’s role. In Stage 1-2, you do the work and AI assists. In Stage 3, the AI does the work and you make judgement calls. The skill shifts from “writing code” to “specifying intent.” You describe what you want. The agent executes. You verify the result.

Think of cooking. Stage 2 is someone reading you tips while you cook. Stage 3 is handing a recipe to a sous chef and tasting the result.

Sound familiar? It should. This is traditional software engineering — scope, plan, review, verify — moved up a layer. The thoughtful work hasn’t gone anywhere. It’s just no longer the code itself. It’s everything around it. This is why I don’t think engineers are getting replaced — the job changes, the judgement doesn’t.

Now the uncomfortable truth. Stage 3 is both breakthrough and bottleneck. You ship faster than ever. You also babysit more than ever. Those bad experiences people report — sloppy output, hallucinated fixes, diffs nobody can review — aren’t model problems. They’re system problems. The models are extraordinary. The system around them makes or breaks the output.

Here’s the system I’ve built.

Want the quick-reference version? Here’s the cheat sheet.

The foundation: the rulebook

Before any task starts, set up the rulebook.

Your AI agent has no memory between sessions. Every convention, every pattern preference, every “don’t do this” — write it down. The agent reads it at the start of every task. Without it, you’re re-explaining your standards from scratch every time.

The core file is CLAUDE.md (or AGENTS.md if you want a tool-agnostic name). Checked into git. Holds coding conventions, design patterns, git workflow rules, and standing instructions. One of those instructions: always verify your work and show the output. This file is your engineering culture, translated for the agent.

Keep it under 200 lines. Bloated rulefiles eat context and adherence drops. If a rule belongs in a linter or formatter config, it doesn’t belong here. Litmus test: “would removing this rule cause a mistake?” If not, cut it.

Around that core file, three mechanisms keep it lean:

Rules — modular instruction files that load alongside the core rulebook. Split by concern: code style, testing standards, API conventions. Path-scoped rules only activate when the agent works in matching directories. Zero wasted tokens.

Skills — on-demand expertise the agent invokes when the task matches. A deployment checklist. A database migration guide. A security review workflow. Skills can bundle supporting files and even spawn subagents with restricted tool access; e.g. a code reviewer that can only read, not write.

Permissions — allow and deny lists that control what the agent can run. Pre-allow your build and test scripts. Deny destructive commands and .env reads. This helps — but it doesn’t solve the problem. You’ll still spend time pressing “Allow” on prompts the agent shouldn’t need to ask about. It’s one of Stage 3’s biggest friction points and part of why the ceiling exists.

For a deep dive on the full folder structure, Avi Chawla’s Anatomy of the .claude/ Folder is an excellent walkthrough.

The compounding loop is the real payoff. A mistake happens. You add a rule — or improve a skill. The agent stops making that mistake. Over weeks, the rulebook captures institutional knowledge. Every session gets better than the last. It’s like onboarding a new hire — except this one reads the docs. And because it’s in git, the whole team benefits from every rule anyone adds.

The workflow: Scope → Plan → Execute → Verify → Wrap-up

This is the workflow for every task. Scoping and verification take 80% of your time. The agent executing takes 20%. That ratio feels wrong until you try it. It’s why the results are good.

Scope

This is the game changer, the mindset shift. For anything beyond a trivial task, scope the work before the agent writes a line of code.

Scoping is a conversation. You know what you want — you just haven’t articulated it with enough precision to build against. “Should we use YAML configs or a database table?” “What are the edge cases?” “How does this interact with the auth flow?” You go back and forth. Poke holes. Define boundaries. I use the agent for architecture decisions and system analysis. It thinks through trade-offs I’d sketch on a whiteboard.

One critical rule: never inject new ideas mid-scope. The agent will blend them into the current feature. You won’t notice until the PR review. Then you’re untangling two features from one branch. Finish the task. Commit. Clear context. Start fresh.

The mistake that taught me this? Vague direction. The agent built the wrong thing. Confidently. Multiple times. The fix was always the same — tighter scoping.

Plan

Scoping is the conversation. The plan is the artifact that comes out of it. It’s the concrete, scoped task definition you hand the agent when you switch from scoping to execution.

An agent plan isn’t a regular engineering spec. An agent can’t read between the lines. It can’t ask the PM a clarifying question. It will fill any gap with its own assumptions. A good agent plan covers five things:

What to build — scoped tight. Not “add user notifications.” Instead: “add an email notification when a patient appointment is confirmed, triggered from the booking service, using the existing email template system.”

What not to touch — the most important part for agents. They love to “improve” nearby code. Explicit boundaries prevent scope creep. “Don’t modify the API layer. Don’t refactor existing tests. Don’t change the database schema.”

How to prove it works — the verification contract. Define this upfront, not after the code is written. “Write integration tests for the new notification path. Run the existing booking test suite. Confirm nothing breaks. Show me the test output.”

Constraints on approach — which libraries, which patterns, where to put the code. Without this, the agent picks its own path. “Use the existing EmailService. Don’t introduce a new dependency. Follow the repository pattern from the booking module.”

Definition of done — what does the PR look like? “One commit. Tests passing. Linter clean. Diff under 200 lines.”

That last point matters. A good plan keeps changes small. You’ve broken the work into pieces during scoping. Small changes are reviewable. Reviewable changes are verifiable. Break this chain — vague plan, huge diff, no tests — and the whole thing collapses. This is why people have bad AI experiences. They skip the plan. The agent runs wild. They get a 2000-line diff. They can’t review it. They conclude “AI coding doesn’t work.” Well,the agent wasn’t the problem, the scope was.

For anyone at Stage 1-2: this one thing will change your results the most. A tight plan turns a bad AI experience into a productive one.

Execute

Hand the agent the plan. Let it work.

This is the 20%. The agent writes code, guided by the plan and the rulebook. Your job during execution is to watch, not steer. If you find yourself correcting the agent mid-task, the plan or the rulebook needs updating — not the conversation.

Large-scale refactors still work at this stage. I’ve landed architectural changes with 112 tests passing across many files. But you verify each step before starting the next. A refactor is a sequence of small, verified steps. Not one giant leap.

Verify

The form varies. The discipline doesn’t.

Never trust the agent’s claim that something works. Trust test output. Trust logs. Trust a running application. The agent will tell you it fixed the bug. Don’t take its word for it. Make it show you.

This isn’t about strict TDD — though TDD is one excellent approach. The principle is broader. The plan already defines how the agent proves its work. Now you hold it to that contract.

What verification looks like depends on the task:

New feature: “Spin up the full stack. Walk through the user flow. Show me the response at each step.”
Bug fix: “Run the integration suite before and after. Show me both outputs.”
API change: “Hit the endpoint with real payloads. Show me the request and response.”
Refactor: “Run the full test suite. Every existing test must still pass. Then start the app and smoke test the affected flows.”
Frontend change: “Start the dev server. Load the page. Describe what you see.”

My tightest feedback loop is the PR review cycle. The agent reviews a diff. I triage by severity. The agent fixes each finding. Runs tests. Shows output. Commits. Pushes. I’ve done eight rounds in a single session. The agent handles multi-file edits and test verification. I make the judgement calls.

PostToolUse hooks auto-run formatters and linters after every edit. The system enforces standards. The agent doesn’t have to remember. Across 72 sessions I logged 1,425 shell calls. Running. Testing. Verifying.

The behavioral shift for your first session: the agent says “done, it should work now.” Don’t accept it. Say “show me the test output.” That one habit changes everything.

Wrap-up

Tests pass. Linter clean. Diff reviewable. Now finish the job.

Commit and push. Open the PR. Then — before you start the next task — stop and ask: what went wrong? What took longer than it should have? Did the agent pick a wrong approach? Miss a convention? Hallucinate a fix?

Every answer is a new rule. Add it to your CLAUDE.md or improve a skill. This is the compounding loop. It takes thirty seconds and it makes every future session better. Skip it and you’ll hit the same problem next week. Do it and the system learns.

Then clear context. The current session is done. Start fresh for the next task. One task, one session.

The discipline: context hygiene

The kitchen-sink anti-pattern

AI agents degrade as context grows. Mixing unrelated tasks in one session is the fastest path to bad output.

You start one task. Ask something unrelated. Go back to the first task. Now the context is full of noise. During scoping, this is catastrophic. The agent bakes two separate features into one design. You don’t notice.

Wrap-up handles this — clear context after every task. But for long-running tasks that span multiple sessions, capture the goal, progress, and next steps in a handoff document before starting fresh.

I’ll be honest — I don’t do this enough. I know it’s right. I keep skipping it. Every time I skip it, I regret it.

Parallelism

Once you’ve dialed in the rest, run multiple agent sessions at the same time. Git worktrees make this work. Each worktree gets its own session. Changes don’t conflict.

This is the biggest throughput multiplier. But it’s listed last for a reason. The manual orchestration is exhausting. You get 3-4x throughput. You also context-switch between sessions, track what each agent is doing, and resolve conflicts when branches collide.

This is where Stage 3 hits its ceiling. You’ve optimised the agent’s work. Now you’re the bottleneck again. Not as a coder. As an orchestrator.

The honest accounting

What still goes wrong

Wrong approach — 19 times in 72 sessions, the agent picked the wrong library, pattern, or architecture. The plan didn’t constrain the approach enough. Or the agent explored when the task was clear. “Just build it” is a valid instruction.

The infinite debug loop — The agent claims it found the issue. Applies a fix. Tests fail. Claims it found the real issue. Applies another fix. Tests fail again. This loops forever if you let it. The escape: tell the agent to stop. Research the issue. Find the root cause first. This helps unlock it.

Context pollution — The kitchen-sink problem again. The agent references things from earlier that aren’t relevant. Quality drops in ways that are hard to spot.

Regressions — The agent fixes one bug and breaks something else. This is why “commit before you debug” matters. Commit your working state first. Then ask the agent to fix. If the fix introduces a new problem, you can roll back clean.

Selective hearing — The agent doesn’t always follow instructions. You write clear rules. It ignores half of them. Or worse — two rules conflict and the agent picks whichever it saw last. The rulebook helps. But agents still drift, especially in long sessions. You catch it in review. Or you don’t, and it ships.

Setup overhead — Every repo needs its own rulebook. Rules, skills, permissions — built from scratch each time. The system works once it’s set up. Getting it set up is the tax. Until then, I’m typing the same instructions, session after session.

Messy PRs — This is the one that burns. The agent mixes features. Mixes concerns. Commits land on the wrong branch. Sometimes the agent forgets an entire branch of commits and opens a PR that’s almost empty. You stare at a diff that should be clean and it’s a tangled mess of unrelated changes. All the time you saved writing code, you spend untangling the PR. This is Stage 3’s ugliest failure mode. It comes back to scoping, planning, and keeping changes small — but even when you do everything right, it still happens.

What I’m still figuring out

How to set the right configuration balance. The agent over-plans when I want code. Under-plans when the task is complex.

How many upfront constraints to provide. Too few and the agent picks a wrong approach. Too many and I might as well write the code myself.

When to let the agent drive versus when to steer. And using context clearing — the habit I know matters and keep neglecting.

Where Stage 3 hits the ceiling

Close the laptop — the agent stops. Go to a meeting — it sits there waiting. Run four sessions at once — you’re babysitting, not engineering.

The time you save writing code, you spend supervising agents. This isn’t a model problem. It’s an infrastructure problem. Autonomy. Sandboxing. Enforced pipelines. Hosting that doesn’t die when your lid closes.

Stage 3 is powerful. But it’s a ceiling. And the ceiling is you.

I’m building toward a system where agents run against a queue of plans, with enforced pipelines and sandboxed execution. No laptop lid required. Stage 4. That’s a different article — follow me if you want to see where it goes.

Where to start

If you’ve read this far, here are concrete starting points.

If you’re at Stage 1 (prompting, copy-paste): Pick an agentic tool. Give it a real task — not a toy exercise. Take a bug from the backlog. Write one paragraph: what’s wrong, what “fixed” looks like. Let the agent work. Watch what it does. One real task teaches more than ten tutorials.

If you’re at Stage 2 (pair programming, autocomplete): Give the agent a whole task instead of guiding it line by line. Start with a PR review cycle — low risk, high learning. Point the agent at a diff. Ask it to review for bugs and logic errors. Let it fix what it finds. You triage. You keep full control but experience the delegation model.

If you’re ready to go deeper: Start your next feature by scoping it with the agent. Spend twenty minutes defining the boundaries before any code. Write the plan with all five components. What to build. What not to touch. How to prove it works. Constraints. Definition of done. Then let the agent execute. Watch the difference.

For the team: Start a CLAUDE.md. It doesn’t need to be complete on day one. Add three conventions you wish the agent would follow. Next time it makes a mistake, add a rule. In a month, every session gets better. Because it’s in git, every person benefits from every rule anyone adds.

The system in one line: Scope → Plan → Execute → Verify → Wrap-up. The form varies. The discipline doesn’t.

Want the quick-reference version? Here’s the cheat sheet.

I went from sceptic to running multiple AI agents across a production codebase. It’s not magic. It’s not effortless. But it compounds. Every session teaches something. Every rule makes the next session better.

The gap between “AI coding doesn’t work” and “AI coding is the biggest force multiplier I’ve found” is a system. This is mine.

I want to hear yours.

If Stage 3 is your ceiling right now, Stage 4 is what comes next. I'm building the infrastructure for it — that's Lotsa.

Try Lotsa →

From Prompting to Orchestrating: How AI Coding Evolves

Sun, 22 Mar 2026 00:00:00 +0100

AI coding is extraordinary. Let me get that out of the way first. For small, well-scoped tasks, it’s magic. “Write me a function that parses this date format.” “Add a test for this edge case.” “Refactor this component to use hooks.” These land. The code works. It’s better than what I’d write myself, and it arrives in seconds.

But there’s a ceiling, and you hit it the moment the task gets complex. Multi-file changes. Features that touch several systems. Anything that requires sustained context, judgement calls, or a coordinated sequence of steps. That’s where the dream collides with reality.

People are asking me “Can’t we rewrite the whole app with AI?”, “Can we replace that vendor in a week?”, “Why do we still need a team this size?”. Every engineering leader I know is fielding these. The excitement is real, and good! The understanding of what it entails is not.

The gap between the promise and the reality isn’t an AI problem. The models are incredible — the one-shot results prove that. It’s an infrastructure problem. The tooling around the AI hasn’t caught up to what the AI can do.

Over the past few months, I’ve gone through a progression that I think most developers will recognise. There are four stages. Most of us are stuck at stage three.

Stage 1: Prompting

Like most people, I was sceptical at first.

I asked ChatGPT to build me an app. It produced code. I pasted it into my editor, ran it — errors everywhere. Back to the chat window, paste the error, get a fix, paste that into the editor, run it again. Another error. Rinse and repeat.

At that point, I couldn’t see AI taking over engineering jobs. I still don’t — but our jobs are changing in ways I didn’t expect back then.

The “aha” moment came later, with smaller asks. A function here, a regex pattern there, boilerplate I’d spend twenty minutes on. For simple, contained tasks, the output was good. Real, usable code — not toy code.

But the workflow was absurd. I was a human copy-paste pipeline between a chat window and a terminal. The AI was fast; I was the bottleneck. I spent more time shuttling text between windows than thinking about the problem.

So I went looking for something better.

Stage 2: Pair programming

I tried Cursor. It didn’t click.

The idea is great: AI lives in the editor, sees your code, suggests the next line or block. Copilot, Cursor inline completion — autocomplete on steroids. The productivity bump is real for certain things. Boilerplate, tests, repetitive patterns. You move faster.

But it’s your pace. You type, it suggests. You drive, it navigates. You can’t step away from the keyboard.

This is where much of the early AI scepticism came from. Studies claimed engineers were not getting faster. At this stage, they had a point – you’re still doing the work. The AI is just an autocomplete.

For me as an engineering manager with a packed meeting schedule, this wasn’t the unlock. I didn’t have hours of uninterrupted coding time. I needed something I could point at a problem and walk away from. I wanted to describe the whole task, not guide the AI through it line by line.

Stage 3: Delegating

Then came Claude Code. The breakthrough.

I describe a task, and it writes the code, runs it and fixes errors. “Build me an invoice exporter that pulls from that API and archives to S3”. All in my terminal. 2 hours later, 500k PDFs on my laptop. I shipped more useful tools in two weeks than in my previous four years at the company. Invoice exporters, GDPR handlers, Jira-to-Linear migration scripts, an OCR receipt scanner — real tools that helped the business. All while keeping up my meeting schedule.

This feels like the dream. At first.

Then I try building bigger things and reality sets in. I call it the handholding problem.

You have to watch it. Close your laptop, the agent stops. Go to a meeting, it sits there waiting. Your working hours are its working hours.

You have to re-explain things. “Remember to run the linter.”. “Code Review bot found more issues on the PR”, 40 times(!), the PR took a week to close. “Don’t modify anything outside the /src directory.” Every session. Sometimes mid-session, after the context window compresses and it forgets your instructions without warning. You gave it clear rules ten minutes ago. Now it acts like it never heard them.

You have to catch it. It does things you didn’t ask for. Modifies files outside scope. Skips review steps you specified. Not out of malice — it doesn’t remember, or it decided it knew better.

You have to be there. The whole thing is synchronous, terminal-bound, tied to one machine. There’s no “fire and forget.”

I found myself running 4-5 Claude Code sessions at once, juggling git worktrees. Coordinating which agent works on what, switching between terminal tabs non-stop. Less engineer, more floor manager at a factory walking between stations, checking output, correcting course, putting out small fires.

The data backs this up. Surveys show developers save ten or more hours per week with AI tools, yet report no decrease in workload. The time they save writing code, they spend supervising it.

Delegating promised to free up my time. Instead I spend all of it babysitting.

And the worst part? I can see what stage four looks like. Fire-and-forget. Asynchronous execution. Agents running overnight while I sleep. No tool that exists today gets me there.

Stage 4: Orchestrating

This is where I want to be. Where I think the whole industry is heading.

Here’s what it looks like: I write a spec on my phone during my morning coffee. I queue it up. Agents pick it up, execute in sandboxed containers, run through an enforced review pipeline. A structured process that runs every single time and doesn’t forget a single step. The agents collect proof that the work meets spec. I check the results when I’m ready. After lunch or the next morning.

The shift: synchronous to asynchronous. Babysitting to reviewing. “I watch the agent work” becomes “I check what the agent produced.”

Single agent to fleet. Multiple specs running in parallel, not one terminal at a time.

Implicit trust — “I hope the agent did it right” — to verified trust. Review pipelines the system enforces, not the LLM’s memory. Proof collection that happens whether the agent feels like doing it or not.

Laptop-bound to infrastructure. Runs on a server. Accessible from anywhere. Doesn’t stop when I close my lid, lose wifi, or go to bed.

Few people operate here today. Not because the AI isn’t good enough. The models are extraordinary. The infrastructure to run them this way doesn’t exist yet.

The infrastructure gap

Why are we stuck at stage three?

The models can write code, fix bugs, refactor systems, and reason through complex tasks. They’re not the bottleneck. Every tool is. Every tool assumes a human is in the loop. Watching. On the same machine. Ready to click “approve” or paste an error or re-explain a constraint.

Four pieces of infrastructure are missing:

Autonomy. Fire-and-forget execution. Not terminal babysitting. Queue a task, walk away, come back to results.

Sandboxing. Isolated execution environments. Not agents running with full access to your personal machine, your SSH keys, your .env files. Containers that limit what the agent can touch — so you don’t have to watch its every move.

Pipelines. Enforced review steps that run every time. Not “the AI remembers to lint and test.” A structured process: code generation, automated review, human approval gates, proof collection. The system enforces it regardless of what the LLM decides to do.

Hosting. Server-based, remote-accessible infrastructure. Not your laptop. Not a terminal that stops when your lid closes. Something that runs while you sleep, while you’re in meetings, while you’re on a plane.

These aren’t product features. They’re infrastructure primitives that should exist for any AI agent workflow. Their absence is why we’re all stuck babysitting.

Where are you?

The progression from prompting to orchestrating is inevitable. The industry is moving there. The question is how fast the infrastructure catches up.

And it won’t be one stage for everything. I still one-shot simple tasks in a chat window — a quick function, a regex, analyse a csv. Pair programming in an IDE works for flow-state feature work. Delegating complex tasks to Claude Code is where the leverage is today. Different stages for different problems. The point isn’t to leave earlier stages behind. It’s to have stage four available when you need it.

So — what stage are you at? Copying and pasting from chat windows? Pair programming with autocomplete? Running multiple terminal sessions, wishing you could walk away?

I’ve gone from sceptic to orchestrating multiple AI agents in a matter of months. Now I’m building toward stage four. Things move fast — follow me if you want to see where it goes.

Stage 4 is what I'm building with Lotsa. Take a look at where it's headed.

Try Lotsa →

Build vs. Buy Is Over. Build Won — and Three Problems It Creates

Wed, 04 Mar 2026 00:00:00 +0100

The build-vs-buy equation has flipped. For decades, only the biggest companies could afford to build custom software. Everyone else bought SaaS — and overpaid for platforms they barely used. 80% of features in the average SaaS product are rarely or never touched. 53% of licenses sit idle. SaaS prices inflated at 5× the rate of general inflation while the products got more bloated, not more valuable.

SaaS companies left the door wide open. AI walked in and scored.

This has happened before

Jim Barksdale, the former Netscape CEO, said there are only two ways to make money in business: bundling and unbundling. It’s a cycle that repeats across every industry. Newspapers bundled news, classifieds, weather, and sports — then the internet unbundled them. Cable TV bundled hundreds of channels — then streaming unbundled it. Banks bundled payments, savings, and lending — then fintech unbundled them.

SaaS was the great bundling. Salesforce absorbed CRM, marketing, analytics, and support into one platform. Atlassian absorbed project management, docs, and code review. The playbook was always the same: land with one use case, bundle more features, raise prices, make switching painful.

AI is the great unbundling. When you can build a focused tool that does exactly what you need — in a day, for nearly nothing — the bundle stops making sense. Klarna ditched Salesforce and Workday, consolidated 1,200 apps. Linear hit $100M revenue with ~100 employees by doing the opposite of Jira: fewer features, not more. Companies aren’t leaving because AI is shiny. They’re leaving because the incumbents made themselves replaceable.

It’s cheap to build now. But somebody still has to maintain it.

I build internal tools with AI regularly. It’s genuinely incredible. Things that would have taken weeks ship in hours. The build-your-own era is real, it’s here, and it’s a massive unlock.

But it’s cheap to build now. Somebody still has to maintain it. Secure it. Govern it.

I run engineering in regulated health tech, and precisely because I’m building with AI every day I can see three problems emerging that most of the celebration is glossing over.

Governance

When Salesforce handled your CRM, Salesforce handled GDPR. When you build your own, that burden transfers to you. Most companies building internal tools with AI haven’t thought about this yet. They will — the moment they get audited.

In Europe, it gets heavier. The AI Act adds compliance requirements when AI-built tools make decisions affecting people. Layer on GDPR, NIS2, and sector-specific regulation, and the governance surface area grows fast. The vendor didn’t just provide software — they provided a compliance wrapper. That wrapper is now your problem.

This isn’t a reason to stop building. It’s a problem worth solving — and the companies that make governance seamless for the build-your-own era will be enormously valuable.

Operations

Building a tool with AI takes an afternoon. Keeping it running takes years.

Who patches it when a dependency breaks? Who monitors uptime? Who gets paged at 2am? And the question nobody asks until it’s too late: what happens when the person who built it leaves the company?

Platform engineering is already the most in-demand discipline in DevOps, and this is exactly why. Every company that builds instead of buys needs someone to keep the lights on. Good platform engineers are scarce and getting more expensive. Most companies embracing the build-your-own era haven’t figured out who maintains what they’re building.

Security

This one should concern everyone. Vibe-coded apps built in an afternoon, deployed to production, handling real customer data — with no security review, no penetration testing, no dependency auditing.

AI-generated code can look perfectly functional and still contain vulnerabilities that no human reviewed. Input validation, authentication edge cases, data exposure — these aren’t things that show up in a demo. They show up in a breach.

The first major data breach traced back to a hastily built internal tool is a matter of when, not if. When it happens, the regulatory and reputational fallout will make the SaaS pricing complaints look trivial.

The hard part is what comes after

Every unbundling cycle leads to re-bundling at a different layer. The software layer is being commoditized — and that’s a good thing. But governance, operations, and security don’t get easier just because building got easier. They get harder when every company is shipping custom tools at speed.

These aren’t reasons to slow down. They’re where the next wave of real value gets created. The people, companies, and platforms that solve these three problems for the build-your-own era will define the next decade of software.

The SaaS incumbents spent ten years bundling features nobody used and charging more every year for the privilege. Build won. But building is the easy part now.

The hard part — and the opportunity — is everything that comes after.

Adapt or Die: What Agentic Coding Means for the Software Industry

Tue, 10 Feb 2026 00:00:00 +0100

I’m seeing a lot of negativity from developers about AI coding. I get it—I was also sceptical at first. But the evidence is in, and it’s not subtle.

The S&P software index just had its worst month since 2008. Salesforce, ServiceNow, Adobe all down 20-40%. Traders at Jefferies are calling it the “SaaSpocalypse”. 245,000 tech jobs were cut in 2025, with Salesforce replacing half its customer support workforce with AI.

This isn’t speculation. This is happening now.

We’ve been here before

As developers, we’ve seen this pattern play out with every major advancement. People resist, then adapt, then forget there was ever resistance.

We’re not punching holes in cards like my father did back in the day. We’re not writing Assembly for web apps. We’re not editing source files in prod over FTP (I have!). Each generation of tooling faced scepticism before it became the baseline.

AI coding is no different, except it’s moving faster than any shift before it.

Build, don’t buy

For decades, the equation was simple: buy software, don’t build it. Only big companies could afford internal tools teams. Everyone else subscribed to platforms that are “good enough” or overpaid for features they don’t use.

AI is rewriting that equation.

Klarna ditched Salesforce and Workday, consolidating 1,200 services with AI. Their revenue per employee jumped from $400k to $700k in a year. They didn’t replace SaaS with an LLM. They consolidated, simplified, and used AI to build what they needed.

This doesn’t mean the software industry is dead. Complex, regulated, integrated platforms will survive. Foundational infrastructure: databases, operating systems, cloud platforms are not going anywhere.

There will always be some buyers. Not everyone has the skills or appetite to build. But the pool of companies that can build just got a lot bigger.

When the cost to build and host approaches zero, the barriers that protected incumbents disappear. Every frustrated customer with technical ability becomes a potential competitor. YouTubers are already cloning popular SaaS products in weekend videos just to demonstrate how good AI coding has become. What used to take a funded team now takes a solo developer with an afternoon.

Commodity SaaS faces a double threat: customers building their own, and upstarts undercutting enterprise margins. If your product is just a database with a UI and some business logic, you could be in trouble. Ask yourself if a product manager or developer with AI can replace your product in a weekend. Better yet - try doing it yourself!

What I’ve seen firsthand

I’ve been an engineering leader for years. Managing teams, sitting in meetings, doing the work that keeps organisations moving. Not a lot of time for hands-on coding.

Here’s what I built in a single week with agentic coding:

An invoice exporter and archiving program for our finance department
A GDPR request handler for our support department
A custom Jira + Notion migration program to Linear for my tech department
An AI + OCR receipt scanner and tracker for my own filing needs
A markdown editor with text analysis for my writing

All in a few hours of prompting. All while keeping up my regular managerial tasks and busy meeting schedule. None of these drive revenue directly, but some save developer time, others help with compliance.

Yesterday, I built a component for our CMS website in two hours starting from zero. I didn’t know the repo, didn’t know how to run the app, didn’t know the codebase. Two hours later: finished component, running Docker app. Only one piece of feedback from my designer.

I’ve produced more code and value in the last two weeks than in my previous four years as an engineering manager.

It’s easy now. But it didn’t start like that.

The skill isn’t prompting

My early attempts didn’t work. I’d fire off prompts and get frustrated when the output wasn’t what I wanted. Sound familiar?

The shift happened when I started planning first. Specifying what I wanted to build before asking the AI to build it. Breaking problems down to first principles. Defining acceptance criteria. Thinking through edge cases. You can even ask your AI to do this!

This is why AI won’t replace developers. The skill isn’t prompting. It’s specification and judgement.

You need to break the problem down to first principles. You need to give precise technical instructions. And of course, you need to understand when the result is wrong or adds risk. The AI will confidently hand you code that looks right but isn’t. If you can’t evaluate the output, you can’t use the tool effectively.

This is what separates useful output from frustrating noise. The people who will succeed with AI coding will be those who understand the problem enough to direct the work and validate the result.

That’s a skill experienced developers already have.

The window is closing

Here’s the uncomfortable truth: if you’re not experimenting with agentic coding yet, the gap is widening.

The developers who figure this out early will ship faster, deliver more value, and become indispensable. Those who wait for it to be “proven” will find themselves competing with people with a two-year head start.

This isn’t about replacing developers. It’s about augmenting them. The best engineers I know are already using these tools. Not because they’re lazy—because they’re strategic.

The negativity I see online feels like people defending territory that’s already shifting beneath them. I understand the instinct. But the evidence is overwhelming.

The software industry is changing. It’s time to adapt.

Sources

S&P software index worst month since 2008 — Yahoo Finance
Salesforce, ServiceNow, Intuit stock declines — CNBC
245,000 global tech layoffs in 2025 — Digital Journal
Salesforce replaces support staff with AI — Salesforce Ben
Klarna ditches Salesforce/Workday, $400k→$700k revenue per employee — TechCrunch

Analys: 6 MSEK i böter — Vad kan vi lära oss från Sportadmin-läckan

Sun, 01 Feb 2026 00:00:00 +0100

Jump to the English version

6 MSEK i vinst. 6 MSEK i böter. En sårbarhet som låg oupptäckt i 2,5 år.

I januari 2025 läckte 2,1 miljoner personuppgifter om svenskar, framförallt barn, till darknet. Namn, personnummer, relationer, och ibland hälsodata som allergier och funktionsnedsättningar. Även personer med skyddad identitet fanns bland de drabbade.

Integritetsskyddsmyndigheten (IMY) svarade med en sanktionsavgift på 6 miljoner kronor.

Det här var ingen sofistikerad attack från en statlig aktör. Det var en SQL-injektion via en enda oskyddad variabel.

För att sätta boten i perspektiv: Sportadmin, som visserligen ingår i en större koncern, omsatte cirka 54 MSEK 2024. Deras vinst samma år? 6 MSEK. Boten motsvarar alltså 100% av deras årsvinst — eller 11% av omsättningen. Det här är inte en administrativ smäll. Det är ett existentiellt hot.

Om ditt bolag hanterar personuppgifter är IMY:s beslut obligatorisk läsning.

Vad hände?

Juni 2022: En kodändring införs i inloggningsflödet. En ny variabel läggs till, men utan det SQL-injektionsskydd som redan fanns på plats för andra variabler. Ändringen klassas som högrisk och granskas av flera personer. Ingen upptäcker sårbarheten.

Januari 2025: Angripare börjar utnyttja sårbarheten den 14 januari. Intrånget upptäcks först den 16 januari — två dagar senare — när servrarna slutar svara.

Mars 2025: Den stulna datan publiceras på darknet.

Sårbarheten låg alltså öppen i 2,5 år.

De fem bristerna IMY pekade på

IMY:s beslut är detaljerat och lärorikt. De identifierade fem kritiska brister som ledde till den höga sanktionsavgiften. Varje punkt är en lärdom för oss andra.

1. De kände till risken — men agerade inte

Sedan 2021 hade Sportadmin i sin årliga riskbedömning identifierat en förhöjd risk för SQL-injektioner. Löpande åtgärder hade genomförts, men inte tillräckliga.

IMY var tydliga: att känna till en risk utan att agera är värre än att inte veta. Dokumenterade risker som ignoreras blir bevis mot dig, inte skydd.

2. De testade skydd — men pausade implementeringen

I maj-juni 2024 testade Sportadmin en Web Application Firewall (WAF). Implementeringen pausades på grund av “höga genomförandekostnader.”

Efter intrånget? WAF var på plats inom dagar.

IMY konstaterade att man kunde implementera WAF snabbt, då borde man ha gjort det innan. Och vad än WAF kostade var det inte 6 miljoner kronor.

3. De upptäckte intrånget två dagar för sent

Attackförsöken började den 14 januari. Intrånget upptäcktes först den 16 januari när systemen kraschade.

Övervakningen var byggt för att mäta prestanda och drifttid, inte för att upptäcka säkerhetsincidenter. Två dagar av angriparaktivitet kunde passera obemärkt.

4. Systemen hade för höga behörigheter

SQL-användarkontot hade högre rättigheter än nödvändigt. Windows-tjänstekontot som körde databasen hade också förhöjda behörigheter. Dessutom tillät databasservern körning av externa program som PowerShell.

Resultatet? Angriparen kunde röra sig till andra system och då komma åt betydligt mer data. Principen om lägsta behörighet (least privilege) är inte en rekommendation — det är en nödvändighet.

5. Kodgranskningen missade sårbarheten

Kodändringen från 2022 klassades som högrisk. Den granskades av flera personer. Ändå upptäcktes inte den saknade inputvalideringen.

Varför? Granskningen fokuserade på funktionalitet (inloggningsflödet), inte på attackvektorer (SQL-injektion). Dessutom saknades automatiserad säkerhetsskanning — ingen SAST, ingen DAST.

Mänsklig granskning är nödvändig men inte tillräcklig.

Frågor du behöver ställa ditt team

Efter att ha läst IMY:s beslut borde alla tech organisationer ställa sig följande frågor.

Riskhantering:

Har vi kända säkerhetsrisker som inte har åtgärdats? Finns det en dokumenterad anledning till varför — och en tidplan för åtgärd?
Om vi testat ett säkerhetsskydd och pausat implementeringen — varför, och när återupptar vi arbetet?

Detektering:

Hur snabbt skulle vi upptäcka onormala databasfrågor eller intrångsförsök?
Är vår övervakning byggd för säkerhet, eller bara för drifttid?
Granskas säkerhetsloggar i realtid, eller bara vid månatliga genomgångar?

Kodgranskning:

Ingår säkerhetsgranskning i våra kodgranskningsrutiner — inte bara funktionalitet?
Är kodgranskning obligatoriskt för alla ändringar, utan undantag?
Har vi automatiserad säkerhetsskanning (OWASP/SAST/DAST) i våra CI/CD-pipelines?

Behörigheter:

Följer våra databas- och tjänstekonton principen om lägsta behörighet?
När granskade vi senast behörighetsnivåerna?
Kan en komprometterad tjänst öppna för lateral förflyttning — eller är tjänsterna isolerade?
Tillåter våra databasservrar körning av externa kommandon?

En startpunkt: Åtgärder att överväga

Det här är ingen uttömmande säkerhetslista, men det är en startpunkt baserad på vad som gick fel i Sportadmin-fallet.

Detektering och övervakning

Implementera realtidsövervakning på WAF- och IDS-loggar. Månatlig genomgång räcker inte.
Övervaka för SQL-injektionsförsök specifikt, inte bara generell trafik.
Behåll loggar längre än 30 dagar för att upptäcka avancerade hot (APT).

Kodgranskning och pipelines

Lägg till OWASP/SAST/DAST/SCA-skanning i er CI/CD-pipeline.
Kräv obligatorisk kodgranskning — med extra fokus på säkerhetsprinciper.
Glöm inte scanna er kod som hanterar infrastruktur.
Använd AI-assisterad kodgranskning som komplement.

Isolation och arkitektur

Kör tjänster i isolerade containers för att begränsa lateral förflyttning.
Implementera zero trust mellan tjänster. Interna system ska inte lita på varandra per automatik.

Teknisk skuld och attackyta

Inventera och arkivera eller uppdatera gamla repos. Varje oanvänt repo är en potentiell attackvektor.

Behörigheter och åtkomst

Granska kontobehörigheter regelbundet.
Begränsa behörigheter till bara det absolut nödvändiga — inklusive för tjänstekonton.
Begränsa möjligheten att köra externa program från databasservrar.
Kryptera all lagrad data, speciellt databaser och under transport.
Implementera MFA för alla kritiska system och adminåtkomst.

Hemlighetshantering

Lagra aldrig API-nycklar, lösenord, certifikat m.m. i kod — använd en hemlighetshanterare
Skanna repos efter oavsiktligt inkluderade hemligheter

Riskhantering

Skanna alla repos automatiskt för nya CVE:er.
Dokumentera kända risker och er åtgärdsplan med tidslinje.
Om en risk dokumenteras men inte åtgärdas måste det finnas ett medvetet beslut och en plan, inte bara tystnad.

Testning och beredskap

Genomför penetrationstestning årligen — eller vid större systemförändringar.
Ha en dokumenterad och testad incidenthanteringsplan.

Slutsats

De här misstagen är lätta att göra. IMY:s beslut kan tyckas hårt, men om du bygger mjukvara som hanterar personuppgifter har ribban för säkerhetsåtgärder precis höjts.

Sportadmins agerande efter intrånget var föredömligt. De stängde ned systemen inom en timme, samordnade incidentanmälningar, och genomförde över 2 000 uppsökande samtal. IMY lyfte detta som en förmildrande omständighet.

Men de fick ändå betala 6 miljoner kronor. Hela sin årsvinst.

Varför? För att det som hände gick att förutse och förhindra. De kände till riskerna. De hade testat lösningar. De valde att vänta.

Den dyraste meningen i GDPR-sammanhang är: “Vi visste, men vi agerade inte.”

Om du hanterar svenska personnummer eller hälsodata är IMY:s beslut din nya botten-nivå. Läs, fråga, och agera innan du blir tvingad.

IMY:s fullständiga beslut finns tillgängligt på imy.se (diarienummer IMY-2025-7801).

Analysis: 6 MSEK in Fines — What Can We Learn from the Sportadmin Leak?

6 MSEK in profit. 6 MSEK in fines. A vulnerability that went undetected for 2.5 years.

In January 2025, personal data for 2.1 million Swedes, the majority children, leaked to the darknet. Names, ID numbers, relationships, and sometimes health data like allergies and disabilities. Even individuals with protected identities were among those affected.

The Swedish Authority for Privacy Protection (IMY) responded with a fine of 6 million SEK. That’s about €570,000 or $670 000.

This wasn’t a sophisticated nation-state attack. It was a SQL injection via a single unprotected variable.

Put it in perspective: Sportadmin, part of a larger group, had a turnover of about 54 MSEK in 2024. Their profit that year? 6 MSEK. The fine equals 100% of their annual profit — or 11% of revenue. This isn’t an administrative slap on the wrist. It’s an existential threat.

If you’re a technology leader in Sweden handling personal data, IMY’s decision is a must read.

What Happened?

June 2022: A code change in the login flow introduced a new variable. It lacked the SQL-injection protection already in place for other variables. The change got flagged as high-risk and reviewed by several people. No one caught the vulnerability.

January 2025: Attackers begin exploiting the vulnerability on January 14. The breach was discovered on January 16 — two days later — when servers stop responding.

March 2025: The stolen data released on the darknet.

The vulnerability remained open for 2.5 years.

The Five Failures IMY Identified

IMY’s decision is detailed and instructive. They identified five critical failures that led to the big fine. Each point is a lesson for the rest of us.

1. They Knew About the Risk — But Didn’t Act

Sportadmin’s annual risk assessments had flagged SQL injection as elevated since 2021. They had ongoing remediation work, but it wasn’t fast enough.

IMY was clear: knowing about a risk without acting is worse than not knowing. Documented risks that are not corrected become evidence against you, not protection.

2. They Tested Protection — But Paused Implementation

In May-June 2024, Sportadmin tested a Web Application Firewall (WAF). Implementation was paused due to “high implementation costs.”

After the breach? WAF was in place within days.

IMY stated the obvious: if it was easy to install after the incident, you could have done it before. And whatever the firewall cost was, it wasn’t 6 million kronor.

3. They Detected the Breach Two Days Too Late

Attack attempts began on January 14. On January 16 they discovered the breach. When systems crashed.

The monitoring system measured performance and uptime, not security incidents. Two days of attacker activity went unnoticed.

4. Systems Had Excessive Privileges

The SQL user account had higher privileges than necessary. The Windows service account running the database also had elevated privileges. Additionally, the database server allowed execution of external programs like PowerShell.

The result? The attacker could move between systems and access even more data. The principle of least privilege isn’t a recommendation — it’s mandatory.

5. Code Review Missed the Vulnerability

The 2022 code change was classified as high-risk, and reviewed by several people. Yet the missing input validation wasn’t detected.

Why? The review focused on functionality (the login flow), not attack vectors (SQL injection). Also, automated security scanning was absent — no OWASP, SAST or DAST scans.

Human review is necessary but not enough.

Questions You Need to Ask Your Team

After reading IMY’s decision, here are some questions every tech team should be asking.

Risk Management:

Do we have known security risks not addressed yet? Is there a documented reason why — and a timeline for remediation?
If we’ve tested a security control and paused implementation — why, and when will we resume?

Detection:

How fast would we detect anomalous database queries or intrusion attempts?
Is our monitoring built for security, performance, and/or uptime?
Are security logs reviewed in real-time, or only during monthly audits?

Code Review:

Is security review part of our code review routines?
Is code review mandatory for all changes, without exception?
Do we have automated security scanning (OWASP/SAST/DAST) in our CI/CD pipelines?

Privileges:

Do our database and service accounts follow the principle of least privilege?
When did we last review privilege levels?
Could a compromised service enable lateral movement — or are services isolated?
Do our database servers allow execution of external commands?

A Starting Point: Actions to Consider

This is not an exhaustive security checklist — but a starting point based on what went wrong here.

Detection and Monitoring

Setup real-time monitoring of WAF and IDS logs. Monthly review isn’t enough.
Watch for SQL injection attempts, not only general traffic.
Keep logs for longer than 30 days to detect advanced persistent threats (APT).

Code Review and Pipeline

Add OWASP/SAST/DAST/SCA scanning to your CI/CD pipeline.
Have mandatory code review — with extra focus on security principles.
Don’t forget to scan your infrastructure-as-code.
Use AI-assisted code review as a complement.

Isolation and Architecture

Run services in isolated containers to limit lateral movement.
Setup zero trust between services — internal systems shouldn’t trust each other by default.

Technical Debt and Attack Surface

Inventory and archive or update old repos — every unused repo is a potential attack vector.

Privileges and Access

Review account privileges.
Limit privileges to what is only necessary — including service accounts.
Restrict the ability to run external programs from database servers.
Encrypt all stored data, especially databases, and data in transit.
Enforce MFA for all critical systems and admin access.

Secrets Management

Never store API keys, passwords, certificates, etc. in code — use a secrets manager.
Scan repos for committed secrets.

Risk Management

Scan all repos for new CVEs.
Document known risks and your remediation plan with timeline.
If a risk found but not addressed — make sure there’s a decision and a plan, not ignorance.

Testing and Preparedness

Conduct annual penetration tests — or when making major system changes.
Have a documented and tested incident response plan.

Conclusion

These mistakes are easy to make. IMY’s decision may be harsh, but if you’re building software that handles personal data, the bar for security measures just got raised.

Sportadmin’s response after the breach was exemplary. Shutting down systems within an hour, coordinating incident reports, and making outreach calls. IMY noted this as a mitigating factor.

But they still paid 6 million kronor. Their entire annual profit.

Why? Because what happened was foreseeable and preventable. They knew about the risks. They had tested solutions. They chose to wait.

The most expensive sentence in GDPR enforcement is: “We knew, but we didn’t act.”

If you handle Swedish national ID numbers or health data, IMY’s decision is your new baseline. Read it. Ask the questions. Act before you are forced to.

IMY’s full decision is available at imy.se (case number IMY-2025-7801).

</div>

The next programming superpower is specs, documentation and orchestrating agentic AI

Thu, 09 Oct 2025 00:00:00 +0200

AI agents are changing how we write software, and here’s the twist: the teams best positioned to win aren’t the ones who code the fastest, it’s the ones who document the best.

I’ve been watching and exploring the agentic AI wave closely, and I keep seeing the same pattern. Teams struggle with AI coding assistants because the AI “misses context” (about 65% of developers report this). Meanwhile, the teams with solid documentation and clear standards are seeing their productivity soar.

Here’s the irony: for years we’ve claimed “the code is the truth” and treated documentation as an afterthought. Now those same documentation practices we’ve been ignoring are becoming our most critical skill.

The shift from programming to engineering is here

Anthropic’s CEO warns that nearly half of entry-level white-collar positions could be eliminated. Salesforce and Meta aren’t hiring junior developers anymore. So yes, programming jobs might be going away.

But here’s what matters: people are resilient and programmers who adapt will thrive and see results they’ve never seen before. The shift isn’t about AI replacing us, it’s about programming becoming less about writing code and more about defining what needs to be built and vitally; controlling the result.

Think about it: when an AI agent can generate thousands of lines of code in minutes, the bottleneck isn’t implementation anymore. It’s specification! A vague requirement like “build me a login system” produces vague, potentially insecure code. But prime the AI with best practices and give it a detailed spec with authentication flows, session management requirements, and security constraints? Now you’re cooking!

Forget “vibecoding” where you just vibe with the AI and hope for the best. That’s a recipe for disaster. This is about becoming an architect who orchestrates AI to build better systems faster. Programmers who learn these skills will find even greater power, compensation and job safety.

Documentation: From Afterthought to Superpower

For years, we’ve treated documentation like that vegetable on your plate you know you should eat but never do. “The code is the truth,” we’d say, as if that excused us from explaining our architectural decisions or business logic, or at best we kept it in a digital whiteboard or shared folder.

That needs to change, and fast.

GitHub just released a spec-driven development toolkit where “intent is the source of truth” and specifications become executable. Google’s dev tools manager uses AI to write 100-line requirement docs before any coding begins. The industry is shifting, and those without good documentation are getting left behind.

Here’s what comprehensive documentation enables:

AI agents that understand your system architecture and design decisions
Consistent code generation that follows your patterns
Faster onboarding of both humans AND AI agents
Clear boundaries and integration points

The brutal truth is that programmers need to start writing specs and documentation NOW. Not next quarter, not when you “have time.” A recent METR study found that experienced developers using AI tools actually work 19% slower on their own repositories. Because the AI lacks context that good documentation would provide.

Quality Matters More Than Ever

There’s a valid concern that AI will enable a flood of crappy applications. And you know what? It probably will. But that’s exactly why professional developers become MORE valuable, not less.

In a world where anyone can prompt an AI to generate code, the differentiator becomes:

Systems that actually scale under load
Applications that don’t leak user data
Codebases that can evolve without falling apart
Software that actually works reliably

Quality, security, and maintainability will command premium prices. The market will quickly separate professional AI-assisted development from amateur “prompt and pray” applications.

The Timeline Is Tighter Than You Think

Nearly 80% of IT leaders are planning to invest at least $1 million in AI agents this year. By 2026, we’ll hit mainstream adoption. The window for building these new skills is now.

Right now (Q4 2025): Early adopters are establishing their advantage 2026: Best practices crystallize, mainstream adoption begins
2027 and beyond: AI-assisted development becomes table stakes

If you’re not learning to write specs, improve documentation, and review like an architect RIGHT NOW, you’ll be playing catch-up while others are already optimizing their second-generation AI workflows.

The New Programming Skills

So, you want to stay relevant? Here are the skills that matter now:

Write Crystal-Clear Specifications

Study design patterns and best practices and algorithms
Define acceptance criteria that leave no room for interpretation
Identify edge cases before they become bugs
Articulate security and performance requirements
Map out integration points and dependencies

Review Like an Architect

Spot when AI introduces anti-patterns or technical debt
Ensure security governance in code and tools (AI loves to leak secrets if you’re not careful)
Maintain architectural coherence across AI-generated components
Validate that the code actually solves the business problem

Establish and Enforce Standards

Create AI-friendly coding guidelines
Build automated checks for AI-generated code
Maintain audit trails of what was generated when and why

Google’s Ryan Salva puts it perfectly: “Your job as a developer is going to look a lot more like an architect.” We need to learn these skills now, not when it’s too late.

Where To Start

Here’s some recommended reading to get started with agentic coding in the right way:

How to start:

Start documenting your system architecture and key decisions, and do it in your repo where AI can read it
Practice writing detailed specifications for your next feature (take help/inspiration from the links above)
Try AI code review tools on a small project to learn their quirks

Level up your specification writing—this IS the skill that matters
Shift code reviews from syntax-checking to architecture and security focus
Create governance policies for AI-generated code
Design new systems to be “AI-friendly” (clear boundaries, good abstractions)
Build your unique advantages into documented processes AI can follow
Keep learning, this space moves fast!

The Bottom Line

We’re entering an era where programmers become architects and conductors rather than typists. The skills that matter are shifting from implementation to specification, from coding to reviewing, from building to governing.

The brutal irony? The very things we’ve traditionally avoided—documentation, specifications, establishing standards—are becoming our survival skills. That “the code is the truth” mentality? It’s about to make you unemployable.

Teams that recognize this shift and adapt will thrive. Those clinging to “I’m valuable because I can code” will struggle. And those who abandon all engineering discipline for “vibecoding”? They’ll produce the garbage that makes the rest of us look good by comparison.

The future belongs to developers who can specify precisely, document thoroughly, and review intelligently. The question isn’t whether to develop these skills—it’s whether you’ll learn them fast enough to stay relevant.

I’m excited about this future. This is a tremendous shift from programming to engineering - making engineers even more valuable if you adopt these skills now.

The train is leaving but it’s not too late. Are you on it?

Engineering Principles for Good Software

Tue, 16 Jan 2024 01:00:00 +0100

Every engineer strives to build good systems, but what is a good system and how do you build it?

A good system needs at least these three traits; it’s easy to maintain, is easy to test and is easy to scale. Let’s dive into what each of those mean.

My goal here is to provide a comprehensive guidebook of principles, tips and best practices for writing better software.

First let’s talk high level…

Maintainability

Managing complexity in a constantly growing application is hard. There are many ways to build software and if we each invented our own way it would be very hard for you and other contributors to keep track of all the different solutions.

We use conventions and design patterns to keep complexity down and make our code easy to read and understand. As the old saying goes; code is written once but read many times by many people.

Testability

We make our apps more reliable and catch bugs earlier by making it easer to test our application and its components.

Having a well designed architecture and following design patterns makes it easier to create isolated components which are easier to test.

The earlier we test, the easier it gets to fix issues.

Scalability

Using a well defined architecture and common design patterns makes it easier to add new features, increases development speed and decreases errors.

Separating concerns and creating reusable components allows teams to add new features without rewriting large pieces of the code or affecting other teams. With good architecture it’s easier to create reusable code which speed up new development.

The principles

We will cover many principles, design patterns, and best practices in this article. To make it easier to navigate I’ve split these into sub-pages. While we stay mostly high-level, there is a list of highly recommended books at the end which dive deeper on these topics.

Everything covered here is worth knowing as an engineer, but every system is specific to it’s domain and it’s needs. Not all of what we cover may be applicable in your codebase.

Throughout the articles there are highlighted principles and patterns which are extra useful or important so pay special attention to them and perhaps dig further with your own research on what they mean for your work.

Planning and design

Before we even start coding we need to consider things like having clear requirements, designing your solution, how to manage your code and other fundamentals.

Planning and design principles

Testing

How should we test our systems or code, what are good things to test, what can we skip. Keep testing simple and keep these other ideas in mind.

Code testing principles

Monitoring

How and why we should think about testing and tips on what to test, and things to monitor.

Software Monitoring

Releasing

What should we pay attention to when preparing for release, how to release and what to monitor once released.

Releasing Software

Code Principles and Design Patterns

What should you be thinking about when organizing and writing the actual code. Architecture and design patterns to follow.

Code Organization

Programming Principles

Architecture and Design Patterns

Refactoring

Regularly refactoring is very important, let’s dive into why, when and how to do that.

Refactoring Principles

Stay curious

Continue to learn and improve by staying up-to-date with the latest language features, frameworks, and best practices. Continuously improve your coding skills through reading, attending conferences, and participating in coding communities.

Regularly review and reflect on your own code and seek feedback from peers to identify areas of improvement. Be open for feedback and stay humble in your reactions.

Books

Much of the content found in this guide is derived or adapted from the following books which I recommend wholeheartedly:

Clean Code - Robert C. Martin (“Uncle Bob”)
Code Complete - Steve McConnell
Design Patterns - Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (”Gang of four”)
Refactoring (2nd edition with Javascript)- Martin Fowler
Patterns of Enterprise Application Architecture - Martin Fowler
Clean Architecture - Robert C. Martin (”Uncle Bob”)