Getting started
You’ve inherited a tool. A friend built feedmill over a few weekends — a self-hosted, terminal-first feed aggregator: a small Go CLI plus an HTTP sync server that pulls dozens of RSS, Atom, and JSON feeds, dedupes them, and serves a reading queue you read from the terminal and could run unattended on a cron. It mostly works. It’s thin on docs. And there’s one feed type you already suspect parses its dates wrong. You’re going to spend a week with OpenCode turning this from someone else’s weekend project into something you trust, and this chapter is the first hour of that week.
The audience here is the engineer who already lives in an editor — a typed Go codebase open in the gutter, the language server drawing red squiggles under anything that doesn’t compile — and who eyes a terminal agent with reasonable suspicion. You don’t have to give any of that up. OpenCode is terminal-first, but by the end of the hour it’s sitting next to your editor, not replacing it, and you’ve used it to fix a real bug in code you didn’t write.
If you’ve used a single-vendor agent before, OpenCode’s first surprise is that it has no opinion about which model you run. It speaks to dozens of providers, and the model is a setting you choose — so the second lesson is its own deliberate stop, not a footnote in the install.
The hour we’ll follow
Section titled “The hour we’ll follow”feedmill ingests feeds from many differently-shaped sources, and you’ve already noticed it mishandles dates from one of them — an entry that clearly published on one day lands in the reading queue stamped as another. That’s your warm-up ticket: small, real, and verifiable against a feed you can read with your own eyes. We’ll go from zero to that fix shipped, in five moves:
- Install it and meet the TUI — and the local server it quietly starts behind it — Install OpenCode and meet the TUI
- Bring your own model, because the provider is yours to pick and the choice is worth making on purpose — Bring your own model
- Watch one read-only turn of the loop — how it gathers context before it’s ever allowed to write — Understand one turn of the loop
- Hand it the date bug and watch that loop close on a real fix you review before it lands — Ship your first reviewed change
- Dock it next to your editor so this becomes a daily habit, not a detour — Put OpenCode next to your editor
None of it is hard. The point of doing it as one continuous task — on a tool you’ve genuinely just inherited — is that the habits you pick up here are the same ones every later chapter leans on: read before you edit, approve before it writes, and commit the moment a change is green and reviewed. On code you didn’t write and don’t fully trust yet, those habits aren’t optional polish. They’re the whole game.
And there’s one detail that can earn the skeptic’s attention early: feedmill is typed Go, and OpenCode can read the same LSP diagnostics your editor turns into red squiggles. There’s a setup step the skeptic should know up front, though — LSP is disabled by default, so you turn it on in your config, and you bring your own Go toolchain. OpenCode auto-detects .go files by extension and, once LSP is on, starts gopls for you: if gopls isn’t already on your PATH it will even go install it on first use — but only if the go command is present and LSP downloads aren’t disabled. So the one thing OpenCode can’t supply is the Go toolchain itself; install that and the rest is automatic. With that in place, a proposed change isn’t guessing about your types — it’s looking at the same gopls output you are. That’s the difference between an agent that hopes the code compiles and one that checks. (OpenCode ships a few dozen built-in language servers, Go among them. ) You’ll feel it for the first time when you ship the date fix, and lean on it in every chapter after.