AI speeds the work. People stay responsible.

AI has changed what is economical. Reading every page of a site instead of a sample, comparing five designs instead of one, checking every record instead of the ones someone had time for, writing the tests nobody had budget for: work that used to be impractical is now affordable. We use AI throughout analysis and development for exactly that reason.

But a model’s output is not the truth. Models produce false positives (problems that aren’t there) and false negatives (problems they miss). They jump to conclusions from partial evidence. And they optimize whatever proxy you hand them, even when it isn’t what you meant: tests that pass because the test was weakened, a summary that is short because it dropped the inconvenient part. Speed without judgment just produces wrong answers faster.

The human role moves up

So the question isn’t whether people or AI do the work. It is which part of the loop each one owns. The human loop is:

1. Understand the operation and what the business needs.
2. Analyze the evidence, with AI reading and comparing at scale.
3. Architect the solution: what belongs to deterministic software, to AI, to automation and to people.
4. Plan the work in pieces small enough to verify.
5. Direct the AI on each piece, with the context and constraints it needs.
6. Validate what comes back, against evidence, tests and business rules.
7. Correct what is wrong, and feed the lesson back into the instructions.
8. Deliver into production, and stay responsible for how it behaves.

AI accelerates the analysis and implementation underneath that loop. It doesn’t replace any step of it.

What we let AI do

• Drafting: first versions of code, documents, test cases, migration scripts and copy.
• Analysis at scale: reading logs, pages, records and transcripts in volumes no person would, and surfacing patterns and outliers worth a closer look.
• Code, with review: implementation against a clear plan, where every change is read and accepted by an engineer before it lands.
• Comparison and iteration: trying several approaches quickly, so decisions are made with evidence rather than habit.

What stays human

• Framing the problem. Deciding what is actually wrong, and what success means, before any tool is chosen.
• Architecture decisions. Data boundaries, security, what must always behave the same, what can fail and how.
• Validation. Deciding whether a finding is real and whether a change is correct.
• Accountability. Once the system is in production, a person answers for it. “The model said so” is never the explanation.

How to review AI work

Reviewing is a skill of its own, and it is where much of an experienced engineer’s value now sits. The habits we hold to:

• Check the claim against the source. If the model says a page lost traffic or a function is unused, open the data or the code and confirm it.
• Test against a known answer. Run the analysis on a case where you already know the result. If it gets that one wrong, it isn’t ready for the cases you don’t know.
• Look for what is missing, not only for what is wrong. False negatives don’t announce themselves.
• Read the change, not the summary. The description of a change is the model’s opinion of it; the change itself is the fact.
• Watch the proxy. When a metric improves, confirm that the outcome it stands for improved too.
• Keep changes small. A small piece can be verified; a thousand-line change gets skimmed.

More on how this loop runs inside every project in our method.