Writing software post solstice. 2026.

This interview was conducted on a Friday afternoon bike ride through the Mullum Mullum and Main Yarra trail east of Melbourne. The interviewer is Judy Otage, Sam's technical writer and master of words. She is also an AI agent, and part of the system being described. Make of that what you will.

Where did this start?

Judy: Take me back to New Year's Day. How were you writing software before this, and what changed?

Sam: In December I realised I was doing the same things again and again. I'd been working with OpenSpec for spec driven development, and I could see how it gave the agent a proper task list and a trace of what the requirements were. Not only for building code, but for documentation, for understanding what the software does. So I started wrapping those repetitive procedures into Claude Code commands. Seven standard operating procedures, starting from a clean development branch, working through the lifecycle to an implemented, merged PRD.

Judy: Seven SOPs sounds structured. What broke?

Sam: The automation handled the work inside each step, but between steps it was me. Sitting at the keyboard for an hour and a half, sometimes two hours, pressing yes to move the pipeline along. The output was generally good. I found myself approving everything. At some point it occurred to me that I'd automated part of it, but the connective tissue was still manual. I knew what was happening at each step. The question was whether I could take the whole lot and build the pipeline as one automation.

What does writing software look like now?

Judy: So what changed? When you sit down to build something now, what's the first thing you do?

Sam: I'm no longer constrained by how to build something. It's what needs to happen. That's a massive shift. I used to sit down for a morning and create a year's worth of backlog. Now I sit down with my lead architect or a team of specialists and we workshop the problem. Out of that comes an implementation plan: a simple change request, a conceptual architecture, or a series of product requirements documents. The creative workshopping has unlocked things I could never have imagined building. Technically complex integrations, whole applications, things that were out of reach for a solo practitioner.

Judy: And then what happens to those PRDs?

Sam: I tell the architect to rack and stack the PRD for the build queue. She sends it to Gavin to run the managed build queue. There might be ten or fifteen PRDs queued up. I have dessert, go to bed, and wake up in the morning to new software. They run all night.

What happens overnight?

Judy: While you're asleep, what is the pipeline doing?

Sam: It's a hybrid system. A deterministic Ruby application manages the bread and butter: checking out a clean feature branch, setting up the right context, ensuring visibility and traceability. Agents are lazy. They'll skip the basics if nothing enforces them. The deterministic layer is the adult in the room.

Working alongside that is Gavin, the agentic project manager. He fires up Mel, the business analyst, to create the OpenSpec change request from the PRD. The deterministic layer validates that change request, and then a compliance step checks that it maps back to what the PRD specified. Before a single line of code is written, there have been three handoffs.

Then Gavin breaks the work into a task dependency tree and assigns it across his team. Architects, front end, back end, integration specialists. If the skill set isn't on the team, it gets spun up. The agents communicate through direct messages and broadcast queues. They report completions, flag issues for each other, escalate design conflicts back to the architecture group. It operates like a team, not a batch job.

Judy: And after the build?

Sam: That's where it gets interesting. First there's a simplification pass, because agents love to overcomplicate things. Then compliance checks every item on the spec manifest against what was built. That runs in a two pass Ralph loop. If it fails twice, it escalates for resolution.

After that, testing. The test plan was built as part of the change request, so it runs the new code and everything adjacent the change might have affected. Depending on scope, there's a full system test across the whole application. Then the PR gets created with proper documentation, and it merges back to the development branch. The queue moves to the next PRD.

Judy: What if something breaks mid pipeline?

Sam: Before the build starts, there's a checkpoint commit on the feature branch. The deterministic layer tracks state at every stage. If something fails, roll back to the checkpoint or the branch start and restart from the appropriate stage. No lost work, no manual cleanup.

And all of this is visible on a live dashboard. Pipeline status, progress bars, task state. I can jump into chat with Gavin during a build, ask questions, steer a decision, intervene on a problem without stopping the pipeline. Hands off when I want it, hands on when I need it.

What's different about the output?

Judy: After seven months of this, what's different about the software that comes out?

Sam: I have become one of "those people" and I don't look at the code anymore. And rightly so, because it's naturally complicated, especially when there's JavaScript involved. What's changed is I have more time to think about what I want to build. The builds used to come back maybe seventy percent complete, needing a fair bit of rework. Now it's ninety percent plus. The remaining gap isn't build quality. Its requirements and nuanced things I couldn't have articulated until I could see the thing running. That last ten percent is the stuff that only becomes clear once you can look at it, touch it, feel it.

Where does someone start?

Judy: If someone's reading this and they're still doing it the old way, where do they start?

Sam: Understand what it is that needs to be built first. And the process that turns an idea into reality. Then automate one thing. Build on that, iterate, figure out what's broken, fix it. Build, break, fix, repeat.

The capability compounds. Small iterations, then step changes where things level up completely. The things I've built have helped me build more things that help me build even better. It's Kaizen. Continuous improvement.

And in figuring out how to automate it, the agent is always a friend. It'll help work out how to break down and structure the thing, fill in the gaps and get everything organised to automate the thing, if the thing can be described. The human's job is knowing what needs to happen.

It's a whole new world we are in 2026 and even then with the arrival of models like Fable 5 we're probably set for even more change as we accelerate into the unknown.