Share your best AI workflow. We could show it to 2M+ people.

AI coding tools can build quickly, but they can also build the wrong thing quickly. Starting implementation from a vague feature request leaves important decisions about scope, architecture, edge cases, success criteria, and expected behavior to be made implicitly during coding. I created a spec-generator agent that sits between an idea and implementation. I give it a feature request, product vision, or rough description of what I want to build. It investigates the existing project, identifies missing decisions and constraints, researches external dependencies when necessary, and turns the request into a detailed specification that another AI agent can implement without having to guess what I meant. The finished specification becomes the source of truth for the rest of the development workflow. Step-by-step: 1. I give the spec-generator the feature or product idea I want to build, along with any existing requirements, vision documents, or constraints. 2. I have it inspect the existing project before proposing a solution. It needs to understand the current architecture, conventions, capabilities, and relevant prior decisions rather than designing the feature in isolation. 3. I have it identify ambiguities and missing decisions, including questions about users, behavior, scope, dependencies, edge cases, data requirements, integrations, and what is explicitly out of scope. 4. I have it research external technologies, APIs, libraries, or platform capabilities when the design depends on facts that cannot be determined from the repository alone. 5. I have it translate the idea into a layered specification: first the product purpose and desired outcomes, then the technical architecture, and finally the detailed implementation requirements. 6. I have it define measurable success criteria and acceptance tests so that “done” means something concrete rather than simply “the code was written.” 7. I have it persist the finished specification in the project so developers or coding agents can treat it as the source of truth during implementation. 8. I pass the specification through a separate review or validation step before coding begins, resolving gaps or contradictions in the spec rather than discovering them halfway through implementation. Instead of asking an AI coding agent to interpret a rough idea while it writes code, I separate figuring out what should be built from building it.

I never ask AI to “build the app.” I move the work through a fixed assembly line, and the most valuable stations are the ones whose only job is to attack what came out of the previous station. I’m a solo developer, and this is how I build and ship software for paying clients without a team to catch my mistakes. I choose the next chunk of work—a “phase”—and run one command. Each phase gets its own fresh context window, which matters more than any single agent because a long-running session gradually forgets its own rules. Step-by-step: 1. I discuss the phase with an agent that interrogates me until every gray area is decided. The decisions go into a file instead of staying in chat, where they can get lost. 2. A planner writes an executable plan covering the tasks, files to be changed, a threat model, and the acceptance checks that will prove the work succeeded. 3. A different agent, working from a fresh context, checks the plan by working backward from the goal and trying to prove that the plan will not achieve it. This agent can block the phase, and regularly does. 4. I execute the plan task by task, making one atomic commit for each task so the changes can be reverted cleanly. 5. I send the diff to a different model than the one that wrote it. I run Codex and CodeRabbit alongside Claude. This is the highest-value station in the line: my own tests verify only what I thought to check, while an independent model can catch the class of problem I did not anticipate. 6. An agent verifies whether the phase goal was achieved by re-deriving it from the actual code. “All tasks completed” and “the thing works” are different claims. Treating them as the same is how you ship a green checklist on top of a broken feature. 7. Before anything reaches a client, I run a security and handoff audit in a real browser against a throwaway clone of the production database. I check every page, every button, and every empty and error state. The part that compounds is what happens when a bug reaches me anyway—whether I find it in production or, worse, a client reports it. I log it as an escape, then walk the chain backward and ask each gate why it missed the problem: the planner, plan checker, executor, both reviewers, verifier, security check, and handoff audit. A one-off escape becomes a written rule. A repeat becomes a change to the gate itself. I have 42 logged escapes. That file is the most valuable thing I own because every entry represents a hole that is now closed. The pipeline I run today is mostly shaped by bugs that got past the pipeline I ran a year ago. The results so far: 29 projects, 17,657 commits, and 574 phase folders. I’ve completed six client engagements, with apps live in production and handed off to their owners, as well as mobile apps built and pushed through App Store review—all as one person, with no team. There are real costs and failure modes. A phase with every gate enabled costs meaningfully more tokens than simply asking a model for the code. That is worth it on client work, where a bug can cost me a relationship, but it is overkill for a throwaway script, so I turn the gates off for those. Gates can also be confidently wrong. My most expensive recurring failure is a check that passes on a signal adjacent to the thing it claims to verify—a green light that means nothing. My rule now is that I do not trust a new check until I have watched it fail against known-bad input. A green result you have never seen turn red is not evidence. A green test suite is not the same as a working feature. Nearly every bug that escaped me was covered by a passing test whose mock had quietly pre-satisfied the exact condition under test. Testing the real boundary is the only thing that catches those failures. This process is not hands-off. I deliberately run one phase per session, and I read what comes back. Anyone selling a fully autonomous overnight build is selling a merge conflict plus a confident summary of work that did not happen. If you want to take one idea from this, it is not the framework. The agent that writes the work must never be the one that approves it. Keep a running log of everything that gets through anyway, then fix the checkpoint that let it through instead of only fixing the bug.

This Codex-driven workflow takes a software request from problem understanding through implementation, validation, review, and delivery evidence. Instead of asking an AI coding agent to simply “build the feature,” it gives the agent an explicit development lifecycle with defined responsibilities, deterministic validation gates, repair loops, and human checkpoints. The goal is to make AI-assisted development more structured, observable, and recoverable. It can be used for new feature implementation, bug fixing, refactoring, test creation and improvement, code quality and security hardening, and documentation and automation changes. The core principle is simple: Don't give the AI only a coding task. Give it an engineering lifecycle to work on. Step-by-step: 1. Understand the problem. Clarify the request, identify the desired outcome, define the scope, and surface ambiguity before implementation begins. The output is problem understanding and scope. 2. Define constraints. Identify technical, functional, non-functional, compatibility, and out-of-scope constraints. The output is a constraint set. 3. Plan. Analyze implementation options, select an appropriate approach, break the work into tasks, and define acceptance criteria. The output is an implementation plan. 4. Inspect the existing system. Review the relevant codebase, dependencies, current behavior, and affected components before making changes. The output is system context. 5. Implement. Make the smallest appropriate code changes while following the existing project’s conventions and the approved plan. The output is code changes. 6. Run deterministic validation. Run tools that can objectively validate the implementation, including formatting, linting, type checks, builds, unit tests, and other available automated checks. The output is validation results. 7. Review. Evaluate the implementation against the original requirement, the plan, code quality expectations, security considerations, and potential regressions. The output is review findings. 8. Repair and iterate. If validation or review identifies problems, diagnose the issue, make the required correction, and repeat validation. The output is a corrected implementation. 9. Verify. Confirm that the acceptance criteria are satisfied and that the relevant tests and checks provide sufficient evidence for completion. The output is a verification result. 10. Produce delivery evidence and handoff. Summarize what changed, what was tested, what passed, known limitations, and any remaining decisions requiring human attention. The output is delivery evidence and a human handoff. The core loop is: Implement → Validate → Review → Repair → Validate → Verify. Testing and review are treated as part of development rather than activities performed only after coding is “finished.” AI coding agents are increasingly capable of inspecting repositories, writing code, running commands, and responding to failures. The problem is that capability alone does not provide an engineering process. This workflow separates the responsibilities an AI coding agent performs into explicit stages. It applies several principles: - Problem before implementation: Understand what needs to change before writing code. - WHY before HOW: Establish the intent and constraints before choosing an implementation. - Single responsibility per stage: Give each stage a defined purpose and output. - Deterministic validation first: Use tests, linters, type checkers, builds, and other deterministic tools wherever they can establish correctness. - Failure localization: When something fails, identify which stage or assumption needs correction. - Evidence-based completion: Support completion with validation and review evidence rather than an AI declaration that the task is finished. - Human checkpoints: Use automation to accelerate execution without removing human judgment from important decisions. The broader idea is: The AI should participate in the engineering system, not become the engineering system.