In late 2024, Sam Altman made a statement that sent a familiar wave of anxiety through developer communities worldwide. Speaking with the particular authority of someone who runs the company building the most capable AI systems on earth, he said that AI was approaching the capability to do the work of a software engineer, that this capability threshold would arrive sooner than most people in the industry expected, and that the implications for the profession were significant.
The headlines were predictable. "AI Will Replace Software Engineers." "Sam Altman Says Coders Are Obsolete." "The End of Programming as a Career." Tech forums exploded with responses ranging from existential panic to defensive dismissal. The panic was understandable. The dismissal was comfortable. Both missed the actual substance of what Altman was saying.
Altman is not a person who makes casual predictions. He runs the company whose products are demonstrably changing what software development looks like in practice. His comments deserve the same careful reading you would apply to a statement from a cardiologist about changes in medicine or a structural engineer about changes in construction. Not uncritical acceptance, but serious engagement.
This article is about what he was actually saying, what the evidence already shows is happening, what the historical analogies reveal about how these transitions unfold, and what every developer and aspiring developer should do with this information to make better decisions about their career right now.
The Actual Statements in Full Context
Altman did not say software engineers would disappear. Across multiple interviews, podcasts, and public appearances between 2023 and 2025, he made several distinct claims that are worth separating carefully rather than collapsing into a single alarming headline.
Claim 1 — Capability threshold: AI systems are already capable of doing a significant fraction of the work currently performed by entry-level and junior software engineers, and this fraction is growing.
Claim 2 — Leverage ratio: A single person with access to AI coding tools can accomplish what previously required a team. The effective productivity multiplier for skilled engineers using AI is substantial.
Claim 3 — Cost collapse: The marginal cost of producing a given quantity of working code is declining toward a small fraction of what it was two years ago. This has profound implications for what gets built and by whom.
Claim 4 — Near-term threshold: The capability he was describing was not a speculative future state — it was already substantially present in 2024, and would be more substantially present in 2025 and 2026.
What he did not say: that software engineering as a discipline was ending, that experienced engineers were being replaced, that the need to understand software systems deeply was becoming less important, or that anyone should leave the profession.
The distinction between what he said and what the headlines reported is the entire point. The headline version is emotionally engaging but analytically useless. The precise version is the one you can act on.
The more accurate paraphrase of Altman's actual position:
The layer of software development that consists of translating clear specifications into working code is being automated. The layer that consists of generating those specifications, understanding the system-level trade-offs, designing the architecture, making the judgment calls about what to build and why, and ensuring the output is actually correct — that layer is not being automated. In fact, as the implementation layer accelerates, the judgment layer becomes proportionally more important and more scarce.
This is a transformation in the structure of the profession, not the elimination of it.
The Historical Framework That Makes This Understandable
Every time in economic history that a significant category of work has been automated, the discourse has followed the same pattern: initial alarm, defensive dismissal, and eventual recognition that the transformation was both real and more nuanced than either extreme predicted.
Understanding where software engineering sits in this pattern requires looking at the analogies carefully.
The spreadsheet and the financial analyst:
When VisiCalc and then Lotus 1-2-3 introduced spreadsheet software in the early 1980s, they essentially eliminated the profession of "human calculator" — people employed by financial firms to perform arithmetic by hand. These were skilled workers whose value came from speed and accuracy at numerical computation.
Spreadsheets did not eliminate financial analysis. They eliminated the commodity skill of performing arithmetic while dramatically expanding the scope and speed of what financial analysts could do. The analysts who adapted used spreadsheets to perform analyses that would have taken weeks in days, modelling scenarios that were previously impractical to explore, and serving more clients with more complex needs.
The analysts who were threatened were those whose primary value was the arithmetic — because that was the layer that was automated. The analysts whose primary value was understanding what the numbers meant, designing the analysis, and making the business judgment were amplified rather than replaced.
The CAD software and the draughts person:
Computer-aided design software automated the technical drawing that was previously performed by skilled draughts people. A draughtsperson who spent years developing the ability to produce precise technical drawings by hand was, to a significant degree, displaced by AutoCAD.
But the engineers who designed the things being drawn were not displaced — they were amplified. They could now iterate on designs faster, explore alternatives more cheaply, and communicate their thinking more clearly. The demand for engineering judgment increased as the cost of expressing that judgment in drawings decreased.
The photography and the portrait painter:
When photography became commercially viable in the 1840s-1860s, it did not eliminate visual art. It fundamentally restructured the visual arts market. Portrait painting as a commodity — capturing a person's likeness for those who could not afford a commissioned artist — was replaced by photography. Portrait painting as a high-art form became more explicitly what it had always implicitly been: not about capturing likeness but about expressing something more complex about the subject.
The people who had positioned themselves as commodity likeness-capturers were displaced. The people who had developed deeper artistic capabilities found that their skills were in higher demand at a higher price point.
What the analogies tell us about software engineering:
In every analogous transition, the skills that were automated were the ones that could be specified precisely enough to be automated. The skills that were not automated were the ones that required judgment, domain expertise, and the ability to handle genuinely novel problems.
In software engineering, what can be specified precisely enough to be automated: writing code that implements a clearly defined function, translating a well-specified requirement into a working implementation, fixing bugs with known patterns, generating boilerplate and scaffolding.
What cannot be specified precisely enough to be automated: deciding what the system should do, designing the architecture that will support what the system needs to do over its lifetime, evaluating whether the system that was built is actually correct, handling the genuinely novel failures that arise in complex production systems.
What Is Already Happening: Ground-Level Evidence From Developer Workflows
The discussion should not be theoretical, because the transformation is already underway and producing observable outcomes in real development environments. What AI coding tools are currently doing, at scale, in real workflows provides the clearest available evidence for what Altman was predicting.
The tooling landscape in 2025:
GitHub Copilot, launched in 2021, has in subsequent years been reported to be responsible for a significant fraction of new code in repositories where it is active — some enterprise reports suggesting 35-50% of new code in certain team contexts. Cursor, the AI-native IDE built around Claude and GPT-4, has rapidly captured developer mindshare among early adopters who describe it as having fundamentally changed their daily workflow. Amazon's CodeWhisperer, Google's Gemini Code Assist, Replit's AI features, and Anthropic's Claude in various coding contexts are all producing production-quality code in developer workflows daily.
Beyond code generation, AI tools are now handling substantial portions of code review (GitHub Copilot for Pull Requests), documentation (auto-generated docstrings and READMEs), test generation (writing test suites from production code), and debugging (explaining stack traces and suggesting fixes).
The productivity evidence:
Studies published in 2023-2024 by GitHub, Turing, and various academic research groups consistently show productivity improvements for developers using AI coding tools ranging from 20% to over 100% on implementation tasks. The variance is large and the methodology varies, but the direction of the effect is consistent: developers who use AI coding tools complete implementation tasks faster.
The critical nuance: the productivity improvements are largest for experienced developers and for well-defined implementation tasks. They are smaller — and sometimes negative — for developers who lack the foundational understanding to evaluate the AI's output, and for tasks that involve genuinely novel problems or complex system-level reasoning.
The 10x engineer becomes the 100x engineer — or the cautionary tale:
The impact on individual developers has been strikingly asymmetric. Senior engineers using AI tools report productivity multipliers that reshape what is possible for a single individual. Work that would have taken a week now takes a day. A solo developer at a startup can now build and maintain a product that would previously have required a team of three.
The impact on developers who lack foundational understanding is more complicated. The tools can produce working code for simple, well-specified tasks — which creates the appearance of competence. But the same tools produce plausible-looking incorrect code for complex or poorly-specified tasks, and the developer without foundational understanding cannot reliably distinguish between the two outcomes.
This creates what practitioners have begun calling the "competence illusion" — a pattern where a developer using AI tools believes they have built something that works, because the code runs and produces plausible output, when in fact the code has significant problems that only emerge under specific conditions, at scale, under concurrent load, or under attack.
The real-world scenario that crystallises the divergence:
A Series A fintech startup hired two developers in early 2024 — both AI tool users, both enthusiastic about using Cursor and Claude for development. One had three years of backend engineering experience at a company with significant scale requirements. The other was a self-taught developer who had built several projects using AI tools from the beginning of their learning.
Six months later: the experienced developer had shipped several significant features and was operating with approximately 5x the productivity they had before adopting AI tools. The self-taught developer had shipped code that worked in development but had produced three production incidents — including one involving a session management bug that allowed users to access each other's accounts under specific conditions.
The session management bug was in AI-generated code. The experienced developer would have caught it in code review because they understood the authentication pattern. The self-taught developer did not catch it because they had not developed the foundational understanding of how session management works.
Same tools. Dramatically different outcomes. The difference was not the tools — it was what the developer brought to the tools.
What "Software Engineering Is Changing" Means Layer by Layer
The profession of software engineering has always contained multiple distinct layers, and the AI transformation is affecting each layer with dramatically different intensity. Understanding this layered structure — not as an abstract framework but as a description of the actual work — is what makes Altman's comments precise rather than alarming or dismissive.
Layer 1: Syntax and implementation — being rapidly automated
This is the layer that translates a clear, precise specification into syntactically correct, working code. "Write a function that takes a list of customer objects and returns those where the last_purchase_date is more than 90 days ago." "Create an Express.js middleware that validates JWT tokens and attaches the decoded user object to the request."
AI coding tools handle this layer extremely well when the specification is clear and the problem is within their training distribution. The speed advantage is real, the quality is often high, and the human value-add at this layer is declining.
The honest reality: this layer was never the highest-value part of software engineering. The bottleneck in most development projects was never "we cannot write the code quickly enough" — it was "we are not sure what we are supposed to build" and "we do not know whether what we built is actually correct." Tools that speed up implementation move the bottleneck further up the value stack, but they do not eliminate it.
Layer 2: Debugging and problem-solving — partially automated with critical limitations
AI tools are increasingly capable of explaining error messages, suggesting fixes for common bugs, tracing through simple logic to find the flaw, and identifying security vulnerabilities in code they are shown. For the category of bugs that match known patterns — a null pointer dereference, an off-by-one error, a missing await in an async function — AI assistance is valuable and fast.
For the category of bugs that arise from complex system interactions — a race condition that only manifests under specific concurrent load conditions, a memory leak that only appears after 72 hours of operation, a data consistency failure that arises from an edge case in distributed transaction handling — AI assistance is limited. These bugs require the developer to form and test hypotheses about system behaviour, which requires understanding the system at a level that cannot be specified in a prompt.
Layer 3: Design and architecture — not being automated, increasingly the value differentiator
Deciding how a system should be structured — what the components are, how they communicate, what the data model looks like, how the system will evolve over time, what the trade-offs are between different approaches — remains fundamentally a human domain. Not because AI cannot generate architectural proposals, but because evaluating whether those proposals are correct requires the understanding that makes the designer valuable in the first place.
This is a subtle but important point. An AI system can propose a microservices architecture for a given problem. But determining whether microservices are the right approach for this specific problem, with this specific team, at this specific scale, with these specific operational constraints — that requires judgment that comes from having designed systems, seen some of them fail for specific reasons, and developed intuitions about where failure modes typically live.
Layer 4: Product and systems thinking — becoming the primary career differentiator
Understanding what should be built, for whom, solving which specific problem, with what constraints, given what organisational context, with what security implications, at what cost — this is the layer that has always been the most valuable and is now most clearly the primary differentiator between developers who thrive in the AI-augmented environment and those who do not.
A developer who deeply understands a problem domain can specify what to build clearly enough for AI tools to build it well. A developer who cannot understand the domain cannot write the specification that produces correct AI output. The quality of the specification is determined by the quality of the understanding, which is determined by years of relevant experience and deliberate learning.
Layer 5: Communication and translation — an underrated and growing layer
The layer that bridges technical capability and business context — translating business requirements into technical specifications, explaining technical constraints to non-technical stakeholders, navigating the gap between what is technically possible and what is economically sensible — is a distinct skill that AI tools do not address.
This layer was undervalued when the bottleneck was implementation. As implementation ceases to be the bottleneck, the quality of the communication layer becomes visible as a constraint. The developer who can listen to a product manager describe a problem, translate it into a precise technical specification, identify the ambiguities that need resolution, and explain the trade-offs in terms the business can evaluate — that developer is positioned at exactly the intersection that the new environment most values.
The Vibe Coding Problem: When Speed Without Understanding Goes Wrong at Scale
The term "vibe coding" — coined by Andrej Karpathy, one of the original OpenAI co-founders and former director of AI at Tesla — entered developer discourse in 2025 to describe a specific, concerning pattern: using AI tools to build things without developing a genuine understanding of what the AI produced.
In vibe coding, the developer describes what they want, accepts what the AI produces if it appears to work, and repeats this cycle without ever building the mental model that would allow them to understand, maintain, or debug the system. When something breaks, they describe the breakage to the AI and accept whatever fix it suggests, again without understanding the underlying mechanism.
This pattern produces results — sometimes impressive ones on simple, well-defined projects. But it has failure modes that are not immediately visible and become catastrophic in specific circumstances.
When vibe coding works:
Vibe coding works well for: prototypes that will be thrown away, personal projects without significant scale or security requirements, exploration of unfamiliar domains where you want to understand what is possible before deciding whether to invest deeply, and well-understood problems where the AI's training data is dense and the pattern is common.
When vibe coding fails spectacularly:
Security-sensitive applications: The fintech scenario described earlier is representative of a broad pattern. AI tools generate authentication and authorisation code that is syntactically correct and passes basic tests but contains security vulnerabilities that only manifest under specific conditions. A vibe coder who does not understand how session management, JWT token validation, or RBAC works cannot identify these vulnerabilities in code review.
In 2024, multiple public disclosures of security vulnerabilities in applications built with AI assistance revealed a pattern: the code looked correct, the tests passed, and the vulnerability existed because the AI had generated code that handled the happy path correctly but mishandled edge cases that require domain knowledge to anticipate.
High-scale systems: At 100 concurrent users, most database queries work fine even if they are not optimised. At 10,000 concurrent users, a missing index on a frequently-queried column turns an adequate application into an unavailable one. AI tools generate database schemas and queries that are correct for the stated requirements — they do not optimise for scale that is not in the specification. A developer who does not understand how database query execution works cannot identify these issues before they manifest as production incidents.
Distributed systems: Vibe coding a system that involves multiple services, message queues, and eventual consistency requirements produces code that works correctly in the happy path. The edge cases — what happens when a service is temporarily unavailable, when a message is delivered twice, when a network partition occurs — require the developer to have thought carefully about the consistency model. AI tools do not spontaneously apply sophisticated distributed systems thinking to their output; they apply patterns from their training data. If the specification does not include the edge cases, the generated code typically does not handle them.
Long-term maintainability: Code built through vibe coding tends to be inconsistent in style, unpredictable in structure, and difficult to modify. Because no single person developed a coherent understanding of how the system works, changes to one part unexpectedly break other parts. The developer who vibe-coded the system cannot predict these interactions because they never understood them.
The specific failure pattern that is most dangerous:
The vibe coding failure mode that causes the most damage is not "the code does not work" — that failure is immediately visible. The failure that causes the most damage is "the code appears to work but has a subtle flaw that produces incorrect behaviour in specific circumstances."
A payment processing function that rounds incorrectly on currency conversion. An authentication token that can be reused after logout under specific timing conditions. A database query that produces incorrect results when applied to records with certain special characters. These failures are not visible in normal testing, do not produce error messages, and only manifest in production under specific conditions — often conditions that attackers specifically engineer.
The developer who understood the payment processing logic, the authentication flow, or the database query would likely have caught these issues. The developer who vibe-coded them has no mental model that would direct their attention to these specific failure modes.
What Remains Irreducibly Human: The Skills That Cannot Be Automated
The conversation about which skills AI is automating is only half the analysis. The more actionable half is: which specific skills remain irreducibly human, what makes them resistant to automation, and how are they developed?
System design and architectural judgment — the primary unreplaceable skill:
The ability to look at a complex, novel problem and design a system that solves it correctly — with appropriate trade-offs between performance, maintainability, security, cost, and evolvability — requires a pattern-matching knowledge base built from years of designing systems and watching some of them fail in specific, instructive ways.
This knowledge cannot be transferred through description. The architectural judgment that tells an experienced engineer "this database schema will become a maintenance nightmare in eighteen months when the requirements evolve in the way I predict they will" comes from having built schemas that became maintenance nightmares in exactly this way. The judgment is embodied in experience, not stored in a fact that can be retrieved.
Security reasoning under adversarial conditions:
Security thinking requires imagining how a system could be attacked — specifically, thinking from the perspective of an adversary who is actively trying to find and exploit failure modes. This reasoning under adversarial conditions is fundamentally different from the reasoning required to build something that works correctly under normal conditions.
AI tools are trained primarily on examples of systems that work. They are not well-calibrated to the adversarial reasoning that security requires. They do not spontaneously consider how an attacker might construct a malicious input, how a race condition could be triggered deliberately, or how a seemingly innocuous API endpoint could be abused to extract sensitive data.
Security-aware code review — reading code and asking "how could this be exploited?" — remains a genuinely human skill. Developing it requires studying attacks, understanding how exploits work mechanically, and developing the adversarial perspective that security practitioners call "thinking like an attacker."
Writing precise, complete specifications:
The quality of AI-generated code is heavily determined by the quality of the specification provided to the AI. A vague specification produces vague code that may not handle edge cases, may not integrate correctly with surrounding systems, and may not satisfy requirements the developer had in mind but did not articulate.
Writing a specification that is precise enough to produce correct AI output requires understanding the problem at least as deeply as you would need to write the code directly. The developer who knows what data types are appropriate, what the edge cases are, what the integration points are with the surrounding system, what the performance requirements are — that developer can write a specification that produces correct AI output. The developer who lacks this understanding produces a specification that produces code that appears correct but fails under specific conditions.
This means the skill of "telling AI what to build" is not lower-skill than "building it yourself." It is the same skill expressed at a higher level of abstraction.
Domain expertise as a technical multiplier:
The most consistently high-value technical professionals in 2025 are those who combine deep technical capability with deep domain expertise in a specific field. A developer who deeply understands how financial risk models work and can build software that correctly implements those models is more valuable than a developer who can build any software but does not understand the domain. A developer who understands clinical trial protocols and can build trial management software that correctly handles regulatory requirements is irreplaceable in that specific context.
AI tools do not provide domain expertise. They provide implementations of specifications. The domain expertise that produces the correct specification is the bottleneck.
Diagnosing novel failures in production systems:
Production systems fail in ways that were not anticipated during design. A service that has operated reliably for two years suddenly exhibits intermittent failures under a specific traffic pattern. A database that has processed millions of transactions correctly starts producing inconsistent results in edge cases. A distributed message queue that has worked flawlessly begins experiencing message loss under specific load conditions.
Diagnosing these failures requires forming hypotheses about the system's internal state, designing experiments to test those hypotheses, interpreting the evidence to narrow the space of possibilities, and eventually identifying the root cause. This is a fundamentally scientific process applied to software systems.
AI tools can assist in this process — they can suggest hypotheses, generate diagnostic code, explain potential causes of specific error messages. But they cannot direct the investigation with the contextual knowledge of this specific system that the developer has accumulated over months or years of working with it.
The Market Transformation: What Altman's Prediction Means for the Industry Structure
Looking at Altman's comments in their full context — not as a statement about individual careers but as an observation about the structure of the software industry — the prediction is primarily about the economics of software production, and what a dramatic change in those economics produces.
The cost collapse and what it enables:
For most of economic history, software development was expensive enough that the set of problems worth solving with software was constrained. The cost of building a custom inventory management system for a small business exceeded the value it would deliver. The cost of building a data pipeline to automate a repetitive task exceeded the salary cost of the employee doing it manually. The cost of building a customer-specific configuration tool was not justified by the number of customers who would use it.
As AI tools collapse the cost of software implementation, problems that were previously not economically worth solving with software become worth solving. This is a genuine expansion of the market for software, not just a redistribution of existing work.
The implication: there is more software to be built in 2025 than in 2020, and significantly more than in 2015. The total demand for software engineering work is expanding, not contracting. What is contracting is the share of that work that consists of pure implementation.
The democratisation layer:
AI tools are enabling a category of software creation that did not meaningfully exist before: non-engineers building useful software tools for their own workflows. Lawyers building contract analysis dashboards. Financial analysts building custom data processing pipelines. Operations managers building workflow automation tools. HR professionals building applicant tracking systems for their specific needs.
These people are not replacing professional software engineers. They are creating software that no professional software engineer would have been hired to build — because the problems were too small, too specific, or too domain-specific to justify a professional engagement. They are expanding the total market.
The bifurcation:
The professional software engineering market is bifurcating into two increasingly distinct segments. The first segment: software that can be built by non-engineers or junior engineers using AI tools with minimal oversight. CRUD applications, basic web apps, simple automation tools, standard integrations. The second segment: software that requires genuine engineering judgment — complex systems with significant security requirements, high scale requirements, complex domain logic, or architectural novelty.
The first segment is expanding in volume while declining in per-unit human labour. The second segment is expanding in both volume and per-unit human value.
The salary implications:
The salary data from major technology markets in 2024-2025 is consistent with this structure. Entry-level and junior developer hiring has contracted at many large technology companies — these roles are where AI tools have had the most impact on productivity, reducing the number of junior engineers needed for a given output. Senior and staff-level engineering positions have maintained strong compensation and hiring activity. Roles that combine deep technical capability with domain expertise — fintech engineering, medical device software, AI systems engineering, security engineering — command significant premiums.
The market is not telling developers "we don't need you." It is telling developers "we need fewer people who primarily implement specifications and more people who generate and evaluate them."
The Curriculum Shift: What to Learn and What to De-Emphasise
Given the layer analysis and the market transformation, the question of what to learn — and in what order — has a clearer answer in 2025 than it had three years ago.
What to emphasise more:
Computer science fundamentals — more important, not less:
This is the counterintuitive recommendation that most AI-era coding advice misses. When implementation is automated, the ability to evaluate whether the implementation is correct becomes the primary value. That evaluation requires the fundamentals: how do algorithms have the complexity characteristics they have, what are the trade-offs between different data structures, how do databases process queries and what determines query performance, how do networks handle failure and what consistency guarantees are possible.
These fundamentals are not important for the test that asks you to implement them. They are important because they are the mental model that tells you whether the AI's output is correct.
System design:
Designing systems that are correct, scalable, maintainable, and appropriately secure is the highest-value skill in the 2025 market. Building skill in system design requires studying existing systems (how does Twitter's timeline system work, what are the trade-offs in Stripe's payment processing architecture, why did Slack's message fan-out architecture evolve the way it did), designing systems yourself, getting that design reviewed by more experienced engineers, and iterating.
Security thinking:
Security is not a module to add to a system — it is a lens through which systems should be designed from the beginning. Developing security thinking requires studying attacks (OWASP Top 10 is the minimum, beyond that: reading security research, doing CTF competitions, understanding how real breaches occurred), applying adversarial reasoning to your own designs, and getting security-aware code review.
Domain expertise:
Picking a specific problem domain — fintech, healthcare, logistics, developer tooling, data infrastructure — and developing genuine expertise in it creates the combination that the market most values and AI tools least replicate. Domain expertise takes years to develop, which means starting early matters.
Writing clear specifications:
The skill of translating a problem into a precise, complete specification — one that captures the edge cases, the constraints, the integration requirements, and the performance requirements — is the skill that determines the quality of AI-assisted development. It can be developed through deliberate practice: before writing any code (or prompting AI to write it), write out the complete specification in prose, identifying what you know and what you need to find out.
What to de-emphasise:
Syntax memorisation:
The ability to write Python, JavaScript, or any other language from memory without reference to documentation is genuinely less important than it was. AI tools handle syntax reliably. Time spent memorising API details could be better spent understanding the underlying principles.
Framework-specific implementation patterns:
Knowing the specific way to write a Django model or a React component — the mechanics of a specific framework's implementation — is less valuable than understanding what the framework is doing and why. Frameworks change; the underlying concepts (HTTP request handling, component lifecycle, database ORM abstractions) do not.
Boilerplate and scaffolding:
Setting up project structure, configuring build tools, writing standard CRUD endpoints — these are the tasks that AI tools handle well and that occupy significant time in traditional development. Spending learning time on these at the expense of the judgment skills is a poor investment.
The Practical Career Decision Framework: What to Do Now
Given the analysis above, the actionable framework for someone making career decisions about software development:
If you are just starting out and have no foundational skills yet:
Resist the temptation to start with AI tools. Start with the foundations — how the web works, how databases work, how operating systems work, how networks work. Build projects that are small enough to understand completely and large enough to encounter real problems. Use AI tools to help you when you are stuck, but do not use them to replace the process of figuring things out, because the figuring-out process is where the foundational understanding is built.
The specific risk: a beginner who starts with AI-assisted development may find themselves six months later able to build things that work in their local environment and fail in production, without the foundational knowledge to understand why. This is a common and expensive mistake.
If you have 1-3 years of experience:
You have enough foundation to use AI tools productively. Integrate them into your workflow — they will make you more productive on implementation. But invest specifically and deliberately in the skills that remain human: read about system design (the Designing Data-Intensive Applications book by Martin Kleppmann remains the most valuable single resource), study security (the OWASP curriculum, plus at least one CTF competition), and look for opportunities to design small systems yourself rather than being handed architectures to implement.
If you have 3+ years of experience:
The tools are a significant productivity amplifier for someone at your level. Use them. The career risk is not being displaced — it is being outcompeted by peers who combine your experience with AI-augmented productivity. The developers who resist AI tools at this level will simply produce less output per hour than those who do not.
The strategic investment at this level: develop the cross-layer fluency that the market increasingly values. Add domain expertise in a specific field. Develop the ability to communicate architectural trade-offs clearly. These are the capabilities that make experienced engineers genuinely irreplaceable rather than merely hard to replace.
The AI tool integration practice that preserves learning:
For developers at any level: when using AI to generate code, adopt the practice of reading every line the AI produces and being able to explain what it does, why it works, and what could go wrong. This is not the fastest way to use AI tools. It is the way to use AI tools while continuing to develop the foundational understanding that makes you more capable of using them well.
Closing: From Altman's Prediction to Your Professional Identity
What Sam Altman was actually predicting about software engineering is a reframing of where value lives in the profession — not a death certificate for it. The commodity layer of development is being automated. The judgment layer is becoming more valuable and more scarce. The total market for software is expanding. The developers who will thrive are those developing skills in the layers that AI amplifies rather than replaces.
This reframing opens onto a set of deeper questions that every developer working in 2025 will encounter within months: How do you design a distributed system that maintains consistency guarantees under the failure modes that production environments produce? How do you build an AI-integrated application that is secure — not just functional — when AI tools regularly generate code that contains security vulnerabilities they cannot identify? How do you evaluate the architectural quality of an AI-generated codebase and identify the places where the AI made reasonable-looking choices that will create serious problems at scale?
These questions are not about using AI tools — they are about the foundational understanding that makes AI tools produce valuable output rather than plausible-looking mistakes. They are what distinguish a developer who has built a career on genuine engineering capability from one who has built a portfolio of demos.
At Meritshot, the Full Stack Development with GenAI programme is built directly for this transition. Students develop the foundational understanding of how systems work — networking, security, database design, distributed systems concepts — alongside the practical skills of building AI-integrated applications in production-like conditions. They encounter the failures that real systems produce: the race condition that only appears under concurrent load, the security vulnerability that passes all tests, the architectural decision that appears correct and creates technical debt at scale. The curriculum is delivered by practitioners who are building production systems with AI tools today and who know from direct experience which foundational understanding is non-negotiable and which syntax details can be safely delegated to AI. If you are building a development career that will be genuinely valuable as AI reshapes what software engineering requires — not despite the reshaping but because you understood it early — Meritshot is where that preparation gets built with the depth and honesty that the moment demands.
Explore the Meritshot Full Stack with GenAI Programme →
This article was written by the Meritshot content team. Meritshot trains professionals in Data Science, AI Engineering, Full Stack Development, Investment Banking, and Cyber Security through hands-on, practitioner-led programmes.
