← Back

So why aren't you full stack?

A few months ago I hit a bug that started in the frontend, ran through an API layer, and then went off into the backend where it was needing some attention. In a traditional setup, that's three different people's problem. A frontend engineer notices the symptom, files a ticket, a backend engineer investigates the API, realises it's a data issue, files another ticket, and eventually someone with database access looks at the query. By the time the fix ships, a week has passed and the context has been handed off twice.

Now I tend to want to fix things straight away when I can, so I just followed the problem from frontend to API to database. Fixed the query, updated the API response, adjusted the component. Took an afternoon.

Two years ago, the backend being in a language I was less familiar with would have stopped me from following the problem all the way through. I'd have had to ask someone else to look at the query. Not anymore. The tools have changed enough that working across the full stack isn't a specialist skill. It's becoming the default for anyone who cares about shipping the right thing.

The old split

For a long time, the industry treated "full stack" as a specific role. You were either a frontend engineer, a backend engineer, or a full stack engineer who was supposedly decent at both but great at neither. The advice for early-career engineers was almost always to specialise. Go deep. Become the person who really understands one layer.

That advice made sense when the cost of working outside your area was high. Learning a new framework, understanding a different paradigm, getting productive in an unfamiliar codebase, all of that took real time and effort. Specialisation was efficient because context-switching was expensive.

What LLMs changed

That cost has dropped dramatically. Not to zero, but enough to change the calculation entirely.

If I'm working on a frontend feature and I need to adjust an API endpoint, I don't need to have the backend framework memorised. I need to understand the shape of the problem well enough to ask the right questions, and the tooling helps me get from "I think this is the issue" to "here's the fix" much faster than before. The same applies to database queries, infrastructure config, deployment scripts, whatever layer the problem lives in.

This isn't about LLMs replacing expertise. Deep knowledge still matters enormously for system design, performance optimisation, and the genuinely hard problems. But for the majority of day-to-day product work, the barrier to crossing layers has collapsed. You can be productive in areas that used to require months of ramp-up.

You still need a captain steering the ship (for now)

This shift doesn't just mean engineers can do more. It means the engineers who think about the product, the ones who care about user outcomes and not just code quality, can now act on that thinking across the full surface area.

A product-minded frontend engineer who spots a data model problem doesn't have to write a detailed ticket and hope someone else understands the nuance. They can go fix it. A backend engineer who realises the API response structure is making the UI awkward doesn't have to file a suggestion and wait for the next sprint. They can adjust both sides.

The handoff has always been where context dies. Every time a problem moves from one person to another, something gets lost. The original insight, the urgency, the understanding of why this matters. When one person can follow a problem end to end, that context stays intact.

Product-minded engineers have always had the instinct to follow the problem. Now they have the tools to actually do it.

What this looks like in practice

It's not about becoming an expert in everything. It's about being comfortable enough across the stack to:

The key word is "sensible." Nobody's saying a frontend engineer should redesign the database schema. But adjusting a query, adding a field to an API response, tweaking a deployment config? That's all within reach now for someone with the right instincts and decent tooling.

The bigger shift

I think this changes what it means to be an engineer. The role used to be defined by breadth of thinking, seeing the product holistically, understanding users, connecting business needs to technical decisions. But the execution was still constrained by whatever layer you happened to specialise in.

That constraint is loosening. Product engineers can now match their breadth of thinking with breadth of execution. If you understand the full picture of what needs to happen, you can increasingly make it happen yourself, across whatever layers are involved.

This doesn't make specialists less valuable. Complex systems will always need deep expertise. But for the product-minded engineer who wants to ship the right thing, the era of "that's not my layer" is fading. And I think that's a good thing.