471–480 of 630 posts
It strikes me that if this technology were as useful and all-encompassing as it's marketed to be, we wouldn't need four articles like this every week
Does something have to be trivial-to-use to be useful?
The failure mode the author describes (implementations that work in isolation but break the surrounding system) is exactly what I see in workshop after workshop. Engineers prompt the LLM with "add pagination to the list endpoint" and get working code that ignores the existing query builder patterns, duplicates filtering logic, or misses the caching layer entirely.
What I tell people: the research.md isn't busywork, it's your verification that the LLM actually understands the system it's about to modify. If you can't confirm the research is accurate, you have no business trusting the plan.
One thing I'd add to the author's workflow: I've found it helpful to have the LLM explicitly list what it does NOT know or is uncertain about after the research phase. This surfaces blind spots before they become bugs buried three abstraction layers deep.
Earlier quoted context omitted.
We're learning the lessons of Agile all over again.
We're learning how to be an engineer all over again. The authors process is super-close what we were taught in engineering 101 40 years ago.
Earlier quoted context omitted.
That's not (or should not be what's happening). They write a short high level plan (let's say 200 words). The plan asks the agent to write a more detailed implementation plan (written by the LLM, let's say 2000-5000 words). They read this plan and adjust as needed, even sending it to the agent for re-dos. Once the implementation plan is done, they ask the agent to write the actual code changes. Then they review that…
I take this concept and I meta-prompt it even more. I have a road map (AI generated, of course) for a side project I'm toying around with to experiment with LLM-driven development. I read the road map and I understand and approve it. Then, using some skills I found on skills.sh and slightly modified, my workflow is as such: 1. Brainstorm the next slice It suggests a few items from the road map that should be worked o…
I just use Jesse’s “superpowers” plugin. It does all of this but also steps you through the design and gives you bite sized chunks and you make architecture decisions along the way. Far better than making big changes to an already established plan.
Link for those interested: https://claude.com/plugins/superpowers
The author seems to think they've hit upon something revolutionary... They've actually hit upon something that several of us have evolved to naturally. LLM's are like unreliable interns with boundless energy. They make silly mistakes, wander into annoying structural traps, and have to be unwound if left to their own devices. It's like the genie that almost pathologically misinterprets your wishes. So, how do you solv…
I've been doing the exact same thing for 2 months now. I wish I had gotten off my ass and written a blog post about it. I can't blame the author for gathering all the well deserved clout they are getting for it now.
Earlier quoted context omitted.
I take this concept and I meta-prompt it even more. I have a road map (AI generated, of course) for a side project I'm toying around with to experiment with LLM-driven development. I read the road map and I understand and approve it. Then, using some skills I found on skills.sh and slightly modified, my workflow is as such: 1. Brainstorm the next slice It suggests a few items from the road map that should be worked o…
This is a super helpful and productive comment. I look forward to a blog post describing your process in more detail.
This all looks fine for someone who can't code, but for anyone with even a moderate amount of experience as a developer all this planning and checking and prompting and orchestrating is far more work than just writing the code yourself. There's no winner for "least amount of code written regardless of productivity outcomes.", except for maybe Anthropic's bank account.
I really don't understand why there are so many comments like this. Yesterday I had Claude write an audit logging feature to track all changes made to entities in my app. Yeah you get this for free with many frameworks, but my company's custom setup doesn't have it. It took maybe 5-10 minutes of wall-time to come up with a good plan, and then ~20-30 min for Claude implement, test, etc. That would've taken me at least…
Earlier quoted context omitted.
>I've never seen it develop something more than trivial correctly. This is 100% incorrect, but the real issue is that the people who are using these llms for non-trivial work tend to be extremely secretive about it. For example, I view my use of LLMs to be a competitive advantage and I will hold on to this for as long as possible.
The key part of my comment is "correctly". Does it write maintainable code? Does it write extensible code? Does it write secure code? Does it write performant code? My experience has been it failing most of these. The code might "work", but it's not good for anything more than trivial, well defined functions (that probably appeared in it's training data written by humans). LLMs have a fundamental lack of understandin…
Here's the rub, I can spin up multiple agents in separate shells. One is prompted to build out , following the pattern the author/OP described. Another is prompted to review the plan/changes and keep an eye out for specific things (code smells, non-scalable architecture, duplicated code, etc. etc.). And then another agent is going to get fed that review and do their own analysis. Pass that back to the original agent once it finishes.
Less time, cleaner code, and the REALLY awesome thing is that I can do this across multiple features at the same time, even across different codebases or applications.