Will AI Replace Programmers? What Coding Tools Change

Will AI replace programmers? The evidence so far shows AI coding tools changing what programmers spend their time on, while responsibility for working software stays with people. The tools now write a large share of first drafts. Someone still has to decide what to build, check it, secure it and fix it when it breaks in production. Nobody can promise how the balance looks in five years, so this post separates what has been measured from guesswork. I am a final-year computer science student who builds web applications for clients (more about me), so I read this question as someone about to compete for junior roles. I have no inside knowledge of where the industry is heading, which is why I stick to studies and surveys I could open and read.

What do the controlled studies show about AI coding tools?

GitHub's Copilot task study was published in September 2022 with Microsoft's Office of the Chief Economist. It gave 95 professional developers one job: write an HTTP server in JavaScript. The Copilot group averaged 1 hour 11 minutes against 2 hours 41 minutes for the other group, which GitHub reports as 55% faster (95% confidence interval 21% to 89%). Some 78% of the Copilot group finished, against 70%. The limits are plain: one small, self-contained task, an early version of the tool, and a result published by the company that sells it. METR's randomized trial from July 2025 looked at a very different setting. Sixteen experienced open-source developers worked on 246 real issues, averaging about two hours each, in repositories they had contributed to for years (averaging over 22,000 stars and a million lines of code). Each issue was randomly assigned to allow or forbid AI. With AI allowed, which mostly meant Cursor Pro with Claude 3.5 and 3.7 Sonnet, tasks took 19% longer. The developers had predicted a 24% speedup, and afterwards still believed AI had sped them up by 20%. The authors list their own limits: a small sample, one setting, early-2025 tools, and no claim that AI never helps. METR then published an update in February 2026 on a larger study that began in August 2025: 57 developers, 143 repositories, over 800 tasks. Developers returning from the first study saw tasks take 18% less time with AI (confidence interval from 38% less to 9% more), and newly recruited developers saw 4% less (15% less to 9% more). Both intervals include zero. METR calls the data weak, because developers increasingly held back tasks they did not want to do without AI (30% to 50% in its surveys). It still thinks developers were probably more sped up in early 2026 than a year earlier. My reading, which is inference and not a finding: small, well-specified tasks show big gains, and large mature codebases that a person already knows well show small or unclear ones. Tools also changed between 2022 and 2026. The 2025 gap between what developers felt and what the stopwatch showed is the result I would remember: "it feels faster" is a poor measure.

How many developers use AI, and how much code does it write?

Stack Overflow's 2025 developer survey found 84% of respondents using or planning to use AI tools, and 51% of professional developers using them daily. Trust was lower than use: 46% distrusted the accuracy of AI output, 33% trusted it to some degree, and 3% highly trusted it. The top frustration, at 66%, was answers that are "almost right, but not quite", and 45% said debugging AI-generated code takes more time. On vibe coding, 72% said it is not part of their professional work. The 2026 survey asked what developers actually use the tools for. The most common tasks were generating code in an area they already know (69.3%), debugging or refactoring (63.8%) and writing tests (58.1%). Over 70% rated AI useful for technical tasks, but only 49% for design and 35% for communication. Company statements are bigger numbers. Google's CEO wrote in April 2026 that 75% of all new code at Google is AI-generated and approved by engineers, up from 50% the previous fall. Microsoft's CEO said in April 2025 that perhaps 20% to 30% of the code in some of Microsoft's repositories was written by software, with Python going better than C++. TechCrunch noted at the time that it is unclear how either company measures this. These are executive statements, not audited studies, and Google's wording includes engineer approval. They say something about how code gets typed and nothing about how many people a company needs.

What do AI coding tools do well?

Going by the survey tasks above, the tools are strong where output is quick to check and cheap to get wrong:

Boilerplate and scaffolding: forms, CRUD endpoints, config files.
First-draft tests, which a developer then reads and tightens.
Explaining unfamiliar code or an error message in plain language.
Translating between languages or frameworks.
Searching documentation for the name of an option or the shape of an API.

What these have in common is that a competent person can look at the result and know within minutes whether it is right. That matches the survey, where the top use is code in an area the developer already knows. The tool saves typing time and the user supplies the judgement.

Where do AI coding tools fall short?

Context in large codebases is the first problem. A real application has years of decisions and hidden dependencies, and a tool that sees a few files can propose changes that look fine locally and break something three modules away. METR's setting, big mature repositories known well by their maintainers, is where the 2025 measurement came out slower. Subtle bugs come next. "Almost right" is the survey's top complaint for a reason: code that fails loudly is easy, and code that passes the obvious case but mishandles a time zone, a rounding rule or a concurrent request is expensive to find. Security is the third. In its GenAI code security report from July 2025, the security vendor Veracode gave more than 100 models 80 curated coding tasks. Where a secure and an insecure way to write something were both available, the models picked the insecure one in 45% of cases, and Java failed more than 70% of the time. That is one vendor's test set and models from a specific moment, so treat the number as a warning, not a constant. The last two are architecture judgement and confident wrong answers. A tool will happily design a data model, but it does not know your traffic, your budget or which feature gets cut next quarter. And it delivers wrong answers in the same calm tone as right ones, so nothing in the output tells you when to double-check.

What is vibe coding, and where does it break?

Andrej Karpathy coined the term in February 2025 for a style of working where you describe what you want, accept what the model produces and mostly stop reading the code. For a throwaway prototype or a personal tool, that is a reasonable trade. The problem starts when the project has users, payments or personal data, because then nobody in the room can explain why the code works or what happens when it does not. In Stack Overflow's 2025 survey, 72% of developers said vibe coding is not part of their professional work. Many use AI heavily and still read and own what ships.

Which programming tasks are shifting and which stay human?

Here is how I would sort the work. It is a judgement, so expect it to move as tools improve.

Text

Shifting toward the tool (a person still checks the result)
  boilerplate and scaffolding
  first-draft unit tests
  explaining unfamiliar code
  converting between languages or frameworks
  searching documentation

Staying with the person (the tool can assist)
  turning a vague request into clear requirements
  design trade-offs: data model, auth, cost, hosting
  debugging in production, with real data and real users
  security review before launch
  being accountable when something fails

The second list holds up because of accountability. A model cannot be called by a client at night or held to a contract. Someone with a name has to sign off on software that handles real money or customer records.

What should clients know before AI builds their software?

If you are hiring someone, whether they use AI tools is a smaller question than whether they review and stand behind what they deliver. A few things are worth asking about, whatever tools sit behind the work:

Who reviews the code? Generated code still needs a human who understands it, and a second look on anything touching logins, payments or personal data.
Who owns it? You should hold the repository, the hosting accounts and the domain, and be able to read the licence terms of anything bundled in.
How is security handled? Secrets out of the code, dependency updates, permission checks on every route. My website launch checklist covers what to verify before going live.
Who maintains it in a year? Code nobody can explain gets expensive to change.

My post on hiring a full stack developer in Pakistan has more questions you can put to a freelancer or studio. Systems that hold business records are where this matters most. A point-of-sale system, which I wrote about in my Laravel POS post, has to get stock and sales numbers right every day. A marketplace like my final year project, GoCart, involves vendor accounts, roles and payments, where one wrong permission check hurts real people.

Will AI replace entry-level developers?

Here is the best case for each side. The case for worry starts with a Stanford Digital Economy Lab paper, "Canaries in the Coal Mine?", by Erik Brynjolfsson, Bharat Chandar and Ruyu Chen. In its revision from August 2026, using ADP payroll data through June 2026, employment of workers aged 22 to 25 in highly AI-exposed occupations was about 19% below what it would have been had it kept pace with less-exposed peers. The gap came mainly from reduced hiring and showed up where AI substitutes for human tasks. Experienced workers in the same jobs showed no comparable gap. A plausible mechanism, and this is my inference, is that tools now do the small tickets and boilerplate that used to teach juniors. The case against starts with the same paper's caveats. The authors call the results early and descriptive, report no economy-wide job displacement, and note that some trends predate generative AI. The update gives no software-specific figure, and where AI complements workers, employment was flat or rising. The US Bureau of Labor Statistics, on a page last modified in August 2026, projects 10% growth from 2025 to 2035 for software developers, QA analysts and testers combined, citing growing demand for software built around AI. Projections can be wrong. A further argument says that cheaper software means more software gets built, and companies still need juniors to become the seniors they will want later. Both can be true at once: fewer junior openings in some places, and no collapse of the profession.

What should developers practise in the AI era?

The practical answer is the skills the tools do not supply. I go deeper in developer skills to learn in the AI era, and the short version is:

Read code more than you write it. Review is the job the survey data keeps pointing to.
Learn to debug without help: reading logs, using a debugger, reproducing a bug in a smaller case.
Know the fundamentals well enough to spot a wrong answer: HTTP, SQL, authentication, how your framework handles state.
Write tests and read generated ones with suspicion.
Learn security basics, starting with the OWASP Top 10.
Practise turning a fuzzy request into a written spec, because that skill sits before any tool.

The same question about software businesses is covered in is SaaS dying because of AI agents.

My take

I am a student developer, not an economist or an industry analyst, and I may be wrong about details. The evidence supports a narrow claim: tools are good at drafting and bad at accountability, and the gap between feeling fast and being fast is real. It does not support the claim that programmers are finished, and it does not support the claim that nothing is changing. What worries me as someone about to start out is the junior pipeline. The Stanford numbers are early and imperfect, but they match what I would expect if the easy tickets are the ones getting automated. That makes the learning-by-doing part of a first job harder to get, so I think students need to build that experience on their own: finish real projects, deploy them, break them and fix them, and be able to explain every line. What would change my view: a large randomized study on mature codebases showing consistent gains with current tools, or evidence that AI-written code holds up on security and maintenance without heavy human review. A year of hiring data that moves the other way would change it too.

Want to talk about this?

I am Fawaz Israr, a full stack developer in Rahim Yar Khan, Pakistan, a final-year Computer Science student, and I work in web development at Hadi Dev Lab. If you have a question about this post or a project you are thinking about, you can message me on WhatsApp or by email. You can also look through my work first. Cover photo from Unsplash.