Senior Engineers in AI-Driven Development: 6 Calls They Keep
Summary: When AI writes most of the code, senior engineers at VAON keep six decisions. They are scope, architecture, trade-offs, business correctness, which security findings are real, and whether to release. AI handles fast drafting and checking. The CTO and a Tech Lead are involved in every project.
Contents
- Who checks the code the AI writes?
- Which decisions do senior engineers keep?
- Step by step: what AI does well, what seniors keep
- Why can't those decisions go to the AI?
- What happened when VAON let AI review a basic design?
- How can you check what the seniors actually decided?
- When are senior engineers not enough?
- FAQ
1. Who checks the code the AI writes?
At VAON, people check AI-written code at several steps, and senior engineers make the final call on the big decisions. The CTO and a Tech Lead are involved in every project.
"Who checks the code the AI writes?" was one of the three questions clients asked VAON most in 2026. "Someone reviews it" is not a full answer. You need to know what that person decides and what evidence they decide on.
This post expands the "a person decides" column of our Claude Code development workflow. That 10-step workflow is the standard VAON applies to most projects, not yet to all. CTO and Tech Lead involvement, review and test records, and automated pull request gates apply to every project.
2. Which decisions do senior engineers keep?
Senior engineers at VAON keep six decisions that are expensive to get wrong and that the AI lacks the grounds to make:
- Scope: what goes into this phase, what waits, which questions go to you instead of guesses.
- Architecture: how the system is split, where data lives, what must stay easy to replace.
- Trade-offs: speed or certainty at each point, with the reason written down.
- Business correctness: code that runs is not always code that follows your rules.
- Real security findings: AI security review raises false alarms and can also miss things.
- Release or not: based on tests, reviews, your acceptance testing and the security check.
These six share one trait: the grounds for deciding usually sit outside the codebase.
3. Step by step: what AI does well, what seniors keep
At every step, the AI drafts and checks fast, while a senior keeps the decision and asks for evidence. This table adds an evidence column to the workflow post's short version:
| Step | AI does well | Senior keeps the decision on | Evidence the senior asks for |
|---|---|---|---|
| Request analysis | Listing questions and vague points | Which questions to ask, which to drop | Filtered question list |
| Spec lock | Drafting requirements from meeting notes | Scope of this phase, what waits | Requirements you confirmed in writing |
| Basic design | Spotting inconsistencies, missing error handling | Business rules, priorities | Findings fixed, or dropped with a reason |
| Plan | Splitting work, listing files, finding risks | Architecture, order, trade-offs | Plan that survived the challenge round |
| Coding | Writing code, unit and e2e tests | Whether the code follows the business rules | Commands run and test output |
| Pull request review | Reading changes against project criteria | Which comments to fix, which to drop | Review record |
| Security, release | Scanning every change | Which findings are real, ship or fix first | Scan results, your UAT checklist with screenshots, release notes |
The last column is the one few teams talk about. The Claude Code best practices page says to ask the AI for evidence: "the command it ran and its output, or the screenshot." "All tests pass" alone tells you very little. Seniors read the evidence, not the AI's own report.
4. Why can't those decisions go to the AI?
Those decisions stay with people because the grounds for them are usually not in anything the AI can read. Claude Code's own documentation lists what the AI cannot find by reading a repository, including "A decision your team made in a meeting."
Two illustrations: your company's spending approval rules, or the reason a feature was moved to a later phase. The AI does not know these unless someone writes them down.
The second reason is review itself. The same page warns: "A reviewer that's asked to find problems will always find something." Fixing every finding adds needless layers and tests for impossible cases. Someone who understands both the system and the business has to pick which comments matter.
Then there is responsibility. Each project's contract sets liability, and VAON does not treat "the AI wrote it" as a reason for that to change.
5. What happened when VAON let AI review a basic design?
VAON tried a large language model (LLM) as a reviewer of a basic design document (基本設計書) on an internal project, not a client project. The results split into two clear groups.
The LLM gave useful findings on four things: inconsistencies between documents, missing error and edge-case handling, basic non-functional requirements, and wording or terminology. People were still needed on three: whether business rules made sense, priorities and trade-offs, and how operations really run.
So VAON set a rule: the LLM reviews first, people review the business side. Our reading of the split is that the first group can be checked inside the documents, while the second needs facts from outside them. We did not count findings during the trial, so there are no numbers here.
6. How can you check what the seniors actually decided?
You check the seniors' role through records, not promises. "AI adds speed, seniors hold the standard" means little unless you can see who decided what.
Things you can ask VAON to show you:
- Review and test records, kept on every project.
- Results of the automated gates on each pull request (secret scanning, dependency scanning, static analysis), which run on every project.
- Handover documents that record the reasons behind technical decisions, so knowledge does not live in one person.
Each pull request goes through self-review, AI review and a second person, as described in how we review AI-generated code. The pre-release gate is covered in pre-release security review for AI-written code. On your side, the UAT checklist with screenshots is the evidence you keep yourself.
7. When are senior engineers not enough?
Senior engineers cannot replace the person on your side who knows the business, and there are other limits:
- Seniors do not know your business better than you. Without someone to answer business questions, "business correctness" becomes a guess.
- If you have not allowed code into AI tools, the AI review and AI security steps do not run. Only automated gates and human reviewers remain.
- The LLM design review trial was internal. Using it on your documents needs your permission first.
- VAON has 15 full-time staff. A project needing dozens of people at short notice may be beyond what we can take on.
8. FAQ
How involved are the CTO and Tech Lead? The CTO and a Tech Lead are involved in every VAON project. In the 10-step workflow, the Tech Lead approves the implementation plan and decides what to change after the challenge round. The team lead decides on merges. The spec lock phase is led by a BrSE (Bridge System Engineer) together with the Tech Lead.
Does a senior read every change the AI writes? Every pull request is read by someone other than its author before merge, and the main branch is locked until review. Self-review, AI review and automated gates come on top. Merge and release decisions always belong to a person, never to the AI.
What if the AI and a senior engineer disagree? The AI's output is input, not a verdict. The senior decides, and you can see the review record. For security findings, the person reading the results separates real issues from false alarms. For business questions the spec cannot answer, VAON asks you instead of guessing.
How does my team take part in these decisions? You decide what belongs to you. Requirements are locked in writing before building starts. Out-of-scope work starts only after you approve the quote and schedule impact. A weekly report covers progress, risks and decisions we need from you. Finally, you run acceptance testing before release.
With this much AI, who is responsible when something breaks? Responsibility is set by each project's contract. VAON does not treat "the AI wrote it" as a reason for that to change. AI-written code goes through the same review, testing and security checks as human code. Both sides have records to check against.
One thing you can do today: ask your current development team two questions. "Who decided to ship the last release? What evidence did they look at?" An answer with a name and a record tells you who holds the standard.
To find out who would hold these decisions on your project, book a free 60-minute consultation. Our CEO joins, you need no documents, and there is no commitment.
Author: Dang Van Luan, Founder & CEO, VAON. Graduate of HEDSPI (Hanoi University of Science and Technology). Worked at FPT Software, then 5 years at Digital Plus (Tokyo) on a system with 10 million users. 8 years as COO of a 120-person IT outsourcing company, where he built the management system to ISO 9001 and ISO 27001. 15 years in the industry.
