Prompt Engineering Starts Before the Prompt

When people hear prompt engineering, many still think first of wording, role descriptions, XML tags, prompt templates, or especially elaborate system instructions. A typical opening might be:

“You are a world-class senior software architect …”

Over the past few years, prompts have grown into a small discipline of their own, sometimes creating the impression that the main difference between a mediocre and an excellent AI answer is the right linguistic formula.

That is not entirely wrong. Structure can help. Examples can help. Clear language helps. Current model guidance still describes concrete prompting techniques as well.

But in my practical work with coding agents, that has become only a relatively small part of the problem.

Take a perfectly understandable sentence:

Build me a user management feature.

There is little wrong with the wording. The instruction is short, clear, and does not use unnecessary jargon.

And yet almost all the information required for a real implementation is missing.

What kinds of users are there? Which roles do they have? Who may create users? Can users change their own data? Are invitations involved? How does authentication work? Which data has to be stored? What happens with duplicate email addresses? Is there already an identity provider? Which parts of the existing system may be changed? Which architecture applies? Which error cases belong to the scope? What is explicitly not part of the task? And how do we ultimately know whether the feature has been implemented correctly?

None of these problems is solved by adding this line before the original instruction:

You are a world-class senior software architect.

A well-worded unclear task is still an unclear task. The real engineering therefore does not begin with finding a more sophisticated way to phrase the same request, but with identifying the decisions and information that are still missing.

Why this article follows from the previous ones

The previous three articles in this series gradually built the foundation for this point.

Article 4 was about Context, Memory, Agent Files, Skills, and Tools. There, we described Context as what is actually on the “desk” for the current model invocation. Memory, Agent Files, Skills, and project documentation can provide information for that Context, but they serve different purposes. Most importantly, we distinguished between persistent project knowledge and the current work assignment.

That already leads to an important consequence for prompts: an implementation prompt should not have to explain the entire repository every single time.

If a project has a permanent rule that Presentation must not access Infrastructure directly, that is not something I want to reinvent for every ticket. If a specific testing strategy applies, naming rules exist, or a particular layering model is mandatory, those decisions need a persistent home.

Simplified:

Agent Files / Skills / Memory / Documentation
=
persistent working knowledge

Implementation prompt
=
the concrete assignment for this task

Recent field reports support exactly this distinction. Anthropic describes Context Engineering as the continuous selection of the most relevant Context rather than the largest possible one and recommends, among other things, just-in-time retrieval for agents. OpenAI reports from an internal agent-first software project that a large monolithic AGENTS.md can push the task, code, and relevant documentation out of Context, while rules quickly become stale and excessive guidance loses priority. Their shorter agent file therefore acts more as a map into deeper, versioned repository documentation.

Article 5 then examined another property: an agent constructs a solution path. It reads files, uses tools, evaluates observations, and continues making decisions based on the Context those actions have changed. The same assignment therefore does not necessarily lead to the same implementation path.

If we do not want to prescribe that path completely deterministically—and with an agent that would often defeat the point—we at least need to define the space within which decisions are acceptable.

Article 6 added the next complication. A plausible path can rest on a false assumption. That assumption can become a code change, be committed, and later appear as local evidence inside the repository. Individual wrong decisions can therefore turn into drift. At the same time, we saw that generation and verification are different tasks.

That brings us almost inevitably to requirements.

We do not write detailed implementation prompts because agents need as much text as possible. We do it because Context is limited, agents have decision-making latitude, and plausible solutions can still be wrong.

So the first question is not simply: How do I write a better prompt?

It is: What actually has to be true?

The actual prompt comes at the end

My current workflow therefore usually does not begin by writing an implementation prompt.

It often starts with nothing more than an idea, a ticket, or an observation. Then discovery begins.

A simplified mental model looks like this:

Idea / Ticket
↓
Discovery
↓
Questions
↓
Alternatives
↓
Domain decisions
↓
Technical decisions
↓
Constraints
↓
Acceptance criteria
↓
Implementation prompt
↓
Agent
↓
Verification

This is explicitly not a process model that I tick off step by step. In my day-to-day work, there is no status transition called “Discovery complete.”

Some tasks are clear enough after five minutes; others need several rounds of discussion. In legacy systems, code often has to be examined first, and sometimes that is exactly what reveals a missing domain decision. In other cases, an existing reference implementation answers almost all technical questions immediately.

I work more by an 80/20 rule: I want to understand and decide enough for the next step to be controllable. I do not try to answer every imaginable future question in advance.

Discovery is complete enough when the next controlled step can sensibly begin.

That also means requirements never suddenly become complete. During implementation, new information can emerge, assumptions can turn out to be wrong, an existing contract can behave differently from what we expected, or a domain-specific edge case may only become visible once we walk through a concrete data flow. Refinement is therefore not a failure of discovery; it is part of it.

The LLM as a requirements sparring partner

At this point, a strong LLM has a different role for me than the coding agent will later.

It should not only answer my questions. It should ask me questions.

When I describe a feature idea, I want to know which decision is still hidden inside it. Which assumption has not been stated? Which failure case is missing? Which roles are affected? What does “delete” actually mean in the domain? Which information would a developer need in order not to make a product decision on their own? Which behavior is merely my spontaneous idea, and which part is actually a requirement?

Typical questions might be:

What is still unclear in this requirement?

Which assumptions are we currently making implicitly?

Which edge cases are missing?

Which domain decision is still open?

What explicitly does not belong to the scope?

Which existing system boundaries could be affected?

How will we know later that the implementation is correct?

A good planning model does not just answer questions. It makes missing questions visible.

This is not merely a theoretical use of LLMs. Research on LLM-assisted requirements elicitation now explicitly studies the generation of follow-up questions for stakeholders. A 2025 paper on software requirement patterns, for example, found that LLM-generated elicitation questions are broadly feasible, while also producing repetitions and out-of-scope questions and still requiring substantial expert assessment. A systematic mapping study from August 2026 reaches a similar picture across 74 analyzed papers: automation is comparatively common when identifying possible requirements, but becomes much thinner once consolidation and especially stakeholder validation are involved.

That fits my practical role for a planning model quite well: it is a sparring partner, not the requirements owner.

Who is actually allowed to make this decision?

Software developers are used to solving problems. During discovery, that can surprisingly quickly lead us to make decisions we were never authorized to make.

From a purely technical perspective, introducing another status might look elegant. A different data flow could be more consistent. An additional process step might eliminate an edge case. Or changing the authorization logic could make the implementation much simpler.

None of that means we are allowed to make that change.

Real projects have product owners, business departments, clients, domain experts, or other people who are responsible for particular domain decisions. If a ticket does not clearly define whether a user may reopen a process, “the technically nicest option” is not automatically the right answer.

Requirements engineering also means not making decisions in places where you do not actually have the authority to make them.

That applies to humans and agents alike.

A planning model can surface options, explain consequences, expose contradictions, and compare alternatives. The decision still belongs where domain responsibility lies, because technically correct does not automatically mean correct for the business.

In legacy systems, discovery becomes technical

In a greenfield project, many technical decisions can be described directly. In a legacy system, I often do not know enough about the real state of the system at the beginning.

That is when I start bouncing work back and forth between the planning model, the coding agent, and the repository.

Planning LLM
↓
Exploration assignment
↓
Coding agent inspects repository
↓
Findings
↓
back into planning
↓
new decision

The decisive difference from a normal coding assignment is the goal: the exploration prompt should not implement anything yet. It should find out, for example, whether a similar flow already exists, which patterns are actually used, which components are affected, how a data flow currently works, or which dependencies a planned change would touch.

Such an assignment can be very narrow:

Inspect how comparable create flows
are currently implemented in this feature.

Do not implement anything.

Report:
- relevant files,
- recurring patterns,
- deviations,
- dependencies in use,
- open questions.

If multiple competing patterns exist,
do not decide on your own which one
should become the future standard.

The repository therefore becomes part of discovery. This matters especially in evolved systems, because documentation and actual code do not necessarily tell the same story. OpenAI describes a related mechanism in its internal Data Agent: metadata alone is not enough there, so code is inspected deliberately to understand the actual meaning and origin of data. The team summarizes one of its lessons roughly as follows: meaning often lives in the code that executes, not just in the description around it.

For legacy software, I would formulate the idea even more broadly:

In legacy systems, requirements do not emerge only from conversations. Some of them have to be extracted from the existing system.

During this phase, the coding agent is an exploration tool before it becomes an implementer.

Discovery may diverge; implementation much less so

During discovery, I absolutely want creativity from a planning model.

It may develop alternatives, challenge an idea, suggest a different data flow, or explain why my first solution is unnecessarily complicated. A larger solution space is useful in this phase because I am still trying to understand which options even exist.

Once domain behavior, architecture, and coding style have been decided, however, the nature of the task changes.

Discovery
=
open the solution space

Decision
=
evaluate options

Implementation
=
close the solution space

A later article in this series will examine that pattern in more detail. For now, one observation from my own work is enough: creativity is not equally valuable in every phase.

If a project has decided how slices are structured, how dependencies flow, how state is modeled, and how naming works, I do not want an agent inventing another plausible variant for every new feature.

My personal standard has become:

The project should read as if one developer had written it.

I do not mean that every developer would produce identical code. I mean consistency. A repository should not reveal from its architecture which agent or model happened to work on which feature.

With coding style, layering, naming, and dependency rules, additional creativity is often not an advantage.

It is additional variance.

So what is an implementation prompt?

Against that background,

Build feature X.

is usually not an implementation prompt for me.

For a small proof of concept, it can be perfectly legitimate. A minimal correction does not need five pages of specification either. And if I deliberately want to see what kind of solution an agent develops on its own, the assignment may intentionally remain open.

For a domain-relevant change in an existing system, however, my work assignment looks very different.

A detailed implementation prompt can contain:

• the goal and domain purpose,
• scope and non-goals,
• relevant findings from discovery,
• affected slices or modules,
• domain decisions that have already been made,
• relevant architectural boundaries,
• existing reference patterns,
• data and state flows,
• error cases and edge cases,
• acceptance criteria,
• required tests,
• verification steps,
• Stop Conditions,
• and, where useful, a sensible implementation sequence.

Such a prompt can genuinely read more like a multi-page technical specification than a chat sentence.

An implementation prompt is not a shout across the room to an agent. It is a condensed specification of the problem and its boundaries.

Current OpenAI guidance for agentic models points in a similar direction: rather than prescribing every working step, prompts should define the outcome, success criteria, constraints, available evidence, and stopping rules. For coding workflows, the guidance additionally recommends acceptance criteria, tests, and rules for when an agent should continue working and when it should ask for help.

That is an important difference from the simplistic idea that prompt engineering merely means expressing the same request in more detail: the extra length has a purpose.

Every section should reduce a risk

Why do I need all this information? Not because an agent prefers long text, but because different parts of the assignment constrain different classes of failure.

Component	What risk does it reduce?
Goal	The agent does not optimize for a technically interesting but wrong problem.
Relevant Context	Task-specific knowledge is not automatically available.
Scope	Plausible additional features do not quietly become part of the assignment.
Constraints	The acceptable solution space is narrowed.
Existing patterns	Relevant local evidence becomes more visible than arbitrary examples the agent happens to find.
Non-goals	The change does not expand unnecessarily.
Acceptance criteria	“Looks plausible” is separated from “fulfills the assignment.”
Verification	Generated output does not become its own proof of quality.
Stop Conditions	The agent does not silently make new fundamental decisions when key assumptions break.

This is where the previous articles come together again: Context is limited, the solution path contains variance, and plausibility is not enough as a quality criterion.

Every additional section in a prompt should therefore reduce a concrete risk—not merely make the prompt longer.

Long prompts are not automatically better prompts

The argument so far could easily lead to the wrong conclusion: if a detailed prompt is better than an unclear one, then an even longer prompt must be even better. That is not how it works.

A gigantic assignment can become difficult to review. It can contradict itself. Old decisions may sit next to new ones. Relevant rules can disappear among irrelevant details. Most importantly, it can create a very large work package in which the agent operates for a long time before a human or another verification step sees the result.

That increases the possible drift distance. My practice is therefore to split larger initiatives deliberately into smaller work packages:

Discovery
↓
Work package 1
↓
Review / Verification
↓
Work package 2
↓
Review / Verification
↓
Work package 3

Smaller work packages shorten the distance between generation and verification.

You can see a similar principle in current agent harnesses. Anthropic describes both decomposition into manageable units and explicit contracts for what counts as “done” inside a work package and how that state is verified. Interestingly, the same experiment later found that with stronger models, some of this sprint structure could be removed again. The structure was therefore not a dogma, but a response to the uncertainty and capability limits of the respective task and model.

That is how I think about my own work packages as well: there is no ideal number of files, no ideal prompt length, and no universal number of acceptance criteria. Package size should follow uncertainty.

Bugs are a special case

This becomes even clearer with bugs. In a feature implementation, additional details can reduce uncertainty because many decisions have already been made; with an unknown defect, the same level of detail can make the investigation worse.

Suppose a list only refreshes after leaving the page and opening it again. If I tell the agent:

The problem is that Store X
is not invalidated after the update.

Add a reload there.

I may already have made the most important decision: the root cause.

If my hypothesis is wrong, the agent can now produce an excellent implementation of an incorrect diagnosis.

For bugs, I therefore often begin by describing:

Observed behavior
Expected behavior
Reproduction conditions
known observations
relevant constraints

Investigate the root cause first.
Do not implement a solution
until the actual flow has been understood.

Details should reduce uncertainty where decisions have already been made—not where the agent still needs to investigate.

At first, that may sound inconsistent with detailed prompts. In reality, it is the same rule.

We are not trying to specify as much as possible. We are trying to specify the right amount of decision-making freedom.

Questions are not a flaw in the prompt

Even after detailed discovery, a coding agent will encounter things during implementation that nobody saw beforehand.

That is normal. The expected API may not exist, a neighboring feature may behave differently from the documentation, two patterns may contradict each other, or the planned solution may only be possible by violating an architectural boundary nobody had noticed before.

An agent should not have to guess in such situations simply because we have decided that a “good prompt” supposedly prevents every follow-up question. Questions are part of the working model.

OpenAI describes its internal Data Agent in a similar way: when instructions are ambiguous or incomplete, the system actively asks clarifying questions and can use reasonable defaults for low-risk gaps. The principle behind this is more important than the concrete implementation: not every uncertainty carries the same risk.

For trivial decisions, an agent can have autonomy; for domain-relevant or architectural decisions, a breakpoint may make more sense.

Stop Conditions define the end of autonomy

That is why explicit Stop Conditions have become one of the most useful prompt components for me.

For example:

If no existing architectural pattern
for this case can be found:

STOP.

Report the finding.

Do not make a new global
architectural decision on your own.

Or:

If the expected API does not exist
or its contract differs materially
from the described behavior:

STOP.

Document the deviation and
suggest possible next steps.

Other breakpoints can include:

• a required contract is missing,
• the ticket contradicts the actual existing behavior,
• the requested implementation would violate a defined dependency rule,
• a domain state has not been specified,
• the implementation requires substantially larger changes than the stated scope.

Not every uncertainty has to be resolved in advance. But we can define where the permitted decision-making space ends.

Stop Conditions therefore serve the same purpose as other constraints: they do not prescribe the entire path; they limit the solution space.

Current OpenAI guidance now also explicitly names such stopping conditions and connects them with success criteria and rules for missing evidence. That is remarkably far removed from the old idea of a secret prompt formula.

Persistent decisions do not belong in a single task

A new fundamental decision can still emerge during implementation.

Perhaps we realize that a certain class of features should use a single mapper consistently in the future. Maybe a new dependency rule emerges. Maybe naming is standardized, or an architectural pattern that was previously implicit is consciously decided for the first time.

That decision initially belongs in the current working context. But then a second question follows: where should it live when the next feature arrives?

If the answer is “in last Tuesday’s prompt,” we have a problem.

Persistent rules need a persistent home. Depending on the kind of information, that might be an Agent File, a Skill, project documentation, an ADR, an architecture test, or another automated rule.

Task-specific
→ implementation prompt

reusable workflow
→ Skill

persistent project rule
→ Agent File / Documentation / ADR

mechanically verifiable rule
→ Test / Linter / Architecture rule

The boundaries are not identical in every agent system; what matters is the intent. Task-specific decisions belong in the implementation prompt. Persistent project decisions need a persistent home. That connects directly back to Article 4 and at the same time avoids a problem from Article 6: an important decision should not become a pattern merely because it happened to be committed as code once. It should be made visible as a decision.

I hardly write implementation prompts anymore

This brings us to a perhaps slightly unusual part of my personal workflow.

I still write short correction prompts directly. If a task is small and unambiguous, I do not need an additional process.

For larger features, however, I work intensively on requirements, scope, decisions, architecture questions, and acceptance criteria—but I often no longer write the final detailed implementation prompt myself. I let an LLM produce it.

I hardly write implementation prompts anymore. I work out their content.

That is a significant distinction for me. I do not want to spend my attention deciding whether section three should be called “Constraints” or “Technical Boundaries.” I want to decide which boundary actually applies.

A strong model is very good at translating already clarified information into a structured work assignment. It can remove redundancy, group decisions, make acceptance criteria explicit, and turn several discussion loops into a coherent execution briefing.

The critical boundary lies elsewhere: AI may write the prompt. But it should not quietly invent the requirements.

If the planning model fills a missing product decision with a plausible option and then confidently writes it into the implementation prompt, we have gained nothing. We have merely hidden where that decision originated.

A recent Anthropic analysis of roughly 400,000 Claude Code sessions between October 2025 and April 2026 provides an interesting picture from practice. In its classifier-based evaluation, humans made roughly 70 percent of planning decisions on average, while Claude made roughly 80 percent of execution decisions. Anthropic interprets this as a recognizable division of labor: humans determine more strongly what should be built and when something counts as done; the agent takes over more of the concrete execution. The study is not a universal law of agentic work, but it describes remarkably well the pattern that has emerged in my own workflow.

OpenAI describes a similar shift from an internal agent-first software project: human work increasingly focused on shaping environments, specifying intent, and building feedback loops while Codex generated the code.

My short version is:

The human does not necessarily author the prompt. The human authors the requirements.

The prompt as a compiled work artifact

You can think of this—explicitly only as a metaphor—like a small compiler.

Intent
↓
Requirements
↓
Decisions
↓
Constraints
↓
LLM
↓
Execution Prompt
↓
Agent
↓
Artifact

The term “prompt compiler” is technically imprecise, of course: an LLM does not compile requirements deterministically the way a TypeScript compiler compiles source code. But as a mental model, I still like the metaphor because it shifts where we locate the actual value.

The prompt is not magical source code from which a feature suddenly appears. It is a condensed representation of already developed information and decisions, shaped into something an agent can work with.

That also explains why the final prompt can be extensive even though I have spent very little time on its exact wording: the real work happened before it.

The same pattern works for writing

This way of working is not limited to software development.

This article series, for example, does not come into existence because I begin with:

Write an article about hallucinations.

It starts with a thesis or an observation. Then come discussions: terms are separated, overstrong claims are corrected, research is gathered, non-comparable numbers are discarded, and personal experience is put into context. Only through that process does it become clearer which claim is actually defensible and which one merely sounds good.

Only then does a detailed generation brief emerge.

initial thesis
↓
discussion
↓
research
↓
counter-questions
↓
decisions
↓
narrative thread
↓
generation prompt
↓
draft
↓
editorial review

The generation prompt may already contain the title, central claims, source framework, examples, statements that must explicitly not be made, desired transitions, and links to other articles in the series.

From the outside, that looks like a very good prompt. In reality, it is only the last visible stage of a much longer discovery process.

The generation prompt is not the creative beginning. It is the result of a thinking process that came before it.

And of course the first draft is still not the published article; generation and editorial work remain separate steps.

The same applies to image generation

Something similar happens with images. I could ask an image model:

Create an infographic about architecture drift.

It might even produce something attractive. But the more important work begins before that: what should the graphic explain? Which relationship should be visible at a glance? Do I need a process, a comparison, or a spatial metaphor? What must the image specifically not imply? Which text has to appear exactly? Which elements are semantically relevant and which are merely decorative?

Only once those questions are clear do I need a translation into the language of the respective image model.

communication goal
↓
visual concept
↓
boundaries of the claim
↓
visible content
↓
style
↓
image prompt
↓
Image Model

Again, the human does not necessarily have to be the best prompt author. The human mainly has to know what the image is supposed to communicate.

The specialized model—or another LLM—can then help translate that intent into a suitable prompt.

Prompt engineering becomes engineering before the prompt

That changes what the term means to me.

Prompt engineering has not disappeared. Concrete wording still matters; structure, examples, priorities, and clear instructions influence model behavior. But in real agentic work, that is only one part of a larger problem.

Anthropic now describes this shift on a technical level as moving from prompt engineering toward Context Engineering: instead of optimizing isolated phrases, agent systems must curate the entire information state available to the model. OpenAI reports a parallel lesson from its own practice: overly rigid, highly prescriptive prompts can work worse, while the more robust approach was to define the goal and relevant boundaries and let the model determine the concrete path.

For my own work, I would take the idea one step further:

Prompt engineering is shifting from writing prompts to engineering the information and decisions from which prompts emerge.

That includes discovery and requirements just as much as Context selection, architectural rules, acceptance criteria, verification, and the conscious decision about where an agent is allowed to decide for itself. The prompt therefore does not stand at the beginning of the process. It comes fairly late.

Requirements are the first boundary

That brings us back to the role of this article within the series.

Article 5 showed that several plausible solution paths can exist. We do not want to eliminate that property completely. An agent should be allowed to decide which file to inspect first or how to solve a local implementation detail within the existing architecture.

Article 6, however, showed that plausible does not automatically mean correct. That is why we need boundaries, and requirements first define what must be true at the end.

They answer questions such as:

Which domain states are allowed? What counts as success? What is an error? Which users may perform which action? What belongs to the scope? Which properties are non-negotiable? Which conditions must be observably satisfied after implementation?

Requirements define which outcomes can be considered acceptable at all.

They do not automatically determine the complete solution path. They describe the acceptable outcome space. That distinction matters.

Requirements are not architecture yet

And even then, something is still missing. Consider a requirement:

A user may only modify their own data.

That describes desired domain or security-relevant behavior.

An architecture rule, by contrast, might be:

Presentation must not access
Infrastructure directly.

Both statements constrain solutions, but at different levels.

Requirements primarily describe what must be true.

Architectural constraints describe more strongly which structural boundaries must not be violated while solving the problem.

This distinction becomes important when agents start changing larger parts of a system independently. A result can be perfectly correct from a domain perspective and still be a structurally poor solution.

The prompt starts earlier

When I hand a multi-page implementation prompt to a coding agent today, the most important part of the work has already happened. We have asked questions and inspected the repository, separated domain decisions from technical ones, defined scope and non-goals, clarified responsibilities, specified the agent’s permitted decision-making space, and decided how the result will later be verified. Only then does that become a prompt.

Prompt engineering starts before the prompt. Article 4 showed that the agent needs relevant Context; Article 5 showed that it can choose different solution paths within that Context; and Article 6 showed that a plausible path can still rest on a false assumption. Article 7 adds the next consequence: we have to define more precisely which outcomes we accept and where the decision-making space ends.

Requirements are the first boundary, but they are not enough. Even if it is completely clear from a domain perspective what must be true, one question remains: how do we ensure that the solution fits structurally into the system that already exists? That is what the next article is about.

Requirements constrain the domain-acceptable outcome. Next, we have to do the same for the structure of the system.

Sources and framing

• OpenAI – Model Guidance / Prompting Best Practices, as of September 2026. The current GPT-5.5 guidance recommends defining outcome, success criteria, constraints, available evidence, and explicit stopping conditions for agentic tasks while discouraging unnecessary process micromanagement. This is product-specific guidance, not a universal theory of prompting. Model guidance
• OpenAI – Inside OpenAI’s in-house data agent, January 2026. The field report describes layered Context, active clarification for ambiguous or incomplete instructions, sensible defaults, and the lesson “Guide the Goal, Not the Path.” It also describes deliberately using code as a source of semantic evidence. Inside OpenAI’s in-house data agent
• OpenAI – Harness engineering: leveraging Codex in an agent-first world, February 2026. The report describes an internal agent-first software project in which human work shifted strongly toward intent, environment design, and feedback loops. A large monolithic AGENTS.md proved problematic; a shorter agent file instead acts as a map into a versioned knowledge base. Harness engineering
• Anthropic – Effective context engineering for AI agents, September 2025. Anthropic describes Context as a finite resource and shifts the focus from isolated prompt wording toward deciding which information should be available to the model at which point in time. Effective context engineering for AI agents
• Anthropic – Agentic coding and persistent returns to expertise, June 2026. Privacy-preserving, classifier-based analysis of roughly 400,000 Claude Code sessions between October 2025 and April 2026. In a typical session, humans made roughly 70 percent of planning decisions while Claude made roughly 80 percent of execution decisions. This describes usage patterns of one concrete product, not a universal law of agentic work. Agentic coding and persistent returns to expertise
• Anthropic – Harness design for long-running application development, March 2026. The field report examines planner/generator/evaluator structures, sprint contracts, and testable criteria. Particularly interesting is the later simplification: with Opus 4.6, sprint decomposition could be removed, while the evaluator still added value near the model’s capability limits. Harness design for long-running application development
• Franch et al. – Leveraging Requirements Elicitation through Software Requirement Patterns and LLMs, REFSQ 2025. The paper shows that LLM-generated stakeholder questions are broadly feasible, but can produce repetitions and out-of-scope questions and still require substantial expert assessment. Publication entry
• Eltahier et al. – Automated Software Requirements Elicitation: A Systematic Mapping Study, August 2026. The study classifies 74 peer-reviewed papers from 2021 to 2025. All 74 automate identification; 51 percent reach structuring, 23 percent consolidation, and only 8 percent technically integrated stakeholder validation. Information 17(8), 777
• Pasquale et al. – Exploring the Use of LLMs for Requirements Specification in an IT Consulting Company, IEEE RE 2025. The industrial case shows that LLMs can standardize requirements specifications and support their creation, but quality remains strongly dependent on the input and human domain and technical review remains necessary. IEEE DOI