Three tries to get it right
Our team did not design a finished AI workflow on the first attempt. We built one version, watched where it broke down, then built the next version to fix that specific problem. So far, there have been three versions.
Version 1: vibe coding
At the start, developers used AI in a loose, personal way. They typed prompts as they worked and let the AI write code on the spot. There was no set process behind it, just instinct. That is why we call this stage vibe coding.
What went wrong:
- Only developers used AI this way. Business Analysts (BA) and Quality Control (QC) staff barely touched it.
- Output quality depended entirely on the person using it. One developer’s results looked nothing like others’.
- Someone still had to check and fix most of the AI-written code by hand. That used up the time AI was supposed to save.
Version 2: one workflow for each role
The second version gave each role – BA, QC, and Dev – its own AI workflow. We call this approach harness engineering.
Before any work began, there was a refinement step. In that step, the AI agent had to fully understand the task and how the finished work would be judged. The written requirement became the single source of truth for the whole team.
This fixed the uneven quality from Version 1.
But it created a new bottleneck.
- QC and Dev spent a lot of time confirming business logic during refinement, before they could start their actual work.
Version 3: BA leads the full flow
The current version keeps harness engineering, but changes who leads it. Now the BA runs the process from start to finish.
Once the BA finishes the requirement and a working prototype, the QC agent and the Dev agent start on their own. Because the BA already worked out the business logic early, QC and Dev no longer need a separate refinement step. The requirement is still a single source of truth. It is just settled once, earlier, instead of three separate times.
This removed the repeated confirmation work that slowed down Version 2. We rolled this version out only recently, so we have not found major problems yet. What we have seen so far: the work moves noticeably faster than it did under Version 2.
This shift lines up with something our CEO, Cong Nguyen, shared at a recent Town Hall, held during Synodus’ summer trip.
“Before, a project might run on 1 BA and 6-8 developers,” Cong said. “Now, with AI taking on more of the coding, that ratio can flip. We can run a project with 2 developers, AI, and 3 BAs.”
The reason is simple. When AI can write code quickly, the real bottleneck moves earlier in the process, to defining exactly what needs to be built and why. Version 3 is built around that same idea: the BA’s work is no longer just the first step. It is the step everything else depends on.
Adapt AI in real software delivery
A version history is one thing. What matters more is what happens when engineers use AI on real, live work.
Trung Ha, our CTO, shared an honest account after more than a month of heavier AI use across the team.
On tasks with a clear, narrow goal, AI worked well.
“We used AI to write fairly advanced JMeter scripts for performance testing,” Trung says. “That was much faster than reading through tutorials and writing the scripts by hand. It also turned raw JMeter output into readable reports without much effort. And it helped us trace slow database queries in Google Cloud straight back to the exact lines of code that caused them, work that used to take a lot of manual digging.”
On full features, the picture changed.
“Hand AI a whole feature, and you can see it doesn’t fully understand what’s already there,” Trung explains. “NestJS already has a built-in way to handle caching. Ask it to add caching, and it will write its own version instead of using the one already built in. That’s extra code to maintain, not extra value.”
Other gaps showed up in places that are easy to miss during a quick review.
“When it created a database index, it didn’t understand how a B+ tree index actually works, so it added the wrong columns in the wrong order,” Trung adds. “And the code was sometimes repetitive in ways that confuse the next person reading it. One query already limited results to 1000 rows, but the generated code added a second check afterward for that same limit.”
What AI is good at, and where it still needs a human
Put together, this points to a clear pattern. AI does well on tasks that stand alone, with a narrow, well-defined goal. It does worse on tasks that depend on many other parts of a system, both technical details and business knowledge that live outside the task itself. It performs worst when a task becomes something other parts of the system will depend on later. In that case, using proven open-source code, or code with a clear and checkable source, is safer than code an AI wrote entirely on its own.
This is also why the move from Version 1 to Version 3 mattered. It was never about using more AI. It was about building a process that catches these gaps early, instead of after the code is already in production.
What this means for engineering leaders
A lot of teams are choosing their AI workflow based on what looks good in a demo, not on what holds up after a few months of real use. That is the wrong test.
The better question is not how fast AI can write code. It is whether the process around it lets a BA, a QC engineer, and a developer all trust what comes out the other end, not just approve it because a machine produced it.
That is the test we applied through three versions of our own process. It is the same test we bring to client work, on systems where a missed check costs more than time. Four of Vietnam’s five largest banks trust us with exactly that kind of work.
We will keep sharing what we learn as our own process keeps changing. A future episode will look at how this same thinking shows up in client projects.
