My software dark factory behind Explore is an end-to-end agentic operating platform with governance built in. Development governance earns trust before merge. Production governance proves the intended outcome is actually live. The release lane bridges the two, and smoke testing turns confidence into evidence.

AI made polished summaries cheap. That is good for formatting. It is bad for proof. A strong engineer can now look polished in an afternoon. Clean headline. Sharp summary. Sensible project bullets. Nice phrasing. None of that is hard anymore. The problem is that polish used to do more proof work than it does now. It suggested care. It ...

Today I had the marketing agents review one of Explore’s public pages against the brand, mission, and source-of-truth docs we’ve set for the product. They identified a few bounded improvements, packaged them into a clean handoff, and passed the approved changes to engineering. Engineering then picked up that brief, made the scoped page...

A lot of companies seem to think agent accessible means they added a chatbot. It doesn’t. A chatbot is just a new way to talk to the old interface. An agent-accessible app is something an agent can actually use. That means it can understand what the product does, what actions are available, what state it is in, what constraints apply, ...

I’ve been thinking about mobile for Explore. Not because every product needs an app. And not because “launched a mobile app” looks nice on a CV. The more interesting question is: what would mobile teach me about the product, and what would it teach me about the factory? Explore is a Rails product. My dark factory is also primarily Rail...

The interesting part is not the CLI. It’s the login flow. Run explore login, approve it in the browser, and your agent gets authenticated access to the real app. Not a toy sandbox. Not a pasted API key. Not some half-baked “AI feature”. The actual app. This is where software is going. We’re moving from “has an API” to “an agent can act...

I’ve been testing that with Explore. Using the Explore CLI, I gave Codex my latest CV and asked it to compare it to my current Explore profile, recommend the right updates, and apply the relevant changes without touching my writing. Within a few minutes, the profile was updated and live. That is the interesting bit for me. Not just a n...

Explore started as a better proof surface for humans. That was the original idea. Something better than a static CV or polished personal site. Something that let people go deeper into the real signal behind a person’s work, writing, projects, and judgement. But it became clear to me that profiles no longer only need to be readable by h...

I’ve been increasingly concerned by the level of anxiety across our profession. I keep seeing very good engineers, people with real experience, strong judgement, and excellent CVs, feeling uncertain about how to stand out in a market that suddenly feels much more crowded and much noisier than before. A lot of that gets framed as “AI wi...

At that point, it stops feeling like an AI coding assistant and starts feeling like an operating model. The factory is now taking on more responsibility across the path from spec to shipped: auto-merge, production deploy, and verification. I’ve started scoring it against StrongDM’s software factory maturity classification, and on my cu...

A lot of operational pain gets misdiagnosed as a tooling problem or a headcount problem. At small scale, experienced people can often bridge the gaps. They remember the exceptions, know which signals matter, spot what needs doing next, and carry a lot of context in their heads. That works for a while. But as volume, variation, and oper...

One of the biggest advantages is that a shipped job can carry its own decision trail with it: • the prompt/spec • the run log • the verification steps • the PR • the final code and tests That becomes more valuable as the system evolves. Because months later, the hard part is often not reading the code. It is understanding the context t...

Software delivery gets easier to improve once you make the timing visible. One thing I’m starting to like in our dark factory workflow is recording delivery timing directly on the PR. Not just token usage or the final diff, but how the work actually moved: context gathering, implementation, verification, external wait, and total elapse...

One of the simplest dark factory wins for us has been pushing more verification earlier, before the PR ever hits shared CI. That means running a meaningful slice of the expected checks locally first, then attaching the evidence and caveats to the work. Cloud CI still matters. It is the shared, trusted gate. But it should confirm qualit...

One thing I’m now adding to personal project is an agent manifest. The idea is simple: when an agent lands on the product, it should understand what the product does, what state the account is in, what actions are available, what the next best step is, and what guardrails apply. Not just for fully autonomous agents either. Also for hum...

I always understood the theory of pair programming. In practice, it often felt like two people doing work one strong engineer could do alone. AI changed that for me. I always got the value on paper: two brains, shared context, faster feedback, fewer blind spots, better knowledge transfer. But especially in startup and scale-up environm...

Most teams are not building software dark factories. They are bolting AI onto old delivery models and mistaking that for the shift. Coding faster with ChatGPT, Copilot, or Codex is useful, but that is still surface level. The real shift starts when the workflow itself is redesigned around AI: scoped prompts, execution runs, validation ...

Blockchains made computation cost visible through gas. AI is doing the same through tokens, model choice, and reasoning effort. That is a useful mental model. In crypto, you do not send every transaction the same way. If it is low value, you want it cheap. If it is urgent, sensitive, or high value, you may pay more or choose a differen...

Because once AI becomes part of delivery, the business question quickly becomes: what did this take, and what did it cost? For this slice, the PR includes: Current AI Usage in the PR: That is why I think it belongs on the PR. Not because the PR is necessarily the perfect long-term home for it. But because it gives both the reviewer and...

At some point, the business conversation stops being “this is cool” and becomes “what is this costing us, what is it saving us, and is it worth it?” Ultimately, it gets boiled down to the number that matters most: cost. I’ve started rolling out a lightweight way to show AI usage inside the PR itself. Not prompt theatre. Not vague “AI h...

“Whatever mess AI gets us into, AI will get us out of.” I hear that assumption a lot in business conversations. It hasn’t been my experience so far. The question I keep asking is: How do we get businesses to take AI-driven software risk seriously before they have to feel the consequences themselves? Unless you’ve lived through the fall...

Don’t just tell the model what good code looks like. Show it, then make it prove it followed it. LLMs already know plenty of patterns from the internet, but that also means they can pick up plenty of bad implementations too. A lot of AI coding guidance is still too vague: “use best practices” “follow SOLID” “keep it maintainable” That ...

I tried Codex “Fast” properly today for the first time. It’s… ridiculous. The speed feels like you’ve removed friction from the entire loop: ask → change → verify → iterate. You can keep momentum in a way that’s genuinely hard to do in a big codebase with normal latency. But there’s an obvious trade-off: Fast is expensive. (And the UI ...

It’s less noise, In the AI era, context is cost. I’m doing a sweep to remove dead repo assets (old CSVs/exports/screenshots/sample data) and trimming logs (lower verbosity + sensible rotation/cleanup). Why? Because in big codebases, context is cost: navigation/search gets harder agents pull in irrelevant files token/context burn goes u...

LLMs can generate a lot of code quickly but the quality range is massive unless you force the work through guardrails. So I don’t ask my agent for “an answer”. I ask it to ship a solution through a playbook (built from ~20 years of patterns/practices I actually trust in production). The key rule: It must cite which playbook rules it ap...

I ask my software factory: “What’s next in the queue — and how does it move us toward the North Star?” It replied with 5 small, verifiable jobs — each with a clear “why” (contract/telemetry, removing manual paths, hardening inputs, runner policy, cross-repo proof). This is the real agentic unlock for me: not “bigger prompts” — tighter ...

Instead of running one job at a time, I queue a handful of small, reversible slices — and the factory sends back a single execution report when it’s done. That report includes: PR links (merged sequentially) exactly what shipped per job verification commands + outputs the prompt/run artifacts for audit + replay The mental shift: I’m no...

AI hasn’t removed engineering work. It’s changed where the leverage is. Writing code is getting cheap. Trust is getting expensive. So my day-to-day is shifting up the stack: Turning intent into a spec (goal + acceptance criteria) Setting constraints + guardrails (what we will / won’t do) Insisting on verification (tests + CI as the gat...

My agent has to state which best practices it applied — and why. Not just “here’s the diff”, but “here’s the thinking”: what refactoring move was used (extract class, etc.) what rules/patterns it followed how it kept the change small + test-backed what evidence it captured (tests/CI) It turns AI output from “looks fine” into something ...

I planned to extract the Dark Factory engine from my personal project as a standalone tool for work. But I wasn’t happy with the code standard — both the factory itself and some of the code it had produced. It was functional, but naïve. So I did something different. I used Codex plan mode to collate: • the software engineering practice...