Project story

Conductor: Making AI-Assisted Engineering Repeatable

A working method for combining human judgment, delegated AI implementation, independent verification, and a record of how decisions were made.

The situation

Workflow Tracker showed me that AI could help me build a credible demonstration with technologies I did not use every day. Job Search Hub raised the bar: now I had a product with real requirements, persistent data, automated tests, and a reason to keep improving it. The faster implementation became, the more noticeable the coordination work became.

A model could propose a solution, another could implement it, and a third could critique it. But someone still had to carry requirements between them, explain what was authorized, determine which tests actually ran, and preserve the decisions that would matter a week later. Copying conversations between tools was not a sustainable engineering process.

The approach

I started treating AI collaboration less like asking one assistant to do everything and more like coordinating a small team with defined responsibilities. That is where the name Conductor came from. I set the direction, constraints, priorities, and acceptance boundaries. AI assists with analysis, planning, implementation, debugging, and review—but I remain accountable for what is built and what is accepted.

The distinction matters because an AI assistant can sound convincing while being wrong, can make a locally sensible change that violates a requirement, or can describe tests it did not independently execute. Experience in QA has made me particularly reluctant to confuse a plausible explanation with verified behavior.

Separating implementation from verification

The workflow evolved toward an orchestration role that prepares bounded assignments and reviews results, while Claude Code performs delegated implementation or debugging. Codex can inspect the changes, run independent checks, and bring consequential decisions back to me. The roles are useful precisely because they are not interchangeable: the implementer's own success report is not the final evidence of correctness.

One of the principles captured in the project is: scripts establish facts; AI interprets facts; humans grant authority. A script can record the command that ran, its exit status, and the files that changed. AI can help interpret that evidence and identify what still needs scrutiny. Neither a passing test nor an AI recommendation automatically authorizes accepting a risk, changing requirements, committing, or publishing.

Making the work traceable

As sessions grew longer, I found that important reasoning could disappear into a transcript. A decision made after comparing alternatives might be forgotten while a polished summary made the work look simpler than it was. Conductor's Python-based bridge therefore records scoped assignments, execution artifacts, source changes, test results, and review material so there is a usable trail behind the outcome.

That record has limits. The bridge can preserve its own delegated runs, but it does not automatically capture every surrounding ChatGPT conversation. Missing source material should be disclosed, not reconstructed as if it were verbatim. Raw transcripts may also contain private context and stay private; the enduring conclusions belong in concise requirements, architecture, test strategy, and decision records.

Keeping authority and scope clear

The process explicitly separates read-only investigation from authorized implementation. It does not allow a requirement to be silently rewritten simply because a test fails. Reviewing a change is not the same as authorizing a commit, and committing is not the same as approving a push or deployment. These are small distinctions until a delegated tool crosses one of them.

At the same time, I do not want a ceremonial framework that consumes more energy than it saves. I use an 'enough' principle: enough structure to preserve intent and verify the result, but no extra tooling or documentation without a clear benefit. The workflow must earn its place through actual use.

What I took away

Conductor grew out of practical frustrations rather than a plan to invent an AI methodology. It is still being tested and refined, including through the work of building this portfolio. Some parts are implemented tools; others are operating rules and habits that need continued validation.

The larger lesson connects directly to my QA background. Faster implementation does not remove the need for judgment; it increases the value of knowing what to ask, what evidence to trust, and when to stop.

Workflow evidence

The capabilities and safeguards that make delegated work reviewable.

Bounded assignments

Keep implementation work tied to an authorized task

Explicit scope and responsibilities

Independent review

Separate creating changes from evaluating them

Review is a distinct responsibility

Execution records

Preserve what changed and which checks ran

Evidence and decisions kept for follow-up

Human authority

Keep acceptance and publication under engineer control

Approval required for consequential actions

← Return to featured work