Balanced SDLC – framework for agentic development
# basode: Balanced Software Development Lifecycle – Conceptual Framework and Implementation Guide v0.41
Monolithic SSOT and Injected State-Driven Software Development Orchestrator Model
Balanced Software Development Lifecycle – Conceptual Framework and Implementation Guide © 2026 by akotomars is licensed under CC BY-SA 4.0
## 0. Rationale: Why is this necessary? Garbage in-garbage out scaled up by AI coding
The core idea:
If we provide AI with incorrect or incomplete information, it will produce incorrect and incomplete results. Correcting this afterwards with human effort is incredibly nerve-wracking – this is when many turn away from AI agentic development, even though it just needs to be done right. This is why the Balanced SDLC method is being created and developed, more pronounceable and briefly: basode.
—
In a traditional software development environment, the consistency between project management and execution was ensured by the balance of human actors’ soft skills, formalized SOPs (Standard Operating Procedures), as well as unwritten community norms, implicit job descriptions, development principles, rules, and nomenclatures.
With the entry of autonomous AI agents (Agentic AI), this paradigm becomes obsolete. Agents do not possess tacit knowledge or social context outside the local file system (working directory) of the project; their operation is strictly limited to explicitly provided context and deterministic instructions. The rules of working can no longer be parts of a corporate culture floating outside the project, but they must become inseparable, Docs-as-Code handled components of the project.
The basode framework responds to this architectural constraint. It converts previously soft, human-driven processes and project management norms into a machine-interpretable, trackable rule system built on a few core premises. This formalized, clear framework radically expands the boundaries of AI agents’ autonomy, enabling them to independently execute longer, more complex, and vertically extended development iterations.
## The surface of the lake, the thrown stones, and the ripples
One of the main pillars of basode is that the current state of the software development system should be clear at a glance: is this a ready, polished, system in a stable state, or is it currently processing one or more demands, meaning a change is currently taking place? The stable system is a lake with a mirror-smooth surface, and the new demand is something someone threw into the lake. Both lakes are the same project: one is in a peaceful state, and in the other, a demand is making ripples. During development time, we and other stakeholders continuously throw stones into the lake, and the lake, the development project, receives and handles these demands. Basode is the collection of physical laws that model the operation of the lake, aiming for the lake’s surface to be smooth again in the end. – Why is this important? If the modeling is bad, if we create bad physics in our world where the lake exists, then the interaction of demands diminishes very slowly – or in the case of a derailed project: it never ceases, we won’t have satisfied stakeholders -, and the lake is constantly rippling, a lot of energy goes into restoring the water surface.
In our everyday life, real physics arranges for the water to smooth out. In our world, this is ensured by basic principles that we summarize. These principles are the other pillar of the operation: the arrival of the thrown object into the lake, the path the object takes: if it’s a stone, then it sinks to the bottom of the lake, if it’s a water lily, then it will float on its surface. The mark it leaves on the lake’s state: if it’s a big stone, it visibly raises the water level – and many small stones do this too, and if it’s a water lily, it’s especially spectacular on the lake’s surface: the software develops, and this will be noticeable on its surface, and the lake bed, its shape changes too. This is our software too: realizing the demand changes both the surface and the implementing code. Our physics ensures that the arrival of all kinds of giant and small things leads to the calming of the lake’s surface, and does this efficiently.
The physical forces working in the lake here are human and AI agent labor, and the infrastructure we use. We want to treat these economically. Once again: if we create bad physics, throwing a stone, according to the nature of our world, won’t be a subsiding ripple, but a rippling lake surface for a long time, or a giant, beautiful, but feather-light water lily instead of gently remaining on the surface with minimal ripples, because of its size it causes a tsunami – meaning it consumes much more resources (e.g. tokens) than with good physics -, and if this slapping-rippling time is infinite, our physics simulation will be shut down, meaning dissatisfied clients will stop the project, e.g. ourselves: we run out of money we allocated for tokens, infra, and the cost of our own time for this.
—
The analogy of the analogy, for clarity:
Accounting also has its own lake, stone, and physics.
When a new invoice document arrives at a double-entry bookkeeping company: this document is the impulse, and the life of the invoice document, its effect on the accounting system, general ledger, and journals, the changes in the debit-credit entries — that is the ripple. According to the physics of the system, the impulse caused by the document eventually, at the latest by the year-end balance sheet, fully takes its place and establishes the new equilibrium state — the smooth water surface once again. And as we will see later when applying basode to accepting a new demand, something similar happens here: In the case of a transfer invoice, the registry splits into two:
– the business result is affected by the amount of the invoice document,
– and on another documentation level, we expect the money movement to happen on the bank account.
So if someone throws a new thing into the lake, accounting handles it by writing it down in multiple places, in one place already as reality (since the incoming impulse already affects the business result), in the other place it starts the physical realization: that at some point it will be necessary to transfer from the bank account. Of course, this is a long process: examining the invoice, what this is, various stakeholders certifying that it is really payable, etc.
Accounting is full of finely polished SOPs (standard operating procedures), rules, clear expectations, which are today up to 100% automated. In software development, we try to achieve a similar result with the basode method.
—
Returning from the analogies
Basode introduces a system similar to accounting into software development: a strict obligation to “book” the new demand in at least two places: we write it into the operational documentation of the finished system with a WIP (work in progress) marking – analogous to how the incoming invoice modifies the business result regardless of the transfer -, and this immediately balances out – in the form of technical debt – so that the task itself appears in the task manager, and then nicely – as the invoice during certification, booking, transfer – we perform quite a few operations on our task, at the end of which with implementation the technical debt disappears and the indication of debt from the operational doc: we remove the WIP marking.
The lake calmed down, and the stone reached the bottom of the lake: a new equilibrium, a new stable version was created, which is a bit different than before: the stakeholders are momentarily satisfied with the interface.
And then someone throws another stone into the lake, a new demand comes, and it starts all over again: this is our software development life cycle, the balanced software development life cycle, abbreviated basode.
## I. Theoretical and abstract model
This section establishes the technology-independent, theoretical foundations of the basode (balanced Software Development Life Cycle) methodology. The framework treats software development as a shared-memory, monolithic state machine that relies on a single deterministic source of truth (SSOT).
**1. The dual product model**
Basode simultaneously develops two logically distinct systems:
* **Target System (Product A):** The software product to be created (the target system, the “cup to be made with the 3D printer”).
* **Delivery System (Product B):** The method producing the software (local implementation of dSdlc), infrastructure and process system (the “3D printer”). Modifying the Delivery System always takes priority over the Target System. If someone already possesses a mature basode implementation for their own developer and infra environment, then the weight of this decreases from project to project; at the same time it must be mentioned because the reality is that this is a continuously changing system – if for no other reason, because of the rapid development of IDEs and other environments supporting agentic programming.
**2. N-tier documentation (doclayerN)**
The state of the Target System is described by hierarchical abstraction layers:
* **doclayer0 (Ideas):** Unstructured, out-of-system demands. The idea: the stone flying towards the surface of the lake.
* **doclayer1 (TargetSpec):** The literary level specification containing the expectations of the Target System. This is the global SSOT. The splashed stone that will transform both the bed and the surface of the lake.
* **doclayer2…N-2 (From TargetSpec to tech spec):** depending on the nature of the project, N layers can be inserted here, where actors discuss and specify, concretize the task towards realization.
* **doclayerN-1 (Functional model):** Technical specifications and transitional models that drive the implementation.
* **doclayerN (Physical implementation):** The tests, the running source code and the infrastructure. The bed of the lake, and water in the lake.
**3. Triage and double-entry bookkeeping (WIP injection)**
The moment of splashing into the lake is when the demand/idea/task/bugreport transfers from doclayer0 to doclayer1 – it crashes from the air into the lake. At this time we decide (product owner or project manager or any forum, this is a matter of project charter) whether the thrown thing really belongs in our lake – if not, we give feedback to the stakeholder (“I think you should talk to your sysadmin”, “buy a faster server”, “you can’t ask us for a new password”). At the moment of a positive decision regarding each individual thing, the double-entry bookkeeping performed according to our basode process is part of our physics. Information materializes synchronously on two vectors:
1. **State-shift on doclayer1:** The expectation is placed into the TargetSpec document with an explicit marker (WIP injection), recording the target state.
2. **Waves start on the lake: state-shift in the task tracking system:** The impacted idea becomes a dedicated work item in the process manager, which also represents the modification of doclayer2.
3. From here, a standard SDLC pipeline follows, which marches the task through the doclayers to realization, meaning the water moves as the new thing arrived in the lake. If this is a surface thing, a water lily, then with an impact penetrating only up to UI depth, but if a new stone was thrown, we follow the path of change with the task manager to the bed. With tests, etc., according to a custom-detailed SDLC. The dataset representing the task in the task manager (gh issue, kanban board, etc., briefly: ticket) contains the physical impulse: its own content – to-dos – and the state of the doclayers show how many to-dos there are. As the to-dos run out on the ticket, the state of the doclayers changes simultaneously, meaning reality. Nicely as we progress towards tested and accepted implementation, the size of the wave decreases: the amount of to-dos on the ticket decreases.
4. When the tasks finally run out on the ticket, the ticket goes to the archive, and the “tension” caused by the WIP entry disappears from the target system’s doclayer1. The waves subsided, physical equilibrium sets in, the smooth water surface.
**4. Non-linear changes and the Instant-Issue**
In case of bottom-up, critical architectural problems or issues affecting the Delivery System, the Instant-Issue procedure comes into effect. This means an immediate freezing of the SDLC assembly line (pipeline freeze), out-of-turn impact analysis, and prioritized correction of the Delivery System (or lower layers of the Target System).
**5. Architectural independence**
The theoretical logic of basode is independent of the physical data storage method, concurrency handling (e.g. distributed version control vs. file locking) and the chosen project management methodology (agile, waterfall).
—
## II. Practical implementation (Antigravity environment)
This section describes the specific, 3-tier (doclayer) mapping of the basode theoretical model in the Antigravity development environment, with a local file system-based Kanban task tracking.
**1. Storage topology and folder structure**
The physical mapping of the system is realized in the following dedicated directory structure:
* **Storage of Target System (Product A):**
* `docs/`: Here we store the TargetSpec (doclayer1), the narrative SSOT.
* `blueprints/`: Here we store technical specifications, diagrams, transitional models (doclayer2).
* *(The root directory and source code folders represent doclayer3).*
* **Task tracking system:**
* `kanban/`: The folder containing the local issue tracking system, which manages execution and state transitions.
* **Storage of Delivery System (Product B):**
* `docs_of_dev/`: The folder system grouping development processes and rules by topic.
* `.agents/`: Folders containing behavioral rules, skills and standard workflows of autonomous AI agents.
* **Storage of the methodology:**
* `docs_of_basode_method/`: In this location we store the description of the basode framework itself, meaning this doc.
**2. Practical syntax of WIP injection**
In the Antigravity environment, during double-entry bookkeeping, we inject the future state into files with the following XML-based syntax:
`
The ticket attribute must point to the identifier of a card in the `kanban/` folder.
—
## III. Practical examples for the iteration
**Example 1: Top-Down double-entry bookkeeping (New feature)**
* **Situation:** Introducing a new payment method (Apple Pay) into the Target System. After Triage, the task gets the identifier `aplpay42`.
* **Execution in topology:**
1. In the `kanban/` folder, the `aplpay42.md` card is created (state-shift in the task tracker).
2. Simultaneously we open the `docs/market/fizetesi_modok.md` file (doclayer1), and inject the future:
`
3. In the `blueprints/` folder (doclayer2) screen designs are updated if necessary. Here too, a WIP marker indicates in the doc that this is under change.
* **Result:** When the task is completed in the source code (doclayer3), the `
**Example 2: Bottom-Up Instant-Issue (Correction of Delivery System)**
* **Situation:** The agent working on the source code (doclayer3) realizes that the textual representation used in the `blueprints/` (doclayer2) folder causes incorrect code generation.
* **Execution in topology:** The agent pulls the “Andon cord”. Pipeline freeze takes effect. An Instant-Issue card is created in the `kanban/` folder, which is dedicatedly aimed at the Delivery System (Product B).
* **Result:** Work stops on the Target System. The team (or agent) updates the specification rules in the `docs_of_dev/` folder (e.g. makes Mermaid diagrams mandatory under `blueprints/`). After correcting the printer’s blueprint, the assembly line restarts.
