Hacker News new | ask | show | jobs
by btown 20 days ago
As a counterpoint: in a complex project, Fable's "curiosity" may be exactly what you want for an exploration and planning stage - not just for the orchestrator that turns your prompt into different angles with which to explore, but for each subagent whose task is to search the codebase for one of those "angles." If you truly want no stone unturned, letting those subagents spawn their own discoveries, and recursively grow the surface area of the inquiry, then it's quite reasonable to want Fable throughout.

That said, if your project is "do this well-planned thing on a bunch of things in parallel" then you should absolutely be instructing to have subagents "step down" to less curious models. Their output may well be more cohesive as a result!

5 comments

The curiosity is inefficient though. So many times I have to stop the agent and tell it to just fucking write the code and try compiling it. Otherwise it will fill its entire context tracing through the program logic to derive from the code itself whether the thing it is about to do would work. It completely fails to notice it can just… try.
Everything about LLMs is inefficient. They have their benefits but watching them reason over things that are painfully obvious, that they've literally investigated before (before a memory compaction), never take a step back aand be like 'this is going too slow let me look for a better way', etc. is painful.
It’s got worse though right? Older models from before everyone went off the deep end with CoT don’t do this and just write the code with 1/10 the token usage.

The downside is the code isn’t as good but it is produced a lot faster and more cheaply and often it’s actually fine.

CoT has made LLMs better (say 50% improvement or something) but increases cost by an order of magnitude. That graph is going in the wrong direction and has been for a while now

CoT?
Chain of Thought, according to a quick search
I think I use it differently. I still mainly stick to web UI.

I write a good prompt, paste the code then copy the output code and place it into my project.

So in the end I hand assemble and I only give it what it needs to know so no extra context wasted.

The human in the loop is of course the secret sauce but this way I am highly efficient, no vibecode and I work really fast too. Everything is audited.

This is how I worked with LLMs originally, and I much preferred it. This gave me a much better understanding of the code that I was adding. But, there's no way to keep up with my team like this anymore. It's just too slow when everyone else is working directly in Claude Code.
If the entire team is vibe coding and there is no human audit then there is no way but to vibe code, for sure.

I would also just vibe it if there is no responsibility, but if I do it that way I don't even care what happens with the project.

I get so detached from it that I stop caring and if it has huge critical bugs..I just don't care anymore because it's not my responsibility or my code at all at that point. I'm just there to nudge things along.

Just hook it up to Jira and let the managers add the features then pass it off to QA.

Real engineering is fully automated at that point.

> I just don't care anymore because it's not my responsibility or my code at all at that point

Yep, 100%.

Business has made it clear they don’t care, so there’s no point in burning one’s energy. Throw the whole thing on auto, check out, and go do something else during the day.

> Throw the whole thing on auto, check out, and go do something else during the day.

If that's what you're doing, you're fucked (in today's society, at least). What happens to your job when they figure out that's what you're doing?

Are the QA team bearing the brunt of the unexpected issues, bugs, performance etc or is it business-as-usual?
Amusing that you think businesses still have QA teams.
Wow, this is almost Dilbertesque level of absurdity.
I like it but how much context does it need for a complex program? If you're giving instructions and using its code, I imagine context is being passed back up in an exponential way. If not, and you give it a very thin context every time, how do you manage to prompt it enough?
Avoid making programs very complex. They can grow big and have a lot of features, but stay as simple as possible.

Depends what I want but I can give a completely new context for every generation.

I try to make everything as simple and human readable as possible because I want the audit to go fast.

I think for me I lean towards an audit optimized approach. Everything is still generated but revolves around the human-in-the-loop for review.

It's tuned for the kinds of tasks where "just try" doesn't get good results.

A major complaint with AI code was that AIs struggle with complex codebases, don't respect existing conventions, reinvent functionality multiple times over, etc. So, newer high end AIs are tuned with the "explore/exploit" dial turned towards "explore".

You could probably get it to do things "quick and dirty" with prompting, but that, of course, requires prompting for it.

I get what you're saying, but these instances are of a different type. It is along the lines of "if I pass None for this parameter, will it default to X or return an error?" and it looks, but finds that the actual logic is distributed across multiple files. And so it quickly falls down that rabbit hole.

All the while, it could have just done a two-line probe test and see what happens when it calls the API with "None" for that parameter. Or just assum it would act as expected and wire in debug logs in case it doesn't.

Perhaps what is missing is a better memory/caching layer to avoid doing the same for explorations over and over again.
That is the usual work of high end programmers, right? Growing codebases as consistent, dependable ontologies?

I feel like most mainstream programming languages do this sort of work for their standard libraries and their official docs. Go and Python come to mind, but plenty others do this reasonably well to the point where one mostly doesn’t need to read the implementation code to effectively use the standard library itself.

I use the human-in-the-loop for managing the context.

Give it only what it needs and do things usually 1 file at a time.

Feels like I'm a sort of manual tape editor, if the context was a tape fed into machine, I assemble that and then watch the machine output the results I need.

that's why i mostly use it for asynchronous work, the inefficiency is something i can bear with because the subscription costs are dirt cheap. if it's token-based, it wouldn't make financial sense.
I need the full context window to get the work done though.
Next time it does that expensive scan, run order it to keep or update an index on the codebase. It really helps prevent these expansive scans if you have additional markdown files for LLM navigation.
That's what the person you replied to is saying. You don't need this model.
Fable and sub agents are two different things. There are many situations for which Fable is great, but Fable doesn't have to run in a sub agent. You can use it for your main agent and that works fine.

Or are you saying my sub agents burned so many tokens because they were all using Fable, whereas my main agent could do the same job with a lesser model?

I think the commenter (who is not me) is saying to use Fable as the main agent but then use lesser models for your subagents so that you get the advantages of Fable to plan but then the subagents don’t cost as much, and may be more focused because they lack Fable’s thinking modes.
I’ve heard the proper pattern is to have Fable write a software design doc and then tell Opus to follow that doc strictly in implementation and testing.
I hear that too, but I'm much more ad-hoc about what model I use for what. Opus can be good at planning too, and Fable is remarkably good at figuring out obscure complexities in the code.
But how is that better than a single agent searching those "angles" sequentially?

Unless they are orthogonal they most likely require similar context anyway so multiple sub agent is just wasteful.

If the assumption is that they can be searched in parallel and it takes the same amount of tokens as doing it sequentially. What you would gain is a speed up.

I vaguely understand you argument with the context, however is that not solved by sum agents handing their results in to the planner (or a third agent) to run on them again? I'd assume that's what is happening anyway. Let me know if that's wrong

How do I get it to spend fable tokens on “curiosity” then switch to cheaper models? Preferably based on its own judgment of what model is truly needed.

Using VS code if it matters.

Just ask it to. If you want, you can also give it pointers to how to read .claude jsonl/metadata so it keeps track of usage and self-adjusts. It's not perfect, but it's pretty dang good if you just say 'This project is allotted X% of my 5h limit'.
I never thought of that. Thanks!
doesnt intelligence involve knowing where to start and what to read and not just throwing everything in the bag.

im on local only AI and subagents are only valuable when they avoid polluting the context with extraneous file reads and parallel exploration when fixes are linear.

as OP is on about, subagents burn tokens because they arnt a deterministic intelligent gatherer but like pooluring water into a maze hoping the exit will illuminate.