Full-Stack Engineer

You ship features end-to-end. The agent writes the code; you architect, you specify, you validate, and you own the outcome. You move fast across the full stack because the agent doesn't have stack preferences — and you have stopped having them too.

Elevationprimary Convergencesecondary Emergencepartial

Family

Engineering

Equivalent legacy role

Full-Stack Engineer, Senior Software Engineer, Staff Engineer (IC track)

Reports to

Tech Lead, Engineering Manager, or Director of Engineering

Works alongside

Tech Lead · Product Designer · Product Manager · Agent Supervisor

The work

You ship features. End-to-end means end-to-end: data layer, API, frontend, tests, deployment, observability. Not because you do all of it personally, but because you own the outcome and the agent handles whichever layer the work needs.

Day-to-day, you:

Specify features completely. Acceptance criteria, edge cases, data implications, UX behavior, risk classification, validation gates. The specification is the artifact that lets the agent execute without real-time supervision.
Run clarification dialogues with the agent before execution. You answer the questions that resolve genuine ambiguity, defer the ones that should be answered during implementation, and reject the ones that signal your spec was vague.
Architect at the feature level. Data model decisions, API shape, component boundaries, dependency choices — yours to make, the agent's to implement.
Review agent-produced PRs. At T2, line-by-line. At T3, at the diff and behavior level. You look for the missing case, the wrong abstraction, the silent breakage — not for typos.
Validate at risk-graded gates. Sampling for reversible changes. Direct approval for irreversible ones. You design the gates for your features as you specify them.
Recalibrate when stories stall. The wrong implementations are usually a symptom of a wrong spec or wrong context. You diagnose, re-spec, and resume — instead of debugging the agent's output.
Maintain the codebase context. Shared prompt templates, context files, house-style guides, scenario libraries. These are first-class artifacts; you contribute to them and use them.
Own observability for what you ship. Telemetry, alerts, error budgets. You design these into the spec; the agent implements them; you verify the signal is real.
Pair with adjacent engineers on cross-stack decisions. The agent absorbs much of what used to require specialist hand-offs, but human judgment is still better in pairs.

What success looks like

Concrete outputs at this tier:

Throughput. You ship features in days, not sprints. Stories complete (spec → implement → review → merge) in hours-to-days for typical work.
Quality. Defects in production from your features are rare and trending down. The agent reviewer catches what you would have caught manually; your interventions catch the rest.
Cost discipline. Token spend per merged PR is tracked. Cost-per-outcome is improving over time, not just absolute throughput.
Cross-stack work. You ship features that touch frontend, backend, and infrastructure in the same week. The agent handles whichever layer; you handle the judgment.
Codebase health. Refactoring is happening, technical debt is paid down, the codebase ages well rather than ossifying.

What does not count as success: lines of code shipped, PR count, hours logged, sprint velocity points that don't translate to user outcomes.

What makes this work interesting

The interesting part of the work is not the speed — it's what becomes possible at that speed.

You ship faster than you thought possible. What used to take you a sprint takes a day. The feature you specified Tuesday morning is in production Wednesday afternoon. The feedback loop with the user closes within the week, and you feel it.

Full-stack becomes natural. You stop having stack preferences because the agent doesn't have any. You move fluidly between data model decisions, API design, and UX behavior because the friction of context-switching across the stack has dropped to near zero. The reward is genuine breadth of scope.

You design more, you type less. Most of your craft now lives in specification and architecture decisions, not in the typing. For engineers who got into the work because they loved the design part more than the typing part, this is a return to what was fun.

The hard problems are the satisfying ones. Wiring up another CRUD endpoint takes minutes. The problems left for you are the ones that need judgment — getting a state machine right, choosing the boundary between two domains, deciding what to test and what to trust. These are the problems that distinguish senior engineering from junior engineering, and they are the bulk of what's left.

You collaborate with another agent, not just other humans. Working with a capable agent is its own skill — different from pair programming, different from solo work. The clarification dialogues are interesting in their own right. The recalibration sessions are interesting in their own right.

You see your work in the world quickly. Features in production within hours of specification means your sense of agency in the role is stronger than it has been for most senior engineers in years. The lag between thought and impact has compressed.

What may not appeal. You write less code by hand. The hours-of-deep-focus-coding flow state happens less often, and when it does, it tends to be in unusual places (recalibration sessions, infrastructure work the agent can't yet do well). The boundaries between "your work" and the agent's blur — if your craft identity is rooted in producing the artifact personally, that identity will have to migrate. Some engineers find a deeper version of the satisfaction in the new work; some don't. Be honest with yourself about which kind of engineer you are.

Who thrives in this role

The aptitudes that matter most at T3 are different from the ones that defined senior engineering pre-AI.

You think before you type. Speed of typing has stopped mattering; quality of thinking up-front matters a lot. You pause to consider edge cases before specifying; you don't pattern-match and dive in.

You write clearly. Specifications are writing first, coding second. People whose written reasoning is fuzzy write fuzzy specs and get fuzzy outputs.

You're comfortable being responsible for outcomes you didn't personally produce. The agent wrote the code; you signed off; if it fails, you own that. People who can hold that accountability without micromanaging the agent thrive.

You handle messy diagnosis well. When a story stalls, the cause is usually in the spec or the context, not in the code. The detective work — figuring out which assumption broke — is part of the craft now. People who enjoy this find the work rich; people who want clean problems with clean answers struggle.

You have taste. When the agent produces three plausible implementations, you can tell which one is right for this codebase. Taste is hard to interview for and harder to teach, but it is the single most durable advantage at T3.

You care about systems, not just features. Features ship and ship and ship. The engineers who thrive over time are the ones who pay attention to how the codebase ages, what patterns recur, what the next architectural decision needs to anticipate.

Less essential than before: raw coding speed, algorithm trivia, language pedantry, the ability to hold five files in your head at once. These were the markers of senior engineering pre-AI. They still help. They are no longer what differentiates the role.

Skills to develop to get there

The aptitudes above describe disposition. The skills below are what you actively build.

Specification engineering. Writing specs an agent can execute end-to-end. Acceptance criteria, edge cases, risk classification, validation gates. How to practice: write the spec before any code, even for small tasks. Reread your specs a month later; the ones that aged badly are your learning material. See the Specification Guide.

Diff-level review judgment. Reading agent output to spot the missing case, the wrong abstraction, the silent breakage — without reading every line. How to practice: review AI-generated PRs from your team. Articulate why you'd push back. Track the pushback that turned out to be wrong; that's where your judgment is miscalibrated.

Recalibration vs debugging diagnosis. When work stalls, knowing whether the issue is in the spec, the context, or the implementation. How to practice: keep a short journal of stuck stories. Classify each post-mortem as recalibration (spec/context issue) or debugging (implementation issue). Track which interventions actually unblocked.

Risk classification. Distinguishing reversible from irreversible work and assigning the right validation gate. How to practice: for every story you spec, name the gates explicitly. Justify why. Adjust as you learn from misclassifications. See AI Execution Standards.

Cross-stack judgment. Making sound decisions outside your historical specialty. Convergence at T3 means a senior engineer with a backend background may now own user-facing features end-to-end. How to practice: read PRs in adjacent areas (frontend, infra, data). Notice what you find confusing — the gap is your learning surface. Pair with the person whose specialty it used to be.

Clarification dialogue craft. Productive Q&A with the agent before execution. Knowing which questions to answer fully, which to defer, which signal a fuzzy spec. How to practice: notice the questions an agent asks before implementing. Categorize them. The categorization will show you where your specs need work.

Context curation. Maintaining the shared prompt templates, context files, and scenario libraries that the team's agents draw from. How to practice: contribute one improvement per sprint. The artifacts compound; small contributions matter.

Pick one skill, practice it for two weeks on real work, and notice how your relationship to the role shifts. Trying to develop all seven at once is the most common failure mode.

How this differs from the legacy Senior Engineer role

Legacy Senior Engineer (pre-AI)	Senior Engineer (AI-native)
Writes complex code yourself; reviews other people's	Writes specifications; reviews agent output at risk-graded gates
Specializes in frontend or backend or infrastructure	Operates across the full stack because the agent does
Spends 50-70% of time coding	Spends under 20% of time coding
Throughput limited by individual focus hours	Throughput limited by specification quality and review judgment
Hand-offs to specialists for cross-stack work	Pairs with specialists on judgment, ships across stack solo
Best engineers are the fastest, most prolific producers	Best engineers are the clearest specifiers and the most discerning reviewers
Tests written line-by-line by humans	Test scenarios specified by humans, written by the agent, reviewed by humans

The role is not a rebranded "senior". The day-to-day is structurally different.

Which role evolution patterns are in play

Elevation (primary). The role's center of gravity moves from execution to specification and validation. Value migrates from typing speed to specification quality and review judgment.
Convergence (secondary). Boundaries between frontend, backend, and infrastructure blur. One senior engineer with strong judgment can direct the agent across the full stack on a feature that previously required three specialists' coordination.
Emergence (partial). Some responsibilities are genuinely new: clarification dialogues with agents, recalibration sessions, agent reviewer configuration contributions.

Specialization and Absorption do not meaningfully apply: the role expands rather than narrows, and does not contract or disappear.