If AI writes and reviews the code, what are engineers accountable for?
Introduction
I want to delegate as much as possible to AI: code generation, review, testing, and requests for fixes. That would leave people more time for business strategy, budgets, architecture choices that account for the company's future, and how the product actually feels to use.
Recently, someone without an engineering background raised a question with me. Even if AI produces the code, wouldn't they still need an engineer's assurance that it is fit to use? I recognize that feeling. AI can draft a contract, but I would still want a lawyer to review it. Personally, I would want expert review before publishing terms of service or a privacy policy.
Key points
- Delegate generation, review, testing, and fixes to AI while changing where people focus their work.
- People set business priorities, direct the user experience, and explain the evidence behind technical decisions.
- Professional assurance should identify what was checked, what remains uncertain, and how the release will be monitored and stopped if necessary.
This essay draws on official material available on November 6, 2026. Product capabilities are distinguished from my preferred way of working and my expectations about the future.
How far can review be delegated?
Automated code review already exists, although current guidance still includes human validation. GitHub's documentation says Copilot can miss problems and make mistakes, and advises validating its feedback and supplementing it with human review.
My own view is that we should not permanently fix the division of labor at AI writing code and people reading every changed line. Checking requirements, generating and running tests, fixing findings, and reviewing again are activities I want to delegate as a connected process.
On November 4, 2026, OpenAI announced plans to acquire Pierre. Pierre makes Code Storage, a service for storing code and tracking its history with Git, as well as libraries for navigating files and displaying changes. Its Trees and Diffs libraries are already used in the Codex app. The acquisition remains subject to closing conditions, including regulatory approvals; the companies remain independent until closing.
I see this as an effort to extend beyond generating code into the surrounding work of storing, understanding, and reviewing it. That broader development environment is worth watching.
Where should people spend their time?
I want people to spend more time on business choices and the experience of using a product. AI can help develop options, but someone still needs to bring the company's constraints and users' actual reactions into the discussion.
Consider an AI-based customer support feature. Should it maximize automated answers, or prioritize getting important customers to a person? Should the company spend this quarter's budget on it at all? Those choices come before implementation.
Architecture also needs to account for more than the fastest route to a prototype. Recurring costs, incident response, migration options, and the ability to maintain the system after today's developer leaves all affect the choice. In my earlier article on why everyone needs a product management perspective, I discussed deciding what to build and why. Here I am taking that thinking further by considering automation of the technical review as well.
People should also try the interface. Can someone recover from an input error? Can they confidently identify what they are confirming? A test that clicks a button does not establish that a first-time user will understand it.
In my experience, AI can produce competent interfaces from familiar patterns. But competence can settle into a polished average: similar spacing, cards, and colors, with a recognizable sameness.
Getting beyond that sameness takes human direction. Whose task should feel easier? What should be distinctive about this product? Choosing references, communicating what feels wrong, and trying successive versions still demand skill in steering AI.
What should an engineer's assurance mean?
I think professional value lies in explaining why a particular version is suitable to adopt, and under which conditions. A name on an approval without that explanation simply transfers the uncertainty to someone else.
The lawyer comparison describes my own desire for professional confidence. A well-formed document and one that suits a company's circumstances are different achievements. Similarly, a passing test does not answer every question about whether a permitted operation makes sense for the business, or whether the company accepts the cost of a failure.
Cyberattacks and confidence in going public
AI lets people without engineering backgrounds build and release services. Yet reports of AI-assisted attacks make me feel that the distance between being able to build something and feeling confident about putting it on the internet may actually be growing.
For example, Anthropic reported in November 2025 that attackers misused Claude Code to attempt infiltration of roughly thirty targets, succeeding in a small number of cases. This is an account of activity the company observed, with that scope of visibility. It reminds us that developers are not the only people using AI.
My expectation is that this will change the skills engineers are hired for. Someone needs to assess authentication, authorization, secret handling, and exposure to the internet, then explain the evidence and remaining risks. The ability to write code alone is not enough for that role.
An engineer without security knowledge will struggle to provide the assurance a client is seeking. I think the ability to learn these skills will increasingly affect who gets chosen for work, and some engineers may lose work as expectations change. Professional assurance here means supporting an informed decision; it does not mean guaranteeing absolute safety.
I would like an explanation to cover the following:
| What to explain | Example |
|---|---|
| Scope | This change and this version of the artifact were checked |
| Evidence | Tests confirmed rejection of access to another company's data |
| Uncertainty | Production-scale peak load has not been tested |
| Adoption conditions | Start with a limited rollout and disable the feature if anomalies appear |
These are proposed examples, not results from a product evaluation. Evidence must be reconsidered when the version changes. Yesterday's test results do not establish the behavior of today's additional changes.
Nor should responsibility become an unlimited personal guarantee from one engineer. The technical lead explains the validation; the business owner decides whether the remaining risks and costs are acceptable; operations takes responsibility for responding to incidents. One person may hold several roles, but the decisions can still be recorded separately.
Validation and stop decisions after release
Software provides an opportunity to update an adoption decision through observation after release. That is an important part of the discussion that the contract analogy does not fully capture.
Google's SRE Workbook describes deploying a change to a limited part of a service for a limited time, then evaluating it before proceeding. This creates a decision point before exposing all users to a change.
For an approval workflow, I would consider the following approach. It is a design proposal, not a measured operational result.
- Agree on expected behavior. Establish who can approve requests and whose information they can see.
- Have AI run the validation loop. Connect implementation, tests that confirm unauthorized operations are rejected, fixes, and reruns; preserve the version and results.
- Have people check the experience and evidence. Try recovering from mistakes, identifying the correct approval target, and reviewing untested conditions.
- Release to a limited scope. Monitor failures and reports of incorrect operations, with a named person authorized to stop the rollout.
Exposing another company's data is not an acceptable way to discover a defect during a small production trial. Some risks must be addressed before release. Where a change writes data, reverting code may not restore the previous state, so recovery needs separate consideration.
AI may carry the same misunderstanding of a requirement into both code and tests. Another AI reviewer can help, but adding models is not itself evidence of independent validation. Business acceptance criteria and observed execution results need to be checked against the implementation.
Conclusion
I want to delegate code generation, review, testing, and fixes to AI, while people focus on strategy, architecture within budget and future constraints, and the experience of using the product.
I also expect preparedness for AI-assisted attacks to change the engineering role further. If clients still seek professional assurance, its value will lie in deciding what evidence is needed, explaining the limits, and updating the decision after release. That can look quite different from reading every line of code.
At ZenChAIne, I want discussions of AI-assisted development to include the conditions under which a business can adopt software, alongside the speed at which it can be generated.