Mind the Intent Gap: A Methodology for Collaborative Agent-Driven Software Engineering

Mind the Intent Gap: A Methodology for Collaborative Agent-Driven Software Engineering Nicolas Tacheny

Tom Mens

Saïd Mahmoudi

University of Mons (UMONS) Mons, Belgium Ni2 Innovation Lab Belgium nicolas.tacheny@{umons.ac.be,ni2.com}

University of Mons (UMONS) Mons, Belgium tom.mens@umons.ac.be

University of Mons (UMONS) Mons, Belgium said.mahmoudi@umons.ac.be

arXiv:2610.37340v1 [cs.SE] 27 Oct 2026

Abstract AI agents have entered software teams, first as tools and now as team members. They produce in minutes what used to take days, yet the expected gain in delivery often fails to appear. We argue that they are entering processes designed for people, which quietly relied on people to cover three of their weaknesses. The team’s intent was never fully written down, because colleagues filled the gaps. An AI agent fills them too, though by guessing, and drifts from what the team had in mind. The reasoning behind each deliverable was already lost from one step to the next, and AI agents now inflate and deflate the documents passed along. The reasoning people did alone was partly private and now moves into AI tools that keep it private by nature. We present CAIA, for Collaborative Agentic Intent Alignment, a methodology for software teams that brings agents into the way they work. A knowledge base describes the product that a project maintains. For each Change, a micro-team aligns on its intent before agents evolve the product and propose updates to the Knowledge Base. The proposed CAIA methodology emerged from an industrial need and is already in use at Ni2, with a platform built to support it. We present the methodology and outline our plans to evaluate it further.

Keywords AI agents, agentic engineering, software process, intent, knowledge management

1

they had worked out alone. Agents fill such gaps from what they learned in training, not from what the team has in mind. Today, many software teams are in a phase of transition and want agents to join the team. We present the CAIA methodology, for Collaborative Agentic Intent Alignment, as a way to facilitate this transition. While vibe coding has been widely criticised because many humans just build with an agent and blindly trust its output, CAIA aims to bring more rigour, by providing a collaborative team methodology within the emerging field of agentic software engineering. CAIA is based on the following main building blocks. A Knowledge Base describes the Product that a Project maintains, for example a web application with all its code, tests and documentation. In each Change, a small team of people aligns on its Intent and writes it down. Agents then evolve the product from that intent and propose how to update the knowledge base. CAIA is currently in use at Ni2, where it emerged from a real industrial need. After presenting related work in Section 2, Section 3 analyses the challenges that appear when agents join a team whose process was designed for people. Section 4 presents the main concepts of the intent-centred CAIA methodology, with the humans and agents that work on them. Section 5 describes the lifecycle of a Change, a flow of seven steps with explicit rules. Finally, Section 6 presents the current use of CAIA in a company setting, and outlines a plan to evaluate CAIA with students in a university setting.

Introduction

In recent years, AI agents, or agents for short, entered software development as assistive tools. They helped complete specific tasks defined by developers, such as writing a function, then a test, then a whole feature. These agents are now becoming full-fledged team members. While they were expected to speed up development, the evidence available to date does not fully confirm their added value. In a randomised trial run by METR in 2025, experienced opensource developers took 19% longer to complete real issues when they could use AI tools [3]. Open-source projects that adopted the Cursor assistant produced code much faster at first, then lost the gain as their code grew more complex [5]. Each step gets faster while the work as a whole does not. We hypothesise that one reason is that agents are entering processes that were designed for people. For each change, most teams organise their work as a chain: they decide what to make, then how to make it, then build it. At each stage of that chain, people implicitly did extra work. They filled in what the documents left out, explained their reasoning to the next team and shared the ideas

2

Related work

In 2025, vibe coding emerged as a new way of programming with coding agents. A developer describes in plain language what they want, the agent writes the code and the developer judges what comes back. Studying such sessions, Sarkar and Drosos [8] find that the developer’s expertise shifts towards managing the context given to the agent. The conversation they observe involves one person and one agent. But in a team setting, how does that person know what the rest of the team has in mind, and how does the team learn what was decided? Intent misalignment between team members is a long-standing challenge in software engineering. Bjarnason et al. [4] traced how requirements slip through the gaps between the requirements engineers who decide what to build and the software engineers who build it. Agile methodologies answered with people, valuing individuals and interactions over processes and tools [2]. Colleagues closed the gaps in conversation. When one person talks to an agent, those colleagues are no longer part of it.

Nicolas Tacheny, Tom Mens, and Saïd Mahmoudi

Krentsel et al. [6] name a requirement gap between what stakeholders intend and what is written down, close to the gap at the heart of this paper, and narrow it with revision loops after the build. In spec-driven development, supported by tools such as GitHub Spec Kit and AWS Kiro, a structured specification drives the agent [1]. CAIA shares the idea of writing the intent down before the agent builds, yet differs in important ways: (1) several disciplines agree on the intent, not a single developer; (2) a knowledge base remembers what every change decided, not only one specification; (3) rules govern who drives the agents and when the intent is frozen. Storey [9] describes how AI-driven development adds two debts to technical debt. Cognitive debt is the erosion of a team’s shared understanding, and intent debt the absence of explicit rationale that humans and agents need to change a system safely. The CAIA methodology proposed in this paper keeps both debts low by writing down the intent of each change and sharing the reasoning behind it. Its knowledge base extends the architecture decision records proposed by Nygard [7] to the whole product and makes updating it part of every change. To the best of our knowledge, no existing methodology combines a collective alignment on intent, a single driver for the agents that change the product and a knowledge base that every change keeps up to date.

3

Challenges when agents join the team

This section presents three challenges (C1 to C3) that may arise when agents join a project team whose process was designed primarily for people. A team keeps changing what it maintains, and each change goes through three kinds of work: deciding on what the change should achieve, deciding on how to achieve this change, and carrying out the change (i.e., build it). What this chain creates is the Product of the project, which is maintained and evolves over time because it has value of its own. The product covers every deliverable, component and document needed to create and maintain it, from code to a website, each in several versions. One team may work on several projects, each with its own product.

C1. The intent gap A team about to create or evolve its product first agrees on what it wants, then writes it down for a colleague or for an agent. What the team agrees on is the Intent of the change. Its human- and agent-readable form is the Stated Intent. The Intent Gap reflects what the intent holds and the stated intent does not declare. What and how shape the Intent, while only build changes the Product. The intent lives in discussions and in people’s minds, so the two never match exactly. Before agents were used, the intent gap rarely hurt. A developer reading a thin ticket knew how the system was built, remembered previous discussions and could walk over and ask. Someone closed the gaps on the fly. An agent, however, works only from what it is given for a task, which we call its LLM context, and from what it learned in training. It can ask the person prompting it, but once the agent works for the team, that person is often not the one who knows. The answer may lie with a colleague from another discipline. Whatever is left unanswered, the agent invents or ignores while still returning a

result that looks complete. Producing has become fast while closing the intent gap has not, and the gap has become the bottleneck.

C2. Reasoning lost between teams In a chained process each link explores options within its own boundary and passes on only its deliverable, such as a description of a need, a design or a plan. The reasoning that was made to produce it stays behind, and AI makes it worse. One link turns a three-line need into a forty-page document in one request, and the next person asks its personal agent for a five-bullet summary. The document is therefore inflated and deflated by agents without anybody reading it in full, and the original intent is lost between the two.

C3. Private reasoning Part of the reasoning behind any piece of work has always been private. Notes, sketches and ideas are rarely documented or shared and often remain in individuals’ minds. With AI, people delegate a growing part of that reasoning to agents whose memory is private by nature, from chat histories to the memories agents keep about each user. When multiple persons collaborate on the same change, each person feeds their personal agent different LLM contexts and get as many versions of the same change. Merging them by hand reintroduces the coordination cost the agents were supposed to remove.

4 The CAIA methodology 4.1 Requirements Based on the challenges identified in Section 3 we derive three main requirements for the proposed CAIA methodology: R1 The team members who hold the Intent of a change must explicitly state it, so that the intent gap is closed before any agent works from it. R2 The reasoning behind a change travels with it to its end, and what was learned is kept for the next change. R3 Several team members, each possibly assisted by their own agents, contribute to one shared stated intent, from which everything that changes the Product is driven.

4.2

Concepts

A Project evolves a Product one Change at a time, raising its value with each one. Each Change carries a Stated Intent, which grows as the project Team works on it. The team decides how large a Change is. It may add a capability, rework a part of the Product or fix a defect. The CAIA methodology does not predefine a fixed list of Change types. Alongside the Product, the Project maintains its evolving Knowledge Base, a body of knowledge that is complete enough to change the Product without relying on unverified assumptions. It covers what the Product is for, how it is organised, the conventions it follows and the decisions that shaped it, together with their reasons.

4.3

Actors

The project team is composed of both human and AI actors (i.e., agents), whose roles are described below.

Mind the Intent Gap: A Methodology for Collaborative Agent-Driven Software Engineering

Project Master

Change Master

may join

Leads

major loop

Alignment

Building

Analyse

Align

Review

next Change

Describe

Consolidation

minor loop

no-go

Build

Update knowledge

Validate

Stated intent of the Change

brief

assistant agents

brief

build agent

Product

brief

knowledge agent

Knowledge Base

Figure 1: Schematic depiction of the life of a Change, its three phases, seven steps, actors involved in each step and the brief its agents work from. The human actor that drives an agent draws its brief from the stated Intent and the Knowledge Base. Human actors: CAIA separates two kinds of contributions in a project, namely bringing expertise to the intent and operating the agents that act on it. We distinguish three human roles: • The Project Master owns the project, builds the project team and assigns which of its members will act as Change Master. The project master creates each Change and describes it. • The Change Master owns the Stated Intent of the Change they are responsible for, keeps the Change coherent and decides when it is ready to act on. The Change Master forms its own micro-team composed of members from the project team. A micro-team is small by design, and a large team splits into as many micro-teams as it has Changes in progress. • A Lead brings one discipline to the Change, such as business, user experience, architecture, development or quality. They contribute to the Stated Intent from that angle. The Change Master assigns some Leads to analyse the Change and others to review it, ensuring that no Lead reviews their own analysis. AI actors: An agent is built around an LLM, reasons on the context it receives, and acts or reacts on its environment through tools. As challenge C1 revealed, an agent initially only knows its LLM context and its training. In CAIA, every agent receives the required context as a Brief (cf. Figure 1), which gathers the relevant parts of the Stated Intent and of the Knowledge Base, along with instructions for the task. CAIA distinguishes three kinds of agent: • An Assistant Agent helps a human actor think. It can explore a topic, draft a text or challenge an argument. It never changes the Product or Knowledge Base. • A Build Agent evolves the Product from the Stated Intent. • A Knowledge Agent proposes updates to the Knowledge Base based on what the Change modified. Rule 1 (One driver). Only the Change Master operates the Build Agent and Knowledge Agent. Every human actor of a Change may use Assistant Agents at any step. Their output enters the Change only when a human writes it into the Stated Intent. This rule ties humans and agents together, and aims to ensure coherence. An agent’s output is only as consistent as the brief it is

given. If multiple human actors drove the agents, the briefs diverge and so do the results. One driver works from one Stated Intent. Whatever an actor works out alone with an assistant agent reaches the Product only through that intent, where the whole micro-team can read it (requirement R3). The quality of that intent, however, comes from the Leads, whose assistant agents help to express what they know.

5

The life of a Change

A Change goes through three main phases subdivided into seven steps (Figure 1). First the micro-team aligns on the intent, next the build agent evolves the Product while the team checks it, and finally the knowledge agent proposes how the Knowledge Base should record the change.

5.1

Alignment

The first phase, called Alignment, closes the intent gap before any build agent or knowledge agent acts. What colleagues used to fill in on the fly is now written down by the team members who hold it (requirement R1). Each step adds a block to the Stated Intent of the Change. As the Stated Intent grows block by block, any actor can draw a Brief from it at any moment, and use it together with the Knowledge Base to work on their block with the help of an assistant agent (Rule 1). Since every discipline writes into the same Stated Intent, work never passes from one team to the next and the reasoning stays in its blocks, next to the decisions it led to (requirement R2). The Alignment phase is composed of four steps: Describe: The Project Master formulates the Stated Intent as they first understand it, including why it matters and what is known to be in or out of scope. Analyse: Each analyst Lead explores the Change from their discipline. For example, an architect identifies what the change will touch, and a quality Lead looks for what will be hard to verify. Review: Each reviewer Lead, who did not participate in the analyses, reviews the Change independently and raises the risks and open questions seen from their discipline. The Change Master’s own review looks at the Stated Intent as a whole and identifies the gaps that remain. Every review ends with a verdict, approved or rejected,

Nicolas Tacheny, Tom Mens, and Saïd Mahmoudi

and is written before the micro-team meets, so that no discipline is anchored by the others. Align: The Change Master meets with all Leads to settle these gaps, if needed by sending the Change back to the Analyse step. The Change Master records the decisions and sets the final go or no-go verdict. A Lead’s rejection carries no veto and is an invitation to discuss.

5.2

Building

Next comes the Building phase, composed of two steps: Build: Together with the Knowledge Base, the blocks written in the four Alignment steps form the build brief. The Change Master gives it to the build agent and drives the agent until the Product has evolved as intended. If the Stated Intent left a decision open, the agent asks the Change Master instead of guessing. A solo build suits a precise intent, and the Change Master builds alone. In a joint build the team has left open parts of the solution on purpose, and the Leads discuss each choice as the agent proposes it. Either way, only the Change Master operates the agent (Rule 1). Validate: The micro-team checks the evolved Product against the Stated Intent. Small corrections send the Change back to the Build step (minor loop), while a new understanding of the change sends it back to the Alignment phase (major loop).

5.3

Consolidation

Once the Product is validated, the single-step Consolidation phase keeps what was learned during the Change. At Update Knowledge, a knowledge brief gathers what changed and the decisions taken, with their reasons, including those made during the build. The Change Master gives it to the knowledge agent, which proposes changes to the Knowledge Base without applying them. Once the Change Master, with the help of Leads when needed, has reviewed them, they update the Knowledge Base and the Change is finished. Rule 2 (A Change updates the Knowledge Base). A Change that does not update the Knowledge Base is not finished. Without this rule, the next Change would work from a Knowledge Base that no longer matches the Product. Each Change must close a loop that raises the Product’s value and makes the Knowledge Base ready for the next Change, whose briefs will read the decisions and their reasons (requirement R2).

5.4

Rules of the flow

The CAIA methodology enforces the aforementioned flow. Each Alignment step owns a block of the Stated Intent, which is either in progress or done, and a review is done once it is approved or rejected. A Change moves forward one step at a time and only when the current step is complete. The final verdict of Align must also be go. No one can therefore reach the build without every analysis written and every reviewer having taken a position (R1). A Change may move back to any earlier step at any time, which distinguishes the methodology from a traditional waterfall process. The Stated Intent and the micro-team are frozen once Build starts, so the build brief cannot change underneath the agent.

6

Current Use and Future Plans

CAIA emerged from a real need at Ni2, a company that builds software to manage digital infrastructure, from data centres to subsea cables. With about 50 employees in Belgium and Canada, its geographically dispersed teams have long known intent gaps, since much of what a team intends never crosses the distance. The first author works at the Ni2 Innovation Lab and explored there how AI agents could help its teams work better. This led to CAIA and to an automation platform built to support the methodology. The platform has been used since early 2026 by about ten company employees, for example to implement a new feature for a digital twin. At the time of writing, 19 Changes have been opened across 4 Projects, some of them still in progress. So far, as a first subjective evaluation, most team members describe the approach as positive. For a more objective evaluation on an independent instantiation of CAIA, we are setting up a controlled experiment in a university setting, led by the second and third authors, in the context of a first course for engineering students in computer science and management and a second course for computer science master students. In each course, groups of students will receive the same software engineering problem, stated as a series of evolutions to carry out end to end on an existing piece of software. Some groups must follow CAIA, while the others can build freely with or without agents, with no imposed methodology. We will compare the groups on performance, such as the time each evolution takes, and on accuracy, such as how well each result matches the intended change. Our hypothesis is that the CAIA groups will deliver results closer to the intended change, with fewer corrections, in comparable time.

7

Conclusion

AI agents have made each step of a team’s work faster, but they join processes designed for people who filled the gaps in what was written, carried the reasoning along and shared what they had thought alone. In this paper, we proposed the CAIA methodology that makes that work part of every change. A micro-team aligns on the intent of each change before any AI agent builds, and the Knowledge Base keeps what the change leaves behind for the next one. Born from an industrial need, CAIA is in use at Ni2 today, and a planned controlled experiment at the University of Mons, Belgium will measure its effect. Language models were built on attention. The teams that build with them now need intent first.

References [1] Shyam Agarwal, Anmol Singhal, Travis Breaux, and Bogdan Vasilescu. 2026. SpecMine: A Large-Scale Corpus of Spec-Driven Development Artifacts. arXiv preprint arXiv:2608.25202. [2] Kent Beck et al. 2001. Manifesto for Agile Software Development. [3] Joel Becker, Nate Rush, Elizabeth Barnes, and David Rein. 2025. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv preprint arXiv:2507.09089. METR. [4] Elizabeth Bjarnason, Krzysztof Wnuk, and Björn Regnell. 2011. Requirements Are Slipping through the Gaps: A Case Study on Causes and Effects of Communication Gaps in Large-Scale Software Development. In Proceedings of the 19th IEEE International Requirements Engineering Conference (RE). 37–46. doi:10.1109/RE. 2011.6051639 [5] Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner, and Bogdan Vasilescu. 2026. Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity. In Proceedings of the IEEE/ACM International Conference on Mining Software Repositories (MSR). arXiv:2511.04427. [6] Alexander Krentsel, Shubham Agarwal, Mert Cemri, Shu Liu, Sidharth Sankhe, Ziming Mao, Matei Zaharia, and Ion Stoica. 2026. Reality Is the Final Verifier: On

Mind the Intent Gap: A Methodology for Collaborative Agent-Driven Software Engineering

Two Key Gaps in Agentic Software Engineering. arXiv preprint arXiv:2609.12039. [7] Michael Nygard. 2011. Documenting Architecture Decisions. Cognitect blog, 15 November 2011. [8] Advait Sarkar and Ian Drosos. 2025. Vibe Coding: Programming through Conversation with Artificial Intelligence. In Proceedings of the 36th Annual Conference of

the Psychology of Programming Interest Group (PPIG). arXiv:2506.23253. [9] Margaret-Anne Storey. 2026. From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI. arXiv preprint arXiv:2603.22106.

Related documents

• Mind the Intent Gap: A Methodology for Collaborative Agent-Driven Software Engineering#1468944
• Coding-Agent Benchmarks Should Match Their Users' Task Flows#1234001
• Coding-Agent Benchmarks Should Match Their Users' Task Flows#1227411
• From Prompt to Process: a Process Taxonomy and Comparative Assessment of Frameworks Supporting AI Software Development Agents#259558
• From Determinism to Delegation: AI-Native Software Engineering and the Evolution of the Agentic Engineer#321916