Banh Mi Ops

An AI agentic orchestration framework built for Claude Code. It turns a single AI session into a coordinated team of specialized agents, managed through a real-time kanban dashboard. You describe what you want built. It scouts your codebase, writes the development plan, and deploys agents in parallel to execute it. The underlying architecture is built on engineering principles that have worked for decades across disciplines: separation of concerns, dependency-driven scheduling, independent verification, and bounded revision cycles.

Why "Banh Mi"? A great bánh mì is its own kind of orchestration. Every layer has a role, the timing matters, and if one ingredient is off the whole thing falls apart. I like codenames, and I'd rather name a framework after something I genuinely love.

What It Does

You point it at a codebase. It runs reconnaissance, maps dependencies and conventions, then generates a development plan. Tasks that can run in parallel do. Harder decisions get smarter models. Every piece of work gets independently verified before it ships.

Pipeline

Two execution modes: Oversight pauses for your approval at each step. Autonomous runs the full wave without stopping.

Why I Built It

When chat-based AI tools became publicly available in 2022, the technology was premature but the potential was obvious. I started exploring how these tools could be shaped around the engineering principles I've built my career on: reconnaissance before action, independent verification, bounded revision, and clear separation of concerns. Banh Mi Ops is that exploration turned into a working framework. For more on this trajectory, see Abe's AI Methodology.md.

View Project on GitHub →

principles April 4, 2026

I have built and maintained web applications and systems at the Legislative Data Center for over a decade, supporting the California State Legislature. The Legislative Data Center has provided technology services to the Legislature since the 1970s, and the pace of the work is faster than most people expect. These principles come from that environment, and from the mistakes that shaped how I operate within it.

I. Live With What You Ship

I still maintain systems I first architected at the start of my career. In an organization where some applications have been evolving for decades, that kind of continuity teaches you things that are hard to learn any other way.

You discover which abstractions held up under real use and which ones became the friction everyone works around. That experience compounds. It made me deliberate about longevity in ways that reading about maintainability never could. Every system I build now, I build with the assumption that anyone on the team should be able to maintain it five years from now. Sustainability is a shared responsibility, and the best way to future-proof a system is to make sure no single person has to carry it alone.

II. Solve the Problems That Need You

I have worked with Drupal my entire career. It provides authentication, role-based access control, and session management out of the box. These are solved problems, and I treat them that way. I lean on those foundations so I can spend my engineering time where it actually matters: the domain logic that requires institutional knowledge to get right. Multi-department procurement rules. Legislative workflow automation. Scheduling systems with constraints that only make sense if you understand how the Legislature operates.

The most valuable engineering I have done came from knowing which problem deserved my time and having the discipline to leave the rest alone.

III. Manage Essential Complexity

The systems I build support the legislative process: floor sessions, committee hearings, the publishing of legislative daily files, and the coordination that keeps all of it moving. Within that process, real-time use cases like member tracking, transportation, and scheduling carry their own complexity. Fred Brooks called this essential complexity: it lives in the problem domain itself and cannot be designed away, only managed well or managed poorly.

The part I can control is everything else. Whether the codebase accumulates unnecessary abstraction layers. Whether a clever pattern obscures the intent it was meant to clarify. Whether a new developer can trace a request through the system without a guided tour. I aim for codebases that are searchable, traceable, and logical. Large enough to handle what they need to handle, clear enough that the next person can work in them confidently.

IV. Know the Domain

Engineering for the legislative process requires more than technical ability. Bills move through a lifecycle, from drafting through committee hearings and floor debate to enrollment. The systems that support each stage carry their own rhythms and their own urgency during session, with constraints that only become visible through experience.

That familiarity is where my best work has come from. When I led the redesign of the Room Reservation Management System, I started by interviewing and observing the staff who operated it hands-on during peak legislative periods. Sitting with them through their actual workflow revealed what no requirements document would have surfaced: the same data entered into the same fields, repeatedly, while the queue backed up. The system functioned, but the process had friction that routine had made invisible. From those observations, I proposed a drag-and-drop interface that let staff move pending requests directly onto the reservation calendar with a single confirmation step, and designed the backend to support it. That kind of improvement comes from spending enough time inside the institution to ask the right questions and recognize the gaps.

V. Verify Honestly

I believe in testing, and I am candid about where my practice stands. Under legislative deadlines, where session calendars are fixed and deployment windows are narrow, test-driven development is not always realistic. We still maintain robust testing procedures, but they require more involvement and time than a TDD workflow assumes. I ensure critical paths have coverage, and I am building verification into my process more systematically with each project.

I would rather be straightforward about where I am than overstate a discipline I am still growing into. The goal is clear, the practice is evolving, and I am honest about the distance between them.

VI. Engineer for Accountability

I have spent enough time inside long-running production systems to know that when something goes wrong, recovery depends on whether the system can be questioned. That means structured logs that tell a coherent story, error paths that surface useful detail instead of swallowing it, and decisions encoded in code that a reader can follow without insider knowledge. Auditability and traceability are properties of mature production engineering, and I treat them that way from the first commit.

This connects to the first principle. A system someone else can maintain five years from now is the same system you can debug under pressure, and both rest on the codebase being readable by people who were not there when it was built. I aim for that readability deliberately.

decision-log April 30, 2026

Where I started

Before “AI” was the popular term, Business Intelligence (BI) dominated the corporate world. The technology we now call AI was already there, embedded in enterprise products but far from mature, and without a consumer footprint. My undergrad and research years were in that era. I worked directly with SAP products, earning an institutional SAP certificate in data warehousing, business intelligence, and ERP systems: real-time analytics, in-memory processing, predictive modeling integrated into ERP. Organizations used these tools to compress forecasting cycles, optimize supply chains, and outpace competitors who were still running batch reports. Every company wanted “data-driven” on their slide deck, the way “blockchain” would later, and “AI” after that. Vendors rebranded old products as “intelligent.” The executives chasing the label wasted money. The practitioners who connected each initiative to a stakeholder’s actual problem were the ones who shipped results. That cycle taught me the lesson I still operate on: the technology is never the hard part. Connecting the technology to what actually drives the value proposition is.

The tooling

By 2018-2020, Machine Learning (ML) had entered the mainstream as a subset of AI focused on pattern recognition and prediction. When OpenAI launched ChatGPT in November 2022, the distinction became clear: ML learns from data, generative AI generates from it. The same hype cycle played out again. Companies stamped “AI-powered” on products that hadn’t changed. The SEC fined two firms in 2024 for fabricating AI claims entirely. The industry called it AI washing. But BI never went away either, and AI practitioners are now evolving that space with capabilities that would have been unimaginable a decade ago.

On the development side, GitHub Copilot and other third-party IDE extensions improved the developer workflow with inline suggestions and autocomplete. They lived inside the editor and augmented how you wrote code. Anthropic’s Claude Code took a different approach entirely. Claude Code is a CLI-based agentic coding tool that operates directly in your terminal with full access to your filesystem. I’ve used it since August 2025 and saw the earlier inception of it in the Sonnet days. Even then, it was promising and provided a unique developer experience in the AI space: planning, code generation, execution, and testing brought into a single interface, operating inside your development environment rather than alongside it.

Then Anthropic released Claude Opus 4.5 in November 2025, and my skepticism broke. I did not see AI development progressing much further at that point. Diminishing returns felt inevitable. Models training on AI-generated data felt like a ceiling. Opus 4.5 proved me wrong. The leap in reasoning, code generation, and sustained context handling across long sessions was tangible in every project I ran through it. On a broader scale, I watched software development itself become democratized. Anyone could bring an idea to a functional prototype in minutes. That spawned real concerns: the flood of AI slop, the complacency of vibe coding, and codebases that look complete but collapse under real-world pressure. But seasoned software engineers and developers understood this moment for what it was: the bottleneck had shifted from keystrokes to judgment. Architecture, systems thinking, domain knowledge, knowing when the AI is wrong, these fundamentals became more valuable, not less. AI didn’t close the gap between disciplined and undisciplined practitioners. It widened it.

What changed my practice was the broader conversation moving from Prompt Engineering to Context Engineering. Prompt engineering focused on crafting the right question. Context engineering focuses on architecting the right environment: what information the model sees, what persists across interactions, what tools are available, and how outputs flow back into the pipeline. When I started applying that to my own development process, encoding project strategy into instruction files, structuring PRDs as agent-readable contracts, building validation loops that feed findings back into design, the methodology below came together.

How I work with AI

The industry already has useful pieces: Spec-Driven Development for defining intent, Test-Driven Development with AI agents, multi-agent orchestration through frameworks like CrewAI and LangGraph. None of them close the full loop from strategy to validation. What I care about is integrating the full pipeline, from business strategy through execution and validation, in a single loop.

It starts with encoding the strategic foundation directly into the AI tooling. Instruction files like CLAUDE.md and AGENTS.md carry the project’s mission, constraints, and ground rules where the agents can actually use them. The project’s mission and constraints, scoped and made executable. From there, I write a Product Requirements Document where every acceptance criterion maps to a testable outcome. The PRD is a contract between me and my agents. If I can’t write the test for it, the requirement is too vague.

Design and planning come next, evaluating the tech stack against requirements and mapping how end users will actually interact with the system. Then execution: AI agents running parallel workstreams with test-driven development as the quality gate. Each iteration measures against the PRD criteria. You ship when the MVP satisfies the contract.

The step most people skip is validation. I use pre-programmed inspection agents to run visual and functional checks against the original success criteria. They catch what human review gets lazy about: layout regressions, broken interaction flows, scope drift between what was specified and what was built. If the gate fails, I loop back to design with specific findings.

Scaling means running multiple independent loops simultaneously, each with its own PRD, its own agents, its own validation gates, across feature suites or entirely different systems. I built a framework called Banh Mi Ops to handle that orchestration layer.

Every individual phase here exists somewhere in the industry. TDD with agents has academic papers. Spec-driven development has dedicated tooling. Multi-agent frameworks are mature. I built with all of them. The integration is what matters. The person who understands the stakeholder’s problem is the same person running the agents that solve it, with no handoff where intent gets diluted.

AI Applications Strategist Engineer

I call this role the AI Applications Strategist Engineer. The full vertical, holding business strategy, technical architecture, agent-driven execution, and quality validation in a single loop, is a gap the industry hasn’t named yet.

The strategist defines the value proposition. The engineer ships it. Same person.

Every system runs inside a set of constraints. Product requirements, security policies, organizational rules, the rules of the domain it operates in. I read those constraints and write the code that enforces them. The industry treats that as two jobs. For this role it’s one muscle.

The BI era needed this role but the technology couldn’t support it. Now it can.

Abraham Nguyen

My Engineering Practice.md

Abe's AI Methodology.md

Banh Mi Ops.md

Legislative Data Center

California State University, Sacramento