Hacker News new | ask | show | jobs
by prohobo 5 days ago
I never said you have to turn your brain off to feel the limitations.

Actually, for more complex work I think it's pretty common to spend a long time crafting some elaborate prompt, and then arguing with the agent for 10-20 turns, getting a "passable" plan, accepting it then arguing with the agent every step of the way because it's doing it wrong. It's incredibly frustrating, even with models like Fable.

Even after that, I'll often find out during later sessions that some feature that was supposed to be deprecated was actually silently left in "because I wasn't sure you wanted it completely gone" or something.

I agree that exploring a codebase through prompts is actually quite nice! But the mental model you get from that is almost always warped - you have to supplement that with reading the code, where 9 times out of 10 you will find some kind of discrepancy that you're unhappy with.

Why not optimize that process?

3 comments

Your experience is night-and-day from mine. Both myself and the AI correct and remove each other's gaps in understanding. There is never what I would call arguing. Disagreements are resolved by back and forth discussion and reaching consensus.
This sounds like not the best workflow. If your prompt is that long, you may not be spending your time very efficiently.

Splitting problems into smaller problems is huge. You want a concrete idea that you still own. Only tell an agent to do something you know it can nail - this will likely be one subsystem. The subsystems and how they talk is on you.

I agree, I tend to give a high-level concept for what I want done first, and then break it into smaller tasks. That said, there's almost always a misunderstanding within the smaller tasks anyway, which I have to test to find out about, then ask the agent to fix.
This does not match my experience at all. I use Fable as an orchestrator, and describe the end goal I want to achieve. It investigates the current state of affairs, and determines the smaller work units needed. We discuss each one, and eventually ticket it out in Linear. By that point, each ticket has all the relevant details, scope, decisions and acceptance criteria.

Then I have it write prompts for implementation agents based on the ticket. These agents are almost always Opus, except for the most complex issues. The prompts contain broader contextual details (like what other tickets might be worked on in parallel, the boundaries, operational/environment constraints, and so on). Each implementation agent starts in plan mode and uses a skill I created called "super plan". Super plan has the agent write the plan and then have it adversarially reviewed by three subagents, and hardened based on their feedback. I then read that plan and greelight it. Once the agent is done with the implementation, it then uses three subagents to do a code review of different aspects (like test quality, regression risk, security, etc.) and incorporate the changes. Then it does a live QA in the browser (if there are UI changes) to make sure the feature has good UX and the UI works as expected at different breakpoints and so on.

Then the Fable orchestrator does one last code review and gives a ship/no-ship verdict, along with a 1-10 rating.

This works incredibly well, and is almost completely hands off. I make all the major decisions and review the results. I never find myself "arguing" with the orchestrator. I might sometimes get frustrated at the implementation agent but that's mostly for UI fidelity issues and honestly pretty rare these days.