There was a time when joining the software industry felt less like arriving and more like being admitted into a new school.

After years of academic learning, becoming a software developer did not mean you finally "knew." It meant you had earned the right to begin learning differently. You entered as a junior. You listened. You respected the people who had already spent years debugging production systems, designing fragile integrations, recovering from bad abstractions, and learning which elegant ideas survived contact with users.

Experience was not measured only by years employed at a company. It was measured by depth of understanding, judgment under uncertainty, and the ability to pass knowledge on. Younger developers sought mentors with the intensity that modern social media influencers seek followers. The craft had a kind of sacredness to it, because the work demanded humility.

To apply for a software developer role implied that you understood both the art and science of the profession. You were expected to know, or at least be actively learning, the foundations: TCP/IP, load balancing, database indexing, trees, graphs, hash tables, sorting and searching algorithms, Big O notation, garbage collection, threading, concurrency, memory management, design patterns, SOLID principles, testing strategies, refactoring techniques, and the difficult judgment of when not to use the clever thing you just learned.

Those were also the days when autocomplete was the closest thing to a copilot. When a complex problem appeared, peers often went for coffee and talked it through before losing hours in the wrong direction.

Now the ground is shifting. AI has not made the fundamentals irrelevant. It has made them easier to bypass.

A developer can now ask an AI tool to explain a TCP protocol, generate a database migration, suggest indices, write tests, refactor a class, summarize unfamiliar code, or scaffold an entire feature. Often, the tool will produce something useful. Sometimes it will produce something confidently wrong. That distinction is central to the future of software development.

The question we ask ourselves as practice leads is no longer, "Can AI write code?" It clearly can. The question we now ask ourselves is "Who is qualified to know whether the code is correct, maintainable, secure, observable, and aligned with business?"

‍

AI Is Already in the Workflow

This is not a distant future. It is already happening.

Let’s look at the data.  

The 2025 Stack Overflow Developer Survey found that 51% of professional developers use AI tools daily, and 52% say AI tools or agents have had a positive effect on their productivity. Among developers using AI agents at work, about 70% say agents have reduced time spent on specific development tasks, and 69% say agents have increased productivity.

At the same time, trust remains a serious concern. The same survey found that 87% of respondents are concerned about the accuracy of information provided by AI agents, and 81% have concerns about security and privacy. Adoption is rising, productivity is real, and confidence is incomplete.

Controlled research shows the same tension. The widely cited Peng et al. study of GitHub Copilot found that developers using the tool completed an HTTP-server task 55.8% faster than those without it. McKinsey's research also found that generative AI can make developers significantly faster on code generation, refactoring, and documentation, while emphasizing that quality depends on developers understanding what good code looks like and iterating with the tool.

But the picture is not uniformly positive. A 2025 randomized controlled trial by METR studied 16 experienced developers working on large, mature open-source codebases they had contributed to for years. The result surprised many people: developers were 19% slower with AI assistance than without, even though they believed they were roughly 20% faster.The researchers attributed the gap to context-switching, prompt iteration, and the cognitive cost of reviewing plausible-looking output.

The 2024 DORA Accelerate State of DevOps report adds another caution. Across respondents who reported relying on AI for at least part of their work, AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. DORA's hypothesis is that AI may help developers produce larger changelists, and larger changes have long correlated with slower, more brittle delivery.

In other words, AI can accelerate the work, but the gains are uneven and do not automatically translate into better systems. The acceleration has to be earned through judgment.

‍

The Developer as Orchestrator

The software developer role is being reshaped.

The developer is becoming more of an orchestrator, reviewer, architect, and supervisor of intelligent systems. As agentic tools become more capable, more implementation work can be delegated. The human role moves upward: defining the problem, decomposing the work, choosing the architecture, constraining the agent, validating assumptions, reviewing outputs, and ensuring that the final system behaves correctly.

This does not mean developers can afford to know less. They need to know more broadly.

A developer working with AI needs enough architectural understanding to recognize when a generated design will not scale, when a service boundary is wrong, when a database query will collapse under real traffic, or when a security assumption is naive. They need enough testing discipline to know whether generated tests prove behavior or merely increase coverage numbers. They need enough product understanding to notice when the implementation technically satisfies the prompt but fails the user.

The best developers in an AI-assisted environment will not be the ones who simply generate the most code. They will be the ones who ask better questions, constrain the system more effectively, review more critically, and connect technical decisions to business outcomes.

Even the orchestrator role may be transitional. Today, reviewing AI output is what keeps the human meaningfully in the loop. But when an agent can generate hundreds or thousands of files in a single sitting, our capacity to objectively review code does not scale with it. The natural response may be to delegate some review to another agent, moving the human up another rung. Software may eventually become what car engines became for most drivers: a black box you trust and use.

‍

The Fundamentals Still Matter

There is a useful analogy in cell phones. Many of us no longer memorize phone numbers. The technology made that unnecessary in everyday life. But there are still moments when memory, understanding, or preparedness matter.

AI may do something similar to software fundamentals. Some knowledge will move from active recall to assisted retrieval. A developer may not remember every detail of a sorting algorithm or concurrency primitive because the tool can explain it on demand. But if the developer cannot evaluate the explanation, they are no longer assisted. They are dependent.

That dependency is risky, and the risk has measurable shape.

AI can hallucinate APIs. It can produce inefficient queries. It can invent configuration options. It can generate tests that assert the implementation rather than the behavior. It can solve the local problem while violating a larger architectural constraint. It can confidently recommend patterns that are obsolete, insecure, or inappropriate for the system in front of it.

A 2025 analysis of 576,000 code samples generated by 16 popular large language models found that 19.7% of package dependencies were "hallucinated," meaning they referred to libraries that do not exist. Open-source models hallucinated at nearly 22%; commercial models, at roughly 5%. This has produced a new supply-chain attack class researchers call slopsquatting, where malicious actors register hallucinated package names so AI-suggested installs become attack vectors. Independent assessments of AI-generated code more broadly find that 29-45% of samples contain security vulnerabilities depending on language and task type.

This is why fundamentals still matter. Beyond memorized trivia, the mental model still needs to supervise the machine.

A developer does not need to hand-write every binary search to be competent. However they should understand why indexing matters and when to use indices. They should understand latency, failure modes, transactions, concurrency, memory, coupling, cohesion, test boundaries, observability, and trade-offs. The details may be assisted. The judgment cannot be outsourced as easily.

At least not yet.

‍

Software May Become Cheaper to Produce, But Not Smaller in Ambition

Manufacturing cars has become heavily automated. The International Federation of Robotics reported that more than one million robots were working in the automotive industry worldwide, with countries such as South Korea, Germany, the United States, and Japan showing very high robot density in automotive production. Automation has helped manufacturers improve consistency, productivity, and throughput.

But cars did not simply become cheaper, simpler objects. They accumulated new expectations: advanced safety systems, navigation, sensors, entertainment systems, software controls, fuel efficiency improvements, driver-assistance features, and now electric drivetrains. The U.S. Bureau of Labor Statistics accounts for these changes when measuring new vehicle prices, adjusting for improvements in safety, fuel economy, mechanical systems, comfort, convenience, navigation, communication systems, backup cameras, sensors, and other functional upgrades.

There is a name for this dynamic in economics: the Jevons paradox. When a resource becomes more efficient to use, total consumption can rise rather than fall because the lower cost unlocks new categories of demand that previously failed the cost-benefit test. It was first observed in 19th-century coal use as steam engines became more efficient, and it has reappeared in electricity, computing, and bandwidth ever since.

The lesson is not that automation makes everything cheap forever. The lesson is that automation changes what becomes economically possible. As production becomes more efficient, expectations rise. Products absorb more features. Markets demand more customization. Companies discover new ways to compete.

AI may reduce the cost of producing certain kinds of software, especially boilerplate, prototypes, migrations, test scaffolding, documentation, internal tools, and routine feature work. But lower cost will not necessarily mean less work. It may mean more software, more experiments, more personalization, more integrations, more automation, and more pressure to deliver faster.

If the cost of building decreases, the appetite for building may increase.

‍

The Human Bottleneck Moves

Historically, one bottleneck in software development was implementation capacity. How many developers do we have? How much code can they write? How many tickets can they complete?

AI changes that equation. In some contexts, a smaller team with strong AI-assisted workflows may produce what previously required a larger team. It would be naive to pretend this will not affect staffing. Some teams may downsize. Some roles may consolidate. Some entry-level work may be automated or transformed.

The early data points are striking. Salesforce reported that it hired no new software engineers in fiscal year 2026, with CEO Marc Benioff attributing the shift to AI coding agents and citing roughly a 30% engineering productivity gain. Across the broader U.S. tech sector, more than 142,000 workers were cut in the first five months of 2026, with AI cited as a top reason in firms tracked by Challenger, Gray & Christmas, and entry-level developer employment falling significantly from its late-2022 peak.

It is worth being honest about where displaced developers may actually go. When automotive robots replaced welders, the displaced workers did not all become robot supervisors and weld inspectors. The arithmetic rarely works that way. Some moved sideways and took welder jobs at companies that had not yet automated. Others left the trade entirely. Software is unlikely to be different. The orchestrator and supervisor roles are real and growing, but they are not a one-for-one replacement for the headcount they consume.

Some developers will move into adjacent technical work: integration, architecture for clients who can no longer afford their own teams, security review, data, and platform engineering. Others will move into roles that lean harder on human capability than technical depth: client conversations, requirements shaping, product judgment, and relationship work. Remaining technical will still matter, but not always in the algorithmic sense it used to.

The lifecycle around the work may compress too. The traditional services arc of lead, discovery, design, build, deploy, and application management depends on the build and deploy phases being expensive. When those phases collapse in cost, the lifecycle compresses with them. It is not hard to imagine a near-term version where the output of a well-run discovery becomes the deployed system itself.

But another bottleneck becomes more visible: decision quality.

What should we build? Why? For whom? What risks are acceptable? What should be automated, and what should remain human-reviewed? Which generated code is good enough? Which system behaviors matter most? Which tests actually protect the business? Which failures are tolerable, and which are existential?

These are not merely coding questions. They are product, architecture, risk, and organizational questions.

This means developers will need to understand the business more deeply. They will need to think like QA, product managers, architects, operators, and security reviewers. They will need to validate outcomes, not just implementations. They will need to know when an AI-generated solution is technically impressive but strategically wrong.

The future developer may spend less time producing every line manually and more time ensuring the system as a whole is coherent.

‍

The Risk of De-Skilling

There is a real concern that AI could produce a generation of developers who can assemble software but do not understand it. That concern should not be dismissed as nostalgia.

If juniors never struggle through debugging, never learn how HTTP works, never reason about data structures, never see production failures, and never receive mentorship from experienced engineers, then the industry may gain short-term velocity while weakening its long-term talent pipeline. The hiring data already suggests this rung of the ladder is under pressure: the entry-level positions where this learning used to happen are among the ones contracting fastest.

The old apprenticeship model was imperfect, but it served a purpose. It gave developers a path from imitation to understanding, from syntax to design, from fixing bugs to anticipating them.

AI can help with learning, but only if used deliberately. It can explain unfamiliar code, generate examples, compare approaches, and provide immediate feedback. But it can also allow a developer to skip the discomfort where real understanding is formed.

Organizations will need to be intentional. They cannot simply hand AI tools to junior developers and expect mastery to emerge automatically. Mentorship still matters. Code review still matters. Pairing still matters. Architecture discussions still matter. So does the old habit of stepping away from the keyboard to think before generating more code.

‍

What May Be True Today May Be False Soon

Any confident prediction about AI should come with an expiration date.

It helps to remember that this is not the first such shift, only the steepest. The work a developer did in the 1980s looks nothing like the work in the 1990s, which looked nothing like the 2000s, and even 2020 already feels distant. Bit-packing because memory was scarce, hand-rolled assembly inside C because higher-level code was too slow, and chasing cache misses to keep applications responsive all became less central as we moved to interpreted languages, containers, virtual machines, managed runtimes, and cloud platforms.

Each generation of developers had to let go of something the previous generation defined themselves by. We should expect the same of ourselves, probably on a faster clock.

That progression has a pattern: each generation of tools raised the level of abstraction, changed the role, and increased output. The arrival of compilers and high-level languages is credited with at least a fivefold improvement in productivity over assembly programming. Virtual machines and managed runtimes erased entire categories of memory and portability work. Containers and orchestration systems made deployment a configuration problem. Cloud platforms turned hardware provisioning, scaling, and global distribution into API calls. Infrastructure-as-code turned operations into a code-review problem.

At every step, the developer produced more, knew slightly less about the layer beneath, and was held responsible for slightly more of the layer above.

The same progression has quietly reshaped entire job titles. Twenty years ago a serious software organization might have needed dedicated systems integrators, database administrators (DBA), and network operations analysts. Much of that work has been absorbed into DevOps, cloud platforms, and managed services. Database administrators have not disappeared, but demand has shifted toward cloud and application-side work, while routine administration that once justified a full team is now often a managed-database setting. Sysadmin and network operations work have followed similar paths. These roles were not abolished. Their demand thinned, their boundaries blurred, and the work moved.

If that pattern holds, the honest answer to "what happens to developers?" may be the same answer that applied to DBAs and integrators: the role does not vanish, but it narrows, shifts, and re-forms around whatever the next layer of abstraction leaves unautomated. The uncomfortable part is that developers are, in a real sense, building their own next abstraction.

The tools are changing too quickly for certainty. What seems risky today may be routine in six months. What seems impressive today may feel primitive in a year. The boundaries between autocomplete, assistant, agent, reviewer, tester, and autonomous implementer are already blurring.

So the safest position is not to declare that AI will replace developers or that it never will. Both claims are too simple.

A more balanced view is this: AI is changing the economic and practical shape of software development. It will automate parts of the work. It will amplify capable developers. It will expose weak engineering practices. It will create new risks. It will reduce the cost of some deliverables and increase expectations for what teams can produce. It will make fundamentals feel less visible, while making judgment more important.

The craft is not disappearing, but its rituals are changing. The developer of the future may not be judged by how much code they can personally type. They may be judged by how well they can direct intelligent tools, evaluate their output, preserve system integrity, understand the business, protect users, and keep learning as the ground moves.

That future may feel less sacred than the past. Or perhaps the sacredness simply moves: from memorizing every command, pattern, or algorithm to caring enough to know when the machine is wrong.

What do you think about the futur of our craft?