Prompt-Driven Feature Development in Production Codebases

Prompt-driven feature development in production codebases now depends less on clever instructions than on the environment in which agents work. As agents make changes across files and sessions, teams need engineered context, including specifications, codebase structure, constraints, and feedback loops. That discipline turns fast code generation into development a production system can sustain.

Why AI agents in production codebases have outgrown the prompt-and-review loop

Agents now explore repositories, implement changes, run tests, fix errors, and iterate across extended sessions. Their work spans files. A prompt can therefore shape changes across multiple test suites and downstream dependencies before a reviewer examines the result. The operational unit is no longer a generated snippet but a sustained sequence of decisions about an existing system.

CLI-first agents, agents native to development environments, and cloud engineering agents are converging around repository awareness, long-running execution, and sub-agent orchestration. This shared architecture makes the shift more durable than any particular interface. It also exposes the limit of treating a good prompt followed by code review as sufficient discipline. Review remains necessary, but it happens after the agent has interpreted intent and acted on that interpretation. The missing control is the information that guides those decisions throughout execution.

What unconstrained prompt-driven development actually produces at scale

Without structured context, generating code faster leaves more code to check and more work to decide whether it fits the system. Models train on code that already exists, including its flaws, and tend to add more technical debt per line than experienced engineers do. Unspecified requirements leave room for patterns that appear plausible without meeting the production system’s needs.

The documented problems extend beyond maintainability to correctness and security. AI-generated code produced more logic and correctness errors, more security findings, and a greater likelihood of cross-site scripting vulnerabilities than human-authored code. CVEs formally attributed to AI-generated code climbed steeply across early 2026. These are trailing indicators of security debt becoming attributable and public, rather than evidence that generation itself provides adequate assurance.

Non-determinism adds a separate obstacle to correcting those defects. Identical prompts can produce functionally different code across invocations, so regeneration does not reliably preserve a previous fix. Specification gaps can return in different forms. Volume and variation increase the cost of leaving intent, boundaries, and verification implicit.

Why the productivity numbers are real but incomplete

The Microsoft/arXiv rollout study found that Copilot CLI adopters merged roughly a quarter more pull requests than they otherwise would have. That is a genuine measured gain in output. An argument for stronger engineering discipline must account for that benefit.

The same study examines individual output. It does not show whether the extra pull requests improved business value or code quality. Faros AI’s research argues that coding assistants help developers produce more work without helping the company get more done. Producing contributions and turning them into changes that meet the system’s needs and can be maintained are separate kinds of work.

AI-generated pull requests wait 4.6 times longer for code review than human contributions, and review times across teams grew sharply after AI adoption. Code was being generated faster than it could be checked. The resulting backlog is an organizational cost that individual output measures do not capture. What discipline helps turn gains for each person into gains for the organization?

What context engineering actually means — and why it differs from prompt crafting

Context engineering is the practice of defining, structuring, and governing the information an agent operates within. It covers what the agent knows about the system, which constraints govern its actions, and how its output is evaluated. The unit of design is the operating environment. Unlike a one-shot prompt decision, that environment persists across sessions and can guide multiple agents.

Prompt crafting still helps state a task clearly, but it cannot replace knowledge of the system that lasts across sessions. Structural context makes modules and existing capabilities discoverable. Specification context records intent, constraints, and acceptance criteria, while constraint context makes security boundaries, API contracts, and ownership rules explicit. Feedback context supplies test results, lint output, and review signals that an agent can use to correct its work.

The arXiv research agenda “From Prompting to Engineering” argues that prompts and their surrounding context increasingly participate in the specification, production, and evolution of software artifacts. It calls for the same concerns about evaluation, traceability, maintainability, and governance that apply to other development artifacts. A well-phrased request can express intent, but a governed environment preserves that intent while the software changes.

How specification-driven development operationalizes context for agents

Specification-driven development makes a structured, versioned specification the primary input to agent behavior, task decomposition, and code generation. Instead of reconstructing requirements from successive prompts, agents work against persistent context that reviewers can inspect. The specification functions as a contract for implementation. It provides a baseline against which drift can be identified across sessions and agents.

GitHub’s Spec Kit, released in September 2025 under an MIT license, implements this approach through a structured pipeline. Specification sets out what is wanted in natural-language descriptions, while planning records the choices made about architecture and the stack. Task decomposition then connects the plan to implementation. Convergence completes the sequence by verifying the codebase against the specification, rather than treating generated code as sufficient evidence of completion.

AWS used the spec-driven tool Kiro to reduce a four-week notification feature build to a day and a half. The case illustrates time compression through structured context. It also addresses the objection that specification work necessarily slows delivery. The effort is front-loaded, while ambiguity otherwise creates downstream rework, review backlog, and security findings. That example shows that spec-first work can replace time spent resolving uncertainty later.

A specification baseline also changes the reviewer’s task. Reviewers can check implementation against known intent instead of inferring requirements from the code they have received. Drift becomes attributable to a documented contract. This makes review more grounded, while leaving a further engineering question about how changes to the instructions themselves are controlled.

Treating the prompt layer as source code, not a configuration afterthought

A single clarifying sentence in a prompt can cause a structured-output endpoint to return malformed responses on roughly 14% of requests. The failure need not be consistent to be costly. Retries can hide intermittent malformed responses from dashboards until users surface the problem. A small text edit can therefore create a production regression without looking like a substantial software change.

In a prompt-as-code workflow, a tracked file or registry replaces a Notion document or Slack thread as the home of every prompt. Every change goes through the same pull request workflow as code, so reviewers can see the diff and test results. At minimum, each prompt has a smoke test against golden inputs that validates output shape in CI before merge.

Runtime traceability connects those controls to production behavior. Logs include the prompt’s version identifier so a regression can be traced to the exact instruction set involved. Rollback is equally part of the workflow, with a one-button revert that does not require a full application redeploy. These properties make prompt changes inspectable before release and recoverable afterward.

Repository-based prompts offer simplicity, visible diffs, and alignment with the release cycle. Managed registries decouple updates from deployments, support non-engineer access, and allow rollback without redeploying the application. Neither architecture is universally preferable to the other. Release cadence and who needs to update prompts determine the choice, while the engineering obligations remain the same.

How codebase structure shapes what agents can and cannot do reliably

An agent exploring a repository consumes its structure as information about how the system works. Redundant files, unused modules, and conflicting logic are therefore more than maintenance burdens. They are ambiguous inputs to implementation decisions. Clear module boundaries and naming conventions make existing capabilities easier to identify, while inline documentation and architecture decision records reduce dependence on inference from code alone.

Deprecation conventions also show which code is still there but should no longer guide implementation. Structural clarity constrains the range of acceptable variation when identical prompts can generate different results. Cleanup has a cost, but ambiguity compounds too. Agents working in poorly structured repositories can leave them even harder to work in.

The 2026 IEEE Transactions on Software Engineering paper “More Code, Less Understanding? On the Impact of AI Assistants on Developers' Productivity and Code Ownership” documents reduced code ownership even as AI assistance improves task completeness. Developers struggled more to understand and explain their implementations. That weakens the human check on structural drift, making navigability a condition of reliable agent work.

Governance and feedback loops that keep agent-generated code aligned over time

Context helps less when it no longer matches the system as built. Specifications drift, prompts age out of alignment, and structural clarity erodes under the volume of generated changes. Initial setup is therefore only the beginning. The 2025 DORA “State of AI-assisted Software Development” finding that AI amplifies existing engineering systems places governance alongside code quality at the center of sustained results.

Automated tests need to validate changes against specifications, while specification versioning keeps the next session grounded in the current system. Review workflows also need to account for agent-generated volume. Review times across teams grew 91% after AI adoption, showing how far the same verification practices could stretch.

GitHub’s 2026 product changes, including PR caps, stacked pull requests, and a redesigned PR inbox, reflect that pressure on reviewer bandwidth. These changes address the flow of contributions, but governance also requires a reliable baseline for judging them. A current specification gives review and automated checks that reference point. Without it, even faster review can judge work against intent that is out of date.

External compliance pressure reinforces the need for traceability. The EU AI Act makes transparency and traceability legal concerns in high-risk contexts, while the NIST AI RMF supports them as voluntary best practices. These pressures help move enterprise work from spec-assisted coding toward spec-governed, multi-agent workflows. Yet documentation alone cannot establish ownership. Engineers must still be able to explain implementation choices and challenge generated work on their own, with ways to correct it beyond asking for another regeneration.

What engineers are actually responsible for when agents do the mechanical work

As agents take on mechanical coding, engineers become responsible for the conditions under which that work is performed. Specification authorship defines intent clearly enough for execution and audit. Structural judgment keeps the repository navigable as an information environment. Constraint design establishes what agents must not do, while feedback loop design determines how tests, review triggers, and monitoring detect drift before it compounds.

A specification can guide several sessions, and a missing boundary can affect many generated changes. The engineer designing that context is therefore making higher-stakes decisions than those involved in producing boilerplate. The role shifts toward governing interpretation and acceptance.

The ownership finding in the same IEEE paper shows why engineers must make a point of understanding the code on their own. The METR finding that senior developers were slower with AI tools despite believing they were faster provides a related warning about perceived gains. It cautions against assuming that new tools improve an unchanged workflow, without establishing that context engineering alone would reverse the result. Measurement must include the work required to understand and validate what agents produce.

“From Prompting to Engineering” identifies the remaining gap between the growing reach of prompt-based interactions and the immature practices surrounding them. Specifications, tracked prompts, navigable repositories, and maintained feedback loops are not an auxiliary discipline detached from development. They are how engineers govern a codebase partly written by agents.