Going Dark: Why I'm Automating My Software Factory From Ticket to Merge

I've reached the point where I trust my AI agent orchestration system more than I trust myself to stay consistent with repetitive code reviews. That's not hyperbole or a hot take for engagement—it's a practical reality I've arrived at after 25 years of building software and the last several months building and refining Sandstorm, my AI-powered development workflow system.

Here's what I mean by "going dark": I'm implementing a configuration option in Sandstorm that will automate the entire development pipeline after ticket refinement. Once a ticket is marked as ready, the system will spin up a stack, execute the work, review itself, fix problems, verify tests pass, create a pull request, resolve merge conflicts, merge the PR, tear down the stack, and clean up—all without human intervention. It's the software equivalent of a dark factory, those manufacturing facilities that run lights-out with no human workers on the floor. You put tickets in one end, and you get merged code out the other.

If that makes you uncomfortable, I get it. It should make you at least a little uncomfortable. We've spent decades building cultural norms around code review, quality gates, and human oversight. But I'm not proposing this as a universal approach—I'm proposing it as a contextual tool that makes sense for specific types of projects. And that distinction is everything.

The Journey to Automation

Let me back up and explain how I got here. Sandstorm started as an experiment in agent orchestration—using AI to handle various parts of the software development lifecycle. Initially, the workflow was semi-automated: I'd create tickets, refine them, and then manually shepherd them through each stage from development to code review to merge. At each step, I was the gatekeeper, manually confirming before moving to the next phase.

Then I migrated the whole system to a Kanban board, and something clicked. The flow became crystal clear: backlog to refined, refined to in progress, in progress to review, review to done. Each transition point was explicit. Each stage had clear entry and exit criteria. The visibility transformed how I thought about the process because I could see exactly where friction existed and where human intervention was actually adding value versus where it was just theatrical quality control.

What I discovered was fascinating: on certain projects, my manual reviews weren't catching anything the automated checks hadn't already caught. I wasn't adding value; I was adding latency. The AI agents were writing code, reviewing their own code, writing comprehensive tests, and the test suite was catching edge cases. My role had become rubber-stamping work that had already been thoroughly validated. That's when I started thinking seriously about going dark.

Not All Projects Are Created Equal

Here's the critical nuance that gets lost in discussions about AI and software development: not all projects have the same quality requirements, and not all code has the same risk profile. I have projects in my portfolio where every single line of code absolutely must be human-reviewed. These are systems where bugs have real consequences, where the codebase is complex enough that context matters enormously, or where the requirements are ambiguous enough that judgment calls are frequent. For these projects, human review is non-negotiable, and Sandstorm will continue to require manual approval at each stage.

But I also have projects where that level of scrutiny simply doesn't matter. These are internal tools, experimental projects, or systems with such comprehensive test coverage and such well-defined specifications that the automated checks provide sufficient quality assurance. For these projects, the bottleneck isn't code quality—it's my availability to click the merge button. The testing is heavy, the ticket specifications are thorough, and I do manual QA on the actual running application rather than reviewing code line by line. In this context, automated merge is not just acceptable; it's the right choice.

The ability to configure this behavior per project is what makes this approach practical. This isn't about replacing human judgment universally; it's about deploying human judgment strategically where it actually matters. Some projects need the lights on. Others can run in the dark.

What "Dark" Actually Means

When I say Sandstorm is going dark, I'm borrowing from the manufacturing concept of the dark factory—facilities that are fully automated and can operate without lighting because no humans need to see what's happening. The metaphor is apt: once I refine a ticket and mark it ready, I don't need to see the intermediate steps. I don't need to watch the stack spin up, observe the code being written, scrutinize the self-review, or monitor the test execution.

The dark factory model works in manufacturing when you have several things in place: extremely clear specifications, robust quality control systems, and automated error detection and correction. You need sensors and feedback loops that can catch problems and either fix them or escalate them. The same principles apply to a dark software factory. My tickets need to be refined with clear acceptance criteria. My test suite needs to be comprehensive enough to catch regressions and edge cases. My AI agents need to be capable of self-review and self-correction. And critically, I need monitoring and QA at the application level to catch anything that slips through.

When those conditions are met, the intermediate steps become implementation details. What matters is the input—a well-specified ticket—and the output—working, tested, merged code. Everything in the middle can happen in the dark because the quality gates ensure that only validated work makes it through.

The Efficiency Gains Are Real

Since migrating to the Kanban board and tightening up the workflow, the pace at which I'm moving through work has been, frankly, insane. Tickets flow from creation through refinement through implementation at a velocity I haven't experienced in my 25 years of building software. Part of that is the agent orchestration—AI handling the repetitive parts of coding, testing, and review. Part of that is the process clarity—knowing exactly what state each piece of work is in and what needs to happen next.

But the remaining bottleneck has been me. Even when a ticket is complete, tested, and ready to merge, it sits waiting for me to review and approve it. That might take hours or days depending on what else I'm working on. For the projects where that review isn't adding value, that wait time is pure waste. Going dark eliminates that waste entirely. The system can process tickets 24/7 without waiting for my input.

This isn't about being lazy or abdicating responsibility—it's about recognizing that my time and attention are finite resources that should be deployed where they create the most value. If I can offload the routine merges on low-risk projects, I can focus my code review energy on the high-stakes projects where my experience and judgment actually matter. That's better for me, and it's better for the work.

Building Confidence Through Testing and QA

The reason I'm comfortable going dark isn't because I trust AI blindly—it's because I've built a system of checks and balances that doesn't rely on code review as the primary quality gate. My approach emphasizes heavy testing and thorough ticket specification on the front end, then manual QA on the actual running application on the back end. This creates a quality sandwich where the work is constrained and validated at both ends.

When tickets are specified properly—with clear acceptance criteria, edge cases identified, and expected behavior documented—the AI agents have a clear target to hit. When the test suite is comprehensive, it validates that the target was hit. And when I do QA on the actual application, I'm verifying that the ticket specification was correct and complete, not just that the code matches the spec. This is arguably a more robust quality process than traditional code review, which often focuses on code style and potential bugs but can miss specification problems entirely.

The confidence to go dark comes from running this process dozens of times and seeing it work. The AI agents catch issues in self-review. The tests catch regressions. The QA catches specification gaps. Each layer provides redundancy, and together they form a quality control system that doesn't require human review of every pull request.

The Future Is Contextual Automation

What excites me about this direction isn't just the efficiency gains for my own work—it's what this represents for the future of software development. We're moving beyond the binary of "humans write code" versus "AI writes code" and into a more nuanced world where the right level of automation is applied based on context. Some work needs deep human involvement. Some work can be fully automated. Most work will exist somewhere in between, with humans and AI collaborating at different stages based on what each does best.

The key is building systems that are flexible enough to handle that contextual variation. Sandstorm's per-project configuration for automation level is a step in that direction. I can run some projects fully dark, keep others fully manual, and tune the automation level for everything in between. As I build more projects and gather more data about what works, those configuration decisions will become more informed and more precise.

This is what the transformation of software engineering practice looks like in practice—not a wholesale replacement of human developers, but a thoughtful reallocation of human attention to where it creates the most value. The dark factory model works for manufacturing because it automates the routine and repeatable, freeing humans to focus on design, optimization, and problem-solving. The same model can work for software, if we're willing to think critically about where human judgment actually matters and where it's just tradition.

Going Dark on Sandstorm

So yes, Sandstorm is going dark—at least for the projects where it makes sense. I'm implementing the full automation pipeline, and I'm genuinely excited about it. Not because I think human developers are obsolete or because I trust AI uncritically, but because I've built a system where the checks and balances are sufficient to ensure quality without requiring my constant oversight. For certain projects, that's exactly the right approach.

The lights are going out, but the work will continue. And honestly, that's exactly how it should be.