AI Engineering Is Easy. So How Do We Change How We Work?

In Part 1, I wrote about the uncomfortable part of AI-assisted engineering: the tools are becoming remarkably good at producing things, while the harder question is what happens around them.

If an agent can write code in minutes, generate a plan in seconds, and create dozens of tasks before we've finished our coffee, our old way of working starts to look a little strange. Not because the process was bad, but because the bottleneck has moved.

We used to spend much of our time producing things. Now we need to spend more time deciding what should be produced, providing the right context, and verifying whether the result is actually what we wanted.

Recognising the need for change is one thing; figuring out how to make it without creating even more process is another.

I don't think we need an entirely new engineering methodology for AI. We need to make a few important parts of our existing process explicit and automate what we can. I think of this as building a harness around the agent.

It's tempting to start with questions like, "Which agent should we use?" or "What's the perfect prompt?" I think that is backwards.

Start with the unit of work. What does the agent receive? What can it change? What does "done" mean? How do we know the result is correct, and what happens when it isn't?

These questions matter whether you're using Claude, Codex, Cursor, an internal agent, or something that doesn't exist yet. The tools will change, but the underlying method shouldn't have to.

A useful agent workflow has six basic components:

You don't need a sophisticated platform to start. You just need to be explicit about these six things.

Giving an agent access to everything can make the first demo impressive, but it can also make the first mistake much more expensive.

Before expanding its access, establish clear boundaries around:

The exact list will vary, but the boundaries should be documented and enforced wherever possible.

If the answer depends on who's running the agent, you don't have a boundary; you have a convention. Conventions are easy to lose when people, tools, and teams change.

As agents become more capable, being deliberate about where their autonomy ends becomes just as important as deciding what they can do.

A process can have ten gates written down and still have none in practice. If someone can skip a step simply by forgetting it, it's an instruction rather than a gate.

A useful gate has three things: a condition that must be satisfied, someone accountable for checking it, and a mechanism that makes skipping it visible.

Automate what you can. Run specification checks automatically, validate consistency between artefacts, and stop the workflow when a required check fails.

Other decisions genuinely need human judgement, such as approving scope or determining whether a change meets the customer's needs.

The goal isn't to automate every decision. It's to automate what doesn't require one and make the remaining decisions explicit. That should reduce the burden on people rather than add another layer of process.

"Human in the loop" can easily become "human reads everything the agent does". If someone has to inspect every intermediate step, we've simply added an AI assistant to the old workflow and asked a person to supervise every keystroke.

Instead, involve people where judgement matters and let automated checks handle what they can.

Agent produces ↓ Automated checks ↓ Human reviews decisions requiring judgement ↓ Agent continues Enter fullscreen mode Exit fullscreen mode The human needs to determine whether the direction is right, the result matches the intended outcome, and the work is safe to continue.

This is also why the unit of work matters. A large ticket gives the agent a large surface area for mistakes, while a small, independently verifiable slice makes the work easier to understand and review.

The objective isn't to remove humans from the workflow, but to reserve their attention for decisions that benefit from their experience.

Agents are very good at doing exactly what you asked, which isn't always the same as doing what you meant.

For every piece of work, make three things explicit:

Exclusions are particularly important because a future-state idea can quietly become an implementation requirement while everyone assumes they're still discussing the same thing.

One piece of product intent can produce many implementation slices. The slice isn't the feature; it's the unit in which we deliver and verify part of it.

Without clear scope, an agent can optimise for completing the task in front of it rather than delivering the outcome we actually wanted. Good specifications help constrain those assumptions without requiring us to prescribe every implementation detail.

If you keep telling an agent, "Remember to check X," ask whether X should actually be a check.

Prompts help communicate intent, but automated checks are more reliable for enforcing objectively verifiable requirements.

If a requirement is testable, test it. If two documents need to agree, compare them. If a branch must not be modified directly, enforce it. If a file must never be changed, block it. If evidence is required before completion, check for it.

Every time you add another paragraph to a prompt, consider whether that instruction could become an automated check instead.

Not everything can be automated, and prompts will remain useful for communicating context and intent. But when correctness can be checked mechanically, relying on the agent to remember an instruction is often weaker than enforcing it in the workflow.

Over time, prompts can become smaller while the system becomes more reliable.

"I've got a really good prompt that I use with my agent."

That's useful for an individual, but it's not a team process.

If an agent needs specific context to work correctly, that context should live somewhere shared, versioned, and reviewable. The same applies to skills, instructions, and workflows.

Otherwise, everyone builds their own operating system for their agent, and the team ends up with different behaviours while assuming everyone follows the same process.

Shared context doesn't mean identical prompts for every team. It means important rules shouldn't depend on someone's local setup.

We don't need to document everything, but information that repeatedly affects decisions should be available where the work happens. If it's important enough for an agent to make the right decision, it's probably important enough for the team to maintain and review.

As generation becomes cheaper and faster, verification becomes an increasingly important part of the workflow.

Asking the same model that produced something to confirm its correctness isn't enough. A confident explanation isn't independent evidence.

Depending on the work, verification might involve automated tests, static analysis, schema validation, comparisons against specifications, independent reviews, acceptance testing, or evaluations against known examples.

Don't measure how much the agent produced. Measure how confidently you can accept what it produced.

A thousand generated lines aren't particularly useful if nobody can establish that they're the right thousand lines. More output can even increase the review burden.

Productivity should therefore include how quickly we move from generation to justified acceptance, not just how quickly we generate something.

Building verification into small, independent work units also makes it easier to catch problems early, understand what went wrong, and correct them before they spread.

Building the entire engineering method around one CLI or agent creates unnecessary coupling. Tools, commands, and models will change, so the underlying workflow shouldn't need to change with every new release.

Instead of defining the method as "run command X, then Y, then Z", define the work itself: specify behaviour, resolve ambiguity, design the solution, decompose the work, implement a small slice, and validate it.

Then map those activities to whichever tools the team uses.

Today that might be one agent; tomorrow it might be another or a combination of agents and conventional automation. The workflow remains useful because it's based on engineering activities rather than a particular command sequence.

You don't need to redesign engineering before using AI. Start with one workflow and answer six questions:

Context: What does the agent need to know, and where can others find and review it?

Tools: What can it do, and which capabilities should remain outside its reach?

Loop: What's the smallest independently deliverable unit that creates useful progress?

Verification: How do we know the result is correct rather than merely plausible?

Guardrails: What must it never touch, regardless of who's running it?

Observability: What do we record so others can understand what happened, what changed, and why?

Once these are clear, try the workflow where the pain is already visible. You don't need to start with every team, repository, or a 40-page AI engineering policy.

Run it, identify where people still compensate manually, and fix those points before expanding the approach. The harness should evolve from actual friction rather than an attempt to design the perfect process upfront.

There's a natural reaction to all of this:

"So we're adding more gates, more checks, more documentation and more meetings?"

Some meetings should become automated checks, some knowledge should become shared context, some repeated prompt instructions should become enforceable rules, and some large tickets should become smaller slices. Other work people currently do manually should simply disappear.

The process should become more explicit but less heavy.

There's also an irony here: AI makes it easier to generate plans, documentation, tickets, and checks, but that doesn't mean we need more of them. We still need to decide which artefacts and controls actually create value.

The opportunity isn't just getting a faster developer. It's redesigning the system that developer works inside, including the parts we've accepted for years simply because nobody had a compelling reason to change them.

If I were starting from scratch, I'd take these steps:

The point isn't to build a perfect AI engineering process. It's to make the system good enough that, as agents improve, we can benefit from their capabilities instead of discovering that our surrounding process has become the new bottleneck.

AI-assisted engineering isn't primarily a tooling problem. The tools will continue to improve, but we still need to decide how much autonomy we want, where human judgement belongs, what evidence is enough to trust a result, and how to make those decisions visible to the team.

The teams that benefit most won't necessarily be the ones with the most powerful agents. They'll be the ones whose engineering systems provide clear work, sufficient context, appropriate boundaries, useful feedback loops, and reliable ways to verify the results.

That's what the harness is for: making it possible to let agents move faster without turning every increase in autonomy into more risk and review overhead.

We may spend less time producing code, plans, and documentation by hand, but we'll still need to think carefully about intent, boundaries, trade-offs, and evidence.

AI can make the work of building easier. Changing how we work is still ours to do.