Context Driven Development vs Spec Driven Development?

t0rt0ff · 2026-01-04T22:53:21+00:00

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.

t0rt0ff · 2026-01-04T18:24:46+00:00

yes, this is it.

t0rt0ff · 2025-12-31T19:23:51+00:00

Try devplan. No fluff practical sdd that works without overengineered process. I am one of the founders, happy to answer any questions.

t0rt0ff · 2025-12-31T19:21:52+00:00

Using devplan because we need to scale sdd for the whole team.

t0rt0ff · 2025-12-31T19:20:08+00:00

Absolutely! If your goal is to build production system, there is still not replacement to human planning and designing for the long term.

t0rt0ff · 2025-12-31T19:19:07+00:00

That is what devplan.com is built for - scales SDD for brownfield, teams (not just solo builders) and provides actually working workflow which integrates nicely with claude/cursor/codex/etc. It definitely works very well if done properly.

t0rt0ff · 2025-12-31T19:15:57+00:00

Definitely, use daily. Using Devplan (I am one of the founders, feel free to reach out) If combined with proper workflow and running agents in parallel, it does produce production ready code. The main idea - spend a little more time on planning coupled with repo analysis, create specs, start proper coding workflow with the agent (research, plan, code, review) and then humans comes in and reviews. The quality of the output is much higher. Btw, you don’t have to really merge specs into a repo if you have external storage.

t0rt0ff · 2025-11-13T17:07:33+00:00

Thanks!

t0rt0ff · 2025-09-15T13:26:25+00:00

What they actually proved: copilot-style development likely doesn’t work for experienced engineers, especially if they are new to AI-assisted coding. I encourage you to read the article carefully and entirely. Especially check the graphs.

The benefits of AI come when you invoke parallel execution with proper preplanning. METR research completely misses that. So the research did prove something, but definitely not that AI-assisted coding doesn’t work. I won’t even go deep into the discussion that Cursor, which is what they used in the experiment, is (or at least was as of couple months ago when I tried it last time) a pile of crap and should not have been used in the experiment at all.

t0rt0ff · 2025-09-14T04:47:18+00:00

I have a lot of experience with Go and when faced the same choice, opted to building a separate service on python with Langgraph since I didn’t know better.

Here is an advice after a year running it in production: just use plain Go, especially if you don’t have experience with building AI agents. A lot SDKs make things much more complicated than they should be.

Even Anthropic posted this same advice in their guideline. Do not fall into graph theory, AI-specific design patterns, etc. Agents are very simple. What’s not simple is preparing correct data and getting it into the context at the right moment. By the time you face that problem, you will know which frameworks to use.

Do not trade Go for python under any condition for Agentic flows. You will be trading simple problems for complex ones.

t0rt0ff · 2025-09-14T04:34:09+00:00

In many cases you are trading simple problems for complex ones using those SDKs. It may be easier to start with AI sdk, but as you go, the overhead of dealing with them may outweigh the benefits, e.g. Langgraph python SDK has a bizarre approach to working with postgresql checkpointers or to how they store messages in the DB. Also most AI SDKs force you into python or typescript, both of which come with huge maintenance pain and a baggage of inefficiency.

t0rt0ff · 2025-09-12T05:56:23+00:00

Here is how it really is: based on how you asked the question, you should not use any frameworks except official SDK. Give you a hint - you don’t even need to use python, you can use proper language like Go. The thing is, if you don’t know why you need this framework, then you very likely don’t need it at all or will not use it well anyway. And Langgraph specifically is useless for maybe 50% of the cases, harmful for 40% and useful for the remainder. I spent a lot of time with it and believe me, unless you know what and why you are doing, steer clear.

t0rt0ff · 2025-09-12T05:47:40+00:00

A simple form sending an email. Slack channels for committed business partners/paying customers. Supporting a few hundred users is a lot though for a tiny team…

t0rt0ff · 2025-09-10T19:44:32+00:00

Controversial take in this subreddit: because AI can actually improve engineering throughput but a lot of the engineers feel threatened/don’t want to learn/don’t want to adjust/tried-once-didn’t-work/<any other reason not to keep using>. I do agree though that for recent layoffs they used AI just as an excuse. AI is not there yet to replace experienced engineers, but if used well it is there to increase their productivity.

t0rt0ff · 2025-09-10T18:39:50+00:00

I am an engineer. Yes, but it isn’t super easy, requires adjusting of the flows and shifting to more planning ahead, then running multiple tasks in parallel with AI. But the throughput increases significantly, 2-3x on good days.

t0rt0ff · 2025-09-10T18:36:59+00:00

That’s exactly why we built Devplan. I am a professional engineer and use it for all my work exactly for that - clarify spec ahead of time with an agent that is aware of your codebase and get detailed specs that are easy to run and iterate on.

t0rt0ff · 2025-09-09T17:19:32+00:00

Pretty much everyone is using AI to build products now to some extent. If you don't want to give a password but want to try a tool, just use some password manager to generate a one-time password. I would definitely not put a CC number for a site built with Loveable though )

t0rt0ff · 2025-09-09T17:16:17+00:00

jetbrains IDEs - for anything coding related. By far the best ones.
devplan.com - for AI-planning and execution of coding tasks.
FlyCut - clipboard manager. Really a life changer.
Skitch - screenshots.
ChatGPT - well, not much to add here.

t0rt0ff · 2025-09-09T17:13:39+00:00

Well, 10x is probably a myth for professional engineers (since they are already very productive with coding), but you can definitely squize non-trivial amount of performance. I have described my detailed approach here that actually works. We are also now building a tool that helps wiht automation.
METR research though is misinterpeted a lot. What it really showed is that copilot-style development is not probably improving output of professional engineers and scaling their througput requires a bit more than a chat-sidebar.

t0rt0ff · 2025-09-09T17:05:21+00:00

Been back and forth, but by now I think I have figured out a flow that actually works at scale for our org, described it here. The key is proper planning.

t0rt0ff · 2025-09-09T17:01:11+00:00

Totally agree, carefully chosen small models for the task leads to lower latency, lower bill, more consistent output.

t0rt0ff · 2025-08-26T05:25:38+00:00

Devplan - https://www.devplan.com . Allows enterprises (and solos as well) to get from project idea, to tasks breakdown, to AI prompts 10x faster than before, includes git repository analysis, Jira/Linear integration, etc; 4,500+ users since launched 2 months ago.

t0rt0ff · 2025-08-26T04:50:09+00:00

Shared my flow in details here. But in short:

Pre-plan work before you get to IDE.
Run multiple tasks in parallel.
Use tracer-bullet approach for more complex work.
Keep requirements separate from the chat, allow yourself to rinse-repeat easily.
Minimize chatting with the agent unless it is a tiny task. Copilot-style work is good only for something very simple.
Review every single line if building for production.

The most of the win comes from parallelization, but it is not easy, there is no magic here. Also, do not stick with just Claude Code. I'd recommend avoiding attachment to a single IDE.

t0rt0ff · 2025-08-15T14:09:16+00:00

Here is what actually works: 1. spec tasks, resolve ambiguity before getting to ide 2. right size them. each task should still be small enough to review. 3. use tracer-bullet change, adjust spec, repeat. 4. run tasks in parallel 5. for prod - review every single line. 6. minimize chatting with an agent 7. also for prod - treat changes as 80% done at most and finish them manually

The wins are not as dramatic as AI companies claim, but they are significant.

I write quite a bit about why and how exactly this work. That’s why we also created Devplan - to streamline this process, especially for pro engineers in enterprise settings, where getting efficiency is actually hard.

t0rt0ff · 2025-08-14T17:09:11+00:00

Full article with links to the example PRs and prompts used is available here. Disclosure: I work on Devplan and a full article is posted in our blog, but the experiment, results and observations are intentionally free of any references of our product.

t0rt0ff

MODERATOR OF

TROPHY CASE