Every few weeks a new AI coding assistant lands on Hacker News with a wave of "this changes everything" comments. OpenCode is the latest terminal-first entry in this space, and the demo looks compelling. But after spending real time with it on a production TypeScript codebase, I want to offer something more useful than another glowing first-impression post: an honest accounting of where these tools help, where they hurt, and what the design decisions of tools like OpenCode reveal about the tradeoffs you're actually accepting.
This isn't a hit piece. It's the kind of evaluation I'd want before spending two weeks integrating a tool into my workflow.
What OpenCode Is Actually Doing
OpenCode is a terminal UI (TUI) coding assistant that wraps an LLM with file-system access, shell execution, and a diff-apply loop. You describe a change in natural language, it reads context from your repo, generates code, and applies it. The pitch is that it stays in the terminal where many engineers already live, avoiding the context-switch to a browser-based chat interface.
The core loop is:
- You provide a prompt
- The tool reads relevant files (via its own heuristics or your explicit direction)
- The LLM generates a diff or full file replacement
- OpenCode applies the change and optionally runs a verification command
This is not fundamentally different from what Aider, Claude Code, or Cursor's agent mode do. The differentiation is in the UX layer, the model routing, and the assumptions baked into the context-gathering step — and those assumptions are where things get interesting.
The Context Problem Is Not Solved
The most critical failure mode for any agentic coding tool is context selection. If the model doesn't see the right files, it will generate plausible-looking code that violates your actual constraints — wrong types, ignored abstractions, duplicated logic.
OpenCode, like its peers, uses a mix of:
- Git history and file recency
- Import graph traversal
- Keyword and embedding similarity search
- Whatever you explicitly paste in
The problem is that in a real TypeScript monorepo — a Turborepo setup with shared packages, for example — the most important constraints often live outside the file being edited. Your Zod schema in packages/validation, your design token types in packages/tokens, your shared component API in packages/ui. These are the files that determine whether the generated code is actually correct.
When I asked OpenCode to extend a form component, it generated perfectly valid TypeScript that was completely inconsistent with the validation schema the form was bound to. It looked right. It compiled. It was wrong.
// What OpenCode generated — valid TS, wrong contract
type FormValues = {
email: string;
role: string; // Should be constrained to z.enum(['admin', 'member', 'viewer'])
};
// What the actual Zod schema required
const formSchema = z.object({
email: z.string().email(),
role: z.enum(['admin', 'member', 'viewer']),
});
The tool didn't know about the schema because it wasn't imported in the component file — it was injected via a form context provider three layers up. This is a structural limitation. The import graph traversal is shallow, and the tool has no model of React's runtime dependency patterns.
The Trust Gradient Problem
Here's a subtler issue that doesn't get enough attention: AI coding tools create an uneven trust gradient that's dangerous for code review culture.
When a junior engineer writes code, experienced reviewers bring appropriate skepticism. When an AI tool produces a clean, well-formatted diff with a tidy commit message, it looks more authoritative than it is. I've watched PRs get merged faster when they're AI-assisted because the surface presentation is polished. That's backwards.
AI-generated code requires more scrutiny in specific areas, not less:
- Edge case handling: LLMs optimize for the happy path
- Security boundaries: Input validation, authorization checks, secrets handling
- Performance characteristics: N+1 queries, unnecessary re-renders, missing memoization
- Long-term maintainability: Generated code often solves the immediate problem in a way that accumulates tech debt
If your team hasn't explicitly recalibrated review standards for AI-assisted code, do that before adopting any of these tools at scale.
Where Terminal-First Actually Wins
There is genuine value here. Terminal-first AI assistants are meaningfully better than browser chat for a specific category of tasks: exploratory refactoring with tight feedback loops.
Tasks like:
- Migrating from one API shape to another across 40 files
- Applying a consistent pattern (logging, error boundaries, analytics events) across many components
- Converting a class-based module to functional with a known target shape
For these, the apply-verify-iterate loop in a terminal tool is faster than copy-pasting between a chat window and your editor. You stay in one context. You can run your test suite as the verification step. You see diffs without context-switching.
# This kind of workflow works well
opencode "Find all fetch() calls in src/ and wrap them with our
httpClient utility from lib/http-client.ts, preserving error handling"
# Run tests as verification
npm test -- --watch=false
For mechanical, well-defined transformations with a narrow constraint space, these tools earn their keep.
The Autonomy Dial Is Set Wrong
Most of these tools default to too much autonomy. OpenCode will, by default, apply changes without a confirmation step if a verification command is configured and passes. That sounds reasonable until your verification command is npm run build and the generated code introduces a subtle runtime bug that doesn't surface at build time.
The right default is more conservative: show the diff, wait for approval, then apply. Autonomy should be opt-in per task, not a global opt-out. The tools that get this right — Cursor's agent mode with explicit step approval, Claude Code with its default confirmation prompts — feel fundamentally safer on anything touching production paths.
If you're evaluating OpenCode or similar tools, check the default autonomy settings before you start. Understand exactly what --auto-apply and equivalent flags are doing.
What a Staff Engineer Actually Wants From These Tools
After using several of these tools across real projects, here's what actually matters:
Respects existing conventions. The tool should read your ESLint config, your component patterns, your naming conventions — and follow them without being told explicitly every time. Most tools do this poorly.
Understands project-specific abstractions. If you have a useFormField hook or a DataTable component, the tool should use them, not generate a new implementation from scratch.
Doesn't hide complexity. Generated code should be readable and auditable. A clever solution that works but is hard to reason about is not a win.
Fails loudly, not silently. If the tool can't gather enough context to be confident, it should say so. Hallucinated-but-plausible code is worse than an honest "I don't have enough context for this."
Integrates with your existing feedback loop. Your test suite, your type checker, your linter — not a parallel system.
OpenCode scores well on the last point and poorly on the first two.
The Honest Verdict
OpenCode is a competent implementation of a tool category that is genuinely useful for a subset of tasks. It's not a reason to overhaul your primary workflow, and it's not a substitute for understanding your codebase.
Engineers who get real value from tools like this treat them as accelerators for well-scoped, mechanical work — not as autonomous collaborators on design decisions. The engineers who get burned are the ones who trust the polish of the output over the quality of the reasoning behind it.
Before adopting any AI coding assistant on a production team, answer these questions:
- What is the verification gate before AI-generated code merges?
- Have we updated code review expectations explicitly?
- Do we have a clear list of task types where we won't use AI assistance — auth flows, payment logic, data migrations?
- Can the tool understand our project-specific abstractions, or will it work against them?
If you can't answer those confidently, the tool will make things slower, not faster.
The promise of AI coding assistants is real. The current implementations require more critical evaluation than they typically receive.
Top comments (0)