When two correct features create one broken system
Two AI agents were assigned to develop related features for a Smart ICU project. Both completed their work, and both passed their individual tests.
But when the features were brought together, they couldn’t integrate properly. Each agent had independently created its own database table, without accounting for how the two features needed to work together.
The problem wasn’t that AI couldn’t generate working code. It was that the agents made separate decisions without sufficient alignment on the overall system design. The tests confirmed that individual features worked, but failed to catch an integration problem between them.
This experience, shared by Nghiêm Viết Tuấn Anh (Liam), Project Manager at Synodus, during the Xtivate #1 knowledge-sharing session, illustrates a growing challenge in AI-assisted software engineering.
As AI takes on more development tasks, generating code becomes easier. But ensuring that the output fits the requirements, follows the intended architecture, and works as part of a complete system remains a much harder problem.
For engineering leaders, this raises a different question: How can AI be organized to accelerate the entire software delivery process, rather than simply producing more code?
The temptation to measure AI by speed
The pressure to deliver faster is nothing new. However, AI has changed what’s possible when engineering teams face limited resources and demanding deadlines.
Across three projects discussed at Xtivate #1, including Smart ICU, a rehabilitation management project, and an eVisa-related project, the teams faced similar constraints: short delivery windows, limited staffing, and requirements scattered across documents or held in individuals’ knowledge.
Instead of relying solely on additional headcount or longer working hours, Liam explored how AI agents could take on defined responsibilities across business analysis, technical design, development, and quality assurance.
The eVisa example demonstrates the scale of output this approach can produce.
With one Product Owner and no dedicated programmers or testers, the AI-assisted workflow produced the following within nine days:
| Delivery output | Reported result |
|---|---|
| Web portals supporting basic business workflows | 2 |
| Specification documents | 16 |
| Test cases | 1,172 |
| Lines of code | Nearly 50,000 |
| Delivery window | 9 days |
These numbers are striking, particularly given the limited staffing.
But they also introduce an important distinction: output volume is not the same as delivery performance.
Thousands of test cases do not automatically prove that all critical scenarios have been covered. A large codebase does not necessarily mean the solution is maintainable, and passing automated checks does not guarantee that the user experience is correct.
The reported eVisa results demonstrate how much work an AI-assisted workflow can generate within a short period. They do not, by themselves, establish production readiness, long-term reliability, or a measured productivity improvement against a conventional team.
This is where AI optimization needs to move beyond coding speed. The real opportunity lies in improving how work progresses from requirements to accepted, usable software.
What happens when AI is organized like an engineering team?
One of the most practical ideas from Liam’s presentation was to stop treating AI as a single assistant responsible for everything.
Instead, the workflow organized eight agents into four pairs, each representing a function in software delivery.
| Function | Execution agent | Review agent |
|---|---|---|
| Business analysis | Drafts requirements and specifications | Reviews requirements for clarity and completeness |
| Quality control | Generates test cases | Checks test coverage and test-case quality |
| Technical leadership | Produces technical designs | Reviews architecture and design decisions |
| Development | Generates code | Reviews implementation |
Each execution agent and its corresponding reviewer operate in separate sessions.
The principle is straightforward: the agent producing an artifact should not be solely responsible for deciding whether that artifact is correct.
However, separating agents is only the beginning. Two AI agents can still make similar assumptions or overlook the same requirements. Independent AI review reduces reliance on a single output, but it cannot replace objective checks and accountable human judgment.
To manage this, Liam’s approach combines three layers of control.
Layer 1: Make requirements clear before generating code
Business Analysis sits at the beginning of the workflow.
AI can help structure requirements, break down user stories, draft preliminary entity-relationship diagrams, and organize development tasks. But it cannot be expected to discover missing business facts on its own.
The Smart ICU database issue showed what happens when related tasks are developed without a sufficiently shared understanding of the intended system.
For this reason, the workflow requires approved designs and prototypes before code generation begins. Missing information must be raised as an open question rather than silently filled in by AI.
This shifts attention to a part of delivery that can easily be overlooked when code generation becomes faster: requirements clarification.
Layer 2: Verify the work before accepting it
Each AI-generated artifact passes through a defined verification sequence.
First, an AI agent performs the task. A separate agent then reviews the result. Automated checks, including relevant tests and build validation, provide another control layer. Finally, a responsible human reviews and approves the deliverable.
If a check fails, the work returns for correction.
The aim isn’t to remove human involvement from software delivery. It’s to help people spend more time assessing requirements, architecture, risks, and results instead of carrying out every repetitive task manually.

Layer 3: Monitor the delivery process proactively
The model also extends beyond individual tasks.
Liam described a monitoring approach that tracks work progress, identifies blocked or at-risk tasks, and raises warnings through Jira and team communication channels, including alerts ahead of approaching deadlines.
This allows AI-assisted work to continue outside normal working hours, with human reviewers assessing the results when they return.
But unattended execution introduces another practical problem: continuity. AI sessions may stop when usage limits are reached or their context is interrupted.
Breaking assignments into smaller tasks, saving intermediate results, and maintaining clear handover notes helps the next session continue without reconstructing the entire task.
Together, these three layers turn AI from an individual productivity tool into a more structured delivery workflow, with defined inputs, quality controls, and supervision.
Where AI still needs human judgmnet
Even with multiple agents and automated checks, some engineering decisions cannot safely be delegated to AI alone.
One example from Liam’s presentation involved automated tests that continued passing for two days while Vietnamese fonts were displayed incorrectly.
The application satisfied the checks being run, yet a visible problem remained in the actual interface.
It was a reminder that passing a test only confirms what the test was designed to check. If the expected behavior is incomplete or the test misses an important user-facing detail, automation can report success while the product still contains defects.
The same limitation applies to requirements. An ambiguous request can travel through multiple AI agents, producing specifications, code, and tests that all agree with one another but are based on the wrong interpretation.
This is particularly important in areas where errors carry greater consequences.
Liam’s team identified a practical boundary between tasks suitable for AI assistance and decisions that require greater human involvement.
| Suitable for greater AI delegation | Requires human-led decisions or specialist validation |
|---|---|
| Repetitive CRUD functionality | Complex integrations with medical devices and specialized systems |
| Test-case drafting | Final database architecture decisions |
| Pattern-based refactoring | User experience and visual quality |
| Structured documentation | Legal, security, and sensitive-data requirements |
These are not absolute boundaries on where AI can provide assistance. Rather, they distinguish between work AI can help produce and decisions that remain the responsibility of qualified people.
Data protection adds another constraint. Sensitive information, such as personal identification details, salaries, bank accounts, unsigned contracts, and restricted project data, should not be supplied to public AI tools without appropriate authorization and safeguards.
In practice, the team retains three responsibilities that cannot simply be transferred to AI:
- Providing accurate business information and resolving unclear requirements.
- Making decisions at important checkpoints, including requirements, design, and acceptance.
- Inspecting and approving the final work before it is accepted or released.
The objective is controlled delegation, not the removal of human accountability.
What engineering leaders should rethink
Liam’s experience highlights an important shift: optimizing software delivery with AI requires more than adopting new tools. It calls for a different approach to managing work, quality, and accountability.
Four lessons stand out:
- Get requirements right before execution: Clear specifications and approved designs prevent AI from multiplying misunderstandings across development tasks.
- Verify the whole system, not just individual outputs: Independent AI reviews, automated tests, and human validation must work together to catch problems that isolated checks can miss.
- Turn mistakes into reusable rules: Document recurring errors in project-specific AI guidelines so every failure helps improve future work.
- Measure outcomes, not output volume: Track accepted deliverables, rework, and delivery time rather than lines of code or generated test cases. Start with a repetitive task, run a one-month trial, and compare results before scaling.
For engineering leaders, the priority is not simply making AI do more work, but ensuring that the work it produces can be trusted and delivered consistently.
How useful was this post?
Click on a star to rate it!
Average rating / 5. Vote count:
No votes so far! Be the first to rate this post.
