Developers and AI
What Developers Do Differently
AI coding assistants move a developer's work from producing code to judging it. The code still gets written, increasingly by AI, but the developer's value now lies in deciding whether that code is correct, secure, maintainable and consistent with the system's architecture. The working rule that follows is simple: never accept code you cannot explain.
The job description still says design, build, test and maintain software. The activity underneath those words has shifted. Developers who once spent most of their time writing code, typing syntax, composing functions and wiring up integrations, now spend a shrinking share of their day on it. That calls for different instincts, a different allocation of attention, and a different understanding of what good work looks like.
The New Shape of Developer Work
In a pre-AI workflow, implementation dominated a developer's day: reading requirements, understanding the problem, designing a solution, writing the code, debugging, testing, refining. The cycle was long, and most of the time went to the middle, fingers on keyboard, building the thing.
AI compresses the middle. A developer working with GitHub Copilot, Claude Code or a similar assistant spends less time typing boilerplate, looking up API signatures and writing routine tests. The code appears faster. But the work on either side of implementation, understanding the problem and validating the solution, expands to fill the space.
The new shape of developer work looks like this: shaping prompts and context to guide AI output, constraining the scope of changes to prevent architectural drift, reviewing diffs line by line, validating behavior against specifications, writing and running tests to verify correctness, and integrating AI-generated code into the existing system without creating inconsistencies. Less typing, more thinking. Less construction, more curation.
GitHub's own research on Copilot shows that developers accept roughly 30% of suggestions without modification. The other 70% are rejected, edited or used as starting points for a different approach. The tool is not replacing the developer's judgment. It gives that judgment more to work on.
Why Senior Developers Matter More
A counterintuitive consequence of AI coding assistants is that they increase the value of senior developers relative to junior ones. The common expectation was the opposite: that AI would be an equalizer, giving junior developers access to patterns and practices they hadn't yet learned. There is some truth to that. Junior developers do report significant productivity gains from AI assistance.
But senior developers bring something AI cannot provide and junior developers have not yet developed: the ability to recognize what good code looks like in context. Not just syntactically correct code, or code that passes tests, but code that fits the system's architecture, respects its performance constraints, handles its edge cases and stays maintainable. That judgment, built over years of building, debugging, refactoring and maintaining production systems, is what it takes to evaluate AI output.
Studies from Microsoft and Google indicate that senior developers using AI assistants see productivity gains of roughly 1.3x, while spending more time reviewing AI output than writing from scratch. They are not faster because they type less. They are faster because they can judge quickly whether AI-generated code meets the standard. A senior developer reads an AI-generated function and spots the missing null check, the inefficient query pattern, the concurrency issue that will only surface under load. A junior developer reads the same function and sees code that compiles and runs.
This does not mean junior developers should avoid AI tools. It means organizations need to invest in mentorship and code review practices that help junior developers build the judgment AI cannot provide. The worst outcome is a junior developer who accepts AI output uncritically and ships code they cannot explain. Code review in the AI era covers the review practices that catch this.
The Cardinal Rule: Never Accept Code You Cannot Explain
GitHub's documentation for Copilot includes a plain warning: the tool can make mistakes. This is not legal boilerplate. It is an accurate description. AI coding assistants generate code that is plausible, syntactically correct and frequently wrong in subtle ways. The variable name suggests one thing and the implementation does another. The function handles nine out of ten cases correctly. The pattern looks standard but introduces a security vulnerability.
The cardinal rule for developers using AI assistants is simple and non-negotiable: never accept code you cannot explain. Every line of AI-generated code should be understood before it is committed. Not skimmed. Not assumed. Understood, the way you would understand code you wrote yourself.
The rule has practical consequences. Developers read every diff carefully, not just the parts that look unusual. They run tests after every AI-generated change instead of batching changes and testing later. They reject code that works but that they don't fully understand, because code you don't understand is code you cannot debug, extend or maintain.
The temptation to skip this step is real. AI-generated code often looks reasonable. It follows patterns you recognize. It passes the tests you've written. The pressure to move fast, to collect the productivity gains that justified adopting the tool, pushes against careful review. But the cost of accepting code you don't understand compounds. Every unexplained function is a future debugging session. Every opaque pattern is a future architectural obstacle.
The AI Delegation Instinct
Experienced developers working with AI assistants develop what might be called an AI delegation instinct: a sense of which tasks to hand to AI and which to handle directly. It is a real skill, and it develops through practice.
Some tasks delegate well: generating boilerplate, writing routine tests, implementing well-defined data transformations, scaffolding CRUD operations, converting between data formats. These tasks have clear specifications, little ambiguity and established patterns. AI handles them reliably because the solution space is constrained.
Other tasks delegate poorly: designing system architectures, resolving conflicting requirements, implementing complex business logic with many edge cases, optimizing performance-critical code paths, handling security-sensitive operations. These require contextual judgment AI does not have. Delegating them doesn't save time. It creates review work that exceeds the time saved.
The instinct develops as developers learn where the boundary lies for their tools, codebase and domain. A developer working on a well-documented API with strong type definitions will find AI handles more tasks reliably than a developer working on a legacy codebase with implicit conventions and undocumented business rules. The boundary is contextual, and reading it accurately is part of a developer's skill set. The chapter on AI-assisted architecture applies the same question to design decisions.
The Multi-Tool Reality
The industry has moved past the single-tool era. A 2025 survey by Stack Overflow found that 70% of developers using AI coding assistants use two to four different tools. This is not tool sprawl. It reflects a real diversity of needs.
A common enterprise pattern pairs a broad baseline tool with a specialized one. An inline assistant such as GitHub Copilot stays present in the IDE, offering completions and handling routine code generation across the codebase. An agentic tool such as Claude Code is invoked for larger tasks that need multi-file reasoning, architectural understanding or extended implementation sessions. Developers switch between them based on the task, the way a craftsperson switches between a power drill and a hand tool.
Other combinations exist. Some teams pair Cursor with an agentic tool. Others use Copilot alongside specialized tools for specific languages or frameworks. No single tool excels at everything. Inline completion tools optimize for speed and convenience in small, local edits. Agentic tools optimize for reasoning and coherence across larger changes. Developers who restrict themselves to one tool leave capabilities on the table.
This has consequences for organizations. AI tool policies need to accommodate several tools instead of mandating one. Developers need training on more than the one tool the organization licensed. And code review needs to account for the fact that different sections of code may have come from different tools with different strengths and weaknesses. It is one reason the Azumo SDLC, our way of working with coding agents, is a shared kit of workflows, skills, rules and review checklists rather than a setup tied to one product: the same kit loads in Claude Code, Qwen Code, OpenCode and Pi.
When AI Slows You Down
Not every study of AI coding assistants shows productivity gains. A widely discussed study by METR found that AI coding assistants sometimes slowed experienced developers working on mature codebases they knew well. The developers spent more time reviewing, correcting and integrating AI suggestions than they would have spent writing the code themselves.
This finding does not contradict AI's value. It marks a boundary condition. AI coding assistants give the largest gains when developers work outside their deepest expertise: in unfamiliar languages, with unfamiliar APIs, on unfamiliar codebases. They give smaller gains, and sometimes negative ones, when developers work in their strongest domain on codebases they know intimately.
The practical lesson is to calibrate AI use to the task. For routine work in familiar territory, the overhead of reviewing AI suggestions may exceed the time saved. For exploratory work in unfamiliar territory, AI assistance can change what one developer can take on. Skilled developers use AI selectively, not reflexively: they engage it when it adds value and set it aside when it doesn't.
The Review Discipline
Code review has always been important. With AI-generated code, it becomes critical. AI-generated code can be subtly wrong in ways that are hard to catch in review. It looks like code a competent developer would write. It follows established patterns. It lacks the obvious tells, such as unusual variable names, unfamiliar patterns or commented-out debugging code, that flag human-written code as problematic.
Reviewing AI-generated code takes a different posture. Reviewers pay more attention to logic and less to style. They verify behavior against specifications instead of pattern-matching against expectations. They check edge cases explicitly instead of assuming they were handled. And they test more aggressively, because AI-generated code is more likely to handle the common case correctly and miss the exceptional one.
Teams that adopt AI coding assistants without strengthening their review practices will accumulate technical debt faster than teams that don't use AI at all. The speed of code generation is a multiplier. It multiplies both the rate of good code and the rate of subtle defects. Only disciplined review keeps the ratio favorable.
The Skill Shift
The skills that set effective developers apart are shifting. Writing code from scratch, producing clean, efficient implementations in a blank editor, matters less as AI handles more of the production work. The skills that matter more are systems thinking, architectural reasoning, debugging complex interactions, reading and evaluating code you didn't write, and explaining technical tradeoffs to non-technical stakeholders.
That changes how developers should invest in their own growth. Learning a new framework's API matters less when AI can look it up for you. Understanding the principles behind the framework's design matters more, because those principles are what let you judge whether AI is using the framework correctly. Memorizing syntax is nearly worthless. Understanding semantics, what the code means and not just what it says, is worth more than ever.
The developers who do well with AI are the ones who think clearly about what the code should do, check carefully whether it does that, and say plainly what remains uncertain.
How Azumo Developers Work With AI
On the custom software development work we do for clients, our developers treat AI as a tool under human direction, not an autonomous producer of finished code. The Azumo SDLC writes that down:
- The feature workflow runs clarify, spec, plan, build, validate, review, deliver. The agent stops where a person should decide: approval after the spec, after the plan, and before shipping.
- Nothing passes review without evidence. Separate review checklists cover correctness, security, test adequacy and UI/UX, and work missing a test goes back to build.
- Each verified task becomes one commit on a feature branch, so each change can be reviewed and explained on its own.
Our senior developers mentor junior team members in the hardest skill of all: knowing when to trust the tool and when to trust their own experience.