See
Start with a runnable, observable application
My current workflow after six weeks with Codex
Questions
before code.
I do not begin by asking an agent to implement a feature. I make the application inspectable, resolve the important decisions with the agent, turn those decisions into an issue graph, and let bounded Codex tasks execute against tests.
human describes intent
grill resolves decisions
issues encode dependencies
tasks claim bounded work
tests decide what passes
status: learning in productionGrill
Resolve intent against the code and docs
Slice
Publish dependency-aware GitHub issues
Dispatch
Give bounded issues to separate Codex tasks
Prove
Use tests and deployment evidence as gates
01 / Foundation
Start with an application the agent can see
I begin with a simple application framework that can run end to end. It exposes as much of its internal behavior as practical: structured events, useful logs, deterministic test seams, and a way for the LLM to inspect what happened after an action.
A thin, complete system
The first version need not be broad. It needs to be runnable through the real boundaries, so every later feature has somewhere truthful to attach and every bug has a reproducible path.
Make state queryable
Introspection means the agent can inspect relevant state and contracts directly. It reduces the amount of application behavior that must be guessed from source code alone.
Leave causal evidence
Logs are most valuable when they identify operations, transitions, durations, and safe error types. A pile of strings is less useful than bounded events an agent can correlate with a failed test or browser action.
02 / Shared understanding
Grill the change before specifying it
I use a grill-me-with-docs skill adapted from Matt Pocock. I briefly describe the bug or feature. Before asking me anything, the agent reads the relevant code and agent documentation. It then asks the highest-leverage questions first, five at a time.
- 1Inspect
Read the codebase, existing contracts, tests, and agent docs before forming questions.
- 2Prioritize
Ask first about choices that change architecture, product behavior, risk, or scope.
- 3Recommend
Offer a concrete default for each question so I can decide quickly or accept a coherent set.
- 4Persist
Add settled, durable decisions to the right project document instead of leaving them trapped in chat.
What it does for me
It exposes assumption mismatches early.
I can correct the agent while a decision is still cheap, rather than after it has spread through code, tests, and deployment configuration.
What it may do for the model
It creates a deliberate reasoning scaffold.
My interpretation is that ordered questions force the model to build a more explicit representation of the problem. That is plausible, but the observable benefit is alignment, not proof of deeper internal reasoning.
The failure mode
Recommendations can become invisible decisions.
Accepting all defaults is efficient, but I still slow down for irreversible product choices, security boundaries, destructive operations, recurring cost, and decisions that constrain later work.
03 / Durable work
Turn the decisions into an executable issue graph
After the grill, another skill files a GitHub issue. Complex work becomes a parent with dependency-ordered children. Each issue says whether it can run AFK, where human judgment is required, what it may touch, what it depends on, and how completion will be proved.
Issue contract#211
Kind
Parent, implementation child, bug, or acceptance issue
Autonomy
AFK or human in the loop
Dependencies
What must finish before this work is ready
Parallel group
Which work may safely overlap
Conflict risk
Likely shared files, interfaces, or deployment surfaces
Validation
The evidence required before completion
Bounded enough to proceed
AFK does not mean unimportant. It means the product decisions, permissions, cost limits, dependencies, and acceptance evidence are explicit enough for a task to continue without asking me.
A judgment boundary remains
Human-in-the-loop issues stop at gates such as product approval, private production verification, spending, migrations, secrets, or an external console action. The stop is part of the contract.
04 / Coordinated execution
Let a parent task operate the queue
My GitHub orchestrator inspects the selected open issues, computes what is ready, and opens separate Codex tasks for implementation. It runs independent work in parallel and serializes work when shared files, interfaces, branches, browsers, or deployments create a high chance of conflict.
Inspect, schedule, integrate
Owns the queue and dependency order, not the implementation.
<!-- codex-claim:v1 -->
Action: claimTask: 019fb430-c114...Time: 2026-07-30T18:12:57ZConcurrency control
The issue claim is a concurrency lock
A task writes its Codex task ID into an append-only issue comment and applies an in-progress label. Other tasks can discover the owner, exchange information, release work, or explicitly take it over. The task ID turns a chat from an isolated transcript into an addressable participant in the delivery system.
05 / Evidence
Tests are the accumulating memory of the product
Each implementation task uses a TDD skill. It first captures the new behavior or bug as a failing test, makes the smallest change that passes, and refactors with the safety net in place. End-to-end coverage grows as features grow, and the required suites run before every push.
Describe the missing behavior
A failing test proves the change is not already present and reproduces the defect.
Make the contract pass
Implementation is judged against an executable expectation, not the confidence of the authoring task.
Improve without changing behavior
The growing suite protects previous decisions while the internal design changes.
A green suite is necessary, not sufficient. Tests can encode the same misunderstanding as the implementation. That is why the grill, issue acceptance criteria, fresh integration checks, and human product judgment remain separate gates.
06 / Repository evidence
This is operating machinery, not a proposed diagram
The Alpha Compose repository shows the workflow under real pressure: privacy boundaries, cloud infrastructure, browser behavior, costed media processing, two integration branches, and hundreds of tests.
Parent issue #206
Seven dependency-ordered children
Implementation work is AFK; final production and costed acceptance remain explicitly HITL.
Inspect issue ↗Child issue #211A narrow vertical contract
Dependencies, touchpoints, non-goals, privacy boundaries, and validation are fixed before dispatch.
Inspect issue ↗Issue #226The test system improves too
Affected-test selection shortened feedback while preserving a complete production-bound test gate.
Inspect issue ↗The structure underneath
The grill resolves what the product should do and records durable invariants.
Issues encode dependencies, autonomy, ownership, conflict risk, and integration order.
Tests, logs, commits, workflow runs, and browser checks show what actually happened.
07 / Possible improvements
What I would add next
The workflow already has strong alignment, durable coordination, and application-level feedback. The next gains are likely to come from measuring the workflow itself and making integration a first-class product gate.