How AI Is Changing What Software Engineers Actually Do
Table of Contents

How AI Is Changing What Software Engineers Actually Do

GitHub Copilot makes developers 55% faster on specific tasks. Here's what AI actually changes about software engineering — and what stays irreducibly human — for kids planning tech careers.

I’ve watched three different transformations hit software development during my career: the object-oriented revolution in the 1990s, the rise of open source in the 2000s, and the cloud/services transition in the 2010s. Each time, people predicted the death of traditional programming. Each time, the number of software engineers grew and the work shifted rather than disappeared.

The AI coding assistant transition is the fourth such shift. It’s real. The productivity gains are real. What I want to argue here is that “AI is changing software engineering” and “AI is replacing software engineers” are different claims, and the first is clearly true while the second is not supported by the current evidence — though the second may become relevant over longer time horizons that matter for kids planning careers.

Key Takeaways

  • GitHub’s published research found developers using Copilot completed specific coding tasks 55% faster than those without — a meaningful productivity gain on the tasks measured.
  • The tasks where AI provides the biggest gains are the ones experienced developers spend the least time on: boilerplate, simple function completion, converting between languages.
  • The tasks AI currently struggles with — requirements clarification, system architecture, debugging non-obvious failures, security review — are the ones that dominate senior engineering work.
  • The “AI-native” developer workflow (constant AI assistance, specification-level thinking, heavy testing and review of AI output) is an emerging professional practice.
  • Kids who learn to work with AI coding tools while developing genuine conceptual foundations will be better positioned than those who learn only to direct AI without understanding what it produces.

What the Research Actually Shows About AI Coding Productivity

The most cited study is GitHub’s controlled experiment (Kalliamvakou, 2022) testing GitHub Copilot: participants using Copilot completed a specific JavaScript task (building a server) in a median of 1.2 hours versus 2.7 hours for those without — a 55% speed advantage.

This number is frequently quoted without its context. The task was well-defined, isolated, and required writing code in a well-documented pattern. Experienced developers doing novel work in complex codebases see smaller gains. A follow-up study by Stanford economists (Noy & Zhang, 2023) found that AI writing assistance improved worker performance — but the gains were larger for lower-skilled workers and smaller for higher-skilled ones, suggesting AI assistance tends to compress the performance distribution more than it lifts all boats equally.

For software engineering specifically, a 2024 RAND Corporation study found that AI coding tools improved engineer productivity on simple, isolated tasks by 20–40%, but showed little to no productivity improvement on complex, cross-cutting tasks requiring understanding of a large existing codebase.

The pattern suggests: AI helps most where the work is well-specified and the patterns are well-documented. It helps least where the work requires contextual judgment about a specific system’s quirks, organizational history, and constraints.

What AI Tools Are Actually Replacing

The tasks that AI coding assistants perform well right now:

Boilerplate generation. Writing the standard setup code for a new React component, a new API endpoint, a new database model. Experienced engineers hate this work; AI does it well.

Documentation writing. Generating docstrings, README files, and inline comments from existing code. Frequently tedious; AI handles it adequately.

Simple function completion. Given a function name and signature, complete the implementation for common patterns.

Unit test generation. Generating test cases for a function based on its signature and docstring. AI generates plausible tests, though human review remains necessary to catch what was missed.

Language and framework translation. Converting Python to JavaScript, or Express to FastAPI, where the patterns are well-known.

Stack Overflow lookup replacement. Many searches for “how do I do X in framework Y” are now answered faster via Copilot or Claude than via web search.

What this amounts to is automating the mechanical, repetitive parts of coding that were always the lowest-value parts of engineering work. The parts that experienced engineers describe as “the grind” — not the interesting problems.

What AI Can’t Do (Yet) in Software Engineering

Requirements clarification. The most common failure mode in software projects is building the wrong thing — solving a problem that wasn’t actually the right problem. A stakeholder says “I want a report that shows sales trends.” What they actually need is a decision support tool that flags when a regional sales team is underperforming relative to its forecast. AI cannot have the business context conversation that surfaces this difference. Humans who are skilled at this — “business analysts” in the old terminology, “product engineers” now — are more valuable than they were before.

System architecture for new problems. Designing a distributed system that handles 50 million daily users with 99.99% uptime and specific latency requirements is not a problem AI can solve by pattern-completing against training data. It requires understanding constraints, trade-offs, failure modes, and organizational context that don’t exist in any documentation. Senior architects who can think through these trade-offs are not being automated.

Debugging non-obvious failures. The hardest debugging problems in production systems involve the interaction of multiple systems in ways that don’t appear in any single component’s logs. “The service is slow on Tuesdays between 2 PM and 4 PM, but only when the database had a specific backup task running two days before.” AI can help with specific isolated debugging tasks, but connecting these contextual dots across an entire system is human reasoning work.

Security review. Finding security vulnerabilities requires adversarial thinking — imagining how a system could be abused, looking for the inputs an attacker would craft rather than the inputs a normal user would provide. AI can catch known vulnerability patterns (SQL injection in obvious cases, common OWASP issues), but novel attack surfaces and business logic vulnerabilities require human creative thinking.

Career and team judgment. Mentoring junior developers, managing competing priorities, deciding which technical debt to pay down first, representing engineering constraints to non-technical stakeholders — none of this is in Copilot’s scope.

The “AI-Native” Developer Workflow

A meaningful shift in professional practice is emerging for developers who use AI assistance heavily. The workflow looks like this:

  1. Specification thinking: Before writing any code, write a detailed specification in plain language of what the function/module/system should do, including edge cases, constraints, and expected outputs. This is then fed to the AI.

  2. AI-assisted generation: Use the AI to generate the initial implementation from the specification.

  3. Test-driven review: Write tests (often also AI-assisted) that verify the specification, then run them against the AI-generated code. This surfaces what the AI got wrong.

  4. Human review for judgment calls: Review for security vulnerabilities, architectural fit with the existing codebase, and long-term maintainability. The AI doesn’t know your codebase the way you do.

  5. Iteration: Correct the AI’s output and iterate.

What this means for the skills that matter: specification writing (clarity about what you want), testing literacy (knowing what to verify), security thinking (adversarial review), and architectural judgment are now more important relative to typing code quickly.

Software Engineering ActivityAI ImpactWhat Changes
Writing boilerplate / setup codeHigh — 50–80% fasterLess time writing; more time spec and review
Implementing well-known patternsHighFocus shifts to selecting right pattern
Designing system architectureLowSame human judgment required
Clarifying requirements with stakeholdersNoneCritical skill, more valuable
Debugging complex production issuesLowSame investigation skills required
Writing unit testsMediumAI generates tests; human verifies coverage
Security reviewLow-mediumKnown patterns caught; novel vulns require humans
DocumentationHighOften fully AI-assisted with human review
Code review of AI outputNew activityHigh-judgment new task

What This Means for Kids Planning Tech Careers

The advice that made sense 15 years ago — “learn to code and you’ll always have a job” — has become more specific and more nuanced.

Learn to code anyway. The kids who understand what code actually does — not just how to prompt AI to produce it — are the ones who can review AI output, catch errors, architect systems, and understand security. You can’t review code you don’t understand. The value of coding skills hasn’t disappeared in the AI era — it’s shifted toward higher-level reasoning and review.

Learn the skills AI can’t replicate. Systems thinking, requirements clarification, security reasoning, architectural design — these require understanding that goes well above the level of any individual function. Develop them deliberately.

Learn to work with AI coding tools early. Cursor, GitHub Copilot, Claude Code — using these tools is a professional skill. Knowing when they’re reliable and when they hallucinate plausible-looking but wrong code is experience. Start building that experience now, with the understanding that you’re supervising the AI, not just accepting its output.

Consider adjacent specializations. ML engineering, security engineering, platform/infrastructure engineering, and developer tools engineering all have strong demand and specific leverage in an AI-assisted world.

How to Teach Your Kid About AI and Software Engineering

Ages 5–8: What does a programmer fix?

When a bug appears in a game or app, say: “A programmer made that mistake. What do you think they got wrong? What would you change?” This builds the intuition that software has authors, authors make mistakes, and fixing mistakes requires understanding what was supposed to happen.

Ages 9–12: Write a specification first

Pick a small programming problem — a simple game, a calculator, a quiz. Before writing any code, write a specification in plain English: what inputs does it take, what outputs does it produce, what should happen in each possible case. Then try to implement it. Notice how much clearer your code is when you’ve specified it first. This is the skill AI makes more important, not less.

Ages 13+: Use Copilot and review its output critically

Set up GitHub Copilot (free for students) or use Claude for a real coding project. For every function Copilot suggests, ask: “Is this correct? What would happen with edge case X? Does this have any security issues?” Then write a test to verify. This is the AI-native workflow in practice. The connection to larger AI literacy concepts is direct: AI produces plausible-looking output that requires human verification.

The question to ask: “If an AI wrote this code and you had to stake your reputation that it works correctly, what would you need to check before you trusted it?”

What to Watch For Over the Next 3 Months

Month 1: If your teenager is interested in software engineering, have them try a small project using an AI coding assistant and without one — something comparable, like building two small utility scripts. Compare the experience. What did the AI make easier? Where did it produce wrong code? Where did having the AI make them less engaged with what they were building?

Month 2: Read the GitHub research blog (github.blog/research) for the most current published data on AI impact on developer productivity. The research is unusually transparent compared to most AI productivity claims.

Month 3: The software engineering field is producing clear signals about what remains valuable — follow the job postings at major tech companies. “Staff engineer” and “principal engineer” job descriptions remain focused on system design, technical leadership, and cross-functional judgment — not code generation speed.

Frequently Asked Questions

Will AI write all software in 10 years, making software engineers obsolete?

Very unlikely in 10 years. The trend is toward automation of specific coding tasks with human engineers shifting toward higher-level specification, architecture, and review work. Whether that trend continues to full automation over decades is genuinely uncertain — but kids entering the workforce in 2030 will find substantial engineering demand, though the nature of the work will differ from 2015.

Should my teenager learn specific languages, or just learn general AI prompting?

Both, and the order matters: learn a programming language well enough to understand what code actually does, then learn to work with AI coding tools. The kids who only learn to prompt AI without understanding the underlying code cannot catch its errors, cannot debug its outputs, and cannot architect systems that exceed what the AI can generate by pattern-completion.

Is it cheating if kids use AI to help with coding homework?

That’s a policy question for each school, but it’s worth separating two things: using AI to understand a concept (generally educationally valuable) and using AI to complete assignments without engaging with the material (undermines learning). The analogy to calculators is imperfect but instructive — calculators became standard tools once the underlying math was learned. AI coding assistance may follow a similar arc.

What programming language should a kid start with in 2026?

Python remains the most accessible and versatile first language, with the largest AI and data science library ecosystem. JavaScript is the most immediately deployable (runs in browsers). Java/Kotlin for Android. Swift for iOS. Scratch, Blockly, and similar block-based languages work well for ages 7–10 before text-based programming. The specific first language matters less than getting to real projects that solve real problems quickly.


About the author Ricky Flores is the founder of HiWave Makers and an electrical engineer with 15+ years of experience building consumer technology at Apple, Samsung, and Texas Instruments. He writes about how kids learn to build, think, and create in a tech-saturated world. Read more at hiwavemakers.com.


Sources

  1. Kalliamvakou, E. (2022). “Research: Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness.” GitHub Research Blog. https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
  2. Noy, S., & Zhang, W. (2023). “Experimental Evidence on the Productivity Effects of Generative Artificial Intelligence.” MIT Working Paper. https://economics.mit.edu/sites/default/files/2023-03/noy_zhang_1.pdf
  3. RAND Corporation. (2024). “AI and the Future of Software Engineering.” https://www.rand.org/
  4. Chen, M., et al. (2021). “Evaluating Large Language Models Trained on Code.” OpenAI Technical Report. https://arxiv.org/abs/2107.03374
  5. Pearce, H., et al. (2022). “Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions.” IEEE Symposium on Security and Privacy. https://doi.org/10.1109/SP46214.2022.9833571
  6. National Institute of Standards and Technology. (2022). “Secure Software Development Framework (SSDF) v1.1.” https://csrc.nist.gov/publications/detail/sp/800-218/final
Ricky Flores
Written by Ricky Flores

Founder of HiWave Makers and electrical engineer with 15+ years working on projects with Apple, Samsung, Texas Instruments, and other Fortune 500 companies. He writes about how kids learn to build, think, and create in a tech-driven world.