AI Can Write Code Faster, but Can Your Team Maintain It?
Fast code can leave slow consequences.
I first began working with AI-assisted development when the tools were still new enough to make many of us hesitant. My team and I were trying to understand what they could do, what they should do, and how they might fit into an already busy working day. There was curiosity, but there was also uncertainty. We had tight deadlines, so there was never much time to experiment properly while we were at work.
Telling people to explore a new tool in their own time produces fairly predictable results. Some people go full Hulk, researching, testing, breaking things and trying again. Some use it for a few simple tasks. Others do nothing because, by the end of the day, they are too tired to begin another learning project. None of those responses tells you what thoughtful adoption could look like inside a team with shared expectations and enough time to learn.
At the same time, there was pressure from above for everyone to start using AI. The enthusiasm arrived before the space to understand it. We were being encouraged to move faster with tools we had not been given proper time to investigate, while questions about security, data protection and access to company information seemed to be lagging behind.
That was one of my earliest frustrations with the way people adopted AI. It felt as though many of the rules we had learned about protecting information had briefly disappeared. We had spent years telling people not to give unfamiliar tools access to sensitive documents or data. Then AI arrived, and in the excitement, people began handing over access before always asking what the tool could see, retain or expose.
This was not a reason to reject AI. It was a reason to take its introduction seriously.
The same pattern soon became visible in the code itself. AI could produce working features quickly, but working was sometimes where the scrutiny ended. Developers would accept generated code without checking it closely or understanding why it had been written in that particular way. When I asked why someone had chosen an implementation, the answer I dreaded was: “I don’t know. AI wrote it.”
For me, that answer is the heart of the problem.
The code may have come from an AI tool, but the responsibility did not. If you add code to a codebase, approve it and push it, you own what happens next. You need to understand how it fits into the architecture, what assumptions it makes and what it might affect later. The fact that the feature works today does not tell us whether the implementation is reusable, secure or maintainable as the system grows.
I have always been particular about neat code, reusability and knowing what is entering a codebase. That is not because I believe there is only one elegant way to write every feature. It is because poorly considered decisions accumulate. A codebase rarely wakes up one morning and decides to become spaghetti. It gets there through a series of small choices that seemed acceptable because the feature worked and the deadline was close.
AI did not invent that problem. Developers have always copied code they did not fully understand, rushed changes and made architectural compromises under pressure. AI simply made it possible to do all of that much faster and at a much larger scale.
That distinction matters because I do not believe blanket claims that AI-generated code is always wrong. It often is not. AI-assisted development can be wonderful. Work that once took me a day and a half can sometimes be completed in half a day, often with extra polish I would not have had time to add before. The tool can help generate tests, explain unfamiliar code, remove repetitive work and create a useful starting point.
The issue is what happens between generation and acceptance.
Research is beginning to reflect the tension many teams are already feeling. In GitLab’s 2026 survey, 78% of respondents said developers were writing and committing code faster after adopting AI tools, while 85% agreed that the bottleneck had shifted from writing code to reviewing and validating it. The same research found that 73% believed overall code quality had improved, which is an important counterweight to the idea that AI code is automatically poor. Speed and quality can coexist, but only when teams retain the ability to understand and govern what they produce.
GitLab Inc.
Sonar’s 2026 developer survey found a similar gap. It reported that only 48% of respondents always verified AI-generated code before committing it, while 38% said reviewing AI code required more effort than reviewing code written by human colleagues. AI can shorten the act of producing code without removing the thinking required to trust it. Sometimes it simply moves that thinking somewhere less visible.
Anirban Chatterjee
I saw that gap when people pushed AI-generated changes without the required approval because the feature appeared to work. The code had not necessarily failed. The human process around it had.
Our team already had a simple boundary: at least one senior developer needed to approve a change. It was not a complicated policy, but it gave another person the opportunity to ask why something had been implemented in a particular way. Those questions mattered because they returned understanding to the process. They made the person submitting the code look at it as something they were responsible for, not something the tool had produced on their behalf.
Over time, people would conveniently forget the approval rule, as people sometimes do when a process stands between them and a satisfying green tick. We kept reminding them. The point was not to slow everyone down or treat developers as though they could not be trusted. The review was part of how trust was built.
Trust does not come from knowing that someone never uses AI. It comes from knowing that they can explain, defend and maintain the code they submit, however it was produced. In a larger company, the eyes of other developers are especially valuable because no single person holds all the context. A smaller, established team may be able to work differently when its members already understand one another’s judgement and the codebase deeply. The exact process can change. Ownership cannot.
This is where the conversation about speed becomes more complicated. If developers understand their code and teams preserve meaningful review, AI can help them move very quickly. Perhaps not quite as quickly as they could by accepting everything and pushing it immediately, but that comparison ignores the work being postponed. The time saved today may return later as debugging, security reviews, architectural rework or a long afternoon spent trying to understand a decision nobody remembers making.
Speed for its own sake is not really speed. Sometimes it is deferred effort wearing a productivity badge.
There is another consequence I think managers need to watch: the mental load placed on developers. A developer using AI is no longer only taking a specification and turning it into code. They may also be planning work, providing context to an AI tool, reviewing its output, correcting its assumptions and deciding when to intervene. If they are running multiple agents across several features or projects, they are also carrying a considerable amount of context switching.
The tool may type faster than a human, but the human still has to think.
That can be easy to overlook when dashboards show more output. A team may appear to be accelerating while its developers are becoming mentally scattered, fatigued or less certain of what they have shipped. Managers cannot assume that because AI reduces some forms of effort, it reduces the total cognitive burden of the work. In some situations, it redistributes that burden and makes it harder to see.
Taking care of engineering teams in this new environment means giving people time to learn the tools during work, not only encouraging adoption. It means having honest conversations about data access and security before something goes wrong. It means protecting code review even when the feature appears finished. It also means noticing when a developer is trying to manage too many parallel streams simply because the technology makes it possible.
I am far less hesitant about AI-assisted development than I was when it first appeared. I use it, I value it, and I know how much time it can save. What I have become more cautious about is the temptation to confuse generation with completion.
A feature is not finished merely because the code exists or because the screen behaves as expected. It is finished when the team can understand it, trust it and take responsibility for what happens after it is shipped.
AI can help us create code faster. The more important question is whether we are still willing to remain present long enough to understand what we have created.
Member discussion