6 ms·
Over the last 2 weeks (evenings only) I've spend a lot of time crafting the "perfect prompt" for claude code to one shot the project. I ended up with a rather s
by hetspookjee 1y ago
Over the last 2 weeks (evenings only) I've spend a lot of time crafting the "perfect prompt" for claude code to one shot the project. I ended up with a rather small CLAUDE.md file that references 8 other MD files, ranging from project_architecture, models_spec, build_sequence, test_hierarchy, test_scenarios, and some other files.
It is a project for model based governance of Databricks Unity Catalog, with which I do have quite a bit of experience, but none of the tooling feels flexible enough.
Eventually I ended up with 3 different subagents that supported in the development of the actual planning files; a Databricks expert, a Pydantic expert, and a prompt expert.
The improvement on the markdown files was rather significant with the aid of these. Ranging from old pydantic versions and inconsistencies, to me having some misconceptions about unity catalog as well.
Yesterday eve I gave it a run and it ran for about 2 hours with me only approving some tool usage, and after that most of the tools + tests were done.
This approach is so different than I how used to do it, but I really do see a future in detailed technical writing and ensuring we're all on the same page.
In a way I found it more productive than going into the code itself.
A downside I found is that with code reading and working on it I really zone in.
With a bunch of markdown docs I find it harder to stay focused.
Curious times!
- razemio 1y agoThat is exactly my issue. I am more districted while being more productive. It feels just wrong, but works for now. In the long run, I need to find a solution for this. What works best for now, is to let multiple agents run on multiple repos of the same project solving different tasks. This way, I stay somewhat focused, since I constantly need to approve things. Just like a Projekt Manager with a big team... Indeed curious times.
- ionwake 1y agoI agree I think this is the way
- m_fayer 1y agoLong after we are all gone and the scrum masters are a barely remembered historical curiosity, there shall remain, humble and eternal, the waterfall model.
- actionfromafar 1y agoA waterfall, frozen, in time?
- unixhero 1y agoWell waterfall is how we built the old world. Piece by piece, module by module, roads, bridges, buildings, boats.
- ionwake 1y agoI got intrigued by your comment, I couldn't wrap my head about a process just changing. Got AI to throw out this table, but I think its of interest: Waterfall ~1970, Agile ~2001, Continuous (DevOps) ~2015, Autonomous Dev ~2030, Self-Evolving Systems ~2040, Goal-Directed Ecosystems ~2050+
- Den_VR 1y agoWhat do you think about “goal-directed ecosystems” mapping to Mulder’s Collaborative Agent Maturity Model (CAMM)?
- ionwake 1y agoterribly interesting! Thank you
- aryehof 1y ago~1985 Iterative Development. That waterfall was what everyone did before agile is a myth. AI produces the recent popular viewpoint as truth whether it is true or not.
- mprivat 1y agoThat's pretty novel. What framework is actually running the agents in your experiment?
- hetspookjee 1y agoIts just the auto generated sub-agents from Claude Code https://docs.anthropic.com/en/docs/claude-code/sub-agents https://docs.anthropic.com/en/docs/claude-code/sub-agents I plan to do a more detailed write down sometime next week or the week after when I've "finished" my 100% vibe coded website.
- a_bonobo 1y agoI feel we're developing something like what made Test-Driven Development so strong: TTD forced you to sit down and design your system first, rather than making it all up on the fly. In the past we mapped the system while we were building the code for it. This kind of AI-driven development feels very similar to that. By forcing you to sit down and map the territory you're planning to build in, the coding itself becomes secondary, just boilerplate to implement the design decision you've made. And AI is great at boilerplate!
- hetspookjee 1y agoThat is exactly what this felt like indeed! I found a lot of interest in both refining the test strategy and test decisions, but when it started implementing some core functions were in fact lost in the process. This rather leaky memory still suprises me every now and then. Especially 'undoing' things is a big challenge as the (do not) kind of route versus the (do) route is so much more confusing for the LLM, it seems.
- mattmanser 1y agoI feel TDD ended up fizzling out quite a bit in the industry, with some evangelists later admitting they'd taken to often writing the code first, then the tests. To me it's always felt like waterfall in disguise and just didn't fit how I make programs. I feel it's just not a good way to build a complex system with unknown unknowns. That the AI design process seems to rely on this same pattern feels off to me, and shows a weakness of developing this way. It might not matter, admittedly. It could be that the flexibility of having the AI rearchitect a significant chunk of code on the fly works as a replacement to the flexibility of designing as you go.
- MoreQARespect 1y agoTDD fizzled because not enough emphasis was put on writing high level tests which matched user stories and too much emphasis was put on it as a tool of design.
- SkyPuncher 1y ago
- brainless 1y agoThese days, I record product details, user journey, etc. with voice, and kick off the product technical details documentation process. Minimal CLAUDE.md. GitHub based workflow for software development process. I am struggling with generating good CI workflows, on it. Here is my playbook: https://nocodo.com/playbook/ https://nocodo.com/playbook/