3 ms·

Heh. Interesting article. > Single developer projects can build to the caliber and consistency of large development teams. This has always been true. Good dev

Heh. Interesting article. > Single developer projects can build to the caliber and consistency of large development teams. This has always been true. Good developers, like truly good devs, could run rings around a team of mediocre devs. It’s a multiplier, a team of 10 1x devs will get dominated by a single 10x dev no matter how much AI they use. Nothing has changed here, if anything it benefits the good developers. > At the moment my rig is supported by two subscriptions (Cursor, Claude) that I can augment with Pi as needed. This conflicts subscriptions with an actual harness, doesn’t bode well for the rest of the article… > Recently I learned about prewalk, Can Bölük's technique that uses frontier for the planning phase and first task, then hands off once the pattern is set. This pattern has been known for years and is not attributable to a single person. > Exploration leads to a plan formalized into an explicit DAG (directed acyclic graph) task list. Then a worker takes over, focusing on implementing the DAG one node at a time. Once complete, I bring in the critic to simplify and question what was implemented. Often this phase will push back enough that the worker phase is revisited. But once satisfied, the critic gives way to a promoter, which is my reminder that a job is not complete until you've properly communicated it to others. I’ve tried all these complicated workflows. In the end the best way to use LLMs is to give it some instructions, take a look at the code, and then ask it for changes. At the end, ask it (in a fresh session) to review the changes for bugs or incorrect assumptions and architecture. Rinse and repeat. Anything more complex is over engineering. None of the rest of the article seems particularly interesting. Just more busywork. > HUMANIST SOFTWARE DEVELOPER Uh huh?

alansaber 2mo ago
Is the article slightly naive? Sure. It describes a relatively uncomplicated multi-agent system (which is good). But frontier model handing off a DAG rather than a raw markdown to a cheap model seems like a decent idea. Ultimately, this is about cost saving, not peak performance.
- slopinthebag 2mo ago
  > But frontier model handing off a DAG rather than a raw markdown to a cheap model seems like a decent idea It's not
ittsel 2mo ago
[dead]
porridgeraisin 2mo ago
> Anything more complex is overentineering. For general workflows, I agree. Doing some DAG system is just a waste of time if you don't have a grounded verifier for every node. If you are going to human verify, why make a dag of subagents and waste time? Keep the dag in your head, the way we all did before LLMs. The dag in your head is also much better. For specific workflows however, even this is under engineering. If your specific task or family of tasks can truly be decomposed into multiple verifiable subtasks then you should spend the effort to build that system. It doesn't matter if it's technically worse than the other method because it is basically automatic and incredibly cheap. For complex systems this is a lot of upfront work, but if it is done, then the return is completely outsized. I painted it black and white, but you can of course compose everything.

alansaber 2mo ago

Is the article slightly naive? Sure. It describes a relatively uncomplicated multi-agent system (which is good). But frontier model handing off a DAG rather than a raw markdown to a cheap model seems like a decent idea. Ultimately, this is about cost saving, not peak performance.

slopinthebag 2mo ago
> But frontier model handing off a DAG rather than a raw markdown to a cheap model seems like a decent idea It's not

ittsel 2mo ago

[dead]

porridgeraisin 2mo ago

> Anything more complex is overentineering. For general workflows, I agree. Doing some DAG system is just a waste of time if you don't have a grounded verifier for every node. If you are going to human verify, why make a dag of subagents and waste time? Keep the dag in your head, the way we all did before LLMs. The dag in your head is also much better. For specific workflows however, even this is under engineering. If your specific task or family of tasks can truly be decomposed into multiple verifiable subtasks then you should spend the effort to build that system. It doesn't matter if it's technically worse than the other method because it is basically automatic and incredibly cheap. For complex systems this is a lot of upfront work, but if it is done, then the return is completely outsized. I painted it black and white, but you can of course compose everything.