Why Intent? #1
My latest labor of love is free and it's available at https://intentapp.dev (open-source). Go download it and give it a try. I think you'll love it. If you already use Claude Code or Codex, it'll supercharge your routine (and if used properly, Intent will reduce your token burn too!)
Specs, Specs, Specs
I can probably tell you a dozen reasons why Intent (there was the OG one and now the OSS one -- here I mean the OG one) became my daily driver since Jan 2026. But I'll give you the one thing that stood out: it (courageously) made the leap from what IDEs were and reimagined how we might build software given an abundance of intelligence manifested as an infinite supply of A+ coders (that is to say, there are still cases where a human will do better but on balance of speed and quality, LLMs are hard to beat in 2026 in coding -- note, not software engineering).
Claude Code was my daily driver in 2025 and before then since, oh, 2006 or so, it had been IntelliJ (which, considering that it was my daily driver for 20 years, says a lot about how consequential it is for the industry itself). But ChatGPT came and replaced Stack Overflow, Claude got better at coding, it started being able to run terminal commands ("just give it terminal access") and of course, Claude Code came and changed everything.
Software software engineering isn't about coding alone and coding isn't about just LOC. The name "Intent" captures it well—engineering and building products involves "intent". PMs write PRDs and do customer research to hone their ability to discover what they intend the product to do. Engineers ask in tickets about intent because "making this button disappear when X is true" isn't intent -- this is often lost in software engineering due to apathy but the better the intent is transmitted in tickets, the more likely that the engineer can iterate with the owner of the ticket or even by themselves for an (often times) better solution.
Intent (the one that @Wattenberger and gang launched in Jan), wanted to let anybody code with LLMs while focused on capturing this. There are other systems out there that do this — /plan being the easiest and GitHub's speckit being perhaps the most pedantic. The approach Intent v0 took was, however, a visual markdown spec that an LLM ideates with the user in a conversational, visual, exploratory manner. It doesn't argue for specifics (although this could be a requirement and will get noted down) and tries to strike the proper balance between high-level goals, definitions of done (DoDs), deliverables, what's out of scope, etc., and an execution plan that a team of agents (sometimes tens or hundreds) can execute efficiently (in parallel and minimizing conflicts).
The (new) Intent is easily the best UI/UX of a product that I have built (and likely beats almost anything out there) thanks to Amelia
The "proof" that a spec is well-written is forced upon the writer as agents do not have the context of the back-and-forth that happened during spec writing. It merely gets a sliver of the spec (often times without knowing who's working adjacent to it) and attempts to do the work. The resulting output can be evaluated by yet another agent (again, with nothing but the spec itself) and sent back for rework if the requirements are not met. This "context-free" implementation and testing regime meant it is more likely for agents to spot inconsistencies in the spec and/or in the implementation. This is an observation that many working with any coding agents will tell you today already -- Intent just built it into the product.
A spec is of course a living document, and freeing the writer (the "Coordinator" as it is called in the app) from having to do the actual work means you can continue to iterate with it to figure out next steps. Yes, it is even possible for it to realize that the spec, as written, is problematic after further considerations, and it can liaise with in-flight agents to resolve tensions and/or tell them to stand down completely.
If you are in the business of building software (and probably also if you're vibe-coding your next thing), having a thoughtful partner is a refreshing change (the alternative being the eager, trigger-happy implementor that goes off and does things the moment it thinks it can). Air-gapping the conversation between the "intent space" of what you're building and the actual building of the thing also meant you can spend more time exploring ideas, pontificating about next steps, deployment plans, or even your tweet about it -- all while the thing is being built.
You can choose the best model as your partner -- the platform allows you to blend Claude with Codex, pi with OpenCode, frontier models with Unsloth for local models, etc. within a single swarm -- so yes, you can have GPT-Sol verify the work of Claude Opus and if you're just doing a merge or resolving conflicts, use a cheaper model. All of this is configurable; we do not enforce how you should use the platform. Even the "Coordinator" is just a specialist that you can customize.
Now back to the question at the beginning of this discussion -- how did I get involved? Honestly, I was just a heavy user, occasional contributor to the project at first, but after feeling the raw power of Intent unleashed on projects at reve.art, endara.ai, foundationdb.org, etc., I wanted to make sure it would go places. When SHV indicated that it could go open source, I jumped at the opportunity and probably got a little bit too excited (you can check the commit histories on the repos).
Building the v2 version of Intent broke the scale of my contribution heat map...
In the days and weeks to come, I hope to share more on how the last months of working at breakneck speeds transformed an already brilliant coding platform into a visually stunning, snappy, reliable, feature-rich agentic orchestration platform that I am already using beyond coding.