For years, software developers have introduced themselves through their technology stack.
- “I am a React developer.”
- “I am a MERN developer.”
- “I work in React Native.”
- “I am a Node.js backend developer.”
Those labels made sense because becoming productive in another framework required a significant amount of learning. You had to understand its syntax, libraries, conventions, project structure, tooling and common implementation patterns before you could deliver confidently. AI coding agents are starting to change that equation.
I do not think frameworks have become irrelevant. But I do think framework knowledge is becoming less important as a professional identity, while engineering fundamentals and experience are becoming more portable. That is a very different claim.
Developers are already using AI outside their familiar areas
The 2026 Stack Overflow Developer Survey gives us a useful signal. Among more than 12,000 respondents, 56% said they use AI to generate code in an unfamiliar area, while almost 50% use AI to understand or onboard to a new codebase. AI is therefore already being used for more than accelerating technologies developers already know. It is helping them cross knowledge boundaries.
OpenAI's case study with Nextdoor shows what this can look like inside a real engineering organization. Nextdoor says engineers are increasingly able to work across systems instead of remaining limited to one framework or area. In one example, a feature that would historically have involved mobile, frontend and backend teams was completed end to end by one engineer using Codex.
That does not mean one person suddenly became an expert in every technology. It means the cost of crossing those boundaries changed.
My own experience changed how I look at framework expertise
I have spent years working with JavaScript, Node.js, React, APIs, databases and backend systems. But some of the most important things I learned about mobile applications did not come from memorizing React Native APIs. They came from repeatedly going through complete product cycles.
As a team lead, I worked through roughly ten mobile projects across different business areas. A development team would create the first version, QA would find issues, the developer would fix them, QA would test again, and eventually we would show the product to the client.
Then something interesting often happened. The client would use the application differently from how we expected.
A layout that appeared logical to the development team would not feel natural to the customer. A workflow that looked complete on paper would need another step. A notification might arrive at the wrong moment. A feature might technically work but still create friction for the user.
Across e-commerce, order management, IoT, healthcare, community applications, chat, notifications and utility apps, those iterations gradually created something much more valuable than framework knowledge. They created pattern recognition.
Eventually, when I started building mobile applications myself, I was not beginning from zero simply because another developer had written the React Native code in earlier projects. I already understood what the product needed to do. AI could then help with implementation.
That distinction matters.
AI can teach syntax much faster than experience can be acquired
Suppose an experienced Node.js engineer moves from a traditional Express backend into NestJS. There are many new things to learn: modules, decorators, guards, dependency injection, DTOs, framework conventions and project structure.
A few years ago, learning those patterns could take substantial time before the engineer became productive. Today, an AI coding agent can explain the framework, inspect its documentation, generate the initial structure, show how an existing Node concept maps into NestJS and help debug mistakes during implementation.
The engineer still needs to understand APIs, authentication, authorization, databases, errors, services, business logic and deployment. But those concepts already transfer.
AI is reducing the price of framework-specific knowledge because much of that knowledge can now be retrieved and applied at the moment it is needed.
The same principle applies when moving from React web development into React Native.
- React knowledge transfers.
- Component thinking transfers.
- State management transfers.
- API integration transfers.
- TypeScript transfers.
But mobile applications introduce their own realities: permissions, app lifecycle, push notifications, device performance, native capabilities, different screen sizes and platform-specific behaviour. AI can help explain and implement those things. Experience helps you recognize when the implementation still does not feel like a good mobile product.
There are really three different kinds of technical knowledge
I find it useful to separate software engineering knowledge into three layers.
1. Engineering fundamentals
These are the concepts that survive framework changes. Architecture, APIs, authentication, authorization, data modelling, state, caching, security, error handling, testing, observability, deployment and business rules belong here. If these concepts are strong, moving between related technologies becomes much easier.
2. Framework knowledge
This is where AI is having the biggest impact. Knowing the exact NestJS decorator, React Native API, TypeScript syntax or library configuration still matters, but developers no longer need to carry every implementation detail in memory. AI can increasingly retrieve, explain and apply those patterns when required.
This does not mean developers should stop understanding the code. It means remembering the syntax is becoming less valuable than understanding why the code should exist.
3. Production experience
This is the hardest layer to replace. Production experience means having already seen unusual user behaviour, strange client requests, security mistakes, scaling problems, failed assumptions, integration issues and features that looked good during development but behaved differently with real users.
AI can describe many of these situations. But reading about ten production problems is not the same as having worked through ten real products. That accumulated judgment remains valuable.
Research suggests expertise still matters
Anthropic recently studied around 400,000 Claude Code sessions to understand how people actually work with coding agents. One of the most interesting findings was that people generally made more of the planning decisions while Claude made more of the execution decisions. More importantly, greater domain expertise was associated with better outcomes, and people with more expertise could get more useful work from the agent per instruction.
That matches my own experience. The more clearly I understand what the system should do, the more effectively I can use an AI coding agent.
If I understand the architecture, I can tell whether the suggested implementation belongs in that architecture. If I understand the business workflow, I can tell whether technically correct code actually solves the requirement. If I understand security, I can recognize when an AI-generated shortcut introduces unnecessary risk.
AI does not remove expertise. It gives expertise more leverage.
The role of the experienced developer is changing
GitHub recently described three skills becoming increasingly important as AI changes software development: directing AI agents, critically reviewing their output and keeping technical judgment at the centre of the workflow. That is an important change.
Historically, a developer could differentiate themselves partly by knowing a framework extremely well. They remembered its APIs. They knew its project structure. They could type common patterns quickly.
Those skills still have value, especially for difficult platform-specific problems. But AI is reducing their scarcity.
A developer who understands the underlying engineering problem can increasingly ask an agent to bridge the implementation gap. The difficult part becomes deciding whether the result is correct.
This does not mean every developer can build in every technology
There is an important boundary to this argument. I would not automatically assume that a JavaScript engineer can take any deeply specialized .NET, Java, embedded or low-level systems project and immediately perform at the level of an experienced specialist simply because AI is available.
The farther we move from our existing knowledge, the more our ability to review the agent becomes weaker. That matters. An engineer should be able to answer a simple question:
If the AI makes a subtle mistake, do I understand the system well enough to recognize it?
If the answer is no, AI assistance alone is not enough. This is why I see the biggest change today within related technology ecosystems.
- Moving from Express to NestJS.
- Moving from JavaScript to TypeScript.
- Moving from React to React Native.
- Moving from one database or ORM approach to another when the engineer already understands data modelling.
These transitions still require learning, but AI can compress the learning curve dramatically.
Locally correct code can still be wrong for the system
Thoughtworks recently described a problem that becomes more important as developers rely more heavily on coding agents. An agent can produce code that looks clean, compiles and appears correct inside the file or module it is working on, while the change is still wrong for the wider system.
Without architectural context and verification, AI can accelerate architectural drift rather than reduce it. This is another reason why architecture becomes more valuable as framework knowledge becomes cheaper. Someone still needs to understand how all the pieces fit together.
The developer of the future may be less stack-specific
I do not think the future belongs to developers who know nothing about frameworks. I think it belongs to engineers who are less dependent on one framework for their professional identity.
Instead of saying: “I am a NestJS developer.” The stronger identity may become: “I design reliable backend systems, and NestJS is one implementation option.”
Instead of: “I am a React Native developer.” It may become: “I understand mobile product engineering, and React Native is one way I currently deliver it.”
That change sounds subtle, but professionally it is significant. The technology becomes a tool. The engineer's value increasingly comes from understanding the system.
So what should experienced developers invest in?
If AI can increasingly help with syntax and framework implementation, I would spend more time strengthening the skills that transfer.
- Learn architecture.
- Understand APIs deeply.
- Understand databases and data modelling.
- Learn security.
- Understand state and concurrency.
- Understand how systems fail.
- Work through production incidents.
- Learn how users actually behave.
- Participate in QA.
- Listen to client feedback.
- Understand why the business needs the feature before deciding how to implement it.
Those skills travel surprisingly well between technologies. And AI makes them even more valuable because they allow you to direct the implementation rather than simply follow it.
Frameworks still matter. They just matter differently.
I would not tell a developer to stop learning React, React Native, NestJS, Next.js or any other technology. You still need enough knowledge to understand what the framework is doing and to review what AI produces. But I would stop building my professional identity around remembering one framework better than everyone else.
AI is steadily reducing the value of memorized implementation knowledge. At the same time, it is increasing the leverage of engineers who understand products, architecture and systems.
That leads me to a simple conclusion:
AI can make engineering experience more portable, but only when there is real engineering experience to carry across the boundary.
The framework still matters.
The engineer matters more.
