<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>The papers on AIgile</title><link>https://goaigile.net/docs/papers/</link><description>Recent content in The papers on AIgile</description><generator>Hugo</generator><language>en</language><atom:link href="https://goaigile.net/docs/papers/index.xml" rel="self" type="application/rss+xml"/><item><title>The working paper: the whole method in one document</title><link>https://goaigile.net/docs/papers/working-paper/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/working-paper/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Prefer a file? Get the &lt;a href="https://goaigile.net/downloads/aigile-working-paper.pdf"&gt;PDF&lt;/a&gt; or &lt;a href="https://goaigile.net/downloads/aigile-working-paper.md"&gt;markdown&lt;/a&gt; on the downloads page.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;&lt;strong&gt;Subtitle:&lt;/strong&gt; Why the agile core survives the agentic era, and how to rebuild software methodology on top of it&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Status:&lt;/strong&gt; Working paper, version 0.1 (draft for discussion)
&lt;strong&gt;Date:&lt;/strong&gt; July 2026
&lt;strong&gt;Intended audience:&lt;/strong&gt; Software engineering leaders, architects, methodologists, and practitioners working with agentic AI systems
&lt;strong&gt;Purpose of this document:&lt;/strong&gt; This paper establishes the conceptual foundation of the aigile approach. It is intentionally foundational. In-depth methodology papers, concrete playbooks, tooling guides, and worked examples are expected to build on the definitions and arguments established here.&lt;/p&gt;</description></item><item><title>Reading guide: how the deep dives fit together</title><link>https://goaigile.net/docs/papers/reading-guide/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/reading-guide/</guid><description>&lt;p&gt;&lt;strong&gt;Status:&lt;/strong&gt; Series v0.1, July 2026
&lt;strong&gt;Foundation:&lt;/strong&gt; All papers in this series elaborate the aigile working paper v0.1. Terminology follows the working paper glossary, which is canonical.&lt;/p&gt;
&lt;h2 id="purpose"&gt;Purpose&lt;/h2&gt;
&lt;p&gt;The working paper establishes the aigile framework as a whole. Each paper in this series takes one load-bearing element, develops it to full depth, specifies its protocols normatively, illustrates it with a running example, and names the derivative artifacts (playbook chapters, slides, website sections, tooling requirements) that should be built from it.&lt;/p&gt;</description></item><item><title>Why feedback beats upfront specs</title><link>https://goaigile.net/docs/papers/why-feedback-beats-upfront-specs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/why-feedback-beats-upfront-specs/</guid><description>&lt;p&gt;&lt;strong&gt;Series:&lt;/strong&gt; Aigile deep dives, paper 01 of 09. Elaborates working paper Parts I and II. No dependencies.&lt;/p&gt;
&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;This paper establishes the intellectual foundation of aigile. It argues that waterfall&amp;rsquo;s defining property is not sequence but the freezing of outputs between phases; that agile&amp;rsquo;s essential innovation is the backward edge, the sanctioned channel through which learning flows against the direction of production; that prevailing spec-driven development reproduces the frozen-output shape in compressed time; and that agentic AI changes three economic conditions under which agile was derived, without touching the condition that made agile correct. Every protocol in the aigile framework is a formalized backward edge, and this paper is the justification all of them share.&lt;/p&gt;</description></item><item><title>Organizing project documents</title><link>https://goaigile.net/docs/papers/organizing-project-documents/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/organizing-project-documents/</guid><description>&lt;p&gt;&lt;strong&gt;Series:&lt;/strong&gt; Aigile deep dives, paper 02 of 09. Elaborates working paper Section 6. Depends on Paper 01.&lt;/p&gt;
&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;Agents are stateless; some written layer is therefore mandatory. But treating all written artifacts alike reproduces either waterfall (everything heavy) or vibe coding (everything absent). This paper develops the three-layer model that resolves the tension: a durable layer maintained like law, an ephemeral layer treated as disposable work product, and a derived layer regenerated rather than maintained. It then specifies layered truth: the precedence rules that decide, in advance, which representation wins when representations disagree. The layer assignment of an artifact determines its maintenance model, its authority, its review process, and its drift exposure; most documentation dysfunction in agentic projects traces to artifacts living in the wrong layer.&lt;/p&gt;</description></item><item><title>Project rules that can change safely</title><link>https://goaigile.net/docs/papers/rules-that-can-change-safely/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/rules-that-can-change-safely/</guid><description>&lt;p&gt;&lt;strong&gt;Series:&lt;/strong&gt; Aigile deep dives, paper 03 of 09. Elaborates working paper Section 7. Depends on Paper 02.&lt;/p&gt;
&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;The constitution is the anchor artifact of the durable layer: the smallest written statement of a project&amp;rsquo;s binding intent. Because every agent reads it in every session, it has the widest blast radius of any artifact in the system; an error in it is not a mistake but a broadcast. This paper specifies its content model, its amendment process, its semantic versioning, the increment-stamping mechanism that makes it auditable, and its rollback semantics. The governing design principle: law-like process, Git-native mechanics. The constitution must be deliberately hard to change and deliberately possible to change, and must never silently drift or silently freeze.&lt;/p&gt;</description></item><item><title>Making review affordable</title><link>https://goaigile.net/docs/papers/making-review-affordable/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/making-review-affordable/</guid><description>&lt;p&gt;&lt;strong&gt;Series:&lt;/strong&gt; Aigile deep dives, paper 04 of 09. Elaborates working paper Sections 5 and 8. Depends on Paper 02.&lt;/p&gt;
&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;When generation is nearly free, verification is the constraint, and any methodology that treats review failure as a discipline problem will fail with disciplined people. This paper develops aigile&amp;rsquo;s structural answer: review economics over review discipline. It specifies the four mechanisms that reprice review (executable acceptance criteria, diff-based review, the atomic PR, and the increment sizing rule), derives the sizing rule&amp;rsquo;s three-way alignment of human attention, agent context, and blast radius, and defines the day-to-day working loop these mechanisms compose into. The claim throughout is economic: people review what is cheap to review and skip what is expensive, and the methodology&amp;rsquo;s job is to move the important checks into the cheap category.&lt;/p&gt;</description></item><item><title>When specs and code disagree</title><link>https://goaigile.net/docs/papers/when-specs-and-code-disagree/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/when-specs-and-code-disagree/</guid><description>&lt;p&gt;&lt;strong&gt;Series:&lt;/strong&gt; Aigile deep dives, paper 05 of 09. Elaborates working paper Sections 9 and 10. Depends on Papers 02, 03, 04.&lt;/p&gt;
&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;Specifications are maps; code and tests are territory. This paper specifies the two protocols that keep them aligned: the deviation protocol, which governs the moment an implementer (human or agent) discovers mid-work that the map is wrong, and the drift-management pipeline, which governs divergence discovered late. Both rest on one observable classification boundary and one philosophical commitment: drift is thermodynamics, not sin, and methodologies that treat it as shameful get hidden drift instead of managed drift. The target variable is drift half-life, the time from divergence to resolution, not drift count.&lt;/p&gt;</description></item><item><title>Keeping humans in charge of what matters</title><link>https://goaigile.net/docs/papers/keeping-humans-in-charge/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/keeping-humans-in-charge/</guid><description>&lt;p&gt;&lt;strong&gt;Series:&lt;/strong&gt; Aigile deep dives, paper 06 of 09. Elaborates working paper Sections 12 and 14. Depends on Paper 04.&lt;/p&gt;
&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;Verification asks whether the thing was built right; validation asks whether the right thing was built. This paper develops aigile&amp;rsquo;s claim that validation is structurally human at every level of automation, specifies the three-trigger demo architecture (skeleton, feature, risk-pulled) that spends human attention proportionally to risk rather than volume, defines the demo verdict as a routed artifact rather than a feeling, and states the brains-eyes-hands rule that keeps validation unmediated. It then closes the framework&amp;rsquo;s largest loop: at full autonomy, the retrospective becomes a recursive self-improvement circle, and that circle is a Goodhart machine unless its fitness function is injected from outside. The human demo verdict is that injection. The demo and the self-improvement circle are one design, adopted together or not at all.&lt;/p&gt;</description></item><item><title>How much agents may do on their own</title><link>https://goaigile.net/docs/papers/how-much-agents-decide/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/how-much-agents-decide/</guid><description>&lt;p&gt;&lt;strong&gt;Series:&lt;/strong&gt; Aigile deep dives, paper 07 of 09. Elaborates working paper Section 13. Depends on Papers 03 and 06.&lt;/p&gt;
&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;Aigile spans the spectrum from human-AI pair collaboration to fully agentic delivery without forking into two methodologies. This paper specifies the mechanism: authority over verification is assigned per layer in a matrix, not per project in a mode switch; autonomy moves rightward through the matrix on evidence and moves back on incident, in the manner of graduated licensing; and one row never moves. It then develops the structural hazard specific to the right side of the matrix, correlated verification failure, and the independence requirements that mitigate it. The framing sentence for the whole paper: humans always own the why; the dial only ever moves who owns the check.&lt;/p&gt;</description></item><item><title>Learning that lasts</title><link>https://goaigile.net/docs/papers/learning-that-lasts/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/learning-that-lasts/</guid><description>&lt;p&gt;&lt;strong&gt;Series:&lt;/strong&gt; Aigile deep dives, paper 08 of 09. Elaborates working paper Sections 5.3 and 11. Depends on Papers 02 and 05.&lt;/p&gt;
&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;The retrospective is aigile&amp;rsquo;s learning organ, and it differs from its classic ancestor in three ways. First, its outputs must land in artifacts, because half its participants have no memory: routing learnings to the correct layer is the entire trick. Second, it produces a category of learning that human teams never had to write down, collaboration knowledge, which must compound in the durable layer or evaporate daily. Third, it carries a maintenance duty its ancestor lacked: the gardening rule, under which the document layer is refactored with the seriousness of code, because it is load-bearing. Woven through all three is the comprehension budget: the deliberate expenditure that keeps human mental models accurate in a system humans no longer implement, without which the feedback quality every other paper depends on silently decays.&lt;/p&gt;</description></item><item><title>Slicing the work</title><link>https://goaigile.net/docs/papers/slicing-the-work/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://goaigile.net/docs/papers/slicing-the-work/</guid><description>&lt;p&gt;&lt;strong&gt;Series:&lt;/strong&gt; Aigile deep dives, paper 09 of 09. Elaborates working paper Section 8 step 2 and the sizing rule of Paper 04. Depends on Papers 04, 05, 06.&lt;/p&gt;
&lt;h2 id="abstract"&gt;Abstract&lt;/h2&gt;
&lt;p&gt;Slicing is the step that sets the clock speed of the entire loop. Every downstream protocol inherits its properties from slice shape: review honesty depends on slice size (Paper 04), agent coherence depends on slice fitting one session, validation cadence depends on every slice being demoable (Paper 06), and the blast radius of a wrong decision is bounded by one slice (Paper 05). A methodology can state all of those protocols correctly and still fail in practice if teams slice by layer, by component, or by convenience, because each of those shapes silently disables a downstream protocol. This paper treats slicing as a craft with teachable rules: the unit of slicing (the user question answered), the two-sided binary sizing test, ordering by discovery value, the embedded-infrastructure rule, a catalog of split patterns, and the calibration loop that keeps the sizing parameters honest as agents and teams change. It contributes rules R33 through R36 and a full worked slicing session.&lt;/p&gt;</description></item></channel></rss>