AI Redraws Responsibility Boundaries: The New Full-Stack Isn't About Doing Everything Alone

I have worked in development for many years, witnessing teams shift from full-stack development to frontend/backend separation, and now back to an emphasis on full-stack.

Over a decade ago, many projects did not strictly distinguish frontend and backend. One developer wrote pages, services, and databases. Larger organizations might have dedicated DBAs, but most application development was done by the same person.

Later, frontend/backend separation became mainstream. Frontend handled pages, interactions, and state; backend handled business logic, data, and RESTful APIs. Integration testing occurred via interfaces. When tests found issues, they were routed to different people based on whether the problem lay in the page, the interface, or the data.

In the last year or two, as AI coding capabilities have rapidly improved, some teams have started emphasizing full-stack development again, reducing fixed boundaries between pure frontend and pure backend roles.

It appears teams have completed a cycle. Is this really "divide long enough, merge long enough"?

I prefer to interpret it as: AI enables execution capabilities to cross role boundaries, so team division of labor must shift from splitting by technical layer to organizing collaboration around complete business capabilities.

From a software engineering perspective, today's "return to full-stack" is not a return to ten years ago, but a reconstruction of responsibility boundaries.

This Isn't "Divide Long Enough, Merge Long Enough"—Collaboration Costs Changed

Whether a team should specialize or consolidate fundamentally depends on two costs: the benefits of specialization and the collaboration costs between roles.

Early web systems were relatively simple; one developer could hold the full context and complete most implementation. The benefits of fine-grained roles did not outweigh handoff costs.

As frontend engineering, mobile, distributed systems, and cloud infrastructure evolved, each direction required continuous accumulation. When specialization benefits exceeded collaboration costs, frontend/backend separation naturally became mainstream.

AI now changes this balance again.

An engineer familiar with the business and system design can use a model to complete pages, interfaces, migrations, and tests. However, requirements interpretation, task scheduling, interface waiting, and issue handoff do not disappear just because code generation is faster. The shorter the execution time, the higher the proportion of collaboration costs in the delivery cycle.

Therefore, today's renewed discussion of full-stack is not because frontend and backend have become simple again, but because AI lowers the cost of cross-stack execution, making the old pipeline-style division feel increasingly heavy.

AI Lowers Cross-Language Implementation Cost, Not Professional Judgment

Large models are shrinking the distance between programming languages and frameworks. Engineers no longer need to memorize all APIs and syntax details before implementing features. But this does not mean technical fundamentals have lost value.

Models can generate runnable code, yet cannot automatically guarantee correct transaction boundaries, safe concurrency conditions, consistent page state, acceptable query performance, or assume responsibility for security, cost, and production incidents.

AI lowers the cost of "writing code," but does not eliminate these problems:

What business problem the requirement actually solves;

How system boundaries, state, and rules should be defined;

Which technical trade-offs and risks are acceptable;

What evidence verifies the result, and who owns it after launch.

Therefore, programmers can stop treating a single language as their entire competitive advantage, but they still need to understand enough technical principles to judge whether a model's implementation is trustworthy.

New Full-Stack Isn't One Person Doing All Work

The AI-era new full-stack is more accurately "full-cycle responsibility": an engineer uses AI to cross technology stacks and takes a well-bounded business capability from requirements understanding, solution design, code implementation, all the way through verification and delivery.

The "old full-stack" referred to here is not denied its rationality in early simple systems; rather, it refers to demanding that one person handle every aspect in today's system complexity.

The two look similar but have different cores:

Being able to generate frontend code does not equal the ability to govern complex frontend engineering long-term; being able to generate tests does not equal possessing quality judgment. Frontend experience, databases, security, architecture, and quality assurance capabilities do not disappear—they just no longer serve as fixed gates, instead intervening based on risk.

Teams Should Organize Around Business Capabilities, Not Technical Layers

Traditional teams usually break requirements into product, frontend, backend, and test tasks. A more sensible approach in the AI era is to first define a complete, verifiable business capability, then decide who owns it and what professional capabilities are needed.

"Business result" here cannot be a vague metric an engineering team cannot independently control. It should be a responsible, verifiable outcome—for example, completing a business flow, reducing a certain operation's failure rate, shortening a processing step, or delivering a business capability that meets explicit acceptance criteria.

How exactly to form teams should depend first on task complexity and risk, then on personnel maturity to determine authorization scope.

Task complexity: how many objects, systems, and upstream/downstream relationships are involved;

Task risk: whether failure is reversible, whether it involves funds, privacy, security, and compliance;

Personnel maturity: whether the owner can understand the full context and judge AI output.

The first two factors determine how many roles, checkpoints, and professional capabilities are needed; personnel maturity determines who can take end-to-end responsibility and which decisions must be escalated.

Low complexity, low risk : Completed end-to-end by a mature engineer assisted by AI

High complexity, low risk : Form a small business capability team, coordinated by one person with rapid iteration

Low complexity, high risk : Execution can be centralized, but retain professional review, independent verification, and launch confirmation

High complexity, high risk : Cross-functional team collaboration with design baselines, checkpoints, and escalation mechanisms

Take "user applies for refund" as an example. The traditional approach would sequentially split it among product, frontend, backend, and test. Refund conditions, order state, payment result, and exception compensation required multiple handoffs to close the loop.

In the AI era, a mature engineer can own the complete result: first clarify state, amount, idempotency, compensation, permissions, and audit requirements, then let AI assist with frontend, backend, data migration, and automated tests.

But because refunds involve funds, payment and business experts must still check state, idempotency, and reconciliation rules; QA must independently verify duplicate submission, timeout, concurrency, and compensation paths. The change is that one person drives the closure, not that professional judgment and launch gates are removed; the number of participants and depth of professional involvement are still determined by the task, not by the old role structure.

Role Boundaries Can Blur, Four Responsibilities Must Not Disappear

After roles merge, the most dangerous state is not that someone lacks technical breadth, but that everyone can do a little, yet no one owns the final result.

In my practice, at least four responsibilities must be explicit.

Execution can be done by the same person crossing boundaries, but these four responsibilities cannot become ownerless just because roles are reduced. The higher the task risk, the more professional judgment and verification must remain independent.

This Doesn't Contradict Multi-Role Collaboration

In my actual development, architecture, development, and test are different roles, but they don't necessarily correspond to three fixed positions. The same engineer can handle frontend and backend implementation, and can also combine design and development in low-risk tasks, but design baselines, implementation artifacts, and verification evidence must still be separated.

High-risk tasks must deliberately keep certain roles independent: the development role cannot change business rules for implementation convenience; the test role cannot simply trust the developer's conclusions. The value of multiple roles is not to maintain old positions, but to avoid mixing problem definition, professional judgment, implementation, and verification into an untraceable process.

Testing Won't Disappear—It Shifts from Executing Cases to Independent Verification

AI-generated code often looks structurally complete and logically sound. If tests are also generated by the same model from the same context, they may repeat the same erroneous assumptions. Code and tests passing together does not mean business rules are correct.

Therefore, QA must establish a verification baseline independent of the implementation process:

BDD scenarios must start from business rules and acceptance criteria, using Given - When - Then to cover normal flows, boundary conditions, and exception paths; contract tests are responsible for checking API, permission, and idempotency constraints, and verifying timeout, retry, concurrency, and partial failure; build, migration, interface, and end-to-end tests must execute in independent CI, test containers, or integration environments and leave auditable evidence—not accept AI's own "tests passed" output.

Testers' repetitive execution work may decrease, but they will take on more acceptance criteria design, risk analysis, and independent evidence gathering. The more code AI generates, the more critical this defense line becomes.

Programmers' Real Competitiveness Is Changing

As AI coding gets stronger, what is a programmer's core competitiveness? My judgment: the value of purely translating requirements into code will decline, while the ability to form correct judgments on complex problems will become more important.

This capability includes at least:

Understanding the business, turning vague requirements into objects, flows, rules, and boundaries;

Making trade-offs among cost, performance, security, experience, and evolution;

Decomposing complex goals into tasks that AI can execute and verify;

Reading, debugging, and reviewing model-generated code, and owning the results.

AI amplifies a person's ability, but also amplifies their cognitive gaps. The stronger the requirements understanding and system design ability, the better one can turn the model into an engineering lever; lacking basic judgment only yields more code that looks complete but cannot be maintained long-term.

Senior and Junior Engineers Must Not Become a New Assembly Line

An arrangement that looks reasonable is: senior engineers design, junior engineers call large models to develop according to documents. This may work short-term, but cannot become a fixed structure.

If all problems wait for senior decisions, seniors become a new bottleneck; if juniors only hand documents to models long-term, they struggle to develop requirements understanding, system design, and quality judgment abilities. A more realistic problem: a person lacking judgment cannot reliably accept AI output that exceeds their own capability range.

A more reasonable way is to let engineers of different maturity own closed loops of different scope and risk: junior engineers start with smaller, low-risk loops; mature engineers own bounded business capabilities, driving from design to delivery end-to-end; senior engineers handle complex design, high-risk decisions, standards building, and key reviews.

AI may reduce total team headcount, but the team's dependence on senior capabilities will not decrease; senior capability density within the team may actually increase. The real difficulty is that the old path of growing junior engineers through large volumes of coding tasks is narrowing, and teams must redesign their growth mechanisms.

Summary

AI will not make software engineering lose division of labor, but it will make the old role-based division gradually obsolete.

In the past, teams mainly split work by frontend, backend, test, and ops; in the future, teams will more often organize delivery around a complete business capability, driven by people who can execute across boundaries to close the loop, while professionals guard key judgments, risks, and quality baselines.

So, the "return to full-stack" in the AI era is not about requiring everyone to master all technologies, nor simply merging frontend, backend, and test into one role, but about a responsibility shift for engineers:

1. From "I am responsible for which technical layer",
2. To "I am responsible for which business capability and delivery result".

Technology stacks can be crossed with AI's help; responsibility boundaries must be clearer than ever.