[flagged]
My automated doubt development process
21–30 of 35 posts
Re: My automated doubt development process
#22I think its common to develop an adversarial-collaborative approach to getting some semblance of quality out of AI. I personally favour using multiple models for different roles, having a bunch of continuity documentation maintained, and having the plan surface human-verifiable deliverables as soon as feasible. It does involve more attention than most people would tolerate probably.
Re: My automated doubt development process
#23I've stumbled on the same workflow. Except for one thing: If I just do as OP does, Claude Code will tend to overengineer. For example it'll build complex solutions to super rare race conditions that have trivial fallout. But I've found that all it takes is a "skeptical pass". Here's how it goes: After having a bunch of specialist subagents review the (plan/implementation), after doing the deduplication/synthesis of t…
This sounds harder than just writing the code.
When you put it like that, it really does, lol.
Re: My automated doubt development process
#24Earlier quoted context omitted.
Personally it's well-defined and agentic - just not circulated. /understand - agents interrogate the problem /huddle - Thinking panel turns it into a PRD - attacks the premise, PRDs regularly die here /tm - claude-task-master breaks the survivor into a dependency graph Nobody writes this half up because "agent talked me out of building it" demos worse than "agent built it".
Sorry I have to ask. How senior are you? The notion that I‘d allow an agent to talk me out of something seems weird. 99% of cases, it’s the other way around. Architecture is just not where they shine.
[dead]
Re: My automated doubt development process
#25Enjoyed it until the first emdash (was half expecting it to arrive anyway). Sorry.
Re: My automated doubt development process
#26Most writings about the spec-driven development I see start with a product requirements document that is assumed to be valid. But I doubt that's the case. If so, you would've written about it, and probably would've involved agents in the research that goes into it. My gut feeling tells me there's much more emphasis on implementing the feature than on questioning if it's relevant, feasible, and based on valid assumpti…
Biased cause I work there, but that’s where software like Tactiq shines. We just added an MCP, and now the agent has access to the meetings when writing the plan. Last week I had three meetings with three stakeholders, and the agent was able to gather everyone’s ideas and make sure they are all working together in the feature.
Add some cron jobs to run a prompt that reviews work being done against the plan and baby, you’ve got a middle manager going.
Re: My automated doubt development process
#27I have a similar skill that assesses project drift (how far the current project state is from the original spec and brief) and looks for artifacts of that - orphaned code or features that are no longer relevant, design decisions that made sense at the time but are now dubious, or parts of the design that no longer fit the current project state.
I found it really useful taming the spaghetti that claude tends to generate by itself.
Re: My automated doubt development process
#28Enjoyed it until the first emdash (was half expecting it to arrive anyway). Sorry.
I'm coming around to liking them; they're like a sort of anti-shibboleth.
"Ah, an em-dash", I think: "now I know".
Re: My automated doubt development process
#29Most writings about the spec-driven development I see start with a product requirements document that is assumed to be valid. But I doubt that's the case. If so, you would've written about it, and probably would've involved agents in the research that goes into it. My gut feeling tells me there's much more emphasis on implementing the feature than on questioning if it's relevant, feasible, and based on valid assumpti…
[flagged]
Re: My automated doubt development process
#30Earlier quoted context omitted.
Personally it's well-defined and agentic - just not circulated. /understand - agents interrogate the problem /huddle - Thinking panel turns it into a PRD - attacks the premise, PRDs regularly die here /tm - claude-task-master breaks the survivor into a dependency graph Nobody writes this half up because "agent talked me out of building it" demos worse than "agent built it".
Sorry I have to ask. How senior are you? The notion that I‘d allow an agent to talk me out of something seems weird. 99% of cases, it’s the other way around. Architecture is just not where they shine.
[flagged]