Topics/AI-Driven Software Engineering: Specifications, Context, Execution, and Feedback

Topics synthesize engineering questions that cross several modules. Pattern definitions, attributed cases, and workshop records remain authoritative on their own pages.

AI coding now extends well beyond completion inside an editor. An agent can inspect a repository, break down work, change several files, run tests, and prepare a commit. Code generation is one step in that process. Engineering teams therefore face a broader set of questions: how to define a bounded unit of work, control which context can affect a decision, verify an outcome, and prevent local delivery speed from degrading the architecture over time.

These questions span perception, memory, reasoning, action, reflection, and governance. ADPS treats them as a cross-cutting topic rather than assigning another pattern number.

Terminology

The terms overlap and continue to evolve. ADPS uses each at the level where it is useful and does not present this vocabulary as an industry standard.

The bottleneck is moving

As agents produce code more quickly, scarce engineering capacity moves upstream and downstream:

1. Task definition. The problem, constraints, and observable acceptance conditions must be explicit enough to guide execution.
2. Context management. Repository files, architecture decisions, runtime logs, previous work, and external material should not enter the model indiscriminately.
3. Acceptance design. Compilation is one class of evidence. User-visible behaviour, data integrity, performance, security, and operability may also matter.
4. Authority boundaries. Read, write, execute, commit, and deploy permissions require separate admission decisions.
5. Architecture stewardship. Every local task may pass while the repository accumulates duplication, dependency drift, and unnecessary code growth.

AI software engineering therefore cannot be evaluated only by lines of code, pull-request volume, or generation speed. Specifications, evidence, traceability, review load, and downstream maintenance cost also matter.

A five-layer engineering structure

Versioned artifacts and runtime evidence connect these layers. Typical artifacts include specifications, architecture decision records, plan steps, code diffs, test results, action events, checkpoints, and repair proposals.

From assistance to managed autonomy

These stages describe engineering capability, not a procurement checklist. Legacy systems, high-traffic services, and regulated work usually remain at lower autonomy levels for longer.

Evidence from the Perception workshop

The first ADPS Perception workshop on 13 August 2026 surfaced several comparable practices:

• The public OpenLogos and RunLogos projects connect Why, What, How, and acceptance criteria in a specification chain, then slice scenarios into vertically complete units of work.
• One class of large backend teams records token use, design iterations, and code changes to observe how AI changes actual engineering work.
• Greenfield projects and high-traffic brownfield systems use different adoption paths, while both place goals and constraints in the task definition.
• As AI-produced pull requests grow, AGENTS.md and skills do not carry architecture stewardship on their own. Repositories still need scheduled cleanup, dependency checks, and architecture review.
• A game-development practice uses ADRs, TDD, task files, and daily records for forward and reverse checks, selecting text or visual input for artefacts such as Unreal Engine Blueprints.
• One class of complex systems separates acceptance into algorithm, map, runtime-environment, and business-behaviour layers. The applicable layers follow the external outcomes a change can affect.

The teams use different tools, but they address the same engineering problem: turning human intent into work an agent can execute, a team can verify, and a repository can sustain.

A conservative adoption path

1. Choose a bounded task with a clear rollback path and write the acceptance criteria first.
2. Keep specifications, constraints, and architecture decisions in the repository so people and agents read the same version.
3. Define the context ingress for that task: required, on-demand, and prohibited information.
4. Begin with a minimal tool set in a sandbox and record plans, calls, state changes, and verification results.
5. Verify external behaviour instead of accepting the agent's completion claim as final evidence.
6. Review whether failures changed specifications, tests, rules, or architecture, and remove duplicated implementation and stale context.

Open questions

• How detailed should a specification be before it starts fixing implementation decisions too early?
• How should teams measure review burden, maintenance cost, and architecture drift caused by agent-produced changes?
• Which long-running task state belongs in checkpoints, the repository, or the control plane?
• When an agent can change code, tests, and specifications together, how can acceptance criteria remain independent?
• As an individual tool becomes an enterprise engineering system, how should authority, business accountability, and architecture ownership move?

The last question is continued in Enterprise Agent Evolution and Operating Model.

Sources

• First ADPS Perception Module Workshop
• GitHub Spec Kit: Spec-Driven Development
• Anthropic: Effective context engineering for AI agents
• OpenAI: Harness engineering
• OpenAI: Running Codex safely
• Anthropic: Effective harnesses for long-running agents