opencode VS Kiro

Dax, the creator of OpenCode — an open-source coding agent, of all the people one might expect to disagree — put the case for hand-coding cleanly in a recent interview about Spec-Driven Development:

Pipa is our agent for studio operations at Lunch Pail Labs. She lives in Slack, is powered by E2B sandboxes, and uses OpenCode for the harness.

One reason I liked OpenSpec more than others, such as Kiro and SpecKit, is that OpenSpec is highly portable between coding assistants, codebases and stages of development. I've plugged OpenSpec into all sorts of projects, from infrastructure to Python libraries. I also work on diverse codebases, with a variety of AI friends that OpenSpec supports: OpenCode, Codex and Claude Code.

Beyond the big names, I would also keep an eye on OpenCode and T3 Code. OpenCode is a solid open-source, terminal-first option if you want a model-agnostic agent and bring your own provider setup. T3 Code is interesting for the opposite reason: it gives you an open-source GUI on top of the agents you may already pay for, like Claude Code, Codex CLI, OpenCode, or Cursor.

Brought to you by the infamous creator of OpenCode, who will exfiltrate all your data, then feign ignorance:

https://github.com/anomalyco/opencode/issues/10416

github.com/kirodotdev/Kiro — issue tracker and feedback repo

AI coding tools are shipping with built-in OpenTelemetry support. Claude Code, Claude CoWork, GitHub Copilot, Gemini CLI, and Cursor (via hooks) all export metrics, traces, and log events over OTLP/HTTP — token counts, tool durations, model latency, the works. Kiro has an open feature request for native OTEL support too.

https://github.com/kirodotdev/Kiro/issues?q=is%3Aissue%20sta...

Stuck Tasks: Tasks frequently get stuck, fail, and require numerous manual retries. I ran into a lot of problems with my terminal that was configured with many plugins; the issue and solution are on GitHub: https://github.com/kirodotdev/Kiro/issues/53 The frustration is compounded by the fact that a failed task often loses all context, forcing developers to restart the entire process from scratch and burning through their daily usage limits on unsuccessful attempts. This gap between the product’s promise and its current usability has been a major source of frustration, perfectly captured by my own user’s experience:

I can totally see that in the near future a feature like this will be implemented where Kiro by default collapses the body of the functions, and us as the Kiro operators can solely focus on the abstractions and see how different modules in the code are connected to each other.

Initially I wasn't aware of this feature, otherwise I would've used it very early on to avoid a problem like this one (https://github.com/kirodotdev/Kiro/issues/2417) during initial scoping of the project.

We'd love to hear your feedback! Share your thoughts on our GitHub repository and download Kiro to start building!

Can you please report an issue on our GitHub Issue tracker: https://github.com/kirodotdev/Kiro/issues?

Or can you join the Discord and message me directly @swaminator