At Synodus, we put that idea to the test in 2026 when we selected Smart ICU (a central monitoring system for a top hospital in Vietnam) as the first project to use our AI-driven delivery framework.
AI can generate code in seconds. That was never the hardest part of the project. The harder question was whether a team without traditional developers could take a software module from requirements to a working product, with AI handling much of the implementation while humans remained responsible for the design, validation, and the final outcome.
In the 7th episode of The Performance-led AI Log, Nghiem Viet Tuan Anh (Liam), our Project Manager, shares what happened when the team put that model into practice: what worked, where it broke down, how the workflow changed, and what the project taught us about the future of software delivery.
The Performance-led AI Log is Synodus’ series of practical insights from our engineering leaders on how we build and scale stable software systems.
What you’ll explore:
- How a team without traditional developers built and delivered a real healthcare product with AI.
- What happened when AI-generated modules started drifting apart, and how the team fixed the process behind them.
- Where AI worked well, where developers still needed to lead, and what this reveals about the future of software delivery.
About Nghiem Viet Tuan Anh (Liam)
4.5+ years in project management & software development
Liam brings experience across both software development and project delivery, with hands-on exposure to healthcare and government systems. His work at Synodus has included a hospital ward-round application, a government project for TKV, a legacy HIS project, EMR, Smart ICU, and an ongoing RIS initiative.
His background gives him a practical view of software delivery from both sides: understanding what needs to be built and managing how it gets delivered.
Why start without developers?
The idea for the AI-first model came directly from Synodus’ division leadership. The goal was to improve delivery speed and optimize production costs. But to prove the model worked, we needed the right test.
“We chose Smart ICU because the business logic was not overly complex, and the scope was smaller than massive hospital systems like EMR or HIS,” Liam explains. “It was practical enough to prove the model worked, but small enough that we could control the risks.”
The starting team was highly unusual on purpose. It consisted of two Business Analysts (BAs), one Project Manager (Liam), and one deployment staff member who had absolutely zero background in coding, testing, or business analysis.
There were no developers and no quality control (QC) testers.
The logic was simple: People would own the business rules, and AI would handle the execution. We gave the team a one-month deadline to build a working proof of concept (POC).
“At first, we honestly did not believe we could meet that one-month deadline,” Liam admits. “Because we had no developers, I personally had to step in during the early stages to help update the AI’s skills and run tests on the new workflows just to see if they functioned.”
They finished the POC in just three weeks. But that speed required a totally new way of working.
Redefining the software team structure
The most visible change from the Smart ICU project is how Synodus now thinks about team structure.
A traditional project organizes a software module through a sequence of handoffs. Every time the work changes hands, context can be lost. The AI-first model allows one person to take much more ownership of that exact same module, moving through the entire lifecycle.
“That does not mean every module should be owned by one person forever, or that specialist review is no longer needed,” Liam notes. “It means the team can be structured around the type of work, instead of assuming that every project needs the exact same ratio of roles.”
For standard, structured business features, one person with the right business understanding can use AI to move through much more of the workflow. For deep technical integration, a developer still needs to lead.
This gives Synodus a much more flexible way to look at engineering capacity. The question is no longer about how many people are assigned to each role. The question is: where is human judgment needed?
The reality check: The moment we almost failed
At Synodus, one of our core DNA values is being Accountable. That means we are honest about our mistakes so we can fix them. At the very beginning, the project almost failed.
“The modules were not linking together. Every module looked like it was built differently, and the database the AI generated was a complete mess,” Liam shares. “With a one-month deadline, it was a very stressful moment. But instead of saying “AI cannot do this”, we realized the problem was not the AI. The problem was our input.”
The team stopped and went back to the planning phase. They cleaned up the database maps (ERD) and the system design documents.
They learned a massive lesson: AI cannot fix a poorly defined problem. When the human design was clear, the AI broke down the requirements perfectly. Once they fixed the ERDs and documents, the messy code disappeared. Everything connected.
The boundary line: CRUD vs. Deep tech
Through this project, the team found exactly where AI shines and where it hits a wall.
The majority of the Smart ICU system handled standard data tasks – creating, reading, updating, and deleting records (CRUD). For those well-defined business functions, AI was the perfect candidate.
But the hardest technical problem was integrating the software with bedside IoT machines (heart monitors and breathing machines).
“AI cannot do this part alone,” Liam explains. “A human developer actually has to look directly at the raw data shooting out of the medical machines to understand it and define the integration architecture.”
At that point, Synodus brought two developers onto the project. However, they worked in a new way. The developers did not type out pure code. They acted as technical guides and reviewers – telling the AI what to do and reviewing the complex output. The human effort was lower, but the deep engineering knowledge was still 100% necessary.
The golden rule: AI executes, humans own
The Smart ICU project proved that an AI-first team still requires absolute human responsibility. We set a strict rule: Output must always be reviewed by the person with the right expertise.
- Business Analysts must review the SRS documents.
- QC must review the test cases.
- Developers must review the complex code and run manual tests.
AI does not replace human judgment. In a healthcare system that tracks a child’s vital signs, human control is the only way to guarantee safety.
The 3 conditions for AI-first delivery
When the POC was placed on the hospital tables in just three weeks, the client was amazed by the speed. But for Synodus, the real victory was building a repeatable process.
Smart ICU showed that AI-first delivery depends on a strong starting point. We learned there are three conditions to make it work:
- Clear system design: ERDs, architecture, and requirements need to be defined carefully and early. AI does not remove the need for design. It makes clear design even more important because the AI can execute the instructions at a much higher speed.
- A reusable foundation: The team started with a base skill set and codebase, then refined them through the project. The next step is to standardize those skills so future teams can start from a proven foundation rather than rebuild the workflow every time.
- Knowing where AI works best: Standard CRUD and well-defined business functions are strong candidates for AI. Deep technical layers, such as device integration, still need experienced engineers. But those engineers can work as technical guides rather than writing every line manually.
“A machine can write code fast,” Liam concludes. “But the true value of your software still lives in how well your people design the process, control the quality, and own the final result.”
