I stopped treating Codex like a developer and built a development system around it

Ever since I wrote about why AI built websites tend to look the same, I have been thinking about the larger problem.

Adding better design skills can improve the interface. It does not automatically give you a better product. A beautiful screen can still sit on top of an unclear customer journey, a fragile architecture, vague permissions, missing failure states, and a development history that disappears every time you open a new conversation.

That is the part people rarely show when they post the polished result.

I am a nontechnical builder. I can define the product, question the experience, connect business requirements, and make decisions. I cannot look at a large codebase and pretend years of engineering instinct suddenly arrived because I subscribed to a more capable model.

So I stopped looking for one perfect prompt. I built a small development system around Codex instead.

This article shows the system as it actually exists. It includes the skills that teach repeatable methods, the agents that take on bounded specialist roles, the memory tools that help with larger codebases, and the points where I still need to make the decision.

A capable model can produce code. A development system gives that code somewhere sensible to come from and somewhere honest to be checked.

First, skills and agents are not the same thing

The terminology makes this sound more mysterious than it is.

A skill is a reusable method. It tells Codex how to approach a kind of work, what evidence matters, and what good completion looks like. A skill may explain how to plan a product, investigate a bug, review accessibility, or prepare a release.

An agent is a temporary specialist context. It receives a bounded responsibility, does that work independently, and returns a result to the main task. I use agents when separation improves the thinking, not because a row of digital employees looks impressive in a diagram.

An MCP service gives Codex access to an external capability. In this system, Codebase Memory provides a persistent structural map of a repository.

The distinction matters because each one has a different cost. Skills load guidance. Agents consume a separate working context. Memory services maintain an index. If all of them activate for every minor change, the operating system becomes the problem.

The development journey and who owns each stage

The system follows the journey of the product rather than a collection of fashionable tools.

1. Product intent

The Product and Specification Steward takes a rough request and turns it into a decision ready working brief. It preserves the problem, user, desired outcome, business rules, scope, assumptions, and product level acceptance conditions.

It uses my Plan AI Product Build skill as its governing method. That keeps the agent from inventing a second planning system or producing a ceremonial PRD for a two line change.

The Steward can ask up to three consequential questions in one round. It recommends a default and explains the consequence, which means I can answer in normal language or simply say, “Use your recommendation.”

This is one of the agents we created ourselves. Anyone can create a similar version with Codex's skill and agent creation tools. The important part is the boundary: use it for a new product, a significant feature, an important product decision, or genuinely unclear scope. Do not summon it to move a button.

2. Experience and interface direction

The Design Product Experiences skill owns substantial journeys, interaction states, accessibility intent, and experience review. The Frontend Art Direction and related product design skills help move the interface away from generic component assembly and towards a coherent visual point of view.

They should shape the experience before detailed implementation and return during review. Distinctiveness is not a final filter applied after the product has already been built.

3. Delivery planning

The Plan Delivery Slices skill converts the agreed product behaviour into small, usable outcomes. It creates observable acceptance criteria, maps dependencies, and identifies the evidence required for each slice.

This means I do not write formal acceptance criteria myself. I describe what should happen. The system translates that intent into conditions that can be checked later.

For example, I might say:

A customer can cancel a booking until the service begins, and should receive confirmation.

The resulting criteria may cover the eligible journey, the blocked journey, confirmation, persistence after refresh, and a useful error state. My job is to confirm that the conditions reflect the business intent.

4. Architecture

The Software Architect agent deals with decisions that become expensive to reverse. Architecture is simply where things live, how they connect, who can access them, and what happens when part of the system fails.

For a nondeveloper, the useful answer is not a lecture about patterns. It is a recommendation such as:

Keep this inside the existing application. A separate service would add deployment and maintenance work without solving a current scale or security problem.

The agent should appear when there is a meaningful choice about data, permissions, integrations, deployment, reliability, scale, or recovery. It should stay quiet during ordinary implementation. The installed architecture specialist comes from the broader Agency Agents repository, while the architecture method is reinforced by the installed OpenAI software architecture plugin.

5. Compliance when the product triggers it

Before implementation begins, there is one conditional checkpoint I had originally left implicit.

The Product Compliance Officer appears when a product involves accounts, personal or sensitive data, payments, subscriptions, refunds, tracking, third party SDKs, mobile distribution, children, regulated activity, or multiple jurisdictions. It determines which obligations are actually relevant, then routes the work to experience design, architecture, security, delivery planning, or verification.

This is not a legal agent running beside every coding task. A simple informational site may need no elevated workflow. A subscription platform storing customer information probably does. The point is to make the decision deliberately, record the applicable requirements, and revisit them before release without turning every project into a compliance exercise.

6. Implementation

Codex remains the main builder. It uses stack specific skills only when the project requires them. React guidance should not load for a Swift application. Supabase guidance should not appear when the product has no Supabase database. Security specialists should be selected according to the actual risk.

The Codebase Onboarding Engineer is useful when Codex enters an unfamiliar or inherited repository. It identifies the important folders, conventions, boundaries, commands, and likely areas of risk. The Code Reviewer enters later for a meaningful feature, risky change, or release candidate. Neither needs to inspect every tiny edit.

Both agent definitions were adapted from Agency Agents. They are useful source material, but the activation rules matter more than the number of agent files installed.

7. Acceptance and quality

The Acceptance and QA Reviewer compares the delivered behaviour with the observable acceptance conditions. It answers a simple question: did we build what we agreed to build?

It activates only when a delivery slice has something observable to verify. It does not review vague aspirations, and it does not replace security, accessibility, performance, or specialist technical checks when those risks matter.

The wider Verify Product Quality skill coordinates consequential verification and release readiness. For products that depend on AI outputs or agent actions, Evaluate AI Product Behaviour checks quality, safety, reliability, and failure behaviour that ordinary software tests cannot fully cover.

8. Handoff and continuity

The Handoff Steward preserves the minimum useful state when work crosses a real boundary. That usually means a new feature task, a new conversation, a milestone, or a change of owner.

It records the current outcome, decisions, unresolved risks, relevant evidence, and the next action. It should not write a memoir after every prompt. A short task level summary is enough during normal work. The fuller handoff is reserved for moments when context could genuinely be lost.

What activates automatically and what stays explicit

The system only works if activation is disciplined.

Skills can be selected implicitly. Their descriptions tell Codex when they are relevant. I can still invoke one explicitly with $skill-name when I want a particular method.

Agents do not magically hold a meeting in the background. The main task or coordinator delegates to them when their activation condition is met. Product Steward appears for important ambiguity. Architecture appears for costly structural choices. Code review appears for consequential changes. Handoff appears at context boundaries.

Compliance is conditional at two useful moments. It is considered early enough to influence the product and data design, then checked again before release when the product has meaningful privacy, payment, store, SDK, or regulatory exposure.

Codebase tools are deliberately selective. Codebase Memory is available for structural exploration, but automatic indexing is disabled in my setup. Graphify remains an explicit mapping tool. That prevents small projects from paying the cost of infrastructure they do not need.

Here is the operating rule I use:

The second brain is really three different memories

I originally used “second brain” as if it described one thing. It does not.

The Product Steward remembers what we are trying to achieve and why.

The Handoff Steward remembers decisions, progress, evidence, and what should happen next.

The codebase index understands what currently exists in the repository and how its parts connect.

Codebase Memory MCP is the ongoing structural layer. It indexes functions, classes, routes, calls, and cross service relationships into a persistent local graph. Codex can use it for architecture summaries, impact analysis, path tracing, and targeted code exploration. It is most useful when a repository is large, inherited, or expensive to rediscover repeatedly.

Graphify serves a related but different purpose. It produces an explainable visual knowledge graph across code and supporting material. I use it when I want to see the system, trace a relationship, or create a map that a human can explore.

I installed both, but I would not run both on every new project. Codebase Memory is the practical working index for a substantial codebase. Graphify is the explicit visual investigation. A small new application may need neither.

Neither tool knows the full reason behind a business decision unless that reason has been recorded. A graph can show that two services connect. It cannot reliably tell you why the customer promise required that connection, why another option was rejected, or what evidence would justify revisiting it.

A worked example

Imagine I start with this request:

I want customers to reschedule appointments. I am not sure about the rules yet. Help me think it through and then build it.

The Product Steward identifies the material questions. How close to the appointment can a customer reschedule? Which roles can override the restriction? What happens to payment or availability when the time changes? It recommends sensible defaults instead of sending me a questionnaire with seventeen empty fields.

If the service stores customer data, takes payment, or sends reminders through a third party, the Compliance Officer identifies only the applicable privacy, consent, refund, retention, and provider requirements. Those become product and technical requirements rather than legal wording pasted onto the end of the project.

Plan AI Product Build preserves the agreed journey and business rules. Plan Delivery Slices creates a coherent first release and acceptance conditions. The Software Architect is consulted only if the change introduces a consequential decision, perhaps a new source of truth for availability or a risky integration boundary.

Codex implements the slice using the project's actual stack and conventions. If the codebase is unfamiliar, the Onboarding Engineer and Codebase Memory help locate the relevant path without rereading the whole repository. The Acceptance Reviewer checks the completed journey against the agreed conditions. The Code Reviewer appears if the change is substantial enough to justify an independent technical pass.

Finally, the Handoff Steward records the result if the work is moving into another feature task or conversation.

At no point did I need to tell six agents to wake up. The journey created the routing.

The standard prompt I would use for a new project

The prompt should establish intent and operating rules without trying to paste the entire development system into every conversation. The expandable section below contains the complete version I would use after installing the relevant skills and agents.

I want to start a new software product or significant feature. Begin by reading the project instructions and any existing product brief, decisions, design system, and repository guidance.

Use the Product and Specification Steward with the Plan AI Product Build method to turn my request into a concise working brief. Preserve the problem, intended users, desired outcome, main journey, business rules, scope boundaries, assumptions, important data or privacy concerns, and observable success.

Do not require me to write a formal PRD, architecture document, or acceptance criteria. Ask only questions whose answers could materially change user value, scope, cost, privacy, risk, or direction. Ask no more than three questions in one round. Give a recommended default and explain its consequence so I can approve it in plain language.

Once the product intent is clear, use the relevant experience design skills to define the primary journey, important states, accessibility intent, and a distinctive interface direction. Then use Plan Delivery Slices to create the smallest coherent delivery sequence and observable acceptance criteria.

Use the Software Architect only for consequential choices involving data ownership, permissions, integrations, deployment, reliability, scale, failure, recovery, or decisions that would be expensive to reverse. Explain recommendations in business language and show the smallest useful set of options.

If the product involves accounts, personal or sensitive data, payments, subscriptions, refunds, tracking, third party SDKs, mobile distribution, children, regulated activity, or multiple jurisdictions, route a proportionate assessment through the Product Compliance Officer. Let it identify applicable product controls, data boundaries, evidence, and professional review needs. Skip the elevated workflow when no trigger exists, and reassess before release when relevant.

During implementation, use only the stack and specialist skills relevant to this repository. For an unfamiliar or substantial existing codebase, use Codebase Memory and the Codebase Onboarding Engineer before broad file exploration. Use Graphify only when I explicitly request a visual codebase map or when an explainable relationship map would materially reduce uncertainty.

Use the Acceptance and QA Reviewer when a delivery slice has observable acceptance criteria. Use the Code Reviewer for consequential features, risky changes, or release candidates, not every small edit. Apply security, accessibility, performance, and AI behaviour evaluation according to the actual risk.

Use the Handoff Steward for a new feature boundary, milestone, change of owner, or move to another conversation. Keep ordinary progress summaries short. Preserve decisions, evidence, unresolved risks, and the next action without duplicating the full project history.

At every stage, distinguish confirmed facts, decisions, proposals, assumptions, implementation status, technical verification, and business acceptance. Prefer the smallest useful artifact and stop when the next decision is clear.

What I would install and what I would build myself

I would treat public repositories as source material, not as an app store.

The external pieces in this system are Codebase Memory MCP, Graphify, selected agent definitions from Agency Agents, official OpenAI skills, and stack specific specialist packages where the active project needs them.

The Product Steward, Compliance Officer, Handoff Steward, Acceptance Reviewer, Plan AI Product Build, Plan Delivery Slices, and project memory rules were shaped around the way I want to work. You can build equivalents yourself. Start with the failure you want to prevent, give it one owner, define when it activates, state what evidence it needs, and make it stop when its job is complete.

The one line test is simple:

If you cannot explain what failure a skill or agent prevents, you probably do not need to install it yet.

The honest limitation

This system does not turn a nondeveloper into a senior engineer. It does something more useful. It makes missing decisions visible earlier, creates better handoffs between kinds of work, and gives the model clearer standards against which to check itself.

It will still make mistakes. A skill can contain bad instructions. An agent can reason confidently from a false assumption. A code graph can be incomplete. Acceptance criteria can faithfully verify the wrong product decision. Human judgment does not disappear because the workflow has more boxes.

The advantage comes from knowing which question belongs where.

My first article focused on escaping generic AI interfaces. This system is the next layer. Design quality belongs inside product intent, architecture, implementation, acceptance, and learning. Once those pieces begin carrying the same idea forward, the result has a better chance of feeling deliberate because it was developed deliberately.

That is the standard I am trying to build towards. Not more agents. Not more theatre. A smaller number of useful specialists, called at the right moment, with enough evidence to know whether the work is actually done.