Process

I define the problem, write the brief, assemble the context, scope the work, and set the quality bar. AI tools help with execution: writing code, generating drafts, running tests, inspecting errors, and proposing changes.

I review the work before it moves forward. The point isn't to remove human judgment. The point is to stop spending human attention on every mechanical step between an idea and a working version.

This isn't typing a prompt and hoping for the best. It's a controlled workflow for turning intention into usable output.

These principles show up in the actual work, not just the theory.

Self-Documenting Systems: Every meaningful task should leave a trail. The goal is not just to finish the work, but to make the work understandable after the fact.

In practice, that means issues, branches, commits, methodology notes, review comments, and handoff notes all matter. A project should explain what changed, why it changed, what was decided, what was rejected, and what should happen next. If a human collaborator or a new AI session has to ask, "Where are we and why?" the system has already failed a little.

Better prompting through better context: A good prompt is not usually a clever sentence. It is the visible tip of a larger context system.

Before AI touches the work, I try to give it the things a useful collaborator would need: the goal, the constraints, the relevant files, the current state of the project, the acceptance criteria, and any prior decisions that should not be relitigated. That takes more effort up front, but it reduces vague output, wrong assumptions, and circular revision later.

Trusted systems around untrustworthy AI: I do not assume AI output is correct just because it looks confident. The useful move is to treat AI as a powerful but unreliable worker, then build a reliable system around it.

That means scoped tasks, review gates, tests, validation checks, source control, and clear state transitions. The AI can generate code, drafts, plans, and analysis, but the workflow decides what happens next. The model is allowed to be variable. The system around it is not.

Managing cognitive load: Most projects do not fail because there is too little information. They fail because the right information is buried under everything else.

I try to keep each task narrow enough that the next action is obvious. The same principle applies to people, AI tools, dashboards, Linear boards, and project documentation. A good workflow does not show everything all the time. It shows the right thing at the right moment, with enough context to act.

Modularity and agnosticism: I do not want the work trapped inside one model, one vendor, one tool, or one person's memory.

The workflow should survive changes in tooling. Claude, Codex, future AI systems, or a human collaborator should be able to step into the same process and understand the handoff. That means keeping the important structure outside the model: in Git, Linear, documents, schemas, tests, and repeatable pipelines.

The tools are chosen for how they connect, not just what they do on their own.

Banzai is the orchestration layer. It assembles context, prepares the work, hands off to an AI backend, and processes the results afterward.

A Banzai workflow is built in stages. Generators collect the right context. Pre-processors prepare state, worktrees, branches, and issue metadata. The AI backend performs the scoped task. Processors handle the aftermath: documentation, status updates, review notes, validation checks, or other side effects.

Claude Code and Codex are execution engines. They can write code, inspect problems, generate drafts, and run through scoped tasks, but their output still goes through review.

Linear is the project management layer. Work is captured as issues, moved through states, and used as the operating record for what should happen next.

Git is the source of truth. It holds the code, but it also holds methodology notes, decision records, content artifacts, and approved briefs.

Elliot's Brain is the context layer. It's a personal knowledge system designed so AI tools can pull relevant notes and project history before they start.

AI tools handle execution. I handle the parts that require judgment.

That means deciding what problem is worth solving, what the work should feel like, what should be cut, and what "good enough" actually means. It also means deciding whether the output is honest, useful, appropriate, and maintainable after the first version ships.

In practice, I write the brief before the work starts. I define the scope, the quality bar, and the success criteria up front. I review artifacts before they advance, and I reject the ones that aren't right.

The process works because the handoff points are clear. AI gets well-scoped execution. I keep responsibility for direction.

This site is a working example of the process.

The V2 rebuild started in Linear as a scoped project: new content, new visual direction, CMS integration, technical SEO, security hardening, launch QA, and production deployment.

The CMS foundation came first: Sanity, a Next.js frontend, draft preview, webhook-triggered publishing, and a content model designed to be maintained rather than hard-coded.

The visual system became its own part of the work. Cursor animation primitives, frame drawing behavior, page rollout, reduced-motion handling, and visual QA were all tracked as scoped issues instead of being treated as vague polish.

Content direction moved through the same process: draft, review, revise, approve, publish. AI helped generate and shape material, but the positioning, voice, and final calls stayed human.

Banzai coordinated the development tasks. Linear tracked the work. Git preserved the artifacts. Vercel shipped the site.

The result isn't just a portfolio site. It's a production example of the method it describes.

Next.js on Vercel. Sanity CMS with draft preview and webhook-triggered publishing. Banzai for AI-assisted development workflow. Linear for project management. Git as the source of truth.