The Next Two Years of Software Engineering

Source: Addy Osmani's Blog

Five Questions That Define the Moment

Software engineering is at an inflection point. AI coding tools have moved from novelty to daily workflow, from autocomplete to autonomous agents that can implement features end-to-end. Addy Osmani identifies five questions that will shape how the profession evolves over the next two years—not decades from now, but in the immediate future that current developers and students need to plan for.

Q1: Will AI Replace Developers?

The short answer: no. The longer answer: the job you're doing today will look different in two years.

The fear of replacement misunderstands what software engineering actually is. Writing code—translating well-defined logic into syntax—is the most automatable part of the job. But deciding what to build, why it matters, and how it fits into a larger system? Those remain deeply human activities.

What's changing is the ratio. A developer who spent 70% of their time writing code and 30% thinking about architecture and requirements will see those numbers shift. The future developer spends more time orchestrating, reviewing, and directing—less time typing. This isn't replacement; it's amplification. But it does mean that developers whose entire value proposition is "I can write code fast" need to expand their skillset.

The parallel to history is instructive. The introduction of compilers didn't eliminate programmers—it eliminated the need to write machine code directly and created space for higher-level thinking. AI coding tools are doing the same thing, one abstraction layer up.

Q2: What Skills Matter Most?

If code generation is increasingly automated, the premium shifts to skills that can't be automated:

Systems Thinking: Understanding how components interact, where bottlenecks will emerge, and how changes propagate through a system. An AI can generate a perfect microservice, but understanding whether a microservice is the right architecture for your scale requires judgment.

Architecture: Knowing which patterns to apply, when to choose simplicity over flexibility, and how to evolve a system over time. Architecture is about constraints and tradeoffs—exactly the kind of contextual reasoning that benefits from human experience.

Verification: As AI generates more code, the ability to review, test, and validate becomes critical. This isn't just reading code—it's understanding whether the code actually solves the problem correctly, handles edge cases, and doesn't introduce subtle bugs. Verification skill becomes the quality bottleneck.

Communication: Translating between business needs and technical implementation has always been valuable. When AI handles the implementation, the ability to precisely define what needs to be implemented becomes even more important. The quality of the prompt determines the quality of the output—and writing good prompts is really just a specific form of clear communication.

Q3: How Will Hiring Change?

The traditional software engineering interview—whiteboard algorithms, LeetCode grinding, system design for hypothetical billion-user systems—is already under pressure. AI tools make it trivial to solve algorithmic puzzles, undermining the signal these tests were designed to provide.

What's emerging instead:

Portfolio of AI-Assisted Projects: Demonstrating that you can effectively use AI tools to build real, working software. The emphasis shifts from "did you write every line" to "did you build something that works, and can you explain the decisions behind it."

Demonstration of Judgment: Can you look at AI-generated code and spot the subtle issues? Can you make architectural decisions that the AI wouldn't make on its own? Can you identify when the AI's suggestion is technically correct but wrong for the context?

Collaboration and Orchestration: How do you break down complex problems for AI agents? How do you review and integrate AI-generated output into a coherent system? These are new skills that are already becoming hiring signals.

The shift won't happen overnight—large organizations move slowly. But startups and forward-thinking teams are already hiring based on demonstrated ability to ship with AI tools, not just demonstrated ability to invert a binary tree.

Q4: What Happens to Junior Developers?

This is the most anxious question in the industry, and it deserves a nuanced answer.

The traditional junior developer path—learning syntax, writing basic features, gradually taking on more complex work—is being compressed. AI tools handle the tasks that used to be assigned to juniors as learning exercises. If a senior developer can use an AI agent to build a CRUD endpoint in seconds, why assign it to a junior who'll take hours?

But the path doesn't disappear—it transforms. Junior developers entering the field now need different skills earlier:

• Reading and reviewing code becomes more important than writing it from scratch
• Understanding systems matters more than memorizing API signatures
• Asking good questions (to both AI and humans) replaces grinding through documentation alone
• Debugging and reasoning about failures remains a fundamentally human skill that AI tools assist but don't replace

The risk is real: companies might hire fewer juniors if AI tools reduce the need for "entry-level coding." But the opportunity is also real: juniors who learn to work effectively with AI tools can reach higher levels of productivity much faster than previous generations.

Q5: How Should Education Adapt?

Computer science curricula built around teaching syntax and algorithms are increasingly misaligned with industry needs. When AI can write a sorting algorithm in any language, spending a semester on implementation details is less valuable than spending it on understanding when to sort, what data structure to choose, and what the performance implications are.

Education needs to shift toward:

More Architecture, Less Syntax: Teaching students to think about systems, tradeoffs, and design patterns. Syntax can be looked up (or generated); understanding why you'd use a particular pattern cannot.

AI Fluency as Baseline: Every graduating developer should be comfortable working with AI coding tools. Not as an advanced elective, but as a fundamental skill taught from the first course. This includes understanding AI limitations, prompt engineering, and code review.

Project-Based Learning: Building real applications—with all the messy, context-dependent decisions that entails—becomes more important than isolated exercises. The gap between "can solve a textbook problem" and "can build a working system" is where the real learning happens.

Ethics and Judgment: As AI handles more of the implementation, the human role in deciding what should be built becomes more prominent. Ethics, security thinking, and user empathy deserve more curriculum space.

Practical Advice

For individuals:

• Invest in the skills AI can't replicate: architecture, system design, communication, domain expertise
• Build things—full applications, not just components—and use AI tools aggressively in the process
• Practice code review; it's becoming one of the most valuable skills in the profession
• Stay curious about new AI capabilities but grounded in engineering fundamentals

For organizations:

• Rethink hiring processes to evaluate AI-augmented productivity, not just raw coding ability
• Create structured paths for junior developers that account for AI tools
• Invest in architecture and system design capabilities—these become the bottleneck when coding speed is no longer the constraint
• Build a culture of verification and review to match the speed of AI-assisted development

The next two years won't be comfortable for everyone. But for those who adapt, they'll be the most productive years software engineering has ever seen.