AI-First Engineering: Writing Intent, Reviewing Code

I am on leave as I write this, and I have been sharing quite a lot with people around me about how I use AI in my engineering work. One of those conversations led to an invitation to speak at an engineering day about how I work with AI.

The invitation gave me a reason to organise thoughts that had mostly emerged through practice. I knew my workflow had changed, but I hadn't stopped to describe precisely what had changed. The easy version of the talk would have been about using AI to write code faster. That no longer felt like an accurate description of how I worked.

The more useful distinction was between writing code with AI assistance and writing intent, directing agents and reviewing what they produce.

This is the argument I presented that day. It is a personal account of how my work has changed. The slides are available on Speaker Deck, but I wanted to unpack the ideas that a slide can only introduce briefly.

I made a deliberate choice to overshoot in the talk. I didn't want to describe only the easiest uses of AI or leave people with a slightly better autocomplete workflow. I wanted to show enough of what is already possible that the room would have to reconsider its assumptions.

For anyone who wasn't using AI seriously, I wanted the direction of travel to feel difficult to ignore. The particular tools will change, but this way of working increasingly feels inevitable to me. People are already doing interesting work this way and it deserves more than a passing experiment. For those already using AI, I wanted to show that generating snippets or occasionally asking a chatbot for help may only be scratching the surface.

Some of the examples came from what we have been doing at Zappi, where AI has been embraced across the organisation rather than treated as an isolated developer tool. Seeing the shift across a company of Zappi's size also made it harder to dismiss as a novelty that works only for one unusually motivated engineer. The point wasn't that every company should copy what we were doing. It was to make the possibilities concrete: agents participating in development, review, incidents, design and the creation of tools that previously wouldn't have been worth building.

From assistance to orchestration

My use of AI didn't change all at once. It progressed through several different ways of working.

With ChatGPT, the interaction sat mostly outside the codebase. I would research a problem, ask questions, copy a useful snippet and then write or adapt the code myself. It made information easier to reach, but the basic workflow remained familiar: I was still the person producing the implementation.

Inline assistants brought the conversation into the editor. I could ask questions about the code in front of me and direct local changes without moving continually between a browser and the codebase. The feedback loop tightened, although I was still working at roughly the level of individual edits and snippets.

Coding agents changed the unit of interaction. Instead of beginning with the code I wanted to write, I could begin with the outcome I wanted, the relevant context and the constraints the implementation needed to respect. The agent could inspect the repository, make changes, run tests and present the result for review.

Automated review added another stage. A separate agent could examine the implementation before I did, looking for the kinds of problems that a team had explicitly asked it to notice. My own review remained the final step, but it could begin with the implementation and an additional reviewer's briefing rather than a cold diff.

The progression looks something like this:

1. I research, then I write the code.
2. I ask questions and direct edits inside the codebase.
3. I write the intent, an agent implements it and I review the result.
4. I write the intent, one agent implements it, another checks it and I review both.

That last workflow is what I mean by AI-First Engineering. It doesn't mean accepting whatever a model produces. It means treating intent, context, verification and judgement as the main work, while delegating more of the initial production and checking.

Where the change became visible

Describing the workflow abstractly only goes so far. I found the shift easier to understand by looking at where it had become visible in my own work:

1. Development
2. Review
3. Debugging
4. Design
5. Economics

Development: the unit of work moved

The useful change is that I can describe the outcome and the shape of acceptable work: what the artefact is for, which constraints matter, how it should be validated and how the result should be divided for review.

This changes what feels valuable during development. Typing speed matters less. Clarity about the problem matters more. A vague instruction often produces a vague implementation, while a precise brief creates something that can be inspected and challenged.

It also makes written context more valuable. Architecture notes, repository guidance and decision records are no longer only documentation for a future human reader. They become part of the environment in which an agent works. When the reasoning behind a system is written down, both people and agents have a better chance of making changes that fit it.

I haven't stopped reading or understanding code. If anything, I need to understand the system well enough to recognise when an implementation is locally convincing but globally wrong. The work has moved up a level, but responsibility hasn't moved with it.

Review: useful feedback depends on context outside the diff

Generic AI review is limited for the same reason generic human review is limited: neither knows what the team knows unless that knowledge has been made available. The interesting part of an AI reviewer is therefore not the model alone. It is the review culture around the model, written down clearly enough to be applied.

A repository-level review guide via a REVIEW.md file can describe the things that matter in that system: performance assumptions, security boundaries, error-handling expectations, operational constraints and even the kinds of comments that create more noise than value. The agent can then perform a first pass using context that a conventional static check cannot express and that a busy reviewer might otherwise have to reconstruct each time.

At Zappi, this moved beyond individual engineers asking a model to inspect their work. Review agents became part of the pull-request workflow, using repository-specific guidance to look for material issues while remaining quiet when there was nothing useful to say. The surprising part wasn't that an AI could comment on code. It was that a team could begin to encode some of its review culture and make that context available on every relevant change.

I think of this less as replacing review and more as changing where human review begins. A useful automated reviewer can catch obvious or well-understood issues, stay quiet when it has nothing material to add and give me a briefing before I inspect the change myself.

That only works when it is calibrated. A reviewer that comments on everything trains people to ignore it. A reviewer without repository context produces generic advice. And, a reviewer treated as authoritative creates a more dangerous problem: confidence without accountability.

The human review becomes more important, not less. There is simply another set of eyes before it.

Debugging: the agent can follow the evidence

Debugging changed when agents gained access to the tools around the codebase rather than only the code itself.

Through integrations with logs, deployment systems, monitoring and other operational tools, an agent can inspect some of the same evidence I would inspect during an incident. It can follow a line of enquiry, compare live behaviour with configuration and recent changes and update its working theory as the conditions change.

In one certificate-related incident at Zappi, this felt less like asking a chatbot for debugging suggestions and more like having another team member following the evidence. The agent helped correlate the failures with configuration and recent changes. The team still confirmed the diagnosis, but the investigation moved more quickly because the agent could participate in it rather than waiting for someone to summarise every observation.

The more interesting outcome came afterwards. The manual recovery didn't remain a set of commands remembered by whoever happened to be on the incident. It became a reviewed change to the system. The agent helped move the work from alert, through evidence and diagnosis, to a permanent fix.

There is an important boundary here. An agent can propose a diagnosis and prepare a change. It doesn't own the production system or the consequences of being wrong. During an incident, plausible explanations are plentiful, but confirmation still matters.

Design: the gap between an idea and an artefact narrowed

Design used to be one of the places where an idea could remain abstract for a long time. I might be able to explain the feeling or direction I wanted, but turning that into something concrete required a different set of skills and often a separate block of work.

For this deck, I began with a short direction: dark, spare and technical, with the shift from AI consumer to orchestrator as the spine. The model produced a first version. I then chose the direction, rejected what didn't work and revised the result until it supported the argument I wanted to make.

Generating a visual artefact isn't the same as having product sensibility and taste. The model can create options quickly, but I still have to decide which direction feels coherent, which details distract and whether the result communicates the intended idea.

It makes it cheaper to turn a brief into several things I can react to. A rough idea becomes a working artefact sooner, which gives critique somewhere concrete to land.

The same pattern becomes more powerful when a design system is available as context. At Zappi, we have seen ideas move from a brief to working concepts quickly enough for people outside a traditional implementation path to participate in the exploration. The first result isn't automatically the right design, but it changes the conversation from imagining an idea to reacting to something tangible.

I don't think this makes specialist design work irrelevant. Complex interfaces still require deep understanding of users, interaction and systems. But it changes who can participate in the early stages and how quickly a team can explore before committing to a direction.

Economics: more ideas became worth testing

The fifth change is less visible in the code, but may be the most consequential.

Software has always had ideas that are useful but not useful enough. A small internal tool might save someone a repeated annoyance, but proposing it means finding time, coordinating the work, implementing it, reviewing it and maintaining it. The expected value may never justify the cost, so the idea remains in a backlog or in someone's head.

Agents reduce the cost of the first serious attempt but that doesn't mean software becomes free. Maintenance, security, operational responsibility and product judgement remain. But the threshold for learning whether an idea is useful has moved. Something I previously wouldn't have proposed can now become a bounded afternoon experiment.

This changes the economics from “is this worth building?” to “is this worth testing?” Those are very different questions. The second permits a small, disposable investigation before a team makes any lasting commitment.

I have seen this at Zappi with internal tools that existed mainly because the initial implementation became cheap enough to try. In the past, some of them would have been difficult to justify against roadmap work. With agents, a useful idea could become a working experiment in an afternoon rather than remain in the backlog. Some experiments deserved to continue. Others taught us enough to stop. Both outcomes were more informative than leaving the idea untouched for another two years.

But there's a trap here too. When producing software becomes cheaper, it becomes easier to create tools that nobody needs, duplicate existing systems or quietly add a new maintenance burden. Lower implementation cost doesn't remove the need for judgement. It just makes judgement the scarce part.

What became harder

The benefits are real, but so are the trade-offs.

The first is accountability. An agent's output is still my responsibility. “The agent did it” isn't meaningfully different from saying a tool made me do it. If I approve the change, I own the result.

The second is cognitive load. Directing several streams of work, maintaining context and reviewing a large volume of output can be exhausting in a way that is different from writing code continuously. At Zappi, we have come to think of it as AI brain fry. More parallelism can feel productive while quietly reducing the quality of my attention.

This creates a maximalism trap. Once it is possible to run many agents, it is tempting to assume that more agents must mean more output. In practice, review and decision-making remain bottlenecks. There is little value in generating changes faster than I can understand them.

There is also an unresolved question about learning. Much of engineering apprenticeship has traditionally happened through writing code, making mistakes and receiving feedback. If agents take on more of the production work, newer engineers still need a way to develop judgement rather than merely supervise output they cannot yet evaluate. The typing apprenticeship may be changing, but the thinking apprenticeship cannot disappear.

Finally, agents still struggle where the problem is ambiguous, the relevant knowledge is unstated or the work sits beyond the model's current frontier. A tool can get surprisingly far and then stall at the point where the remaining work requires a new idea rather than more persistence. Knowing when the agent is accelerating the work and when it is preventing deeper thought is becoming an engineering skill of its own.

Starting with experiments

The destination I wanted the room to see wasn't faster autocomplete. It was an engineering organisation in which agents can participate throughout the workflow: receiving intent, producing implementation, checking changes, following operational evidence and helping people turn ideas into working artefacts. That future doesn't feel speculative to me. Parts of it are already normal in how I work and increasingly visible around me.

I was deliberately ambitious about that destination, but I think the first step should still be bounded. Showing the edge of what is possible can create the motivation to begin; it doesn't require transforming an entire engineering organisation at once.

I would start with one bounded, real task. Write down the intended outcome and the constraints, let an agent attempt it and review the result carefully. The goal isn't to prove that AI works. It is to learn which context was missing, which checks mattered and where the workflow genuinely improved.

I would try first-pass review on a non-critical repository and compare it with human review. What did it catch? What noise did it create? Which repository-specific rules would make it more useful?

And I would create time for engineers to learn together. The most valuable outcome of an internal AI day isn't a mandate or a productivity claim. It is giving each person a chance to experience one genuine “I get it” moment, then letting the team decide what deserves adoption.

The practical change in my own work is straightforward: I spend less time producing code and more time specifying, reviewing and deciding. And the broader change is that engineering teams can now consider work, workflows and tools that previously sat outside the practical boundary of what they could attempt.

That doesn't feel like leaving engineering behind. It feels like being pushed towards the parts of engineering that were always the hardest to automate: understanding the problem, expressing intent, recognising quality and taking responsibility for the result.

I presented this personal perspective at DigiTax Engineering Day on 14th July 2026. It is not an official Zappi presentation or company position. You can view the presentation on Speaker Deck.