Building FrenchExDev with AI📋

I now use Codex intensively as my main coding agent for C# and .NET development. I have largely moved away from Claude Code. The work continues because the architecture, conventions and reusable tools I developed are carried by the repository.

In my daily experience, Codex understands C# and the .NET ecosystem very well. It can follow the types, abstractions, source generators and consumers that make up FrenchExDev. That makes it a productive collaborator on both the tools themselves and the projects that use them.

FrenchExDev remains under intensive development throughout, including Diem, the libraries, wrappers, bundles and their integration. This page describes my working approach as of 10 September 2026.

Anything-as-Code is the common thread. Recurring project knowledge becomes types, reusable implementations and checks. Requirements-as-Code applies this to software intent; Diem extends it to applications and their development environment, toward a reproducible HomeLab described in C#. AI proposes, tooling checks, people decide.

Codex in My Daily Development📋

Codex is part of the development loop: exploring the codebase, discussing a design, implementing changes, examining generated output, working on tests and updating documentation. I use it extensively across the FrenchExDev ecosystem.

Claude Code helped during an earlier stage, when I was also writing CLAUDE.md files to explain project structure, patterns, constraints and recurring procedures. That investment still helps today. The files retain useful context, and much of the knowledge they describe now has a concrete implementation in C#.

From CLAUDE.md to C# Contracts📋

I describe this evolution as “typing my CLAUDE.md in C#.” I progressively took recurring instructions and design choices, implemented them as libraries, models and generators, then used those tools in subsequent projects.

For example, explaining how to wrap a command-line tool led to building BinaryWrapper. Once the framework existed, a new integration could reuse its descriptors, parsers, generation pipeline and runtime contracts. The next project could express its own differences through those abstractions.

The existing BinaryWrapper context file↗ (ouvre dans une nouvelle fenêtre) explains the approach; the implementation↗ (ouvre dans une nouvelle fenêtre) makes the reusable behavior available to consumers.

This is why changing coding agents has preserved continuity. Codex can inspect the same interfaces, implementations, examples and tests. C# gives us a shared, precise way to express the work, while documentation retains the rationale and the choices still to be made.

Building BinaryWrapper, Then Using It📋

There are two connected activities in my workflow: develop the abstraction, then use it to build something else.

BinaryWrapper collects CLI help into versioned JSON descriptions. Its Roslyn generator combines those inputs with a descriptor such as [BinaryWrapper("podman")], then emits command types, builders and clients. Consumers work with that generated C# API; runtime services connect commands to the underlying executable.

This short example follows the existing Podman argument-serialization test:

using FrenchExDev.Net.Podman;

var command = new PodmanRunCommand
{
    Volume = ["/host:/container", "/data:/data"]
};

var arguments = command.ToArguments();

The test checks that two --volume options and their values are present. The example constructs arguments; executing Podman is a separate step. Source test↗ (ouvre dans une nouvelle fenêtre).

For Codex, the task now has concrete reference points: a property, its type, the emitter that generates its serialization, and the test that describes the expected result. BinaryWrapper practical guide · CLI wrapper implementations.

The bundles extend that approach to configuration: Compose services, Traefik settings, Packer HCL and GitLab configuration can be modeled and composed from C#. Commands and configuration become reusable parts of a larger project.

How I Use It📋

Architecture & Design Conversations📋

I use Codex to explore trade-offs, challenge assumptions and follow the consequences of a proposed abstraction across consumers. I define the product direction and decide which design fits. The Diem architecture work connects those decisions to a concrete product goal.

Source Generator Development📋

A generator change spans declarations, Roslyn analysis, emitted code and the consuming project. I use Codex to follow that chain and locate the cause of a missing member, a naming collision or an inconsistent generated API. BinaryWrapper and the library generators provide substantial material for this work.

Code Generation at Scale📋

Shared parsers and emitters affect many generated commands. I use Codex to investigate representative failures, improve the common implementation and inspect the resulting output. Collected version snapshots help reproduce cases; they describe inputs and need separate checks for runtime compatibility.

Test Writing & Property-Based Testing📋

I work with Codex on the behavior a test should establish: useful invariants, edge cases and controlled dependencies. FrenchExDev includes CsCheck properties and fakes for dependencies such as HTTP, time and process execution. The testing practices explain what each kind of check can establish.

Documentation📋

I use Codex to connect explanations to the source: architecture, usage examples, practical guides and implementation status. The documentation needs to distinguish an existing API, a test present in the repository, a check actually executed and a feature still being designed.

PowerShell Module Development📋

My PowerShell tooling remains part of the workflow alongside C#. Codex helps inspect and evolve scripts, parameter handling and operational tooling. Some scripts remain specific to my own environment, including utilities created when I used Claude.

Refactoring & Code Quality📋

Typed contracts make changes easier to follow through libraries and consumers. I use Codex to update those call sites, examine error handling and keep the generated and handwritten APIs coherent. Compiler diagnostics and focused tests provide feedback on the proposed change.

The Workflow📋

1. Specify: define the intended behavior, constraints and acceptance criteria.
2. Inspect: read the existing contracts, implementations and relevant tests.
3. Design and implement: work through the approach with Codex and make the change.
4. Validate: run appropriate builds and checks, then examine the actual results.
5. Review and document: review the diff, resolve remaining issues and explain the resulting behavior.

I remain responsible for the requirements, architecture and acceptance of the result. Checks provide evidence within their scope: a successful compilation establishes different things from an argument test or an integration test against a running service.

Requirements-as-Code: A Typed Map for AI📋

Requirements-as-Code extends this approach to intent: requirements, features and acceptance criteria can be represented in the repository and connected to tests. Codex can navigate that structure when investigating a feature or implementing a change.

The forward path starts with a need and develops an approved model to guide implementation and verification. I am also experimenting with the reverse path: inspect existing code and tests with AI, propose candidate requirements and review them before they guide change. The aim is to recover knowledge, expose gaps and prepare refactoring or redesign. Observed behavior remains distinct from approved intent. Experimental workflow and illustrative example.

Declared links and executed evidence are separate. Test results, coverage and mutation reports add information about the behavior exercised and the strength of the tests. Their usefulness depends on the checks actually run and the assertions they contain.

The TypeScript tooling used by this site and the C# implementation have different levels of completion. The C# project generates a requirement registry, while its coverage analyzer still declares REQ100 without registering an analysis action. A complete compliance chain therefore remains work in progress on that side. Current C# implementation · Requirements workflow.

Diem and the Personal Software Factory Lab📋

I started Diem to give the ecosystem a product dimension and bring the pieces together. The application models and reusable libraries are developing alongside binary wrappers, bundles and infrastructure components.

The intended convergence is a software factory Lab with GitLab, GitLab CI and nodes, expressed through a project such as MyLocalHost.Diem.Lab that would run precisely on my laptop. C# is the language for describing that instance: its services, configuration and operations. In the proposed architecture, the Lab is part of the product; its exposure and access controls are configurable. The HomeLab is the integration target for those existing building blocks.

Codex helps me develop the components and work toward that composition. Diem and the full stack are still under intensive development; the complete integrated Lab is a target. Product presentation and current direction.

Toward Local AI📋

I also want to use locally operated models for suitable tasks. Keeping the design in source code, reusable APIs, documentation and tests supports that direction: another agent can work from the same project knowledge.

Local execution remains an area to develop, depending on the models, hardware and tooling available. Codex is my current main development companion.

The lasting investment is the system I am building: explicit intent, typed abstractions, reusable tools and observable behavior. My intensive use of Codex builds on that investment and helps carry it into the next project.

Explore the FrenchExDev ecosystem · My C# and .NET practice