Harnesses, Orbs, Software Factories, Nightly Agents. For months, my feed has been full of different names for the same thing: countless people cosplaying as Tony Stark with their own JARVIS(es?).
At first, I assumed it was just unemployed indie hackers; looks in the mirror; who were LARPing as a poor man’s RDJ, But then companies started releasing their own “factories”, claiming productivity boosts so dramatic that they now ship thousands of PRs every day, while their apps somehow look and feel exactly as they did six months ago.
Marvelous!
Anyway, I’m not going to spend an entire post hating on them. What I do want to talk about is how everyone seems to be running with the gains of the agentic boom, while Octarine — and, by extension, I; are trying to brisk-walk our way toward a calmer, better writing platform for our users.
Ew, you read the code?
The internet is divided on this.
A sizable group believes SOTA models write excellent code — often better than we could — so why become the bottleneck?  | Others argue that if you do not read the code, you are building pet projects or selling courses — not seriously shipping a product into customers’ hands. Assuming you even have customers.  |
I agree with both.
- The models are exceptional; most times. In 2026, I would not spend much time writing code, and mostly haven’t. The exception is when a model keeps running in circles and fixing it myself is simply faster.
- But regardless of who writes the code — your AI, your own artisanal organic hands, or your cat — you are responsible for it when shit hits the fan. If customers, your manager’s customers, or your manager’s manager’s customers are entering their credit-card details for your app or service, someone will hold you accountable.
Enough industry chatter like I know what I’m talking about.
So how does Octarine ship?
Here’s how I work with agents, use AI to write code, and review it before shipping new versions to customers.
We’ve already established that I write very little of the code myself in 2026. Most of it is delegated to a more intelligent machine. But how do we get there?
Plan
Every customer request, bug fix, and internal roadmap item starts with a detailed plan.
- I fire up Codex, talk through the request, point it to the files that need to be considered or created, and let it reason through the work.
- Once it has a draft, it’s automatically saved to Octarine in the Codex Plans folder using the handy octarine-notes skill, ready for me to review.
- I go through the document, add comments or make changes, then ask the agent to revisit it and incorporate the feedback.
- Once I’m satisfied, we build.
It’s built. Now what?
- First, I ask an agent to review the code it just wrote and catch any P1 or P2 bugs — SOTA, apparently.
- It fixes the issues it created, then I run another review with a different model. Less bias, I think, though that’s purely anecdotal.
- Once the agents are happy with the code quality, I run a custom skill I made called PR Review. It creates an Octarine note with a walkthrough of the PR, Mermaid diagrams, and code blocks to help me understand the change. Here’s an example from a recent performance-improvement PR.
Throughout this process, I’m constantly testing the feature visually. I don’t run agents overnight or leave them in long, self-contained loops. I can’t work like that — I need to see responses quickly and changes quickly. That’s probably why I became a frontend engineer in the first place: I need to see the result.
Once all of that is checked off, we finally get to reading the code.
You don’t need to read every line of code. But you need to know what changed and where, because you’re ultimately responsible — and you have a deeper, first-principles understanding of the codebase than the AI agent does in this run.
I used to review everything in GitHub, but it has become painfully slow for medium-to-large PRs — which is what SOTA models tend to ship these days. So I did what every other indie does: I made my own review app.
It’s called Diff, and I think it’s pretty cool. It’s faster, lighter, and gets the job done. (Was this post all an ad for it? No. Maybe. No.)
Anyway, I review the code file by file rather than line by line. I skim the purely UI-related files, spend more time on helpers and useEffects, and pay attention to the random Rust performance improvements Codex likes to make. I want to understand whether they’re necessary — and, in the process, learn more about the codebase.
Meanwhile, at the software factory
The new craze is agents that pull customer issues from whatever portal you use (Linear, Intercom, Slack), spin up a VM Sandbox (gotta get with the times), investigate, open a PR, send over a screenshot or recording, and get merged to prod after someone looks it over (I hope, at the very least).
Apparently this happens 50–100 times a day/week. The interval depends on how “agentic” you are; lower is better. That’s how they’ve all become productive. This is what Vibe Coding looks like when you’re a professional getting paid.
The gains are real. I ship more because of AI than I ever could alone.
AI lets me ship more. It does not let me care less.
Do you need to do this?
Maybe. I don’t think everyone needs to be as annoyingly hands-on as I am (even I don’t on hobby projects, like Diff). If you are just having fun on a weekend project OR building for a consumer of 1, then not being attached or worried about the output code is fine. Just different stakes.
But once customers are paying you, “idk the agent wrote that” stops being a particularly useful explanation. The user doesn’t care who wrote it.
So no, I don’t think a software factory works for me, not now atleast, not for Octarine. What works is a tightely knit workflow that makes me feel fine about putting my name on the code that a clanker wrote.
That’s plenty Tony Stark for me.