Spec is essentially a set of facts + fluff. List of facts is essentially the spec minus the fluff. This was my main idea when trying this approach out. It worked quite well, so I went on building the CLI and a set of skills to better guide the agent about this specific workflow.
Thanks! The project is dogfooded, so the most direct example is the project itself.
Outside of that, I found a few things particularly useful so far:
- I can seed a relatively complex project with just a few core assumptions about behaviors I have, agent will firgure out all the gaps in a formalised way
- I can easily diff/compare the fact sheets against one another. One example: I built a fact sheet for a fairly hairy Python CLI, then asked the agent to update all Python-related entries to their Rust equivalents, then rebuilt this CLI in Rust in the scope of another project
- It's much quicker than working with large spec formats, agent uses less tool calls to capture the context it needs to work on something
- After doing large refactoring, agent doing a "fact check" is essentially a full on e2e test run
Two biggest gains for agentic use are because fact sheets are more compact and that they are all assertions about the desired state, it's much easier to reason about things that should and shouldn't be there
owning GGUF conversion step is good in sone circumstances, but running in fp16 is below optimal for this hardware due to low-ish bandwidth.
It looks like context is set to 32k which is the bare minimum needed for OpenCode with its ~10k initial system prompt. So overall, something like Unsloth's UD q8 XL or q6 XL quants free up a lot of memory and bandwidth moving into the next tier of usefulness.
I tried, really really hard but then I realised that I essence it's a poorly written agentic coding assistant that wastes a lot of tokens antropomorphising itself while forcing me to debug via WhatsApp instead of normal tools. So I leaned into that and made OpenCode my general assistant, it worked much better in this aspect.
After seeing a recent video from Theo, I wanted to see how far I can take a harness contained in just 30 lines of JavaScript. Turns out - far enough to be useful, it handles simple tasks just fine, works with both cloud and local models, uses just three tools (but can do with a single one, frankly speaking), cleanly handles detached commands or cancellation mid-run, has non-interactive mode and can be run with NPX.
They are playing catch up with Anthropic's in this functionality. Claude's app was unified and extended with new use-cases since pretty much the very beginning and OpenAIs approach is just a reflection of their attempt too shoot for all targets once (with independent teams, of course).
Many folks from other tools are only getting exposed to the same functionality they got used to, but it offers much more than other harnesses, especially for remote coding.
You can start a service via `opencode serve`, it can be accessed from anywhere and has great experience on mobile except a few bugs. It's a really good way to work with your agents remotely, goes really well with TailScale.
The WebUI that they have can connect to multiple OpenCode backends at once, so you may use multiple VPS-es for various projects you have and control all of them from a single place.
Lastly, there's a desktop app, but TBH I find it redundant when WebUI has everything needed.
Make no mistakes though, it's not a perfect tool, my gripes with it:
- There are random bugs with loading/restoring state of the session
- Model/Provider selection switch across sessions/projects is often annoying
- I had a bug making Sonnet/Opus unusable from mobile phone because phone's clock was 150ms ahead of laptop's (ID generation)
- Sometimes agent get randomly stuck. It especially sucks for long/nested sessions
- WebUI on laptop just completely forgot all the projects at
one day
- `opencode serve` doesn't pick up new skills automatically, it needs to be restarted
Spec is essentially a set of facts + fluff. List of facts is essentially the spec minus the fluff. This was my main idea when trying this approach out. It worked quite well, so I went on building the CLI and a set of skills to better guide the agent about this specific workflow.
reply