What it means to be a full stack engineer in the AI era

I started shipping production software in 2019, writing React Native apps and Laravel backends at Dominion Global. Since then I have shipped 50+ products, moved through full stack roles, and now lead a team of seven-plus engineers. Over the same stretch, the job of a full stack engineer has changed more in the last couple of years than in the four before. AI writes a growing share of the code. The question worth asking is what the full stack engineer in the AI era is actually responsible for.

My answer: the same things as before, at a higher level, with less typing.

How the role grew for me

Looking back, each step widened what I owned.

• 2019 to 2021, Dominion Global. React Native and Laravel. I learned to ship mobile apps and the APIs behind them.
• 2021 to 2022, Potato Logics. Full stack, owning a marketplace end to end. I provisioned the AWS infrastructure from scratch and kept it at 99.9% uptime. This is where "full stack" came to mean infrastructure too, as well as frontend and backend.
• 2023, Logical Creations. I solo-built a hospital SaaS, a property marketplace and a prayer app. Being the only engineer on a product teaches you every layer, because nobody else is there to own it.
• 2023 to now, my current team. Senior Engineer, promoted to Team Lead. I own backend, infrastructure and CI/CD, and I drove our adoption of Spec-Driven Development.

Along the way: Buffdudes, a fitness platform with 60K+ users where I built the backend solo, a multi-tenant hospital system, offline-capable point of sale software, Flutter apps with Node.js backends, and more recently AI products. The projects page has the longer list.

The common thread is that the job kept moving up a level: from writing screens, to owning features, to owning systems, to owning how a team builds systems.

What AI changed

AI coding assistants and agents are now good at a lot of what used to fill a full stack engineer's day: route handlers, form components, migrations that follow a pattern, test scaffolding, glue code between two APIs. On a well-specified task, an agent can produce a working first draft in minutes.

That shifts where the time goes. Less of it is spent producing code. More of it is spent on:

• Deciding what to build. Turning a vague request into a clear spec with edge cases.
• Giving agents the right context. Conventions, architecture, which existing module to follow.
• Reviewing. Reading generated code with the same rigour as code from a colleague.
• Verifying. Running the thing, reading the query plan, checking the failure paths.
• Owning the system. Knowing how the pieces fit, what breaks under load, and what a change will touch.

None of those got easier. Several got more important, because an agent can generate a lot of plausible code very quickly, including code that is wrong in ways that only show up in production.

Specs became the main interface

The single biggest change in how I work is that the spec is now the main thing I write. Spec-Driven Development started as a way to cut rework on my team. With AI agents in the loop, it is also how you get good output from them. An agent given a clear spec with inputs, outputs, edge cases and acceptance criteria produces far better code than one given a sentence.

REQ Agent, a CLI I built, takes this further. It reads raw client discovery material and generates client, designer and developer handoff documents through two sequential model calls, then validates the documents for structure, feature coverage and design-to-dev token consistency before writing them. It is SDD turned into a tool.

Conventions became infrastructure

The second change: team conventions used to live in a wiki and in senior engineers' heads. Now they need to be readable by agents too.

My team's conventions are served to AI coding agents from a conventions server (an MCP server), grouped by platform: backend, frontend, Flutter, integrations and shared. It carries rules like spec-first development, branch-per-spec naming, the PR workflow and comment style. An agent working in any of our repos reads the same rules a new engineer would. I wrote about the approach in making team conventions machine-readable for AI agents.

The same server includes guidance on Marionette, which lets an agent drive a Flutter app running in debug mode to test it: tapping, entering text, taking screenshots and reading logs. That covers testing as well as writing. More on that in letting an AI agent test your Flutter app.

What still makes someone senior

If AI can write most of the code, what separates a senior full stack engineer from someone prompting an assistant? In my view, the same things that always did:

• Judgement about tradeoffs. Background job or inline call. Cache or query. Ship now or fix the foundation first.
• Knowing where things break. Slow queries, N+1s, race conditions, migrations that lock tables, timeouts between a load balancer and a long request.
• Breadth across the stack. Frontend, backend, mobile, database, infrastructure, CI/CD. AI features touch all of them, and someone has to see the whole path.
• Taste in scope. Cutting a feature down to what users need and what can be shipped well.
• Accountability. If it ships under your name, you can explain every line, whoever or whatever typed it.

These are the skills that let you direct AI well. Without them, an assistant just helps you produce mistakes faster.

The short version

Being a full stack engineer in the AI era means owning the whole system while writing less of the code by hand. The work moves toward specs, context, review and verification, and toward conventions that agents can read. The fundamentals I learned shipping React Native apps and Laravel backends in 2019 still matter; they now decide how much value you get out of the tools.