Table Of Contents
The security tax nobody budgeted for
A word on juniors, and on skill formation
Every credible signal points in the same direction: generative AI is now part of how software gets built. The harder question is what that actually means for the people who build it. The honest answer, backed by the research rather than the marketing, is more interesting than either the utopian or the apocalyptic version.
Where we actually are in 2026
Adoption is no longer the debate. GitHub’s Octoverse 2025 report (published October 2025, covering activity through August 2025) found that the platform crossed 180 million developers, adding roughly 36 million in a single year, and that nearly 80% of new developers used GitHub Copilot within their first week. More than 1.1 million public repositories now import a large-language-model SDK, a 178% year-over-year jump. AI-assisted coding has effectively become the default entry point to the profession rather than an optional add-on.
The shift runs deeper than tooling. In the same report, TypeScript overtook Python and JavaScript to become the most-used language on GitHub for the first time, a change GitHub attributes partly to a “convenience loop”: AI works better with strongly typed languages because types give the model clearer constraints, so developers gravitate toward what the AI handles well, which generates more training data, which makes the AI better still. AI isn’t just changing how fast we write code. It’s quietly reshaping which technologies win.
At the organizational level, adoption is nearly universal but shallow. McKinsey’s most recent State of AI research puts the share of organizations using AI in at least one business function around 88%, with roughly four in five using generative AI specifically. Yet only a small single-digit percentage have scaled it enterprise-wide or can point to a meaningful profit impact. That gap between “we use it” and “it moved the numbers” is the real story of this moment.
Table Of Contents
The productivity paradox
Here is where careful reading matters, because the most rigorous study we have delivered a genuinely surprising result.
In July 2025, the nonprofit research group METR published a randomized controlled trial, the same methodology used to test medicines, measuring how AI tools affected experienced open-source developers on real tasks in their own mature codebases. Sixteen developers completed 246 tasks, each randomly assigned to allow or forbid AI assistance. Before starting, the developers predicted AI would make them 24% faster. Afterward, they believed it had made them about 20% faster.
In reality, allowing AI made them 19% slower. Even after living through the slowdown, the developers still believed they had sped up.
That 39-point gap between perceived and measured performance is the finding worth sitting with. It doesn’t prove AI tools are useless; METR itself cautioned that the result reflects a specific setting, expert developers working in large, mature repositories they already knew intimately, exactly the scenario where a human’s existing context beats an AI’s suggestions. Other evidence points the other way: AI tends to deliver its biggest gains on greenfield projects, boilerplate, test generation, and helping developers work in unfamiliar languages or frameworks.
The takeaway isn’t “AI slows you down.” It’s that the productivity story is conditional, and that our intuition about our own speed is unreliable. Where the task is well-defined and the developer lacks deep prior context, AI shines. Where the codebase is intricate and the human is already an expert, the overhead of prompting, reviewing, and correcting can cost more than it saves. Any team claiming a flat, universal productivity multiplier is selling something.
Table Of Contents
The security tax nobody budgeted for
Speed that ships vulnerabilities isn’t speed. Veracode’s 2025 GenAI Code Security Report tested code from more than 100 large language models across 80 curated tasks and found that when a model could choose between a secure and an insecure way to write something, it chose the insecure option roughly 45% of the time. Cross-site scripting and log-injection tasks failed the vast majority of the time, and Java fared worst, with a security failure rate above 70%.
The most sobering detail: newer, larger models were not meaningfully more secure than older ones. This looks less like a temporary limitation the next release will fix and more like a structural property of how these models generate code, they reproduce the patterns, insecure ones included, that dominate their training data. As “vibe coding” spreads, where developers accept AI output without specifying security requirements, the risk is that we accumulate security debt faster than we can review it.
None of this argues for banning the tools. Developers are already using them, sanctioned or not. It argues for treating AI-generated code as untrusted input: automated security scanning in the pipeline, human review that scales with risk, and a culture where “the AI wrote it” is never an excuse for what ships.
Table Of Contents
What the job actually becomes
Put the data together and a consistent picture emerges. The software engineer’s center of gravity is moving from authoring code to directing, reviewing, and taking responsibility for it. Writing a function line by line becomes a smaller share of the work; specifying intent precisely, decomposing problems, evaluating AI output, and owning the result become larger shares.
The industry term for the emerging model is “agentic” development, where AI agents don’t just autocomplete a line but attempt whole tasks: opening pull requests, running tests, fixing what breaks. That raises the leverage of a good engineer and the cost of a careless one. When an agent can generate a thousand lines in a minute, the bottleneck isn’t typing. It’s judgment, the verification gap between “the code runs” and “the code is correct, secure, and maintainable.”
This reframes which skills appreciate in value:
- System design and architecture. Deciding what to build and how the pieces fit is exactly the work AI is weakest at and humans are accountable for.
- Code reading and review. As more code is generated than written, the ability to quickly evaluate unfamiliar code becomes a core competency rather than a chore.
- Specification and decomposition. Getting good output depends on stating the problem, constraints, and edge cases clearly, a skill closer to technical writing and product thinking than to syntax.
- Security and testing literacy. Given the vulnerability data, the engineer who can spot and close gaps in generated code is worth more, not less.
- Debugging complex systems. When something fails in production, no agent yet replaces a human who understands the whole system.
Table Of Contents
A word on juniors, and on skill formation
There’s a real, unresolved tension here. AI is most helpful precisely at the tasks that used to train junior engineers, writing boilerplate, wiring up simple features, fixing small bugs. If those rungs of the ladder get automated, how does the next generation build the deep context that the METR study shows is so valuable?
This is a genuine open question, not a settled one. Early research on skill formation under heavy AI assistance suggests a risk that developers who lean on generation without engaging deeply may build shallower understanding, a “false sense of security” that shows up as confidence untethered from competence. The teams that navigate this well will likely be the ones that treat AI as a tutor to interrogate rather than an oracle to obey, and that deliberately preserve opportunities for people to struggle productively with hard problems.
What stays human
Strip away the hype and a durable core remains. Deciding what is worth building. Understanding what users actually need versus what they asked for. Making trade-offs between speed, cost, security, and maintainability. Taking responsibility when something goes wrong. Collaborating across a team and a business. These are not code-generation problems, and there’s no evidence the current generation of models is close to owning them.
Demand for skilled engineers has stayed strong even as tooling has advanced, which fits a pattern from earlier waves of abstraction: compilers, high-level languages, and open-source frameworks all automated enormous amounts of manual work and all coincided with more software being built and more people building it, not fewer. Lowering the cost of producing software tends to expand the universe of software worth producing.
Table Of Contents
How to prepare, honestly
For individual engineers: get fluent with AI tools, but calibrate against measured outcomes rather than the feeling of speed, because the research shows that feeling lies. Invest disproportionately in the durable skills, design, review, debugging, security, that rise in value as generation gets cheap. Treat every line of AI output as a code review, not a gift.
For teams and leaders: measure real outcomes, not tool adoption. Put security scanning and meaningful human review in the path of anything AI touches. Resist the temptation to translate impressive demos into headcount math; the productivity picture is too conditional and too easy to get wrong. And think hard about how you’ll keep growing junior talent when the tasks that used to train them are the ones getting automated first.
Table Of Contents
The honest conclusion
The future of software engineering isn’t a story of AI replacing engineers, and it isn’t a story of AI changing nothing. It’s a story of the work moving up the stack, from producing code to directing, verifying, and owning it, while the volume of software in the world keeps growing. The engineers who thrive won’t be the ones who resist the tools or the ones who surrender their judgment to them. They’ll be the ones who stay firmly in the loop: faster where the tools genuinely help, skeptical where the data says to be, and accountable throughout.
The tools are extraordinary and getting better. What they can’t do yet, and what the evidence suggests they won’t do soon, is care whether the thing they built is actually right. That’s still the job.
Table Of Contents
Sources
Figures in this article are drawn from primary and reputable secondary sources, including: GitHub, Octoverse 2025 (developer growth, Copilot first-week adoption, TypeScript, LLM-SDK repositories); METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv:2507.09089, the 19% slowdown randomized controlled trial); Veracode, 2025 GenAI Code Security Report (the 45% insecure-code finding); and McKinsey, The State of AI (enterprise adoption and value-capture figures). Widely repeated statistics that could not be traced to a primary source, such as claims that a specific percentage of all code on GitHub is AI-generated, were deliberately excluded. Readers are encouraged to consult the original reports for full methodology.