What building with AI has changed my mind about

When I started using AI for development, I was overly enthusiastic about how much it could take on. Having spent several months building Patched and developing the pipeline around it, I’ve pared back those expectations.

I still find it enormously useful. I’m also more aware of how much the result depends on the person directing the work.

The view I’ve arrived at is that AI is a multiplier in the hands of a domain expert. It can increase what that person can get done, but it doesn’t replace the understanding needed to direct the work and judge the outcome.

The early enthusiasm

It is easy to get carried away when you can describe a change and watch an agent start working through it. It can inspect a codebase, propose an approach, write code and run tests. Work that previously needed a long stretch of uninterrupted time suddenly feels much more accessible.

That capability is real. It also makes it tempting to extrapolate.

Once an agent can complete a well-defined task, you start wondering how much more responsibility it could take. Could it work through a backlog? Could another agent review its output? Could the whole thing continue with less intervention?

Those questions have shaped the pipeline I’ve been building. But each step introduces responsibilities that are less obvious than writing the code.

Someone has to decide whether the task is sufficiently defined. Someone has to recognise when a proposed solution changes the scope. Someone has to judge whether the verification supports the claim that the work is finished.

An early example was trying to get the agent to revamp the Patched dashboard in one go. I expected it to take the brief and produce something close enough that I could review the result and make a few adjustments.

It ultimately became a page-by-page review, with each page going through roughly five to ten iterations. I had underestimated how much direction and judgement I would still need to provide.

The agent could make changes quickly. Getting those changes to match what I wanted took repeated review and feedback. That experience helped me set more realistic expectations about the size of task I could delegate usefully.

Knowing what to question

Patched is a macOS app updater. My background in endpoint management helps me think about what an updater needs to get right and what happens when it gets something wrong.

That background doesn’t mean I know every part of the implementation. It does give me a basis for questioning the behaviour.

How does the application know an update succeeded? What happens if the process is interrupted? Does the evidence show that something works on a Mac, or only that a test passed in another environment?

AI can help investigate those questions and implement the answers. But the questions have to be part of the work.

One example was the failure handling around download verification. If verification failed, the process failed closed and stopped the download from being used. That was the right behaviour, but it didn’t alert anyone to the failure.

From an endpoint-management perspective, that left an operational gap. I needed to know that an update had failed so I could investigate it. Stopping safely was only part of the requirement; the failure also needed to be visible.

That check came from thinking about how I would manage the updater in practice. It changed what I considered a complete implementation.

This is where the domain-expert point becomes practical. Experience gives you a sense of where to look, which assumptions deserve scrutiny and which apparently small details could cause a larger problem.

An agent can produce an implementation that looks reasonable. Assessing it requires an understanding of the environment it will operate in and the consequences of failure.

I’ve become more careful about distinguishing between code being written, tests passing, a change being reviewed and the intended behaviour being verified. Those are separate pieces of evidence. A confident completion message doesn’t join them together.

Why the pipeline has boundaries

The pipeline around Patched has become more explicit about scope, review and verification.

Work needs a clear description and a checkable definition of done. The agent needs to know what it is authorised to change and when it should stop. Review needs to come from a separate session that didn’t implement the change, using a different model, and it needs to cover security as well as correctness.

I also want records that survive the session. If work stops halfway through, the next session should be able to establish what happened, what was verified and what remains blocked.

These requirements add work. They also make it possible to delegate with more confidence.

A second AI reviewing the first AI’s code is useful, but the review itself needs scrutiny. During work on the review pipeline, a candidate reviewer passed formatting checks but failed a qualification case involving the meaning of a workflow condition. It could return output in the required format without demonstrating the understanding needed for that case.

That was a useful reminder to assess the substance of a review. Receiving a neatly structured response tells you very little about whether the important problem was understood.

I’ve also had to keep the distinction between testing the pipeline and proving it in use. A dispatcher behaving correctly in an offline trial doesn’t establish that an autonomous development queue works end to end. That needs its own evidence.

The same discipline applies to the product and the tooling around it: make the claim match what was actually tested.

Being more selective about automation

I still want agents to get on with authorised work without asking me to approve every routine step. Constant interruption defeats much of the purpose.

But useful autonomy needs a defined scope and sensible stopping conditions. If a required check cannot run, or a review is unavailable, continuing until something can be described as a success creates more uncertainty.

There is also a cost to the machinery around the work. Models, reviews, retries and context all need managing. A process can become elaborate without becoming more effective.

Model selection has become part of the pipeline too. An orchestrator model coordinates the work, delegates bounded tasks to lower-tier models where appropriate and assesses the results. Straightforward collection or mechanical work doesn’t always need the same model as an ambiguous implementation problem.

If a task proves harder than expected, it can be escalated to a more capable model. That needs a reason: an unresolved problem or a capability gap, rather than automatically sending everything to the most expensive option. I still need to define the boundaries and the evidence required before accepting the work.

Independent review is another area where I’ve adjusted the approach. I wanted a different model to review the implementation, but those reviews were eating into the tokens available through my subscriptions.

I then explored free models, including Nemotron, as another route. That introduced a different trade-off: waiting longer for a review. For work where the turnaround is acceptable, I’m willing to wait.

The requirement is still that the reviewer meets a high bar. Being free doesn’t make a model suitable, and producing a convincing-looking review doesn’t establish that it can recognise the problems I need it to catch. Qualification has to come before relying on it.

I haven’t measured a savings figure I can put against this. The practical change has been to consider the demands of the task, review quality, subscription capacity and turnaround together.

Where my expectations are now

I haven’t stopped being enthusiastic about AI development. I have a more specific idea of what I’m enthusiastic about.

It helps me investigate unfamiliar code, work through implementation options and turn defined work into something I can inspect and test. It expands what I can attempt and how much ground I can cover.

I still need to understand the problem well enough to direct that effort. I need to recognise when an answer is incomplete and decide what evidence would make it convincing.

This doesn’t mean you must already know everything before using AI. It can help you learn. But when I move beyond my own expertise, I need to account for the fact that I’m less equipped to judge the result. Generating more output doesn’t resolve that gap.

After several months of building Patched, I’m putting more effort into defining the work and checking the outcome. That is where my experience has proved most useful, and where AI gives me the most value.