CHOP: chat-oriented programming
Table of content
by Ray Svitla
steve yegge, while working on cody at sourcegraph, gave a name to something every developer using AI tools was already doing: coding by talking to the AI instead of typing code directly. he called it CHOP — chat-oriented programming.
the name stuck because it describes a real behavioral shift, not a product feature.
what CHOP actually means
traditional programming: you think about what the code should do, then you type the code. your hands are the bottleneck between your intent and the implementation.
CHOP: you think about what the code should do, then you describe it in natural language to an AI. the AI types the code. your ability to articulate intent is the bottleneck.
this is not autocomplete. autocomplete finishes your lines. CHOP replaces the line-writing entirely. you’re not writing code faster — you’re not writing code at all. you’re writing descriptions of code.
# traditional
function calculateTax(amount: number, rate: number): number {
return amount * rate;
}
# CHOP
"write a function that calculates tax given an amount and rate"
the output is the same. the input is fundamentally different.
the spectrum
yegge describes a spectrum from traditional coding to full CHOP:
line-smithing → you write every character. the old way.
autocomplete → the AI finishes your lines. copilot’s original mode. you’re still steering, the AI just types faster.
chat-assisted → you write some code, ask the AI about tricky parts, paste in suggestions. most developers are here now.
full CHOP → you describe features in natural language. the AI writes all the code. you review and iterate. claude code’s plan-then-execute workflow lives here.
vibe coding → you describe what you want, the AI builds it, and you don’t even review the code carefully. you just check if it works. andrej karpathy’s term for the extreme end of the spectrum.
most professional developers oscillate between chat-assisted and full CHOP. you drop into line-smithing for quick tweaks and escalate to full CHOP for features.
why it matters
CHOP changes what’s valuable about a programmer.
in traditional programming, typing speed, syntax knowledge, and API memorization all matter. you need to know that Array.prototype.reduce takes an accumulator and a current value, and the initial value goes after the callback.
in CHOP, none of that matters. what matters: can you describe what the code should do clearly? can you spot when the generated code is wrong? can you decompose a complex feature into describable pieces?
these are different skills. experienced developers often have them implicitly — they’ve spent years building mental models of how software works. but they’re not the skills that were explicitly valued or tested for.
junior developers who are great at articulating intent might outperform seniors who are great at typing code. that’s an uncomfortable inversion for the industry.
the criticism
CHOP has real problems that enthusiasts gloss over:
you still need to read code. generating code is the easy part. understanding what was generated, catching bugs, maintaining it over time — that requires reading skills that CHOP doesn’t develop. if you can’t read the output, you can’t verify it.
natural language is ambiguous. “add authentication” means wildly different things depending on context. code is precise. english is not. CHOP pushes the precision problem from the code to the prompt, and most people are worse at precise natural language than they think.
debugging gets weird. when you wrote the code, you understand it implicitly. when the AI wrote the code, debugging requires understanding someone else’s implementation. this is why CHOP debugging sessions often start with “explain what this code does” — you have to read the code you didn’t write before you can fix it.
the vibe coding failure mode. when CHOP goes wrong, it goes wrong fast. generating 500 lines of code you don’t understand is worse than writing 50 lines you do. the AI can produce plausible-looking code that passes tests but has subtle logic errors that only surface in production.
where CHOP works
→ prototyping. you want to test an idea fast, code quality is secondary, iteration speed is everything. CHOP is perfect.
→ boilerplate. CRUD endpoints, form components, database migrations, CI configs. stuff where the pattern is well-known and the implementation is repetitive.
→ unfamiliar territory. you need to integrate a library you’ve never used. describing what you want and letting the AI figure out the API is faster than reading docs.
→ cross-domain work. backend developer needs some CSS. data scientist needs a web interface. CHOP lets you operate outside your expertise without learning the full stack.
where CHOP fails
→ novel algorithms. if the problem is genuinely new, the AI can’t generate a solution from pattern matching. you need to think.
→ performance-critical code. generated code tends toward correctness, not optimization. hot paths, memory management, concurrent systems — these need human attention to detail.
→ security boundaries. auth flows, encryption, access control. the cost of a subtle bug is too high to trust generated code without deep review.
→ code you’ll maintain for years. if you can’t read it, you can’t maintain it. CHOP code that you don’t understand becomes legacy code the moment it’s committed.
the real shift
CHOP isn’t a technique. it’s a symptom of a deeper change: code is becoming a compiled artifact of human intent, like assembly language became a compiled artifact of C.
nobody writes assembly by hand anymore (almost). nobody will write boilerplate by hand in five years (probably). the question is where the line settles between “AI writes it” and “humans write it.”
yegge thinks the line moves further toward AI every year. he’s probably right. but “further” is not “all the way.” the developers who thrive will be the ones who know when to CHOP and when to type — who treat AI as a power tool, not a replacement for understanding.
the acronym is catchy. the shift is real. the nuance is in knowing when to chat and when to code.
→ claude code vs aider — CHOP tools compared → plan mode mastery — structured CHOP workflow → agent-first design — making repos CHOP-friendly
Ray Svitla stay evolving