2 Background
2.1 AI Assistants and Agents
The tools that assist developers as they write code have changed quickly, from completing a single line to carrying out whole tasks on their own. Integrated development environments have offered identifier and interface completion since the 1990s. By the late 2010s, machine-learning models trained on large code corpora ranked those suggestions. Such systems retrieve and rank symbols that already exist; they do not compose new code. The generative shift came when large language models (LLMs), whose training data includes large quantities of code, began producing novel, multi-line completions in the editor. GitHub Copilot introduced this form in 2021 [7]. A distinct mode of interaction followed in late 2022, when general-purpose conversational assistants based on LLMs reached the public. These were not explicitly coding tools, but developers used them to explain unfamiliar code, stand in for documentation, think through a problem, and draft code snippets to copy and paste. This conversational mode soon entered the editor and then moved from advice to action. AI assistants began acting directly on software projects. Tools of this kind emerged over 2024 and 2025 [8], [9]. The systems under study descend from this conversational line.
We use the term agent in a specific sense. In its classical formulation, an agent is anything that perceives its environment through sensors and acts upon that environment through actuators [10]. In an LLM-based agent, the model serves as the central controller within an iterative loop. The surrounding system provides planning and memory and equips the model with perception and action mechanisms through which it can use tools and respond to its environment [1]. Within the loop, the model reasons about the goal, chooses an action, observes the result, and decides what to do next [11]. Accordingly, agent denotes a model-directed system with these capabilities. A coding agent applies them to a software project, allowing the model to inspect and edit files, run commands, and revise its work against the results.
The distinction between two forms of LLM-based agent matters to our comparison. A purpose-built application can implement an agent by calling a model through its programming interface, assembling the input it receives, exposing tools, and routing its outputs in code. Alternatively, an interactive coding agent can package that machinery as a general development tool to which the developer assigns work directly. A framework can then operate on top of that coding agent by supplying natural-language instructions, roles, and procedures for it to follow.
Attempts to measure the effect of these tools on developer productivity have reached conflicting conclusions across different generations of the technology. Field experiments with an earlier generation of assistants reported substantial gains. One study pooled three randomised controlled trials at Microsoft, Accenture, and a Fortune-100 company, in which nearly five thousand professional developers using an AI assistant completed around a quarter more tasks, with the clearest gains among the less experienced [12]. A later METR trial of early-2025 tools reached the opposite result among experienced open-source developers working on large repositories to which they regularly contributed. When allowed to use AI tools, primarily the Cursor editor [13] with Claude 3.5 and 3.7 Sonnet, they were roughly 19% slower even as they expected the tools to speed them up [14]. Their models, tools, tasks, and participants differ, so the effect appears to depend on those conditions. A third study varies neither the tool nor the task but the developer. Among a hundred students who built small graphical applications by prompting an agent, without ever seeing the code it wrote, those who scored higher on a computer-science test and those who wrote more clearly both produced better results, and the test scores accounted for the larger share of the difference [15]. These studies vary the tool, the generation, and the developer. None varies the workflow or framework through which a developer uses AI assistance, the dimension we compare.
2.2 Context Windows and Context Decay
Whatever its form, an agent is built on a model that accepts input and produces output in units called tokens. The model itself does not retain the conversation between independent calls. Instead, the surrounding system preserves the session’s continuity by assembling prior messages, tool results, and other retained content as the next call’s context. The context window bounds the span of input and output that the model can process in that call. This context can include the system prompt, the agent’s instructions, tool calls and their results, and preceding exchanges retained by the system. The new output then becomes part of the history on the following call. At the time of writing, a frontier model’s context window spans several hundred thousand to a million tokens, yet a long real-world task can still reach that limit [16], [17].
The growing conversation history creates strain on both capacity and cost, a condition we refer to as context pressure. Bringing the session closer to the context-window limit makes each later call process more input tokens than the one before it. Because model use is priced by the input and output tokens processed, the total input cost of a long session can grow faster than its number of turns [18]. Prompt caching can lower the price of a repeated prefix, but it does not remove those tokens from the context window, and cache reads and writes remain billable.
A model does not use this growing context evenly. Controlled experiments on long-context models found a U-shaped pattern. Performance is highest when the relevant information sits at the start or the end of the input and falls sharply when it lands in the middle [2]. Usable capacity is smaller than the raw token count suggests. In a coding session, subsequent exchanges push earlier decisions and instructions deeper into the model’s context, where they can become harder to recover. The agent may then lose relevant information or reasoning consistency as this accumulation continues [2], [16]. In this thesis, we refer to the loss of recall and reasoning fidelity over extended context as context decay.
One response is compaction [16]. As a conversation approaches its limit, the surrounding system replaces earlier history with a shorter summary and continues from it. This reset frees space in the context window and reduces the input carried into the next call, but the omitted detail is no longer directly available to the model. Compaction exchanges fidelity for capacity rather than eliminating the accumulation problem.
Together, the decline in reliability and the rise in cost have made deliberate management of the context window a concern in its own right. Early practice centred on prompt engineering, structuring the natural-language input given to a model to elicit a particular response. As work grew into long agentic sessions, the harder question became what the context window should hold at each step, not only how to phrase a single request. This wider practice manages the whole body of context supplied to a model so that the agent’s limited attention and tokens remain focused on relevant material. It is known as context engineering [19], [20]. The strategies in the rest of this chapter are different forms of it.
2.3 Spec-Driven Development
One way to keep an agent focused is to give it a durable specification of what it should build before implementation begins. In AI-assisted development, this approach is known as spec-driven development (SDD). Its underlying principle predates AI. Design by Contract, described in 1992 [21], makes the specification part of the program itself. It attaches to each routine the conditions assumed on entry, the guarantees required on exit, and the invariants preserved throughout. Test-driven development (TDD), codified in 2002, reverses the usual order of coding and testing. It begins with tests that define correct behaviour, so an executable specification of what the code must do precedes the code itself [22]. The name has an earlier history of its own. In 2004, an approach called specification-driven development [23] combined TDD with Design by Contract, treating tests and contracts as complementary kinds of specification. We reserve SDD for the current AI-assisted practice.
Beyond defining the intended software, the specification helps manage the agent’s context. When developers improvise instructions turn by turn, their intent remains only in a lengthening conversation and can become difficult to recover. SDD instead fixes that intent in a durable artifact written before the code. The conversation still grows, but the agent can return to the specification and check its work against it. SDD is therefore one context-engineering strategy.
As a named practice in AI-assisted development, SDD took shape over 2025 in tools at different implementation layers. Amazon’s Kiro, announced in July as an agentic development environment, built the practice into the tool itself. Its agent carries a developer from natural-language requirements through a technical design to sequenced implementation tasks [24]. GitHub’s Spec-kit, released in September, instead supplies an external toolkit that brings a sequence of specification, planning, and implementation to an existing coding agent. It turns specifications into software on the premise that the spec, not the code, is the source of truth [3].
In the core workflows introduced by both tools, one agent carries the specification through planning and implementation. The spec-driven discipline itself does not determine how many agents perform the work.
2.4 Multi-Agent Systems
Another context-engineering strategy distributes work across several agents. A multi-agent system (MAS) consists of agents whose interactions contribute to a shared task. Their organisation varies: agents may discuss the same problem, take specialised roles, or receive separate parts of a decomposed task [25]. In the decomposed form APM uses, each part can be handled in its own conversation, reducing the accumulating context burden on any one of them and allowing independent work to proceed in parallel. The value of this decomposition depends on how readily the work can be divided and how well the agents coordinate.
Multi-agent systems have a long history in artificial intelligence, where they describe collections of autonomous entities acting within a shared environment [10]. Capable language models prompted a wave of research that applied the idea to LLM-based agents. During 2023, several systems organised these agents into role-specialised teams, including teams applied to software tasks. CAMEL paired agents in a structured dialogue [26]. ChatDev cast them as the staff of a virtual software company [27], while MetaGPT coordinated them through the documents and standard procedures of a development process [4]. Microsoft’s open-source AutoGen framework supported collaborative conversations between agents that solved complex problems and wrote code [28]. These research systems belong to the purpose-built form introduced earlier. The code assembles the context and tools for each agent and routes messages between them, while the models choose actions within that scaffold.
The evidence that this approach improves performance compared with a single agent is weak. One study analysed more than sixteen hundred execution traces from seven multi-agent frameworks and found recurrent failures across their workflows, while gains over single-agent systems or simpler baselines were often minimal [25]. A separate empirical comparison found that the advantage of a MAS narrows as the underlying model grows more capable, so much of the benefit seen with weaker models recedes with stronger ones [29]. Together, these results suggest that any improvement from division of labour is neither reliable nor stable as the models improve.
Practitioner accounts identify similar limits for agents used in software development. Anthropic reports a large gain from a multi-agent system over a single agent on open-ended research, where the task allows broad parallel search, and identifies coding as a poor fit. Most coding work, it notes, divides into fewer genuinely independent pieces and depends on context that every agent would need to share [30]. Cognition similarly argues that splitting coding work disperses decisions and prevents agents from sharing enough context, leaving the resulting systems fragile [31]. Although these reports carry the weight of practice rather than controlled measurement, they consistently identify coordination as particularly difficult for the software work we examine. Yet an agent taking on a large task alone still encounters the accumulation described in Section 2.2. Its context grows, its reliability decays, and the cost of each step rises. The single agent and the coordinated team each face a difficulty the other does not.
2.5 Frameworks on Top of a Coding Agent
Multi-agent coordination nevertheless appeared in everyday development through external frameworks built on the coding agents developers already use, rather than through the purpose-built research systems of Section 2.4. Their natural-language instructions, role descriptions, and methodology guides shape how an existing agent approaches its work. The field has not agreed on a name for this class. We refer to them as frameworks operating on top of a coding agent. Some guide one agent through a workflow. Others coordinate several agents and thus implement a MAS.
How such frameworks coordinate several agents has changed as coding agents have become more capable. In earlier forms, the user organised each agent in a separate conversation, assigned its role and task through explicit instructions, and carried work between conversations through shared files. BMAD initially followed this arrangement [32]. It assigned a role to each agent so that they collaborated like members of a software development team.
Later, coding agents gained the ability to delegate work to other agents launched into separate conversations. These delegated agents are known as subagents. They receive work from and return their results to the agent that launched them. Frameworks can build around this lower-friction capability. Superpowers, for example, uses reusable natural-language files to teach a coding agent to divide work into tasks and launch subagents to execute and review them [33]. Because the two arrangements are not exclusive, a framework may coordinate several user-facing agents while also using subagents within one or more of them.
2.6 Agentic Project Management and the Research Gap
We present and evaluate Agentic Project Management (APM). The author designed and built APM independently, first releasing it as open source in May 2025 [5]. APM operates on top of an existing coding agent and combines the context-engineering strategies of Section 2.3 and Section 2.4 by having several agents follow a spec-driven workflow. APM’s first release predated Kiro in July and Spec-kit in September, two of the tools on which early practitioner reviews of SDD focused [34], [35].
APM has been revised continually as the coding agents beneath it and the underlying models improved. For this thesis, APM v1 was developed as a ground-up redesign whose roles, workflow, artifacts, and file structure differ substantially from earlier releases. In the rest of the thesis, APM refers to this release, and we write APM v1 where it must be distinguished from earlier ones.
One design choice persisted through that redesign: APM’s coordination is user-mediated. Several agents work in their own conversations, and every exchange among them passes through the user. These exchanges give the user points at which to review the agents’ work, in contrast to prompting an agent ad hoc and accepting its changes unreviewed, a practice known as vibe coding [36], [37]. While this arrangement began as the only way to coordinate several coding-agent conversations as a MAS, APM v1 retains it to preserve these opportunities for review and reflection throughout its workflow. File-based protocols govern both communication among APM agents and the spec-driven workflow they follow. Chapter 3 describes these architectural choices in full. Table 2.1 places APM v1 beside selected earlier systems, ordered by their first public appearance.
| System | How it handles a long task | How work is coordinated |
|---|---|---|
| GitHub Copilot (2021) [7] | Suggests code from the current editing context. | The developer accepts or rejects each suggestion. |
| MetaGPT (2023) [4] | Specialist agents receive information relevant to their roles. | The system routes structured messages through a shared pool. |
| Early BMAD (Apr 2025) [32] | Documents carry plans and decisions between roles. | The user moves work between role-specific conversations. |
| Spec-kit (Sep 2025) [3] | Keeps the specification, plan, and tasks in project files. | The developer steers a coding agent through specification, planning, and implementation. |
| Superpowers (Oct 2025) [33] | Keeps a written plan and gives each task a fresh subagent context. | The coding agent dispatches tasks in sequence and arranges a review after each. |
| APM v1 (2026) | Divides work across role-specific conversations and preserves plans, state, and history in files. | Agent messages pass through the user. |
APM has attracted visible interest in the open-source community,1 yet it has not been evaluated in use by developers. The studies of Section 2.4 evaluate purpose-built programmatic multi-agent systems on benchmarks. Frameworks operating on top of coding agents remain outside their scope. That omission matters because this framework class has entered everyday development through interactive workflows in which developers assign and steer work. A benchmark also supplies both the task and the measurement, and neither carries over once the developer is in the loop. The closest controlled human-participant study we found compares OpenHands, a purpose-built coding-agent application, with the completion-and-chat form of GitHub Copilot available at the time [38]. The two conditions therefore belong to different tool classes.
In the literature we reviewed, the emerging class of frameworks to which APM belongs, operating on top of coding agents with developers in the loop, remains unevaluated. In this thesis, we describe APM’s design, propose a methodology for evaluating frameworks of this class, and apply it with human participants to compare APM against another framework that also applies spec-driven development.