Lately, I hear more and more early-stage companies shouting into the void for a full-stack unicorn. It makes sense, in the way duct-taping a rocket makes sense when you’re short on budget but big on ambition. Small teams want someone who can wear multiple hats, which sounds feasible until you realise they’re asking one person to simultaneously wear a fire helmet, a chef’s hat, a VR headset, and a tinfoil crown. You can add the unicorn horn on there as well while we're at it.

Thankfully, we now have AI to visualise our metaphors. So instead of imagining this mythical full-stack unicorn, we can actually see how absurd it would be.

Or for companies who want to achieve certain HR KPIs 🌶️ :

This post is an attempt to explore why the idea of a full-stack engineer made sense in the

past and why, in the 2020’s, it often feels like chasing a unicorn. The stack kept growing. The title didn’t. And somewhere along the way, the expectations between developers and business people quietly drifted apart.

As someone who's been building SaaS products since we still had to actually read documentation, I’ve yet to meet someone I’d genuinely call completely full-stack by today's definition. And with the rise of AI, I’m beginning to question whether the term still makes sense or if it ever did.

The product web development role spectrum ™

Whenever I think of a role definition, I have to envision the (my made-up, overly simplified) spectrum in my head. Traditionally, the web-coding spectrum had a fairly clean axis:

And obviously, the term full-stack covered an engineer who could take up the other type of role as well, let's call it his +1. Simple times. “full-stack” meant someone who could grudgingly squint at both sides of that axis and mumble something useful. A back-end dev with a CSS hobby, or a front-end dev who once ran npm run build on a NodeJS server. That sort of thing.

Then reality hit. Suddenly, we needed infrastructure to run things and designers to make things look less like a '90s website. Enter the second non-coding dimension:

Now the +1 got interesting. A back-end dev who set up infrastructure? DevOps Engineer. A front-end dev with an eye for design? No cool name, but probably your startup's favourite person. Still, the rules stayed the same:

  • Rule 1: The spectrum is a spectrum. People lean adjacent to their primary role. A back-end dev doesn’t wander into Figma without supervision. Front-end devs do not SSH into production unless they’ve lost a bet.
  • Rule 2: The stack expanded, but “full-stack” stayed stubbornly two-dimensional. Like naming your kid “Junior” and still calling it that when it’s a 60-year-old senior.

And just when we thought things were getting spicy enough… AI entered the chat.

Stack overflow

The rise of AI didn’t just add complexity; it opened a portal to a new plane of role-based confusion. Suddenly, we needed:

  • Data Scientists: To whisper to the models.
  • Data Engineers: To build the pipes, clean the muck, and somehow scale the whole mess
  • Data Analysts: Because understanding your data might also be interesting.

Add in your classic back-end and infrastructure folks, sprinkle in some UX, and you’ve got a talent matrix so complex it needs its own legend (legend not included):

Here are some of the delightful new +1 combos we’ve invented:

  • Back-end + Data Engineer: The person who speaks fluent API and Spark. Often called an AI Engineer.
  • Data Engineer + Data Scientist: No official title, but always a single point of failure, and usually owns more GPUs than friends.
  • Data Engineer + Ops: MLOps wizard. Talks about Kubernetes the way most people talk about horoscopes.
  • Data Scientist + Data Analyst: Occasionally labelled Data Prophet. Sees numbers. Predicts vibes.

Things are getting complicated. Here's the legend I didn't want to add before.

  • Red: Data Prophet
  • Orange: AI guru
  • Purple: MLOps Engineer
  • Green: AI Engineer
  • Pink: DevOps Engineer
  • Blue: Original Full-stack Engineer
  • Brown: Pixel-Perfect Front-end Engineer

And still, despite this stack madness, we cling to an ancient title relic called Full-stack Engineer and keep stretching it, quietly ignoring the human cost of pretending one person can carry an entire stack.

The full stack discrepancy

Let’s talk about the growing gap between how developers and business stakeholders define the term “full-stack.” As we clarified before, in the past, the title meant something specific. A back-end engineer who could manage some front-end work, or vice versa. A +1 skill, maybe a +2 if you had time and experience on your side.

That was the original full-stack: a primary role with adjacent capabilities. You leaned, but you didn’t stretch.

Fast forward to the present, and the expectations have mutated. Today, “full-stack” is too often code for everything. Back-end, front-end, infrastructure, CI/CD, data pipelines, AI integration, cloud cost optimisation, and—why not—Figma and SEO while you're at it.

Let’s be honest: no one is truly full-stack by that definition. At best, most engineers are 1.2-stack. Maybe 1.4 on a good day, with caffeine and no meetings.

Even the classic full-stack engineers, the ones who used to proudly straddle back-end and front-end, now find themselves mislabelled or overwhelmed. The job they signed up for aged like milk, while the stack just kept growing.

And everyone leans. That’s not a flaw, it’s the reality of having finite time, attention, and brain space. The more hats you stack, the more context-switching becomes its own unpaid role. And no, multitasking isn't a skill. It’s a slow-motion breakdown.

Still, companies keep publishing job descriptions that read like overconfident RPG character sheets:

Looking for a Full-stack Engineer:Must know React, Django, Docker, AWS, Terraform, HuggingFace, Kafka, Figma, magic, and French.

At this point, we’re no longer looking for a unicorn, we’re summoning a Cthulhu. With tentacles in every layer of the stack.

Some folks are calling this profile the Vibe Coder. Using LLMs, any engineer can be everything. I just call it unsustainable.

To be clear: Yes, I believe full-stack engineers exist. The traditional kind who can build a back-end, stitch together a frontend, and maybe wrangle some infrastructure. That’s still a legit and valuable profile. What I don’t believe in is the mythical creature disguised under the same title; the one expected to do everything, perfectly, and solo, while somehow keeping up with a stack that changes faster than most teams can document it.

That’s not a role. That’s a risk.

But I want my Cthulhu

Look, I get it. Budgets are tight. Founders are stressed. The dog’s name is on the team page. You need someone who can ship everything, preferably by tomorrow.

I've written about initial hires for new startups before. Here’s what I recommend instead of trying to birth a mythological beast:

  • If you're building a traditional SaaS (with a bit of AI glued on, like we all have to do for investment's sake):Hire a classic T-shape, full-stack dev (back-end leaning preferred). They can prompt a few GPTs and vibe their way through a dashboard. Later, pay off the AI debt with proper roles.
  • If you're building a data/AI-heavy product:Hire the back-end + data engineer hybrid. You don’t need a data scientist yet. Use LLMs. The UI can be held together with bubblegum, spreadsheets, or low-code tools. But yes, you’ll owe a front-end engineer your soul later.

Honest titles, please

Here’s the actual takeaway.

This post is intentionally opinionated. Not because hybrid engineers don’t exist, and not because “full-stack” was ever a lie, but because the term has been stretched so far that it quietly stopped meaning the same thing to everyone involved.

Full-stack doesn’t mean “knows everything.” It means "can squint at the other side of the stack without immediately panicking." If you’re hiring someone to handle back-end, front-end, infra, data pipelines, and AI… you’re not hiring a full-stack engineer. You’re hiring an entire engineering team with a single login.

Be transparent. Split the role into priorities, actual requirements, and nice-to-haves. Good engineers don’t mind hybrid roles. But they will mind when they realise you expect one person to architect streaming pipelines and then spend the afternoon nudging a button two pixels to the left. That’s not a role, that’s a cry for help disguised as a job posting.

When one role is asked to absorb five disciplines, keep up with a stack that never stops moving, and quietly carry the fallout of burnout and misalignment, the problem isn’t the engineer, it’s the expectation.