At Google I/O this year, Principal Software Engineer Adam Bender asked developers to stop thinking about their codebases as just files and folders.
He called it a software ecology.
A software ecology is a system made of three things: the technology you build, the people who build it, and the habits and culture that shape how they work. What your team ships is a direct reflection of what your organization values.
The 2025 DORA Report put it plainly: AI is an amplifier. It does not choose direction. It multiplies whatever you already have. Give it a healthy engineering culture, and it will give you better software, faster. Give it a broken one, and it will give you more bugs, more confusion, and more code nobody understands, faster.
In episode 3 of The Performance-led AI Log, our two CTOs – Ba Vu and Trung Ha – and our Director of Solutions and Services, Quan Nguyen, sat down to talk about what this actually looks like inside a software team. What breaks first. What needs to change. And what Synodus has built to make sure AI speed does not outrun human understanding.
What breaks first when everything speeds up
When a team first starts using AI coding tools, the results look great. Developers ship faster. Output goes up. Managers are happy.
But something quiet starts to break.
Ba Vu, our CTO, calls it the disappearing filter.
“Here is the uncomfortable part: AI does not break your code first. The code often works, and that is what makes it dangerous. What breaks first is human judgment. When writing 500 lines costs almost nothing, the natural pause a developer used to have – ‘Wait, should I even build this?’ – disappears. Effort used to be a quality filter. Remove the effort, and you remove the filter.”
Here is what that looks like in practice:
Review debt replaces tech debt: Code is cheap to generate. But it still costs the same amount of human brainpower to read and understand. When AI output piles up faster than seniors can review it, reviews stop being real. People click approve because they have no other choice. You end up with a codebase full of merged code that nobody actually understands.
Tests that test nothing: AI is good at writing tests, but it tends to write tests that simply repeat what the code already does. These tests stay green even when the behavior is wrong. Your coverage number looks great. Your system is not.
Architecture that drifts: AI solves problems file by file. It does not see the whole system. Without strong rules, a codebase slowly fills up with five different ways of doing the same thing. Nobody planned it. Nobody noticed until it became a problem.
Fake libraries with real malware: AI sometimes invents library names that do not exist. Hackers watch for these. They register those fake names on npm or PyPI and fill them with malicious code. A developer moving too fast installs the AI’s suggestion and pulls a backdoor straight into the product.
Humans govern, AI executes
At Synodus, we do not just tell developers to “be careful.” We build a culture where careful is the default.
“AI generates code. It does not generate understanding,” Ba says. “Our entire training approach is built around one principle: the understanding must always live in a human, not in a tool.”
These are the exact behaviors we train for:
Think before you prompt: Before anyone opens an AI copilot, the developer writes the spec first: what the function should do, what goes in, what comes out, and what should happen when things go wrong. Human defines what “correct” means. The AI fills it in.
Code reviews test understanding, not just output: In the AI era, “it passes the tests” is not a good enough answer. In every code review, the author explains their design decisions, names the alternatives they rejected, and describes what breaks if a key assumption changes. If the author cannot explain it, the code does not get merged. It does not matter who wrote it.
Say “I’m not sure” without fear: Trung Ha, our CTO, puts it this way: “We have strict everyday etiquette. Debates are not about winning. They are about making the product better. When a developer feels safe saying ‘I am not confident about this AI output’, bugs get caught in development – not in production.” That kind of safety has to be built deliberately. It does not happen on its own.
Treat AI output as a hypothesis, not an answer: Decades of aviation research show that humans over-trust automated outputs. A confident AI is more dangerous than a confident colleague because it never hesitates and never says “I am not sure.” We train developers to follow one rule with every AI output: generate, interrogate, verify, then trust.
Measure understanding, not volume: The moment a team starts counting lines of code or pull requests merged, developers are being paid to copy and paste. Instead, we track change failure rate, defect escape rate, and time-to-diagnose. The best engineer on our team is not the fastest typist. They are the people who know when the machine is confidently wrong.
Test the rules, not just examples: To stop AI from writing hollow tests, we use property-based testing. Instead of checking specific cases, developers write rules that must hold true for all inputs – then let tooling generate thousands of edge cases to try and break the AI’s logic. This is much harder to fake.
Protecting the systems that cannot go down
Banks, hospitals, and government agencies run on older core systems. These systems are not glamorous, but they are the backbone of how things work. A mistake here is not a bug ticket. It is a crisis.
Quan Nguyen, our Director of Solutions & Services, has seen what happens when AI speed meets legacy infrastructure without proper guardrails.
“AI can write code fast, but it has no sense of the weight of a legacy system. An API call that looks perfectly logical to an AI can lock an entire banking database table during peak hours. Fast and wrong is much worse than slow and right.”
To make sure AI-generated code never destabilizes these systems, Synodus enforces three non-negotiable rules:
Contract testing before any legacy touch: AI-generated code is not just tested end-to-end. It must pass contract testing first, meaning every single data “promise” between the new code and the old system is individually verified before anything goes live.
Architecture that defends itself: We do not ask developers to memorize guidelines and hope they follow them. We encode the architecture into automated checks that run in CI. If new code breaks a latency budget or points a dependency in the wrong direction, the build fails. The system protects itself.
Feature flags and rollbacks, no exceptions: Every integration with a core system requires an automated feature flag and a tested rollback plan. Our dedicated PQA team validates both before deployment. If something goes wrong, we can turn it off in seconds.
The 70/30 rule
AI handles the first 70% of software development well – the scaffolding, the boilerplate, the predictable patterns. That part is fast now. That part is cheap now.
The last 30% is different. Edge cases. System integrations. Non-functional requirements like performance under real load, security under real attacks, behavior under real failures. This part is disproportionately hard. It is also disproportionately important.
A 2025 research paper warned that if you leave AI unchecked, it pulls your codebase toward the statistical average of how software has always been written. You do not get innovation. You get the most common solution, wrapped in a fast timeline.
We let AI handle the easy part. We pay humans to conquer the hard part.
What this means for your team
Software is not just code. It is a system of people, habits, tools, and culture. Bloomberg, one of the most respected engineering organizations in the world, runs a flat, title-free culture where every developer owns their product end to end. Not because it looks good in a job posting. Because ownership produces quality.
When you introduce AI’s speed into a system like that, you multiply good engineering. When you introduce it into a system that rewards volume over understanding, you multiply problems.
The question is not whether to use AI. That decision is already made for most teams.
The question is what kind of culture your AI is amplifying.
At Synodus, we have made our answer clear.
