The two things missing from every AI coding tool: workflow and context discipline

Adithya K — Tue, 21 Jul 2026 12:40:11 +0000

AI coding tools have gotten very good at one thing: generating code fast. What they haven't gotten good at is discipline.

They don't know your architecture. They don't remember that you rejected a pattern last sprint. They don't know which parts of your context window are signal and which are noise. And they have no concept of a development workflow — no phases, no review gates, no verification steps. You describe what you want, they generate, and you hope the output fits.

For small tasks this works fine. For anything that touches your real codebase at scale — refactors, new features with cross-cutting concerns, compliance-sensitive changes — the lack of workflow structure creates subtle, expensive problems that compound over time.

We've been building Ortho to address two of these problems: workflow discipline (through ASES, a 6-phase AI development methodology) and context discipline (through a 9-component token optimization pipeline). This post explains both.

The workflow problem with AI coding tools

When a junior engineer joins your team, you don't just hand them a task and say "generate." There's a process: understand the codebase, plan the change, get the architecture reviewed, build it, test it, verify it, get it reviewed. The process exists because individual steps catch different categories of mistakes.

AI coding tools collapse all of that into one step. You prompt. You get code. Done.

The result isn't always bad code per file. The problem is architectural: the AI has no model of your layer boundaries, so it imports from layers it shouldn't touch. It has no memory of past decisions, so it re-proposes patterns you've already rejected. It has no verification step, so it confidently generates code that looks right but has subtle issues a reviewer would have caught in 30 seconds.

The missing piece isn't a smarter model. It's a workflow.

ASES: A 6-phase workflow for AI-assisted development

ASES (v1.2) is the methodology built into Ortho's orchestration layer. It structures AI-assisted development into six sequential phases, each with a distinct role:

01 — PLANNER
Understands the intent, scans the existing codebase for relevant context, and produces a structured implementation plan with scope, assumptions, and open questions. The AI doesn't write a line of code in this phase.

02 — ARCHITECT
Reviews the plan against the actual architecture model. Identifies which layers will be touched, what the blast radius is, and whether the proposed approach violates any boundaries. Produces an architecture brief with constraints.

03 — BUILDER
Generates the implementation — with the architecture brief and context from phases 1–2 in hand. This is the only phase that produces code, and it operates with explicit constraints from the preceding phases.

04 — TEST-DESIGNER
Designs the test strategy: which behaviors to test, which edge cases matter, what coverage gaps exist. Produces test specs before tests are written.

05 — VERIFIER
Runs the generated code against real checks: lint, type checking, tests, architecture scan. If something fails, it feeds back to BUILDER — not to the user.

06 — REVIEWER
Summarizes the full change with evidence: what was built, what was tested, what architecture constraints were respected, what the verifier found. The human reviews a brief, not raw output.

Each phase is a separate agent call with its own context window. The outputs chain: PLANNER feeds ARCHITECT, ARCHITECT constrains BUILDER, and so on.

ortho run "add rate limiting to the API layer"
# → PLANNER: scans repo, produces plan
# → ARCHITECT: validates against arch model, adds constraints
# → BUILDER: generates implementation with constraints
# → TEST-DESIGNER: proposes test coverage
# → VERIFIER: runs checks, feeds back if needed
# → REVIEWER: summary for human approval

ortho approve   # accept the change
ortho reject "wrong layer for rate limiting, use middleware"

The reject step matters: that decision is stored. Next time a similar change is proposed, Ortho cites it: "Rejected 2026-07-15: use middleware layer, not API handler." The AI doesn't propose the same anti-pattern twice.

The token problem nobody talks about

Context windows have gotten large. That doesn't mean you should fill them.

Most teams using AI coding tools are doing one of two things: (1) sending too little context and getting generic output that doesn't fit the codebase, or (2) sending everything and burning tokens on noise — boilerplate, generated files, test fixtures, third-party vendored code — that makes the model's actual reasoning worse, not better.

The naive solution is "just send more." The real solution is sending the right context: the signal, not the noise. But figuring out what's signal for a given task requires understanding the task, the codebase, and the relationship between them.

This is what Ortho's token optimizer does.

The 9-component token optimization pipeline

Ortho's token optimizer runs before every agent call in the ASES workflow. It takes the raw context candidates and applies nine filtering and ranking passes to produce a lean, high-signal context window:

Intent Extractor — Parses the task to identify the primary intent, affected layers, and key symbols. Everything downstream is filtered against this.
Symbol Ranker — Scores every symbol in the index by relevance to the intent. Direct matches score highest; indirect references score lower.
Import Graph Pruner — Walks the import graph from the intent's entry points and prunes branches that don't connect back to the affected code paths.
Call Graph Filter — Uses the call graph to identify which functions are actually on the execution path for this task.
Architecture Context Selector — Injects the architecture model at the right level of detail — full for ARCHITECT phase, minimal for BUILDER.
History Deduplicator — Strips context already included in a previous phase's call. Prevents re-sending the same file content across six agent calls.
Feedback Injector — Retrieves relevant past decisions from the feedback store and injects them as constraints. "Pattern X was rejected on [date] for [reason]" goes into every relevant call.
Budget Allocator — Enforces a per-phase token budget. If ranked context exceeds the budget, lower-scoring items are dropped.
Format Compressor — Strips comments, docstrings, and whitespace from included source before sending. A 400-line file often compresses to 200 lines of signal.

The result: each agent call gets a context window purpose-built for that phase. The PLANNER gets broad repo context. The ARCHITECT gets the architecture model. The BUILDER gets only the code paths it needs to touch. Nothing leaks between phases that shouldn't.

Why these two things belong together

Workflow and token optimization sound like separate problems. They're not.

A workflow without context discipline produces well-structured calls with bloated, noisy inputs. The ARCHITECT phase is only useful if it gets accurate architecture context — not every file in the repo.

And context optimization without workflow structure produces lean inputs to an unstructured process. You might send the right 200 lines of code, but if there's no ARCHITECT phase enforcing layer constraints before BUILDER generates, the lean input goes to the wrong question.

The workflow defines what questions to ask, in what order. The token optimizer ensures each question gets the right signal to answer it. Together, they're the missing layer between "I have an AI coding tool" and "AI coding is actually disciplined on my team."

Try it

Ortho is local-first — your source never leaves your machine. One SQLite file in your repo root, zero telemetry.

# Windows
irm https://adithyak3106.github.io/Ortho-community/install.ps1 | iex

# macOS / Linux
git clone https://github.com/AdithyaK3106/Ortho.git && cd Ortho && ./install.sh

# Then:
cd your-repo
ortho run "add Redis caching to the API layer"   # ASES workflow
ortho guardrails                                  # architecture scan
ortho memory search "rate limiting"              # search past decisions

GitHub: https://github.com/AdithyaK3106/Ortho
Landing page: https://adithyak3106.github.io/Ortho-community/

We're looking for 5 engineering teams to run Ortho on a real internal repo for 30 days and give honest feedback. If you're shipping AI-generated code and hitting architecture or workflow problems, I'd love to hear about it. Email: urbrain369@gmail.com