MITHAQ PRAXIS

Build Note II — From Codex to Claude Code

Published On: June 28th, 2026Last Updated: September 15th, 20266036 words30.2 min readDaily Views: 1Total Views: 13

The construction of The Visual Register by Mithaq Praxis begins with an irony I do not consider a contradiction.

I am building a human-led system with the assistance of AI coding tools.

The product argues that a machine may help carry, organise, translate, and render decisions without becoming the source of the human intention behind them. Its own development follows the same principle.

I decide:

what problem the product is meant to address;
which philosophy governs it;
what belongs in the first build;
what must be excluded;
how the interface should distribute responsibility;
which behaviours would violate the product’s purpose;
what counts as a successful prototype.

Claude helps pressure-test and formalise the build description.
Codex will be used for the first implementation.
Claude Code will then help inspect, refine, and strengthen that implementation.

A smaller HTML or PHP artefact may be built for demonstration when I write publicly about the project.

None of these tools determines what The Visual Register is.

They participate in its construction.

That distinction is not incidental to the build. It is the same distinction the product is being designed to preserve for its users:

The human supplies the intention. The system helps carry it into form.

The code should not begin before the product is clear

It is easy to begin software development too early.

A concept feels exciting.
The first interface appears obvious.
A coding agent can produce a form, database tables, navigation, and styled components within a short session.
The speed creates momentum.
It can also hide the fact that the product has not yet decided what it is.

Had I begun coding from the first version of the specification, I might have asked Codex to build:

three separate creative modes;
platform-specific prompt adapters;
corporate permissions;
shot-deck tools;
campaign systems;
decision histories;
prompt repair;
provenance features;
visual education modules;
direct image-generation integrations.

The result might have looked substantial.
It would also have embedded unresolved product assumptions into the code.

The most important work before implementation was therefore subtractive.

The concept had to be pressure-tested until the central structure became clear:

a persistent Visual Bible;
a required human-written scene intention;
one progressively expanding Visual Brief Composer;
visible inheritance and deliberate overrides;
a human-readable brief;
lightweight decision notes.

That is the product spine.

The build description given to Codex should describe that spine clearly enough that the first implementation does not accidentally recreate the earlier roadmap.

The build description is a boundary document

A software specification does more than list features.
It establishes boundaries around what the implementation is allowed to become.

For The Visual Register, the build description must encode several non-negotiable product laws.

The human writes the first line

The initial scene or communication intention cannot be silently generated on the user’s behalf.

The user may write one sentence.
The system may help clarify it.
The original intention must remain visible.

Persistent decisions are inherited

A selected Visual Bible should carry relevant information into the brief without requiring the user to restate it.

Inheritance must remain inspectable

The user should be able to distinguish:

what they wrote;
what came from the Bible;
what they selected during composition;
what temporarily overrides a default;
what the system translated or formatted.

The Bible cannot be rewritten casually

A scene-specific variation must not automatically become permanent continuity.
Updating the Bible requires an explicit action.

Advanced depth is optional

The composer begins with essential questions.
More detailed visual controls expand only when the user needs them.

The output remains human-readable

The canonical result is a visual brief another person can understand.
A platform-oriented prompt is secondary.

The system does not certify authorship

Decision records describe the process.
They do not create copyright, originality, or authorship scores.

These rules must not exist only in blog essays.
They need to shape the data model, interface, actions, labels, and state changes of the software.

Otherwise, the product would say one thing philosophically and do another operationally.

Why begin with Codex

The first implementation needs to turn the product structure into a working system.

Codex is useful here because the task is not merely to produce isolated code fragments. It is to construct an initial application from a defined build target:

establish the project structure;
create the data model;
connect the primary workflows;
implement storage;
produce the first usable interface;
expose where the specification remains ambiguous.

The first pass does not need to be visually perfect.

It needs to make the logic testable.

Can I create a Visual Bible?
Can I store different kinds of continuity?
Can I create a new brief with no Bible attached?
Can I attach a Bible and see its rules inherited?
Can I override a default without changing the source?
Can I distinguish locked continuity from optional motifs?
Can I produce a clear final brief?
Can I preserve the original scene seed and a revision note?

Until those actions exist, much of the product remains theoretical.

Codex’s job in the first pass is therefore not to create the final polished product.
It is to turn the product laws into functioning behaviour.

The first implementation should be plain enough to inspect

A highly polished interface can disguise weak structure.
Beautiful typography, transitions, illustrations, and branded panels may make a prototype feel more complete than it is.

For the initial build, I would rather see a plain interface that handles inheritance correctly than a beautiful one that merges every source into an opaque generated paragraph.

The first version should make the mechanics visible.

For example, a brief may display:

Human scene seed

Farah and Zayd review the first Visual Register prototype together in the Mithaq Praxis Systems Laboratory.

Inherited from the Mithaq Praxis Bible

restrained Islamic modernism;
warm stone, walnut, paper, muted green, and charcoal;
clean institutional environment;
credible near-future interfaces;
purposeful technology;
no cyberpunk neon;
no Algorithm Atelier honeycomb branding.

Inherited character continuity

established Farah and Zayd profiles;
relative height;
attire;
jewellery;
recognisable appearance;
professional but close working dynamic.

New decisions

Farah demonstrates the interface;
Zayd reviews a continuity map beside her;
the tone is analytical and quietly pleased;
the prototype remains the primary focal point;
the image is intended for a horizontal blog header.

Temporary override

stronger screen illumination than the usual environment profile, limited to the central worktable.

Constraints

no decorative holographic spectacle;
no duplicated interface panels;
no unrelated staff;
no embedded headline text.

The first application should show these layers openly.

Only after the structure is trusted should the interface compress them into smoother reading experiences.

The data model carries the philosophy

The database is not a neutral technical concern.

How the information is stored determines what the product can distinguish later.

If the entire Visual Bible is saved as one large text field, it may be easy to display but difficult to apply selectively.
If every rule is reduced to isolated tags, it may become reusable but lose its explanation and meaning.

The first data model needs to preserve both structure and readable context.

A Visual Bible may require entities such as:

Bible

The parent visual identity.

Possible fields:

name;
description;
purpose;
owner or workspace;
status;
version;
created and updated dates.

Bible entry

A specific part of the identity.

Possible categories:

style;
palette;
character;
attire;
environment;
architecture;
material;
object;
motif;
easter egg;
technology;
continuity rule;
avoid rule;
reference.

Rule strength

The system may need to distinguish:

locked;
strong default;
contextual;
optional;
experimental.

Rationale

Why the entry exists.

A rule such as “avoid blue neon” is less useful than a rule explaining that generic blue-neon futurism contradicts Mithaq Praxis’s restrained institutional character.

Context

Where the entry applies.

A rule may belong to:

the whole Bible;
one location;
one character;
one campaign;
one treatment;
one type of image.

Reference note

What a reference contributes and what must not be copied from it.

The brief requires its own structure:

original scene seed;
purpose;
audience;
selected Bible;
inherited entries;
new decisions;
overrides;
constraints;
output requirements;
current assembled brief;
revision note;
status.

This may appear more technical than the user-facing experience.
That is intentional.

A simple interface still needs a model capable of preserving meaningful distinctions.

Inheritance is the hardest part of the first build

A form is easy to build.

A list of Visual Bible entries is also relatively straightforward.

The more important challenge is the relationship between them.

When a user selects a Visual Bible, the system needs to determine:

which rules are relevant to the current scene;
which ones should appear automatically;
which ones are locked;
which ones are only suggestions;
which contextual entries apply;
whether a scene-specific override has been added;
whether the user intends to update the parent Bible.

The first prototype does not need a sophisticated inference engine.

It can begin with explicit selection.

For example, the user may attach:

one parent Bible;
selected character profiles;
one environment;
one treatment profile;
relevant motifs;
the general avoid list.

This is less automatic than the eventual product might become.
It is also easier to inspect.

The system can later learn to suggest relevant entries.
It should not begin by silently guessing which parts of a large Bible matter.

The first build should privilege clarity over cleverness.

The composer should expand, not fork

The first interface should not contain three separate creation systems labelled Basic, Studio, and Corporate.
That distinction was useful during conceptual exploration.

It is not the cleanest implementation.
The composer should instead use progressive disclosure.

Essential section

Always visible:

What do you want to see?
What is the image for?
Who or what appears?
What is happening?
Where is the scene?
What should it feel like?
What format is required?
What must be present?
What must be avoided?

Visual Bible section

Optional:

attach a Bible;
select relevant characters;
select environment;
review inherited rules;
add temporary overrides.

Expanded direction

Opened when needed:

visual hierarchy;
subject blocking;
framing;
camera position;
shot distance;
light;
colour behaviour;
materials;
atmosphere;
negative space;
treatment-specific notes.

Decision section

Lightweight:

revision note;
draft, selected, or approved status.

A novice can remain in the essential section.
An experienced creator can open deeper controls.
A company user may inherit locked rules from a governed Bible.

The underlying workflow remains one composer.
This reduces duplicated code and keeps the conceptual model coherent.

Corporate behaviour begins as a state, not a second product

The first build does not need full enterprise infrastructure.
It should, however, demonstrate that a Visual Bible can exist in different ownership contexts.

The prototype might support:

Personal Bible

Owned and editable by one user.

Shared Bible

Accessible by several users.

Governed Bible

Contains fields or entries marked as locked.

That is enough to test the distinction between:

personal creative continuity;
collaborative continuity;
organisational authority.

A governed brief may show:

This logo entry is locked by the workspace.

This product profile cannot be overridden in the current brief.

This palette is a strong default and may be overridden with a note.

The first version does not need:

single sign-on;
complex role matrices;
legal approval stages;
enterprise audit systems.

Those are not required to test whether controlled inheritance is useful.
The initial build should not pretend to be enterprise-ready merely because the concept has corporate value.

The human-readable brief is the first real output

The initial product should not be judged by whether it creates an impressive generator prompt.

The primary output is a clear visual brief.

It should be understandable to:

the original user;
a collaborator;
a designer;
a manager;
a future version of the user;
a language model preparing a platform-specific prompt.

A useful brief may contain:

Purpose

Why the image is being created and where it will be used.

Scene

The human-written intention, clarified through the user’s own selections.

Subjects and action

Who appears and what each person is doing.

Environment

Where the scene takes place and which established environment rules apply.

Visual direction

Mood, hierarchy, composition, light, colour, materials, and treatment.

Continuity

The relevant Visual Bible rules.

Overrides

Deliberate departures from normal continuity.

Constraints

What must not appear, change, or dominate.

Output requirements

Aspect ratio, orientation, layout needs, text space, and technical notes.

The brief should not read like a database export.
The implementation must convert structured fields into a coherent document while keeping the source layers inspectable.

That translation is an appropriate use of AI assistance.

The decisions already exist.
The system helps organise them.

The platform-shaped output remains secondary

The first build may include a copy-ready prompt-shaped view.

It should not become the canonical record.

The platform-shaped version may:

compress headings;
combine related details;
reorder information;
remove internal notes;
convert plain language into generator-facing instructions.

The original brief remains unchanged.

A future runtime adaptation could allow:

Prepare this brief for ChatGPT Image.

Or:

Condense this for Midjourney.

Or:

Convert this into a Sora scene specification.

The adaptation should be treated as temporary output.

It should not overwrite:

the human scene seed;
the canonical brief;
the Visual Bible;
the decision record.

This protects the project from platform change and keeps the product centred on visual direction rather than syntax maintenance.

Claude Code enters after the system can stand

Once Codex produces the initial implementation, Claude Code can be used for a different kind of work.

The purpose is not to have two coding agents compete over which one writes the better application.
The purpose is to use a second pass to inspect the first from another angle.

Claude Code can help review:

architecture;
duplication;
unclear responsibilities;
data relationships;
security;
validation;
accessibility;
PHP or WordPress conventions if the build uses that environment;
maintainability;
whether the interface accidentally violates the product laws;
whether the implementation has overgrown the MVP.

The shift from Codex to Claude Code is therefore not:

One model builds badly; another fixes it.

It is:

One implementation creates something concrete enough to examine; the next pass reviews and refines it against the original intent.

This mirrors ordinary human software development.

A first implementation is not a moral failure.

It is material for review.

Refinement must include product behaviour, not only code quality

A code review can focus too narrowly on:

syntax;
performance;
file structure;
naming;
errors;
security.

Those things matter.

For The Visual Register, refinement also needs to test behavioural integrity.

Questions for the Claude Code pass may include:

Does the interface preserve the scene seed?

Can the user always see what they originally wrote?

Are inherited rules labelled?

Or are they merged invisibly into the assembled brief?

Can an override be mistaken for a permanent Bible update?

Does the application quietly generate missing creative choices?

Does the composer expose too many fields too early?

Does attaching a Bible reduce repetition?

Or does it make the form longer?

Can a locked rule actually be bypassed?

Are rationale and context preserved?

Is the final brief readable?

Does the prompt-shaped output remain clearly secondary?

Does the product imply legal certainty it cannot provide?

These are not merely design questions.
They are acceptance criteria.

The code is correct only if the product behaves correctly.

The coding tools also need boundaries

AI coding systems can be extremely productive.
They can also expand scope enthusiastically.

A request to add a small feature may produce:

new abstractions;
additional settings;
speculative integrations;
unnecessary dependencies;
elegant infrastructure for problems that do not yet exist.

The build process therefore needs its own refusal list.

Codex and Claude Code should not be invited to add:

direct image-generation APIs;
elaborate prompt scoring;
automatic authorship ratings;
a full enterprise role system;
social features;
complex analytics;
a marketplace of style presets;
automatic Visual Bible creation from uploaded images;
generated scene ideas as the default entry point.

These may appear useful to a coding agent evaluating feature completeness.
They may undermine the product or distract from the first test.

The human builder must keep returning to:

Does this help prove the Visual Bible and brief workflow?

If not, it waits.

The first three test Bibles already exist

The prototype has a strong internal test set because I already maintain three distinct visual worlds:

Bayt al-ʿAhd;
Algorithm Atelier;
Mithaq Praxis.

They share some lineage.
They must remain distinct.

This makes them more useful than three unrelated sample brands.

The application should be able to preserve both connection and separation.

Bayt al-ʿAhd

The Bible may include:

warm domestic and sacred intimacy;
Levantine, Ottoman, and Andalusian architectural language;
stone, arches, lanterns, manuscripts, and the fig tree;
indigo, amber, black, and gold;
recurring characters and jewellery;
ritual, relationship, and lived continuity;
avoidance of generic luxury-palace excess.

Algorithm Atelier

The Bible may include:

communal maker-space energy;
process and experimentation;
galleries, workshops, unfinished work, and conversation;
a more colourful, active, public posture;
bee and hive identity;
visible participation and community culture.

The Bible may include:

institutional quiet;
research, writing, publishing, and systems work;
restrained Islamic modernism;
warm stone, walnut, paper, charcoal, and muted green;
desert-facing calm;
credible near-future technology;
clean, minimal, purposeful environments;
no accidental honeycomb branding;
no cyberpunk spectacle.

If the system applies the same visual language to all three, it fails.
If it treats every shared motif as evidence that the worlds are identical, it fails.
If it can preserve their relationship while maintaining their distinct posture, the model is beginning to work.

The build needs one-off tests too

A product centred on Visual Bibles could accidentally become hostile to people who do not have one.

The first testing set should therefore include Bible-free briefs.

Examples:

An elderly woman repairs a radio during a power cut.

A child waits beside a closed library in the rain.

A group of engineers tests a water-filtration prototype outdoors.

The composer should be useful without forcing the creation of permanent continuity.

It should ask enough to create a readable brief.
It should not become a twenty-field interrogation.

The test is whether the product can help a one-off user become more deliberate without making them construct an identity system they do not need.

The build should test inherited silence

One of the hardest things to evaluate is whether the system knows when not to ask.

Suppose the Mithaq Praxis Bible already contains:

standard palette;
environment materials;
default technology language;
architecture;
general avoid list.

The composer should not repeatedly ask:

What colours should the environment use?

Should it contain futuristic technology?

What architectural style should it have?

Those answers already exist.

The application may show them as inherited summaries.
The user can override them if necessary.
The composer’s usefulness should increase as the Bible becomes richer.

This produces a measurable product test:

Does a mature Visual Bible make the brief process shorter and clearer?

If not, the system is storing information without using it intelligently.

The build should test temporary difference

The opposite test is also important.

A strong Bible must allow deliberate variation.

For example:

Show the Mithaq Praxis Research Library during an emergency power outage.

The ordinary Bible may specify:

warm indirect institutional light;
active research interfaces;
calm working environment.

The present scene overrides:

lighting;
system availability;
emotional posture.

It should not overwrite the permanent environment profile.

The application needs to represent:

Inherited

Research Library architecture, materials, layout, and institutional identity.

Overridden for this brief

Normal lighting and interface activity.

New

Emergency illumination, handheld lamps, interrupted work, and controlled tension.

If the system cannot distinguish a temporary condition from a permanent revision, it cannot safely carry continuity.

The build should test refusal

The product should also be tested against requests that tempt it to cross its own boundary.

For example:

Generate a meaningful scene for my company’s innovation campaign.

The system should not silently invent the full concept.

It may respond through the interface:

Begin with one sentence describing what you want the audience to see. You may keep it simple.

Or present prompts such as:

Who is involved?
What are they doing?
What makes the scene about innovation in your organisation?
Where does it occur?

Similarly, when the user writes:

Make this prompt better,

the product should avoid replacing the scene invisibly.

It can show:

missing information;
vocabulary choices;
structural suggestions;
conflicting instructions.

The refusal must be testable.

Otherwise, convenience pressure will gradually erase it.

The smaller CoWork artefact has a different purpose

The production-oriented build and the public demonstration do not need the same architecture.

A small HTML or PHP prototype may be useful when I write about the project because readers need to understand the concept quickly.

The demonstration might contain:

a small Visual Bible selector;
several inherited rules;
one required scene field;
a few expandable direction choices;
a visible override;
an assembled human-readable brief.

The demonstration does not need:

full authentication;
complex database migrations;
scalable permissions;
complete revision history;
production security;
every Bible category.

Its purpose is explanatory.

A reader should be able to see:

This part was already stored.

This is what the person wrote today.

This choice temporarily changes the default.

This is the brief produced from both.

That makes the product argument tangible.

The production build’s purpose is durability.
The public artefact’s purpose is legibility.

Confusing those goals could produce either an overbuilt demonstration or an underbuilt application.

The prototype should expose, not conceal, incompleteness

A prototype is not a promise that every question has been resolved.

It should help identify what still needs testing.

For example:

Do users understand the phrase Visual Bible?
Do they know what should be stored there?
Can they distinguish a lock from a preference?
Do they understand overrides?
Does the scene field feel empowering or obstructive?
Are the essential questions sufficient?
Do users open the expanded controls?
Does the final brief sound like their intention?
Does the system add too much language?
Are company users comfortable with shared Bibles?
Do designers find the brief useful?
Does the decision note clarify the process or feel administrative?

The prototype should make these questions easier to observe.

A polished interface that directs users toward the expected answer may produce flattering but weak feedback.

The first tests should leave room for the product to be wrong.

Success is not a long prompt

The easiest demonstration would show a short sentence becoming an elaborate paragraph.

That transformation looks impressive.
It is not enough.

A strong first build should be judged by whether it:

preserves the user’s meaning;
carries relevant continuity;
exposes inherited rules;
asks for necessary new decisions;
allows deliberate overrides;
avoids adding unapproved narrative content;
produces a brief another person can use.

The final output may be long or short.

Length is not the metric.

The test is whether the construction became clearer without the system taking over the authorship.

Success is not visual polish either

The prototype may use Mithaq Praxis colours, typography, and interface styling.
That will help it feel coherent.

But the first build should not be declared successful because it looks like a refined product page.

Its real success conditions are behavioural:

Continuity

Does information survive across briefs?

Selectivity

Can the user apply only the relevant parts of a Bible?

Transparency

Can they see where each part came from?

Control

Can they override a default without damaging the source?

Restraint

Does the system avoid inventing meaning?

Portability

Can the final brief be used outside the application?

Legibility

Can another person understand the decisions?

Those are more important than animation, decorative illustration, or surface polish.

The handoff between tools needs its own record

Using several AI coding tools can create continuity problems similar to those found in image work.

One tool receives the full conceptual context.
Another receives only the repository.
A later session may not know why a seemingly unnecessary constraint exists.
A future coding agent may “simplify” behaviour that was deliberately designed.

The project therefore needs a developer-facing register containing:

product laws;
MVP scope;
excluded features;
data-model principles;
interface rules;
acceptance tests;
terminology;
unresolved questions;
reasons behind important constraints.

For example:

The original scene seed must remain immutable in the project record because the product distinguishes human intention from later system translation.

Without the reason, a coding agent may replace the original field with the latest revised text for convenience.

Or:

Platform-oriented prompts must not overwrite the canonical brief because the brief is designed to remain platform-neutral.

Without the reason, a refactor may collapse them into one field.

The development record protects the product’s intent across tools and sessions.
In that sense, the software build itself needs something resembling a Visual Bible.

Claude’s build description is not the final authority

Claude’s role is to transform our product reasoning into a concise and actionable build target.

That description will be useful.

It should not become unquestionable canon.

Codex may reveal:

technical contradictions;
missing states;
awkward data relationships;
features that appear simple but require more infrastructure;
areas where the product specification is too abstract.

Claude Code may later identify:

fragile implementation;
unclear responsibilities;
security issues;
accessibility gaps;
duplicated logic;
behaviour that does not match the specification.

My responsibility is to decide what those findings mean.

Some will require code changes.
Some may require changes to the product concept.
Some may reveal that a feature should be postponed.

The human-led principle applies here too.
The tools contribute analysis and implementation.

I govern the product.

The implementation may argue back

A concept can appear elegant in prose and become awkward in software.

For example:

Apply only the relevant parts of the Visual Bible.

Relevant according to whom?

The user?
A rule system?
A language model?
Manual selection?
Context tags?

Each method creates different complexity.

Or:

Distinguish inherited content from new decisions.

This may require the assembled brief to preserve source references at sentence or section level.

Or:

Allow overrides without changing the Bible.

The data model needs a clean relationship among:

parent rule;
brief-level override;
displayed result;
possible later promotion.

The implementation forces vague language to become operational.

That pressure is useful.

The code does not merely obey the product.
It exposes what the product has not fully decided.

The appropriate response is not to let the coding tool invent the missing policy unnoticed.
It is to return the question to product reasoning.

The likely first technical compromises

The prototype will probably need explicit compromises.

For example:

Manual entry selection

Instead of automatically retrieving every relevant Bible rule, the user may initially choose the character and environment entries.

Simple rule strengths

The first version may support only:

locked;
default;
optional.

More nuanced contextual logic can wait.

Text-based references

The prototype may store reference notes and file identifiers without building a complete asset-management system.

Lightweight ownership

The first build may distinguish only personal and governed Bibles.

Basic versions

Bible revisions may initially use timestamps and change notes rather than a sophisticated branching system.

Simple brief assembly

The system may use templates and a language-model formatting pass rather than a complex rules engine.

These compromises are acceptable if they preserve the product laws.

An MVP may simplify implementation.
It should not simplify away the reason the product exists.

The coding agents should not be asked to choose product priorities

A coding tool may propose:

Adding direct image generation would improve the experience.

Or:

Automatic prompt enhancement would reduce user effort.

Or:

A scoring system would make the product more engaging.

These suggestions may be technically reasonable.

They are product decisions.

The agent can describe:

complexity;
dependencies;
risks;
possible implementations.

It should not determine whether the feature belongs.

The development process remains human-led when the tools help reveal consequences and I decide which consequences are acceptable.
This requires discipline because a generated feature can be seductive.

Once something works, removing it feels like losing progress.

That is why the exclusions need to be written before implementation.

The build itself creates a body of decisions

This article series argues that authorship becomes legible through a body of decisions.

The software project develops the same way.

Its construction includes:

the original problem;
rejected product framings;
the decision to centre the Visual Bible;
the collapse of three modes into one composer;
the demotion of platform adapters;
the requirement for a human-written scene;
the distinction between personal and governed contexts;
the refusal to score authorship;
the decision to build a human-readable brief first;
the choice to separate the production application from the public demonstration.

Claude’s build description will record some of these decisions.
Codex’s implementation will force more.
Claude Code’s refinement will challenge others.

The final application will not be authored by one isolated act of coding.
It will emerge from a chain of human and machine contributions governed by a persistent product intention.

That makes the development process an appropriate first case study for the product’s own philosophy.

Provenance in the build should remain practical

The project does not need to publish every message exchanged with every coding assistant.
That would produce noise rather than useful transparency.

A practical build record may preserve:

the human-written product concept;
the build description;
major architectural decisions;
substantial changes suggested by each tool;
accepted and rejected recommendations;
key code revisions;
testing results;
release notes.

This describes the construction without pretending that every intermediate output deserves equal importance.

The goal is not to prove that I personally typed every line of code.

I will not have.

The goal is to describe honestly what I directed, what the tools implemented, what I reviewed, and what I chose to retain.

AI-assisted coding is not button-press development

There is a version of AI-assisted software development that resembles the weakest image workflow:

Make me an app.

The system generates files.
The user sees a functioning interface.
The application is declared complete.

That process may be sufficient for:

a disposable experiment;
a private mock-up;
a quick demonstration.

It is not sufficient for a product intended to store creative identities, project rules, references, and organisational material.

The generated code must be read.

Its data handling must be understood.
Its permissions must be tested.
Its assumptions must be challenged.
Its dependencies must be documented.
Its failures must be diagnosed.

The same argument applies:

The existence of output does not prove the resolution of the design.

A working screen is not necessarily a trustworthy system.

Reading the code is part of the build

Just as the user of The Visual Register must read the generated image, I must read the generated application.

I need to ask:

What assumptions did the coding agent introduce?
Did it choose a framework or dependency I did not need?
Did it merge data that should remain distinct?
Does it protect user content?
Are permissions enforced only in the interface or also on the server?
Can a Bible override change the parent accidentally?
Are original scene seeds preserved?
Is system-generated text labelled?
Can users export their data?
Does the schema allow later versioning?
Does the application remain understandable without the coding agent present?

The coding system may produce a plausible architecture.

I remain responsible for what I deploy.

The parallel with visual generation is exact enough to be uncomfortable:

I cannot claim human-led development if I refuse to examine what the machine built.

The application should document its own limits

The prototype should be explicit about what it does not yet provide.

For example:

no direct image generation;
no legal authorship certification;
no guarantee of identical results across platforms;
no full enterprise permission system;
no automatic cultural validation;
no complete asset-rights verification;
no promise that a brief will produce a successful render;
no replacement for a designer or reviewer.

These statements are not signs that the product lacks confidence.
They establish the boundary of the current build.

A trustworthy prototype tells users where human judgment remains necessary.

The first release should invite use, not belief

The public demonstration should not ask readers to accept the theory because the essays sound persuasive.

It should let them test the mechanism.

Can they create a small Bible?
Can they understand the categories?
Can they write one line and see the difference between inherited and new information?
Does the assembled brief remain recognisably theirs?
Does the process help them notice a missing decision?
Would they hand the brief to a designer?
Would they reuse the Bible?
Does the system reduce repetition?
Does it feel like a useful handrail or an unnecessary form?

Those answers matter more than whether the concept receives immediate praise.

The product should be examined through use.

The first build is allowed to change the thesis

The purpose of construction is not only to prove that the original idea was correct.

It may reveal that:

users do not understand Visual Bible;
some categories need different names;
the scene seed should include purpose in the same field;
inheritance needs to be more selective;
rule strengths are too complicated;
one-off users need a lighter path;
decision notes belong later;
a feature I removed is more important than expected;
a feature I defended adds little value.

These findings should be allowed to alter the product.

Human-led does not mean the human refuses evidence.
It means the human remains accountable for interpreting it.

The prototype is part of the thinking.

What Codex should deliver first

The first Codex milestone should be small enough to inspect in one coherent flow.

A useful target is:

Visual Bible management

create;
edit;
view;
archive;
export later if feasible.

Structured Bible entries

category;
title;
description;
strength;
rationale;
context;
optional reference note.

Brief creation

required human scene seed;
purpose;
audience or use;
selected Bible;
selected entries;
new scene decisions;
constraints;
output format.

Inheritance view

inherited;
locked;
optional;
overridden.

Brief output

readable structured document;
copy-ready text view.

Lightweight record

original seed;
revision note;
draft, selected, or approved status.

That is enough to test the spine.

What Claude Code should examine next

After the initial flow works, the refinement pass should examine:

schema integrity;
source labelling;
update safety;
access control;
input validation;
output escaping;
portability;
accessibility;
responsive behaviour;
component reuse;
progressive disclosure;
clarity of inherited versus new content;
whether the MVP has accumulated accidental scope.

It should also inspect whether the application remains faithful to its refusals.

The question is not only:

Does it work?

It is:

Does it work as the product I intended to build?

The handoff is not the end

Codex and Claude Code are stages, not authors who receive the product and return it complete.

After each pass, I still need to:

use the application;
populate real Visual Bibles;
test ordinary and difficult scenes;
compare the output with my actual prompting practice;
identify where the interface obstructs thought;
identify where it allows the system to assume too much;
review the code;
revise the specification;
decide what proceeds.

The tool chain can accelerate implementation.

It cannot remove the builder from the build without changing what the project is.

Construction as an argument

The Visual Register is not only making an argument about image generation.

It is making an argument about software:

AI assistance does not make human direction obsolete. It makes the location of human direction more important.

In the image workflow, the model may render.
In the software workflow, the coding agent may implement.

In both cases, the human must still determine:

purpose;
structure;
boundaries;
success;
failure;
revision;
responsibility.

The tools are powerful.

That is precisely why the governing decisions need to remain visible.

From Codex to Claude Code, with the human still in the loop

The development sequence can be stated simply:

Claude helps define the build.
Codex turns the definition into a first implementation.
Claude Code helps inspect and refine the implementation.
I decide what the product becomes.

That does not minimise what the tools contribute.

Their contribution may be substantial.
They may write much of the code.
They may expose problems I missed.
They may propose better structures.
They may accelerate a build that would otherwise take far longer.

But the project is not human-led merely because I initiated the first request.
It remains human-led only if I continue to read, decide, reject, revise, and take responsibility for what is built.

The same standard I am designing for users of The Visual Register applies to me.

I cannot ask other people to preserve the human body of decisions while treating my own software as something that appeared from a sufficiently impressive prompt.

The build itself must show the practice.

From product concept to build description.
From Codex to Claude Code.
From generated implementation to examined system.
From possibility to something I am willing to place under the name of Mithaq Praxis.

That is the construction.