Stop Giving Engineers Requirements

There is a phrase I have disliked for most of my career: "Give me the requirements." It sounds reasonable. A developer needs to know what to build, product needs to define expected behavior, and acceptance criteria need to be clear. Ambiguity creates mistakes. All of that is true.

But taken too far, "give me the requirements" expresses something deeper about how we have organized software development. The request is not just for clarity. It is for a fully prescribed solution, handed down before engineering begins:

You understand the problem. You decide what should happen. You break it down until I can execute my piece. Then give me the instructions.

Requirements are not the problem. The assumption is. The assumption that someone else must convert customer context, business objectives, and real-world constraints into a detailed specification before engineering can contribute value. That is the problem. Engineers still need that context. They need to understand the customer, the objective, the constraints, and the evidence. What they do not need is to receive it pre-digested.

For decades, software organizations developed elaborate ways to decompose complex problems into work that could be distributed across specialized people and teams. Business problems became requirements, requirements became smaller units of work, technical decisions were separated from implementation, and development was often separated from validation and release. As organizations grew, they added roles, workflows, planning practices, tracking systems, and coordination mechanisms to keep all of those pieces aligned.

Agile reduced many of the problems created by long planning cycles and large handoffs, but it did not eliminate the underlying need to coordinate distributed ownership. In many organizations, that coordination eventually accumulated its own machinery: backlogs, stories, estimation, sprint planning, standups, reviews, retrospectives, release processes, and tools such as Jira.

There was a reason for all of this. Software execution was expensive, individual capacity was limited, and context was genuinely difficult to distribute across a large organization. Specialization let organizations scale, but specialization created handoffs, and handoffs created coordination costs. AI is changing those constraints. When the constraints change, we should be willing to question the operating model built around them.

When Requirements Become Detailed Enough, AI Can Already Do Much of the Work

Consider what happens when a developer asks for detailed requirements. You explain the business problem and describe the desired behavior. You define the edge cases, document the data involved, explain the existing architecture, define the interfaces, specify the acceptance criteria, and describe how the result should be tested. At some point, an uncomfortable question surfaces:

If I have explained the problem this completely, why do I need someone whose primary value is translating those instructions into code?

Given sufficient context, AI can now handle much of that translation. It can inspect a codebase, analyze dependencies, propose an implementation, write code, generate and run tests, identify failures, revise the implementation, review the result, update documentation, and prepare a change for deployment. It does not do all of this perfectly. That is not the point. What has changed is that the mechanical act of implementation is becoming less scarce. Judgment is.

The valuable engineer now starts further upstream. Not "give me the requirements" but "tell me the problem." The questions that matter are:

• What are we actually trying to accomplish?
• Why does it matter?
• What evidence suggests it is worth solving?
• Who is affected?
• What have customers actually told us?
• Which constraints are real and which are assumed?
• What hypotheses do we need to test?
• What alternatives should we consider?
• What tradeoffs are acceptable?
• What does success look like?
• What should we deliberately not build?

An engineer who can own those questions can direct AI to provide enormous execution capacity. The human contribution shifts toward understanding, judgment, architecture, prioritization, and accountability. That is a fundamentally different job.

The Unit of Engineering Work Is Changing

For years, the basic unit of software development has been the task. A large problem gets decomposed, then decomposed again, until it is small enough to put into a ticket and assign to someone. That made sense when execution capacity was constrained. AI changes how much one capable engineer can execute.

An engineer can now run multiple agents in parallel: one inspecting the architecture, another analyzing dependencies, another writing the implementation, others generating tests, checking security, challenging the design, or updating documentation. The engineer is not performing every step personally. The engineer directs the work and remains accountable for the result.

That allows the unit of accountability to move upstream. Instead of a long chain of handoffs:

TASK-ORIENTED MODEL

The model can become:

OUTCOME-ORIENTED MODEL

The difference is not merely speed. The second model changes ownership. It removes the distance between the person who understands the problem and the person responsible for solving it.

What About Brand-New Features?

A natural objection: what about work where no requirements exist yet, where the problem itself is still being discovered? The answer is that discovery is part of the work, not a prerequisite delivered by someone else before engineering begins.

An engineer owning a problem works directly with customers, product leaders, designers, and domain experts to understand what is worth building and why. AI can accelerate that process considerably. It can analyze customer feedback at scale, surface patterns in support data, generate multiple design alternatives, and build working prototypes quickly. But AI output is not customer evidence. A prototype is not product validation. A technically correct feature can still be the wrong feature if it was never validated against real customer behavior.

This is why the outcome-oriented model distinguishes between three things: verification, validation, and measurement. Verification asks whether the implementation works correctly. Validation asks whether it solves the right problem for real users. Measurement asks whether it produced the intended outcome in production. All three are the engineer's responsibility, not separate functions that take the handoff.

Product thinking does not disappear in this model. Its highest value has always been understanding customers and markets, not converting decisions into stories. The same principle applies across disciplines: design, security, architecture, and operations all remain valuable. The change is that their expertise enters the work rather than fragmenting the ownership of it.

Agile Solved a Real Problem

This is not an argument that Agile was a mistake. Agile emerged because what came before it was often worse. Large requirements documents, long development cycles, massive releases, and limited customer feedback created enormous risk. Shorter iterations, frequent feedback, working software over documentation, and responding to change were genuine improvements.

But many organizations did not stop at those principles. They built an operating bureaucracy around them:

• Backlog grooming
• Story refinement
• Story points
• Estimation sessions
• Sprint planning
• Daily standups
• Two-week commitments
• Sprint reviews
• Retrospectives
• Release trains
• Scrum of Scrums
• Program increments

Entire management structures developed around coordinating people who each owned a small portion of the outcome. Over time, work was decomposed so thoroughly that an engineer could perform successfully while understanding very little about the underlying business problem. The surrounding organization supplied the missing context: product owned the problem definition, architecture owned the technical vision, engineering owned implementation, QA owned validation, and project management owned coordination. The process made fragmented ownership function. AI gives us an opportunity to reverse some of that fragmentation.

The Sprint Was a Solution to a Coordination Problem

A common reaction to AI is: "Great. Now we can complete more story points per sprint." That misses the opportunity.

If AI allows an engineer to solve something in four hours that previously took four days, why is a two-week sprint still the natural unit of time? Why are we batching execution at all? Imagine an engineer starts a problem on Monday morning. By that afternoon, the relevant systems have been analyzed, an implementation has been proposed, code has been written, tests have been created and run, a failure found and corrected, security checks passed, and the result is ready for production. Why should that work care that Sprint 83 ends the following Thursday?

It should not. The sprint was a solution to a coordination problem. AI changes the coordination problem. The answer is not a faster sprint. It may be that we no longer need the sprint as the primary engineering clock.

Flow Makes More Sense

A pull-based model makes more sense than artificial batching. Maintain a prioritized queue of meaningful problems, limit work in progress, and when capacity becomes available, pull the highest-value eligible problem. An engineer owns it, solves it, verifies it, delivers it, and then pulls the next one. That looks much closer to Kanban than Scrum.

More importantly, it shifts management attention away from estimates of activity and toward observations of actual system performance. Measure what the system produces:

• Lead time and cycle time
• Throughput and work in progress
• Aging work and blocked time
• Rework and escaped defects
• Deployment failures and human interventions required
• Cost and business outcome

If cycle time increases, investigate it. If work accumulates, investigate it. If AI-generated changes consistently require significant rework, improve the engineering harness. If production quality deteriorates, strengthen verification. If certain classes of work repeatedly require senior intervention, determine whether the issue is capability, architecture, context, or governance. We do not need a ceremony to tell us the system is struggling when the system itself can show us.

The Daily Standup Is a Good Example

The standup's traditional questions help teams synchronize distributed human work. But an AI-native engineering system should already have visibility into much of that state. It knows what is being worked on, when the work started, what changed, which tests failed, which agent attempts succeeded or failed, what is blocked, where human intervention is required, and how long the work has been sitting. Assembling eight people every morning to verbally reconstruct what the system can already show you is a poor use of everyone's time.

Communication still matters. High-quality human conversation becomes more important, not less. But it should happen because judgment is required, not because the calendar says 9:15 AM. An architectural decision that affects three products? Get the right people together. A customer request that conflicts with platform strategy? Discuss it. A security tradeoff that exceeds the engineer's authority? Escalate it. A team repeatedly failing to produce expected outcomes? Investigate it.

"What did you do yesterday?" is status synchronization. Software should handle status synchronization. Humans should spend their time making decisions.

QA Does Not Disappear. The Handoff Should.

The same principle applies to quality assurance. The wrong conclusion is that AI means we no longer need testing. The opposite is true: AI should let us test dramatically more. What becomes questionable is the organizational handoff: developer finishes, QA receives the work, QA finds a defect, developer fixes it, QA retests. Why should quality be a downstream function responsible for determining whether engineering completed its work correctly?

An engineer who owns the problem should own correctness. The engineering system can generate unit tests, integration tests, edge cases, and regression scenarios; perform security analysis; simulate failure conditions; inspect logs; validate performance; compare expected and actual behavior; challenge the implementation; and repeat the cycle until verification succeeds. Quality becomes part of the engineering system, not a handoff to another department.

That does not mean specialized quality expertise disappears. Complex systems will continue to require specialists in performance, reliability, security, safety, and compliance. Specialized expertise remains valuable. Fragmented accountability does not have to come with it.

We Do Not Need Less Discipline

This model is easy to mistake for an argument against process. It is not. I am not suggesting we eliminate architecture, controls, reviews, testing, governance, management, or accountability. AI increases both the speed of execution and the blast radius of mistakes, so some forms of discipline become more important. But the discipline changes.

This is not a trust model. AI-generated work must earn confidence through evidence: customer validation, automated tests, architecture compliance, security controls, controlled releases, observability, and measurable results. We are not replacing detailed requirements with faith in AI. We are replacing prescriptive handoffs with accountable judgment supported by evidence. Accountability is the organizing principle. Evidence is the control mechanism.

We do not need less engineering discipline in the AI era. We need less coordination theater and more ownership.

The Engineer Becomes a Problem Owner

This raises the standard for engineering talent. The engineer of the future cannot simply be someone who turns instructions into code. Execution skill still matters, but AI amplifies and automates significant portions of it. What distinguishes an engineer shifts to a different set of abilities:

• Can you understand an ambiguous problem?
• Can you understand the business well enough to know what actually matters?
• Can you challenge a bad assumption before writing a line of code?
• Can you work directly with customers and domain experts?
• Can you design a useful experiment rather than immediately committing to a solution?
• Can you make architectural tradeoffs?
• Can you recognize when AI has produced something technically plausible but fundamentally wrong?
• Can you distinguish an inconvenience from a material risk?
• Can you decide what should not be built?
• Can you operate with incomplete information?
• Can you connect technical decisions to customer and business outcomes?
• Can you take accountability for the result?

Problem ownership is not solitary decision-making or unlimited authority. It means the engineer remains engaged across the entire path from problem to measured outcome, bringing in specialized expertise and escalating decisions when necessary rather than ending responsibility at the boundary of implementation.

"Give me the requirements and I will implement them" is no longer a sufficient description of engineering value.

That does not mean every system will be built by one generalist. It means accountability should remain coherent even when many specialists contribute. Accountability does not mean that one engineer performs every activity or possesses every form of expertise. Other engineers and specialists may contribute throughout the work. The difference is that responsibility for integrating those contributions and producing the outcome remains coherent from beginning to end.

It also creates an uncomfortable implication for some engineering organizations. If an organization has been built around highly specialized people executing narrowly defined tasks, AI may expose the coordination cost that structure was hiding. A smaller number of engineers capable of owning broader problems may outperform a much larger organization optimized for task execution.

Management Has to Change Too

This is not only a developer transformation. Engineering management has to move away from managing activity. How many tickets did we close? How many story points did we complete? Are we on track for the sprint? Did everyone update Jira? Those questions become even less useful when AI can dramatically increase mechanical output. They were already measuring the wrong things.

Management should be asking a different set of questions:

• What problems did we actually solve?
• How quickly did we solve them?
• Did the result work technically?
• Did customers use it?
• Did it produce the intended business outcome?
• What did it cost?
• What risks did we introduce?
• How much rework occurred?
• Where did human judgment become necessary, and what can we learn from that?
• Where are constraints accumulating?
• What capability would most improve the system's performance?

Management still decides which outcomes matter, allocates capital, establishes risk tolerance, sets authority boundaries, resolves organizational conflicts, and develops the capabilities the organization will need next. The purpose of management becomes improving the performance of the delivery system, not supervising the movement of tickets through it.

This Changes Technology Diligence Too

For investors and boards, this creates a new set of questions. Technology diligence has traditionally examined things like: Does the company follow Agile? How mature is Scrum? What is engineering velocity? How large is the engineering organization? What is the developer-to-QA ratio? How frequently does the team release? Those questions are becoming increasingly incomplete.

A more relevant set of questions looks like this:

• How much organizational machinery is required to turn a business problem into a verified production outcome?
• How many handoffs are involved, and how much context is lost between them?
• How much work exists primarily to coordinate other work?
• How much end-to-end ownership exists?
• How effectively are engineers using AI?
• What percentage of verification is automated?
• How much human intervention does AI-generated work require?
• How quickly can the organization move from identifying a problem to delivering a verified outcome?
• How quickly can the organization test a new product hypothesis?
• How reliably does the organization connect technical delivery to customer adoption and economic value?

Why does this company require this many people and this much process to produce this amount of software?

AI will make that an investment question, not merely an engineering one.

AI May Finally Force Us to Become Agile

There is an irony here. The Agile Manifesto emphasized individuals and interactions, working software, customer collaboration, and responding to change. Yet many enterprise Agile implementations evolved into rigid calendars, elaborate workflows, specialized roles, mandatory ceremonies, and increasingly sophisticated mechanisms for coordinating fragmented work. The process began to crowd out the principle.

AI gives us an opportunity to revisit the original intent. Not by doing Scrum faster, but by reducing the distance between the problem and the person accountable for solving it. The AI-native engineering organization looks something like this:

• A prioritized flow of meaningful problems and opportunities
• Engineers who remain accountable from discovery through measured outcome
• Direct collaboration with customers and domain experts
• AI agents that expand human execution capacity
• Specialized expertise applied without fragmented accountability
• Strong automated verification, security, and governance
• Continuous delivery when the result is ready
• Measurement based on flow, quality, adoption, and business outcome
• Human conversation when judgment, learning, or collaboration is required

No artificial batching. No ceremony because the process says it is Tuesday. No perfectly prepared ticket handed to someone who has no idea why the work matters.

The Next Question Is Bigger Than Engineering

Once engineers own problems and orchestrate AI-assisted work, a larger question follows. What system governs all of that work? Who decides what an agent is allowed to do? How is the right context supplied? How are architecture, security, and business policies enforced? How is evidence collected? How does the system recognize when a human decision is required? What happens when solving the problem requires a capability the organization does not yet have?

That begins to look like an operating system for AI-assisted work. Engineering is simply the most obvious place to start because software gives us unusually strong mechanisms for automation, testing, evidence, and verification. But the underlying model is not inherently about software development. It is about how organizations turn problems into outcomes.

That is the next question.

The biggest change AI brings to engineering may not be that we write software faster. It may be that we no longer need an organization designed around breaking problems into tiny tasks, distributing those tasks to specialists, and coordinating all the handoffs required to reassemble the pieces. The unit of work can move from the task to the outcome. The unit of accountability can move back to the person who understands the problem.

Give me the problem. I own the outcome.