Should You Become an AI-Driven Developer? How Professional Engineers Push Their Productivity Higher

Hello, this is Ryuta Hamamoto from TIMEWELL.

It is Friday evening. You have opened a pull request and you are waiting for the review to come back. The next ticket is already stacked up in front of you, but if you start it the interruptions only multiply, so your hands somehow stall. When the review finally does come back, the comments are about naming, or a missing null check, the same routine points as every other time. Come next week, you are writing yet another similar piece of CRUD logic from scratch, this time for a different screen. I suspect there are more than a few engineers who feel a quiet dissatisfaction with spending their time this way.

This article is written for the professional engineer who carries that feeling from the shop floor and remains half-convinced about AI-driven development. Does AI coding really raise productivity, or is it partly marketing copy? How many times faster does it make you? What skills should you build, and how does your career change? Avoiding exaggeration, and leaning only on publicly available primary sources, I want to lay it out as honestly as I can.

Time dissolves into review queues and boilerplate

First, let me look concretely at where the daily wear and tear happens. If you recognise yourself here, the rest of this piece will be worth your time.

Do you have the sense that time is lost not so much in the implementation itself as around it? The design is more or less finished in your head, yet the manual work of turning it into code eats up the hours. You write a dozen similar API endpoints. You prepare mocks and fixtures for tests. You fill in the boilerplate for error handling. None of it is hard, but all of it reliably consumes time. Much of the day is drained not into work that uses your head but into work that moves your hands.

The back-and-forth of reviews is a quietly heavy burden too. Your own pull request sits still until the other person has a free moment, and your concentration is broken to look at someone else's. Most of the comments are not essential debates about design but variations in style or things that were simply overlooked. When you think about it, humans endlessly repeating this exchange with each other is an inefficient structure.

Then there is the heavier weight of technical debt and the cost of learning. You reach nervously into code a predecessor wrote in a hurry and then left untouched. There is no specification document; the code alone remains as the truth. On top of that, frameworks and libraries update one after another, and unless you keep catching up on new ways of writing, you fall behind. Time to move your hands, time to relearn, and time to decipher other people's code. Squeezed between these three, the time you have left for genuinely valuable design and problem-solving is smaller than you would think. That, I believe, is the real picture on many teams. If you are curious how much you are already putting AI to work in your job, it helps to first check where you stand with our free AI literacy self-check. The discussion ahead will feel more concrete once you have.

Why the structure that wears you down comes about

Next, let me dig one layer deeper into why that wear happens. Once you see the cause, you also start to see where AI is effective.

Software development mixes two different kinds of work. One is the work of deciding what to build. You organise the requirements, think through the design and judge the trade-offs. The other is the work of giving form to what you have decided. You write the code, get the tests passing and connect it to the existing code. The former is creative work that draws on human judgment; the latter is patterned, labour-intensive work.

The problem is that these two have long stayed undivided inside a single engineer. Even for a strong engineer, a considerable share of the working day goes to the latter, that is, to routine implementation, setting up tests and reading existing code. The moment that calls for judgment is brief, and a long stretch of manual work follows it. This structure is the true identity of that opening feeling that you are using your hands rather than your head.

The heaviness of the review cycle comes from the same structure. Variations in style and simple oversights are things that could, in principle, be checked mechanically. Because we lean on the eyes of a human reviewer for them, the back-and-forth arises and both sides lose focus. Technical debt is the same: because the specification survives only as code, you redo the costly work of deciphering it every time.

In other words, much of the wear comes from humans continuing to handle, by hand, work that could be patterned. This is exactly where AI has room to enter. Humans carry the judgment; AI takes on the patternable implementation and verification. Once you can divide the roles this way, the quality of work you can handle in the same amount of time begins to change.

What AI-driven development actually changes

Here, let me sort out what the phrase "AI-driven development" contains. It tends to be lumped together, but in practice it holds several approaches at different stages.

The most familiar is AI coding assistance. The completion feature that suggests the continuation of your code in the editor, and generating a function from an instruction written in natural language, both belong here. For work where what to write is more or less fixed, such as boilerplate, test code and routine CRUD logic, it visibly cuts the time you spend moving your hands. It applies directly to the situation from the earlier section, where your head is decided but your hands are slow.

A step beyond that is what is called spec-driven development. Rather than having the AI write code straight away, you first put into words, as a specification, what you are building and under what conditions, and have the AI implement from that specification. The human concentrates on refining the specification, and the AI takes on the implementation. Because the clearer the specification, the higher the quality of the output, the ability to write requirements without ambiguity comes to shape the quality of the development directly. I cover the way of building development from the specification outward in more detail in a plain-language guide to AI spec-driven development.

Further out again is parallel work by AI agents. Rather than a one-off completion, you hand off bundled work such as fixing tests, refactoring, and changes spanning several files, and let an AI agent carry it forward. The human moves into the role of reviewing that output, correcting direction and deciding whether to adopt it. That the use of AI on development teams is shifting from "assistance" toward "delegation" shows up in the data too. In an analysis Anthropic published in September 2025, among uses on Claude.ai, the automation-type use where work is handed to the AI rose from 27% to 39%, overtaking for the first time the collaborative pattern where human and AI work together. Among enterprise API usage the tendency was stronger still, with much of it reported as centred on automation¹.

Put these together and the centre of gravity of an AI-driven developer's work moves from writing code line by line to conveying intent clearly, evaluating what has been generated and deciding. From a person who moves their hands to a person who judges. This shift is the source of the jump in productivity.

Checking "how many times faster" against the primary sources

This is the part you most want to know, I imagine. That said, I have no intention of lining up only the convenient numbers. Let me look at the publicly available primary sources, with the caveats attached.

A figure often quoted is "55% faster." This is the result of a controlled experiment GitHub ran officially. Ninety-five professional developers were split into two groups and given the task of implementing an HTTP server in JavaScript from scratch. The group using AI assistance finished in an average of 1 hour 11 minutes, and the group not using it in an average of 2 hours 41 minutes, about 55% faster. The difference was statistically significant too². What I want to stress, though, is that this is a survey result on a narrow task, implementing something fixed from scratch. It is not a number that transfers directly to maintaining a large existing codebase or to development where the specification is not yet settled.

There are also surveys that ask about the subjective sense of it. In a questionnaire GitHub ran with more than 2,000 developers, 73% of assistant-tool users answered that they could stay focused, 87% that their exhaustion from repetitive work was reduced, and more than 90% that they felt they could finish tasks faster³. The numbers are striking, but these are, in the end, the respondents' own subjective evaluations. That perception and measurement do not always match is a point I will return to in the next section.

And I will deliberately look at the data on the other side too. In a randomised controlled trial METR published in 2025, 16 experienced developers with an average of more than five years each worked on 246 issues in the large, mature repositories they regularly contribute to. The result was that using AI tools left them about 19% slower than not using them⁴. On a new, narrow task the speed nearly doubles; on a codebase an expert knows well it slows down instead. Even the same act of "using AI" produces opposite results depending on the kind of task and the situation.

This gap is itself, I think, the honest conclusion. How many times productivity rises depends strongly on context, and it cannot be spoken of with a single number. On routine implementation and new code a large effect can be expected; on maintaining complex existing systems the effect is limited, and if you are careless, counterproductive. That is exactly why the design that discerns which work it helps and where to be cautious becomes the crux. Discerning where and how to bring AI in so that a company's own development gets faster, and designing that together, is one of the places we feel we are getting somewhere with WARP, our AI consulting service.

Overconfidence is dangerous, another primary source

If you believe only the "it gets faster" story, you get your legs swept out from under you. In this section I will deliberately stand on the side of caution and look at the data.

The most instructive thing in METR's trial is not that the developers got slower, but that their felt sense and the measurement diverged. The experienced developers who took part predicted before the work that AI would make them roughly 24% faster, and after the work self-reported that they had been about 20% faster. Yet the measurement showed them 19% slower instead⁴. They felt faster while actually being slower. This divergence captures a pitfall of AI coding well. The sensation that your hands are moving, and the felt reduction in waiting time, do not necessarily match the speed of the outcome.

The matter of quality and stability cannot be left out either. In the 2025 DORA report Google Cloud published, of about 5,000 engineers, 90% used AI in their work and more than 80% said their productivity had risen. At the same time, roughly 30% answered that they trust the code AI generates barely, or not at all. More important still is the observation that while AI adoption showed a positive correlation with throughput and product performance, it showed a negative correlation with delivery stability⁵. In other words, AI pushes volume and speed up, but unless you secure quality and stability separately, they tend to break down.

The practical stance this leads to is clear. Speed and quality are two goals to be defended separately. Code that AI generates must always be reviewed by a human. Confirm stability with tests. Handle the output on the assumption that vulnerabilities and mistakes are mixed into it. On top of that, the handling of source code and confidential information when passing it to external services needs to be set out clearly as an internal rule. The more you use AI, the importance of review and testing does not fall; it rises. Whether you can accept this paradox is the dividing line for whether you can run AI-driven development safely.

The skills an AI-driven developer needs, and where the career leads

So what should a professional engineer build in an age like this, and where should they head? Let me think this through.

The skills you need come down, I believe, to three. The first is the ability to put requirements into words without ambiguity. In spec-driven development and in delegation to agents alike, if your instruction to the AI is vague, the output is vague. Being able to write down, without room for misunderstanding, what you are building, under what conditions and how far. This is continuous with conventional design ability, but it comes further to the front. The second is the review judgment to read generated code and tell good from bad. The third is the foundational knowledge that supports that judgment. The more you have a base in data structures and algorithms, design principles and the basics of security, the better you can see through whether the AI's output is sound. It sounds ironic, but the very age of handing work to AI is when the foundations to evaluate the handed-over result carry value. Far from making learning the fundamentals unnecessary, it increases their importance.

There is a tailwind from a career perspective too. Looking at the nation's own primary sources, the estimate in the Ministry of Economy, Trade and Industry's "Survey on Supply and Demand of IT Human Resources," published in 2019, projected the scale of the IT talent shortage in 2030 at roughly 160,000 people to as many as about 790,000, depending on the scenario. In particular, while conventional personnel are projected to move into oversupply, the shortage of people who can handle advanced fields such as AI and big data is expected to grow serious⁶. This is a somewhat old estimate published in 2019, and it is a projection resting on certain assumptions, but the direction, a structural demand for developers who can put AI to use, is shared even in policy discussion.

What may worry you is whether your own skills will decline if you hand work to AI. This, I think, depends on how you hand it over. If you keep adopting generated code without reading it, judgment struggles to grow. If instead you always review the output and use it while understanding why it was implemented that way, the increase in the volume of code you touch in a day means your chances to learn actually grow. Do you make AI a substitute for thinking, or a tool that speeds thinking up? That difference in stance tells on your real ability a few years out. How to make AI an ally in the context of entrepreneurship and product development I touch on in a piece on developing AI-driven entrepreneurs, and practice on the ground of education and research in a piece on AI-driven development at universities.

Where to place the first step

This has run long, so let me organise a realistic first step for getting moving, and close.

You do not need to reorganise your whole development around AI at once. Starting where the effect comes easily and the risk is low is the wise order. First, try handing off routine work where what to write is fixed. Test code, boilerplate, the implementation of similar endpoints. This is the territory where GitHub's survey shows the effect, the place AI is good at. Once you are used to it, try the spec-driven approach, putting the specification into words first and then having it implemented, on a small feature. Once you have that much of a feel for it, move to the stage of delegating bundled work to an agent and taking on the review role yourself.

At the same time, set up the defensive mechanisms from the start. Always review generated code. Confirm stability with tests. Decide internally the scope of code and information you send to external services. These three are the foundation you lay before you chase speed. Only when you can defend speed and quality at once does AI-driven development become a lasting weapon.

If you would like to think through, together and from the discernment stage, where in your own development bringing AI in is effective and where you should be cautious, please talk to the WARP team. Specialists who have carried DX and data strategy at major companies walk alongside you month by month, helping you bring AI down into development and into management.

Finally, let me organise the key points.

• Much of the wear on the shop floor comes from humans continuing to handle, by hand, patternable work such as routine implementation, the back-and-forth of reviews and deciphering existing code
• AI-driven development has stages, from AI coding assistance through spec-driven development to delegation to agents, and it moves the centre of work from "writing" to "judging"
• How much productivity rises depends on context. On new, narrow tasks large effects are reported, while there are cases where experts working on mature code get slower instead, so it cannot be told in a single "how many times"
• The felt sense and the measurement can diverge, and while AI raises volume and speed, stability needs to be secured separately. Speed and quality are goals to be defended apart
• What you need is the ability to put requirements into words, review judgment, and the foundational knowledge that supports that judgment. The importance of learning the fundamentals rises, if anything
• If you are starting, hand off routine work first and set up the defensive mechanisms at the outset. This order is the realistic one

Rather than the question of whether AI will take your job, the question of what kind of developer you become in putting AI to use will, from here on, bear more fruit. Take back the time you spend moving your hands, and put time into judgment. Begin the first step of that shift from today's routine work.

References and primary sources

Footnotes

1. Anthropic, "Anthropic Economic Index," September 2025 report (automation-type use rose from 27% to 39%, enterprise API usage centred on automation) https://www.anthropic.com/research/anthropic-economic-index-september-2025-report ↩

2. GitHub, "Research: quantifying GitHub Copilot's impact on developer productivity and happiness" (controlled experiment, 95 developers, roughly 55% faster on an HTTP-server implementation task) https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/ / academic version https://arxiv.org/abs/2302.06590 ↩

3. GitHub, same source (survey of more than 2,000 developers; staying focused 73%, reduced exhaustion from repetitive work 87%, and more than 90% feeling they could finish faster are the respondents' own subjective evaluations) https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/ ↩

4. METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (randomised controlled trial, 16 experienced developers, 246 issues, about 19% slower with AI, diverging from the pre-study prediction of +24% and post-study self-report of +20%) https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ / paper https://arxiv.org/abs/2507.09089 ↩ ↩²

5. Google Cloud / DORA, "2025 DORA Report" (about 5,000 engineers, AI use 90%, more than 80% feeling a productivity rise, about 30% not trusting AI-generated code, throughput positively correlated and delivery stability negatively correlated) https://dora.dev/dora-report-2025/ / https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report ↩

6. Ministry of Economy, Trade and Industry, "Survey on Supply and Demand of IT Human Resources" (estimate published in April 2019; the 2030 IT talent shortage projected at roughly 160,000 to as many as about 790,000, with the shortage of advanced IT talent expected to grow serious) https://www.meti.go.jp/policy/it_policy/jinzai/gaiyou.pdf ↩