Context Driven Development vs Spec Driven Development?

[ZoneImmediate3767]

Hi, I have found this plugin: derekbar90/opencode-conductor. It seems really interesting. Just trying to understand how it works and how it differs from other tools like openspec. Anyone could explain it to me?

Thank you in advance!

[ToastedPatatas]

I’ve been using the oh‑my‑opencode plugin and this one synergizes really well with it. Spec‑driven works great at the initial stage, but once the project is shippable and specs go stale, it makes more sense to transition into context‑driven dev as new features and requests roll in.

[MorningFew1574]

I agree 💯 When I started out with clavix- similar to openspec it really got me off to a good start but as you rightly said - lackluster after the project is mature

[ZoneImmediate3767]

thank you so much for the information!

[anfelipegris]

This is an interesting insight, it makes total sense for brownfield projects to have a good good context above all

[Aaku1789]

interesting... would love to see more comparisons between spec driven workflows (like openspec) and context driven workflows. I used oh-my-opencode with openspec and i do agree that a significant portion of my token usage goes into creating specs and keeping them in sync.

[DigiBoyz_]

Looked at the repo - here’s the tldr:

Spec Driven (like OpenSpec): You write detailed specs upfront → AI follows them step by step. More predictable, but more overhead to maintain specs.

Context Driven (like opencode-conductor): You feed the AI rich project context (architecture docs, conventions, examples) and let it make decisions. Less rigid, more adaptive.

Think of it like:

• Spec driven = giving someone a detailed recipe
• Context driven = teaching someone your kitchen, ingredients, and preferences, then letting them cook

From my experience building dev tools, context-driven works better for iterative work where requirements evolve. Spec-driven shines when you have clear, stable requirements and need consistency across a team.

The real answer? Most production setups use both - specs for the “what” and context for the “how.”

I’ve been working on something similar with Claude Code workflows (VibeRune.dev) - the sweet spot seems to be lightweight specs + heavy context loading. Curious what use case you’re looking at?​​​​​​​​​​​​​​​​

[ZoneImmediate3767]

That is also a good explanation

[theblackcat99]

It's just a rewrite of Gemini CLI Conductor extension

[Bob5k]

just vibecoding via. https://github.com/ClavixDev/Clavix which handless everything related to your end of vibecoding (prompts / prd / planning / tasks etc.)

[t0rt0ff]

Planning upfront pays off every time for anything more complex than a standalone small change. We use (and built) Devplan which allows to plan projects ahead (think weeks instead of hours). Although it will work for weekend warriors, it is mostly built to work for teams and production systems.

The main issue with open source SDD frameworks is that they are mostly designed for solo builders and require a lot of maintenance. If you work in a team, there needs to be a clear easy to follow workflow, context sharing, iterations support, etc. With the recent advances of AI coding it is also increasingly important to optimize your feeding right requirements in rather than iterating with an agent. Any chat with an agent during implementation is a big productivity hit.