The Agentic Assembly Line: How I Shipped Sprawl v2 with Zero Merge Conflicts

YB
Younes Baghor - WebWizArt
6 min read  •  Oct 16, 2026
The Agentic Assembly Line: How I Shipped Sprawl v2 with Zero Merge Conflicts

Generative AI has a scaling problem. At the prototype stage, it feels effortless. But as soon as you attempt to refactor a dependency-heavy monolithic codebase into a production-grade application, the illusion shatters. Agents step on each other's toes, context windows degrade, and merge conflicts bring development to a dead stop.

In my advisory work, I consistently point out that AI projects do not fail because of model limitations; they fail because of broken architecture and undisciplined workflows.

Recently, I put this philosophy to the ultimate test: upgrading Sprawl CLI from a prototype script to a modular, public v2.0.0 Release Candidate.

I did not just rewrite the tool manually. I engineered an autonomous, closed-loop assembly line to execute the refactor.

The output: 145 unit tests, zero failures, 0.068-second test suite execution, and exactly zero merge conflicts.

Here is the exact architectural blueprint I used to orchestrate it.

1. The Diagnosis: The Fragility of Ad-Hoc Prompting

The standard approach to AI-assisted development relies on ad-hoc conversational prompting. You feed snippets to an LLM, copy-paste the output back into your editor, and manually stitch the differences.

This methodology breaks down completely on large refactors. It forces you to maintain system state in your head, track complex cross-file dependencies, and referee code collisions.

When I set out to dismantle the monolithic core of Sprawl v1 and replace it with a modular, standard-library architecture, I knew conversational prompting would trigger prompt drift, context thrash, and regression bugs.

To build durable software, you need deterministic governance: strict physical file boundaries, automated execution loops, and a structure where the AI acts not as a chatty co-pilot, but as a disciplined worker on an assembly line.

2. The Architectural Core: Clean Room and Zero Dependencies

The defining success factor of Sprawl v2 was enforcing physical boundaries within the codebase. I established two core structural constraints:

The Clean Room Architecture

In early setups, agents operating in a workspace could inspect Sprawl's internal management files, causing context pollution and scope creep. In v2, I enforced a Two-Layer Stealth architecture:

The agent remains completely unaware of the orchestrator governing it. Its context window stays lean, isolated, and focused exclusively on application source code.

The Single-Dependency Rule (Python stdlib)

To guarantee frictionless enterprise distribution and an auditable supply chain, I stripped out third-party packages. I eliminated Pydantic, PyYAML, Typer, and structlog.

Sprawl v2 ships with exactly one external runtime dependency: rich (for rendering terminal interfaces). Everything else, from workspace validation schemas to CLI argument parsing, relies purely on the Python standard library.

Using native dataclasses and an in-house regex frontmatter parser reduced our attack surface to near zero. It compiles in milliseconds on any developer workstation without dependency hell.

Universal Multi-IDE Binding

With the core engine stabilized, I built sprawl bind. This acts as a universal compiler, translating the sovereign policies in AGENTS.md directly into native configurations for Cursor, Windsurf, Claude Code, and Antigravity. Regardless of which editor an engineer prefers, the agent is bound to identical operational constraints.

3. The Design System: The Dual-Brand Divide

A common failure mode in technical marketing is attempting to force a single visual voice onto two different audiences. An enterprise leadership team evaluating security and TCO does not buy software with the same cues as an engineer optimizing their terminal workflow.

I resolved this by establishing a reactive Dual-Brand Design System managed by a global state trigger:

                  ┌──────────────────────────────┐
                  │     Global State Trigger     │
                  └──────────────┬───────────────┘
                                 │
         ┌───────────────────────┴───────────────────────┐
         ▼ (Theme: Brutalist)                            ▼ (Theme: Enterprise)
 [ YOUNES_BAGHOR Personal Brand ]                [ SPRAWL.SOFTWARE Corporate ]
 - Industrial Cyber-Brutalism                    - High-Precision Technical Minimalism
 - System Magenta & Atomic Cyan                  - Sovereign Emerald Green
 - Vibe: Fractional CTO / Trench Authority       - Vibe: Boardroom Governance

Brand 1: The Personal Operator (YOUNES_BAGHOR)

Brand 2: The Governance Gateway (SPRAWL.SOFTWARE)

The 100-Character TUI Spec

I standardized all console diagnostic tools (sprawl doctor) to render at exactly 100 characters in line width (including borders). This eliminates jagged wraps and broken columns across varying terminal dimensions.

4. The Assembly Line: Executing the Epics

The operational backbone of the Release Candidate was my Markdown Project Management (MDPM) convention. I eliminated web-based project boards and replaced them with file-system-based markdown tasks inside a local repository.

The Project Scaffolding

I decomposed the v2 milestone into six bounded Epics:

Every Epic folder contained atomic Task documents with explicit acceptance criteria and exact file paths.

The Closed-Loop Directive

Instead of hand-holding, I launched execution agents with an uncompromising loop directive:

"Act as the Master Engineer. Navigate to this Epic directory. Pick the next 'To Do' task. Set status to 'In Progress'. Write the tests and code. Execute the test runner. Commit to Git. Set status to 'Review'. Move to the next task. Do not stop until the folder is empty."

To eliminate merge conflicts, I constrained concurrent execution to two agents operating on disjoint subtrees. The agents wrote, tested, and committed code sequentially. The pipeline compiled 145 unit tests and staged commits without human intervention.

Emergent Engineering Realities

Conclusion: Systems Thinking Over Model Hype

Shipping Sprawl v2 proved an immutable software rule: Agentic engineering is an exercise in systems architecture, not prompt trickery.

Foundation models are merely the combustion engines; the file boundaries, markdown state machines, and standard-library constraints are what steer the vehicle. High-fidelity structure produces high-fidelity output.

Syntax is temporary. Architecture is permanent.

Related Architecture Essays

Architecting Autonomous Systems?

Stop building fragile monoliths on raw conversational prompts. If you are an engineering lead, CTO, or enterprise architect structuring sovereign agentic workflows, deterministic containment, or local developer governance:

Younes Baghor
Fractional Head of AI & Enterprise Systems Architect | Founder, Sprawl.software

« Previous Back to Blog Next »