The stack is no longer the job
For a long time, software engineers were hired for a stack. "React developer", "Java backend engineer", ".NET developer", "Rails person". The job description was the technology, and the career was a slow accumulation of depth in that one ecosystem.
That model made sense when most of an engineer's day was spent producing code by hand. Knowing a framework's idioms, its quirks and its tooling inside out was a real productivity advantage, and switching stacks meant months of being slow again.
AI changed the economics. Coding agents now write the boilerplate, know every framework's conventions, and translate a pattern from one language to another in seconds. The part of the job that was tied to a specific stack — remembering syntax, wiring libraries, following framework recipes — is exactly the part AI does best.
What is left for the engineer is the part that was never about the stack: understanding the problem, choosing the right technology for it, designing the system, and verifying that what got built is correct and valuable. That is the job now.
Why companies need multi-stack engineers
Companies do not have one stack. They have a history.
Existing projects. Every company with more than a few years behind it runs systems built in whatever was reasonable at the time: a PHP monolith that still handles billing, a Java service that everyone is afraid to touch, a React app from three redesigns ago, a Python data pipeline someone wrote before they left. These systems are not going away, and the business depends on them. Someone has to be able to walk in, understand them and improve them — regardless of the language.
New projects. When a company starts something new, the ideal technology is rarely "whatever the team already knows". A real-time feature may call for a different runtime than the CRUD app. A data-heavy product may belong in Python. A latency-critical service may justify Go or Rust. An internal tool may be best served by a fast full-stack framework. A team that can only work in one stack picks the tool it knows instead of the tool the problem needs — and pays for that decision for years.
The cost of one-stack teams shows up everywhere: features built on the wrong foundation, rewrites nobody wanted, hiring bottlenecks because every opening needs "5 years of X", and knowledge locked in the two people who still understand the legacy service.
Companies need engineers who can move between these worlds: join an existing codebase in any technology and contribute quickly, or start a project from zero in the stack that fits the problem. Not because they have memorised every framework, but because what they know transfers.
What makes stack-switching possible
Switching stacks is not a matter of learning more syntax. It is a matter of having the layer above syntax solid enough that the syntax becomes a detail. Three things make up that layer.
1. Software architecture fundamentals
System design, data modelling, API design, object-oriented and domain design, the trade-offs of consistency, resilience and cost — none of these belong to a language. A well-designed service boundary is well designed in Java, TypeScript or Go. A bad data model is bad in Postgres, MongoDB or DynamoDB.
An engineer with strong fundamentals reads an unfamiliar codebase by looking for the architecture, not the syntax: where the boundaries are, how data flows, what the failure modes are. That is what lets them become useful in a new stack in days instead of months.
2. Product engineering
Knowing what to build and why is what lets you choose how. An engineer who understands the problem, the user, the metric that matters and the constraints of the business can evaluate technologies on their merits: does this stack get us to a validated product faster? Does it fit the team we will have in a year? Does it scale for the load we will actually see, not the load we imagine?
Product thinking turns "which stack do I know?" into "which stack does this problem deserve?" — and gives the engineer the ownership to see the decision through to an outcome.
3. Working with AI
This is the piece that makes the first two sufficient. Coding agents close the gap between knowing how a system should be built and knowing the exact incantation in a given framework. The engineer supplies the design, the constraints and the acceptance criteria; the agent supplies the framework-specific implementation; the engineer verifies it.
That only works if the engineer can actually judge the output. Directing an agent through a Django codebase you have never seen still requires knowing what a good migration looks like, what a sane transaction boundary is, and when the generated code is subtly wrong. AI multiplies the fundamentals — it does not replace them.
The AI multi full-stack engineer
Put the three together and you get a new profile: the AI multi full-stack engineer. Not "full-stack" in the old sense of "front-end and back-end in one framework", but full-stack across stacks — able to take a problem end to end in whatever technology it calls for, using AI to be as productive in an unfamiliar ecosystem as they are in a familiar one.
On a given Monday, this engineer can:
- Pick up a legacy Java service, map its architecture, and ship a safe change with agent-generated code they have reviewed and tested.
- Spin up a new product MVP in Next.js and Postgres because that is the fastest path to validating the idea.
- Add an LLM-powered feature to a Python backend — with evals, guardrails and cost control, not just a prompt.
- Design the API contract between two teams' services and defend the trade-offs in a review.
- Decide that the new real-time module should not be in the company's default stack, and explain why in terms of the product's metrics.
Their value is not the number of frameworks on their CV. It is the ability to make the right technical decision for each problem and execute it in the right technology.
How to build them
You cannot train this profile by sending engineers to another framework course. Courses teach syntax, and syntax is the cheap part now. The skills that transfer — architecture, product judgment, working with AI — are built by practising them on real problems, getting specific feedback, and doing it again.
That is exactly what Archicise is designed for:
- Exercises across the three disciplines — system, database and API design, object-oriented and domain design, product discovery and scoping, agent and LLM application architecture — stated as real-world problems, independent of any language.
- AI coaching on every submission — specific, actionable feedback and a score, so engineers know what to improve and not just that they were wrong.
- Visibility for the company — a dashboard of activity and progress per engineer and per discipline, so you can see the flexibility being built and invest where it matters.
The engineers who will define the next decade are the ones who can walk into any codebase, start any project, and use AI to ship the right thing in the right stack. Companies that build teams of them will move faster than those still hiring for a framework.
If you want your engineers to be that kind of engineer, register your company and start practising today.