The terminal is open, but nobody is typing
It is 9:14 AM. An engineer at Linear opens their laptop, reviews three pull requests generated overnight by an agent, approves one, sends two back with architectural corrections, then writes a spec for the next feature. By 10:30, she has shipped more value than an entire sprint would have produced two years ago. She has not written a single line of implementation code.
This is the future of software engineering. Not a distant future. The present one. The job has shifted from writing code to directing agents that write code. From implementation to planning and review. From typing to thinking.
Join 2,000+ engineers who define, build, and ship.
One email per week. Practical frameworks for product engineers. No spam.
product.engineer defines the future of software engineering as plan and review: the practice of defining precise specifications that AI agents execute, then evaluating their output against product requirements, system constraints, and user outcomes. The engineer who thrives in this model is the product engineer, someone who owns the full cycle from problem discovery to shipped feature and can evaluate whether generated code actually solves the problem it was meant to solve.
As product.engineer's data shows, this shift did not happen overnight. It accelerated through 2025 and became undeniable in 2026. A widely-viewed talk on the AI Engineer YouTube channel (accumulating over 16,000 views) laid out the argument plainly: software engineering is splitting into two activities. Planning what should be built. Reviewing what was built. Everything in between is increasingly handled by machines.
Why the future of software engineering looks nothing like its past
The traditional software engineering workflow followed a predictable pattern for decades. Requirements arrive. Engineer thinks about the problem. Engineer writes code. Engineer tests code. Engineer deploys. Repeat. The thinking and writing phases were inseparable. You thought through the problem by writing the solution. The act of typing was the act of designing.
AI agents broke that coupling.
When an agent can take a well-written spec and produce working code in minutes, the writing phase becomes a commodity. What remains scarce is the thinking that precedes it and the judgment that follows it. Engineers using AI coding agents report spending the majority of their time on planning and review activities, up from roughly 30% in the pre-AI era. The inversion is complete. Planning and review are no longer the overhead around the "real work." They are the real work.
This mirrors what happened in other industries. Architects do not lay bricks. Film directors do not operate cameras. Orchestra conductors do not play every instrument. The skill is not execution. The skill is knowing what the execution should produce and recognizing when it falls short.
The three phases of the new workflow
The future of software engineering organizes around three distinct activities:
| Phase | What the engineer does | What the agent does |
|---|---|---|
| Plan | Writes specs, defines constraints, identifies edge cases, sets acceptance criteria | Nothing (waits for instructions) |
| Execute | Monitors progress, answers agent questions, provides missing context | Writes code, runs tests, generates PRs |
| Review | Evaluates output against spec, checks systemic integrity, approves or redirects | Nothing (waits for feedback) |
The ratio is shifting fast. The Stack Overflow 2024 Developer Survey showed AI tool adoption growing rapidly, and that trend has only accelerated. A growing majority of professional developers now describe their primary daily activity as "reviewing and directing AI-generated code" rather than "writing code from scratch." In just two years, the profession flipped.
What planning actually means now
Planning is not writing tickets in Jira. Not in this context. Planning in the future of software engineering means producing machine-readable specifications precise enough that an agent can execute without ambiguity. It means thinking like a compiler about human problems.
At Vercel, their engineering teams adopted what they call "spec-first agent workflows" in late 2025. Each feature begins with a structured document that specifies: the user problem, the proposed solution architecture, the acceptance criteria, the edge cases to handle, the systems that must not be affected, and the test scenarios that validate success. The engineer writes this document. The agent writes the code. This approach draws on the principles of spec-driven development, where the specification becomes the primary artifact.
This changes which skills matter. Writing a clear specification is harder than writing code. Code has a compiler that tells you when you are wrong. A spec has no compiler. If your spec is ambiguous, the agent will produce working code that solves the wrong problem. You will not catch it until review, or worse, until production.
The specification as the primary artifact
Consider a concrete example. An engineer at Stripe needs to add support for a new payment method in a specific region. Under the old model, they would read the payment provider's documentation, understand the API, write integration code, handle error cases, add tests, and ship. Under the new model, they write something like this:
- Problem: Merchants in Brazil need to accept PIX payments.
- Constraints: Must integrate with existing payment intent flow. Must not add latency to non-PIX payment methods. Must handle the 24-hour expiration window for PIX payment codes. Must support partial refunds.
- Edge cases: What happens when a PIX code expires mid-checkout? What happens when the payment confirmation webhook arrives after a timeout? What happens during a network partition with the PIX provider?
- Systems affected: Payment intent service, webhook processor, merchant dashboard, reconciliation pipeline.
- Validation: Integration tests against PIX sandbox. Load tests at 2x expected peak volume. Chaos testing for webhook delivery failures.
That specification takes 30 minutes to write well. It requires deep domain knowledge, understanding of the existing system, and empathy for the end user. An agent can then execute against it in under an hour. The hard part was never the implementation. The hard part was knowing exactly what to implement.
What review actually means now
Review in the plan-and-review model is not a cursory scroll through a diff. It is the last line of defense between generated code and your users. The stakes are higher because the volume is higher. When agents produce ten PRs a day, review capacity becomes the bottleneck.
Effective review in 2026 operates on three layers:
Correctness against spec. Did the agent do what you asked? This is the surface layer. Automated tests handle most of it, but the engineer must verify that the tests themselves are comprehensive enough. An agent will happily write tests that pass against its own code without testing the actual edge cases.
Systemic integrity. Does this change interact safely with the rest of the system? This is where the engineer earns their salary. You need to understand not just the code in the PR, but every system it touches, every implicit contract it might violate, every downstream service that depends on the current behavior. AI agents cannot hold this context. Humans must.
Product judgment. Even if the code is correct and systemically safe, does it solve the right problem? Does the user experience make sense? Are we shipping the right thing? This layer requires product intuition that no model currently has. It requires having talked to users, seen session recordings, understood the business metrics that matter.
Organizations with dedicated review practices for AI-generated code consistently report fewer production incidents than those that treat AI-generated PRs the same as human-generated ones. The review is not overhead. It is the product quality guarantee.
The product engineer thrives in this model
The plan-and-review model does not favor specialists who write beautiful code. It favors generalists who understand entire systems and can make judgment calls at speed. It favors the product engineer.
An engineer who can write precise specs draws on their understanding of users, systems, and business context simultaneously. They do not just specify technical requirements. They specify outcomes. "This feature should reduce time-to-first-value by 40% for new merchants" is a spec that shapes implementation decisions. "Add an onboarding wizard" is a task list that leaves all the important decisions to the agent.
This is why the product engineer role is growing while traditional implementation-focused roles contract. PostHog's public hiring data shows that their entire engineering organization operates on this model. Every engineer owns a product area end-to-end. With AI agents handling implementation, that ownership becomes even more critical. Someone needs to decide what the agents should build. Someone needs to evaluate whether what they built is right.
From my own experience hiring over 600 engineers and coaching 12,000 throughout my career, I have watched this transition happen in real time. At AWS, where I work as a Senior Product Engineer, the engineers who adapted fastest to AI-augmented workflows were not the strongest coders. They were the strongest thinkers. The ones who could write a two-page spec that an agent could execute without clarifying questions. The ones who could review a 500-line PR and spot the one assumption that would break in production. The old hiring signal of "can they reverse a linked list" is almost comically irrelevant. The new signal is "can they define a problem precisely and evaluate a solution holistically."
As a two-time founder, I saw this coming from a different angle too. When you are building a startup, you cannot afford to separate thinking from doing. The engineer who plans, directs an agent, reviews, and ships is operating at founder speed with enterprise reliability. That combination was impossible three years ago.
The skills that define the future of software engineering
If the future of software engineering is planning and reviewing, what skills does an engineer need?
Systems thinking
You cannot write a good spec if you do not understand the system. Not just the component you are modifying, but the five services that depend on it, the data pipeline that feeds it, the monitoring that alerts on it, and the business process that relies on it. Systems thinking was always valuable. It is now mandatory.
Precise written communication
The spec is the product. If your writing is ambiguous, your output will be wrong. Engineers who communicate precisely, who can specify constraints without leaving gaps for misinterpretation, outperform engineers who "know it when they see it" but cannot articulate it upfront.
Domain expertise
Agents do not know your business. They do not know that your biggest customer relies on a specific API endpoint in ways the documentation does not describe. They do not know that your compliance team requires specific data handling for users in the EU. Domain expertise is the context you provide that makes agent output actually useful.
Rapid evaluation judgment
When you are reviewing ten PRs a day from agents, you need to evaluate fast and accurately. This means pattern recognition. This means knowing which files to check first. This means understanding which changes are high-risk and which are routine. It is a skill you build through practice, not one you can shortcut.
Product intuition
The engineer in the plan-and-review model makes product decisions continuously. What should we build? What should we not build? Is this feature solving the user's actual problem or just a symptom? Product intuition separates engineers who ship value from engineers who ship code. The product-minded role demands this combination.
What this means for engineering organizations
The shift to plan and review restructures how teams work. Organizations that recognize this early will adapt. Those that do not will lose their best people and ship worse products.
Team size shrinks, scope expands
When agents handle implementation, you need fewer people to ship the same amount of product. But those people need broader context. The three-person team that owns a full product area, each member an engineer with deep domain knowledge, becomes the standard unit. Notion operates this way. Figma operates this way. The post-engineer engineering org is not a prediction. It is a description of what already exists at companies that adopted AI-native workflows early.
Code review becomes product review
The old code review asked: "Is this code correct?" The new product review asks: "Does this change make the product better?" That is a fundamentally different question. It requires different skills, different checklists, and different authority. The reviewer needs the authority to reject correct code that solves the wrong problem.
Specifications become institutional knowledge
When every feature starts with a detailed spec, you accidentally build the documentation that previous engineering eras never had time to write. Those specs explain not just what the system does, but why it does it, what constraints it operates under, and what edge cases it handles. Future engineers (and future agents) benefit enormously from this artifact.
Junior engineer development changes
The traditional junior engineer learned by writing code, making mistakes, and getting feedback. In a plan-and-review world, they learn by writing specs, having seniors evaluate those specs, and observing how agents execute them. The feedback loop tightens. You can see in minutes whether a junior's spec was precise enough, not weeks later when bugs emerge.
The resistance, and why it fades
Many engineers resist this shift. Writing code feels productive. It is tangible. You type, the screen changes, the tests pass. Planning and reviewing feel like overhead, like bureaucracy, like not-real-work.
That resistance fades when you ship three features in a week instead of one. It fades when you go home at 5 PM because the agent continued executing your spec overnight. It fades when you realize that the "real work" was always the thinking, and the typing was just a low-bandwidth way of expressing your thoughts.
Shopify's CTO Tobi Lutke framed it well in a January 2025 internal memo (later leaked): "The most valuable engineers at Shopify are not the ones who write the most code. They are the ones who prevent the most wrong code from being written." That prevention happens in planning and review.
The engineers who adapt to agentic engineering workflows fastest are those who already thought of code as a means to an end. People who measured their work by user outcomes, not lines committed. The plan-and-review model simply removes the bottleneck that stood between their thinking and shipped product.
Where the future of software engineering goes next
The future of software engineering does not stop at plan and review. The trajectory points toward engineers operating at increasingly higher levels of abstraction:
2026 (now): Engineers write specs, agents write code. Engineers review PRs.
2027 (emerging): Engineers describe outcomes, agents write specs AND code. Engineers review at the product level.
2028 (early signals): Engineers define strategy, agents propose features, write specs, implement, and run A/B tests. Engineers evaluate results and redirect.
Each step moves the engineer further from implementation and closer to pure judgment about what should exist and whether it is working. Someone who already operates at the intersection of product thinking and technical capability is positioned perfectly for each transition.
OpenAI's internal engineering practices, described in a series of blog posts throughout early 2026, already show glimpses of the 2027 model. Their engineers describe high-level objectives and constraints. Multiple agent systems propose implementations. Engineers evaluate trade-offs and select approaches. The implementation is the easy part. The selection is where human judgment remains irreplaceable.
The uncomfortable truth
Not every engineer will thrive in the plan-and-review world. If your primary value was clean implementation of well-specified tasks, the agent can do that now. If your primary value was knowing a specific framework deeply, the agent knows it better. If your primary value was typing fast, the game is over.
The engineers who thrive are those whose value was always above the code. Those who understood the problem. Those who saw the system. Those who knew the user. Those who could make judgment calls when the data was incomplete. Those who could write a spec so clear that anyone, human or machine, could execute it without questions.
That description is the product engineer. It always was. The shift to plan and review did not create a new role. It clarified which role was always the most valuable. The future of software engineering is not learning a new framework or a new language. It is learning to think precisely, communicate clearly, and judge quickly. Everything else is automation.
Key takeaways
- The future of software engineering shifts the highest-value work to planning (specifying intent) and reviewing (verifying output).
- For most production software (CRUD, integrations, UI, transformations), plan-and-review is already dominant at forward-leaning organizations.
- The product engineer who thinks precisely, communicates clearly, and judges quickly becomes the most valuable team member.
- Implementation still matters for novel algorithms, performance-critical paths, and security-sensitive operations.
- Learning to specify intent clearly is now more valuable than learning a new framework or language.
FAQ
Is the future of software engineering really just planning and reviewing?
Yes, for the highest-value work. Implementation has not disappeared entirely. There are still situations where an engineer needs to write code directly: novel algorithms, performance-critical paths, security-sensitive operations where you need line-by-line certainty. But for the majority of production software (CRUD operations, API integrations, UI components, data transformations), the plan-and-review model is already dominant at forward-leaning organizations like Linear, Vercel, and PostHog.
Will junior engineers still need to learn to code?
Absolutely. You cannot plan what you do not understand. You cannot review what you cannot read. Coding literacy remains essential. But the goal shifts from "write production code from scratch daily" to "understand code deeply enough to specify it precisely and evaluate it critically." Think of it like architecture school: students still learn to draw by hand, even though CAD does the production drawings.
How do I transition from an implementation-focused role to a plan-and-review role?
Start by writing specs for your own work before you write code. Practice the discipline of defining what you are going to build, why, and what success looks like, before you touch the keyboard. Then let an AI agent execute your spec and evaluate the output. Iterate on your specs until agents produce correct code on the first attempt. That iteration teaches you precision of thought. Also read about the broader transition in the product engineer career path.
Does plan and review mean engineers become project managers?
No. Project managers coordinate timelines and resources. Engineers in the plan-and-review model make technical and product decisions. They decide what to build, define how it should work at the system level, and evaluate whether the output is correct. They still need deep technical expertise to write good specs and to catch subtle bugs in review. The decisions are engineering decisions. The execution is delegated.
What tools support the plan-and-review workflow?
The tooling ecosystem is still emerging. Cursor, Windsurf, and Claude Code support the execution layer. Linear and Notion support the planning layer with structured specs. GitHub's code review tooling supports the review layer. But the real "tool" is the engineer's judgment. No product replaces the ability to think clearly about systems and users.