Engineering
Context for engineering is more important now than ever.
That may sound strange in a world where teams are moving faster, writing fewer formal specs, building with AI, and turning prototypes into products at a pace that would have seemed unrealistic just a few years ago.
But that is exactly why context matters more.
AI has accelerated execution. Engineers can produce code faster. Designers and product managers can generate prototypes faster. Non-technical teammates can contribute in new and exciting ways. Small teams can ship at speeds that used to require much larger organizations.
That is mostly good. But faster execution creates a new risk: moving quickly in the wrong direction.
AI will move fast in whatever direction you point it. If the team has not taken the time to deeply understand the problem, articulate the opportunity, define success, and make tradeoffs explicit, then AI does not solve that problem. It amplifies it.
As coding gets cheaper, judgment gets more valuable. And judgment requires context.
A lot of teams have moved away from traditional product requirements documents, and for good reason.
Heavy PRDs often take too long to create. They can require too much stakeholder input before anything useful happens. They get too granular too early. They try to answer implementation questions before the team has learned enough. They become stale almost immediately after publishing. And once they exist, someone has to own the ongoing burden of keeping them up to date. Worse, long PRDs often do not get read.
So yes, the old PRD model deserves criticism. A twenty-page document that takes a week to produce, gets skimmed once, and immediately drifts from reality is not the answer.
But rejecting heavy PRDs does not mean rejecting written context. That is the overcorrection.
The question is not whether teams need giant product documents. Most do not. The question is whether a project has enough explicit context for humans and AI to execute effectively. Very often, the answer is no.
One common replacement for the PRD is the prototype. In many ways, that is a good thing. Prototypes are excellent tools for showing a possible solution. They make ideas tangible. They help stakeholders react to something concrete. They reveal design gaps that written documents might miss. They can help a team align around an experience quickly.
But a prototype is not the same thing as a source of truth. A prototype shows a solution. It does not necessarily explain the problem.
It may demonstrate a flow, but it does not always communicate what is required, what is optional, what is placeholder, what is intentionally out of scope, or what exists only to make the demo feel complete.
As an engineer, if the prototype is the only artifact, I am forced to reverse engineer intent from the interface. Is this real functionality or just a demonstration? Is this edge case expected? Is this field required? Is this state designed or accidental? What happens when the prototype conflicts with existing product behavior, and what matters more: matching the prototype exactly or preserving the underlying business rule?
These are not minor questions. They are product questions. And if they are not written down anywhere, engineers either interrupt someone to ask, make assumptions, or build based on their best interpretation. That may work sometimes. But it is not a system.
Another response is: “just talk to the product manager.” Of course engineers should talk to product managers. Written context should not replace conversation. Good teams talk constantly. But conversation alone does not scale.
It may work on a very small team, with one product manager, a few engineers, and a shared mental model of the business. But as the team grows, this breaks down. Is it effective for every engineer to constantly ask the product manager for clarification? To answer the same question in five different Slack threads? To jump into repeated huddles when the answer could have been captured once?
At some point, “just ask product” turns the product manager into an oracle. That creates bottlenecks. It creates inconsistency. It slows down engineering. It makes onboarding harder. It makes async work harder. It also makes it harder for AI tools to help, because the most important context is not actually available to them.
Conversation is still necessary. But conversation should create context, not be the only place context exists.
There is a simple question teams should ask more often: if we do not write this down, how do we know it is true?
Should we rely on Slack conversations? Google Meet notes? Figma comments? Linear issue threads? Someone's memory? A quick hallway conversation? All of those can be useful inputs. None of them are a reliable source of truth on their own.
Without written context, project intent becomes folklore. People may remember different versions of the same decision. A product manager may think something was obvious. An engineer may think a tradeoff was unresolved. A designer may believe the prototype answered a question that engineering still sees as open. Leadership may assume success means one thing while the team optimizes for another.
This is how teams drift. Not because people are careless. Because implicit context decays.
Written context does not eliminate ambiguity, but it gives the team something to inspect, challenge, update, and align around. It creates a shared surface area for judgment.
AI changes the equation. We are no longer collaborating only with human coworkers. Increasingly, we are also collaborating with AI systems: coding agents, design assistants, summarizers, planning tools, review bots, and autonomous workflows.
But AI does not have the same memory humans do. It does not remember the hallway conversation. It does not know which Slack thread mattered. It does not understand which part of a prototype is intentional and which part is throwaway. It does not know the business context unless that context is available somewhere.
For AI, if something is not written down, it might as well not exist.
That does not mean AI needs massive documents. In fact, too much stale or conflicting context can make AI worse. The goal is not more documentation for its own sake. The goal is better context.
A lightweight project brief gives AI a better operating frame. It tells the system what problem is being solved, why it matters, what success looks like, what not to do, and what assumptions to be careful with. That makes AI more useful. It can generate better implementation plans, break work into better tasks, identify missing requirements, review whether a pull request matches the project intent, and summarize project state for stakeholders.
But AI cannot invent sound product judgment from thin air. Humans still have to provide that. If anything, it raises the bar.
This also connects to a broader shift in engineering. Engineers are increasingly expected to be more than coders. We are expected to be problem owners. I think that is a good thing.
Engineers should understand the business. We should care about customer outcomes. We should challenge assumptions. We should ask whether the thing we are building is worth building. We should participate in shaping the solution, not merely implement tickets.
But asking engineers to be problem owners while removing written context is contradictory. Problem ownership requires access to the problem. If engineers only receive prototypes, tickets, and scattered Slack context, they are not being empowered as problem owners. They are being asked to infer the problem from implementation artifacts. That is backwards.
If we want engineers to exercise judgment, we need to give them the context required to judge well.
The answer is not to bring back bloated product requirements documents. The answer is lightweight written context.
A modern project brief should be short, useful, and alive. It should not take a week to write. It should not require endless stakeholder review. It should not attempt to specify every detail. It should not pretend the team knows everything upfront. It should answer the questions that actually matter:
What problem or opportunity are we addressing? Why are we doing this now? Why did we choose this over other alternatives? What does success look like? What risks or constraints should we consider? What solution paths are we exploring? What is intentionally out of scope? What should humans or AI not assume?
That is not bureaucracy. That is project intent. And if we cannot take the time to express the problem and opportunity clearly in writing, we should ask whether the work is actually ready to be done.
One of the best arguments against heavy documentation is that it is expensive to create and maintain. That used to be more true than it is now.
AI can help turn messy inputs into clear context. It can summarize Slack discussions, meeting notes, customer feedback, Linear issues, design comments, and technical constraints. It can draft the first version of a project brief. It can identify unanswered questions. It can suggest non-goals. It can turn a conversation into a decision log.
It can also help keep the document updated. When the team learns something new, AI can propose changes. When scope shifts, AI can update the brief. When a decision is made in a thread, AI can capture it.
This is the better future of product documentation. Not humans writing giant documents that immediately go stale. Not teams abandoning written context entirely. But humans using AI to capture, refine, and maintain the context that makes execution better. The goal is not to document more. The goal is to make shared understanding easier to create and cheaper to maintain.
The debate should not be “PRDs or no PRDs.” That framing is too simplistic. The real question is: is the intent of this project explicit enough for humans and AI to execute effectively?
Sometimes a Linear issue is enough. Sometimes a prototype is enough to explain the interaction. Sometimes a quick conversation is enough to unblock a decision. But for meaningful projects, cross-functional work, ambiguous opportunities, or anything involving multiple engineers, AI agents, design tradeoffs, customer impact, or business risk, the team needs more than vibes. It needs written context.
Not necessarily more pages. But more explicit intent. A lightweight project brief should not slow the team down. It should make execution faster because fewer people are guessing, make collaboration better because everyone has the same starting point, and make AI more effective because the system has something better than scattered fragments to work from.
AI has made execution dramatically faster. But speed is not the same thing as progress.
The teams that win will not simply be the teams that generate the most code. They will be the teams that combine fast execution with clear judgment. They will be the teams that know how to define problems, evaluate opportunities, make tradeoffs, document intent, and use AI to stay aligned as the work evolves.
The answer is not less context. It is more explicit context. Not heavier documents. Not more process. Not a return to PRD theater. Just enough written clarity to help humans and AI understand what matters, why it matters, and where to focus.
Because when code gets cheap, the costliest mistake is building the wrong thing faster.