Also see: Oracle

A toy/simplified version lives here: https://github.com/chaboud/goulash

Consideration of mutation rate (a sort of temporal Shannon-ish coding/ordering) lives in there (with some RoPE-friendly structuring). Note: That was a vacation project, not the day job, but similar principles apply even with larger models.

I'm shocked! Shocked, I say!

Sometimes you just want something that works with all the things. That's pandas. But, like the bamboo eaters, it wont be long...

Goodhart's law strikes again.

https://en.wikipedia.org/wiki/Goodhart%27s_law

However, what is meaningful is whether something is able to create usefully adjacent output, like "let's make Minecraft, but with marching cubes, subdivision surfaces, and global illumination... and behaviorally accurate pandas..." (or something like that).

I have an 11 year old, and most of his game ideas are adjacent to other games he's played. He can make those now, or, at least, enough that he can see where it works and where it doesn't.

Compared to a few years ago, that's pretty cool.

By contrast, Claude Code's bias to make assumptions of reasonableness about underlying systems has proven to be immensely frustrating over the last month or two, both personally and at work. I've wasted days on "that was my mistake. I've been reporting numbers on the old architecture because I hadn't enabled the new one in the config" both at work and home. It's immensely frustrating.

But here we are. Wrestling with energetic idiots in model form, wrangled by over-specific harnesses that struggle to stay off of deranged side-quests.

What a time to be alive!

(Note: there's still a huge grammar penalty, so, ugh do think small.)

You are building to solve their problems or open up their capabilities, and if they knew how to do it, they would have already. So listen to your customers for the "why", but use your own judgment for the "what" and the "how" of it all.

And be honest about being differentially valuable. I once had a prospective consultancy customer ask me for a very specific and elaborate piece of software to be built. He'd been thinking about it for years. I dug in on what he was actually trying to achieve, and I realized that small modifications to an existing in-market product would be able to satisfy his actual needs. I connected him with that company, he ended up with exactly what he needed, and they ended up with a high-end expert user as a resource.

Of course, I ended up putting myself out of a lucrative consultancy job, but I don't regret the decision at all. I suspect that most folks on HN feel the same way. Find a way to make a difference, and be honest with your customers (and leads) about what you're bringing to the table. That kind of integrity pays dividends in the long run if you have something truly valuable.

I get into a regular pattern of asking Claude, ChatGPT, or a local model how I'd write a command or do something with some files or a prompt, then going back to the terminal with a mad-lib command and reasoning through it.

So I built goulash. It takes up the bottom four lines of your terminal as a place to comment on your session and suggest commands that you can select by hitting down arrow to select your "future history", staying in flow with up arrow for history in most shells. Want to ask it a direct command question? Just type "# your question" and hit enter, and it will take that inline comment and make a suggestion.

Running a suggested command is always up to the user. Hit down arrow to scroll through suggestions, modify if you want, hit enter to execute.

This is made for running with local engines hosting local-friendly models, like Ollama or LM Studio with gemma4:e4b on a Macbook Air. It relies heavily on context caching to stay snappy, but goulash doesn't block as it thinks or runs. It's a ride-along in the passenger seat.

Have a tweaky command set that your tiny model doesn't know? Use "#@ YourCommandReference.md" to give that gemma4:e4b (or whatever) a guide as a pin for the session, or use it to temporarily style your life (e.g., I have a FarmAnimals.md file that adds a barnyard joke to any comment. Hey... the tokens are local...).

Written in rust, largely with Fable and Opus 5. Tested with zsh and bash on Mac. Check out the repo, or install with "cargo install goulash".

Comments URL: https://news.ycombinator.com/item?id=49135861

Points: 1

# Comments: 0

However, I've been hearing "load-bearing" at least two orders of magnitude more often over the last few months, particularly after uncorking Claude Code for the team.

I don't think it's a dead give-away of AI usage, and I don't think AI usage is a problem. I just think we can introduce phrases into common use by having them be used by common tools. So let's train the models on obscure/archaic terms and see what happens. Heck, we can just prompt it...

If a model couldn't ever do that in the first place, it'll just get stuck.

I work in the "ZeroOne" space, working on concepts and prototypes for things that don't exist in market yet. Sometimes these models crank hard and immolate tokens while grounding themselves on expensive-to-ingest self-developed frameworks. If the results are well judged and the crank-turn latency is low, I'm okay with the cost as long as the model isn't wasting my time.

But when I want to do more boilerplate work, I turn down the model and thinking level and get more traditional about restraining action. For the really hard stuff, I reach for the models that will start a token bonfire in the back yard.

Sandy water at the beach that looks a bit brown? Suspension.

Mining run off that looks like soup and coats everything? Slurry.

What's the Half & Half between milk and cream but for tweaky techniques for fabrication? Slurspension?

Thanks for the openness. I got bit by this one and was, frankly, pretty surprised.

The funny thing about user-facing interaction mechanics is that everyone is part of some minority, and everyone comes with their own sense of what "natural" or "obvious" is. With something this impactful, communicated clarity of behavior will important. Your feature is also doing double-duty, serving as a last net against prompt-injection attacks by giving the user the final say.

(Also, BTW, folks outside of Anthropic are unlikely to be as tooled-up for long-running unsupervised Claude jaunts as you guys. The cost of wild success is wide adoption.)

One thing I'll suggest is that the mechanics of permissions and asking are presently pretty hacker/nerd friendly but simultaneously too-scary and not-scary-enough for non-coders.

Examples:

- Wild-cards on always approve is awesome, but, with prefixes like timeout and nohup, the "thing" that is getting done is buried and largely unexplained to the user.

- Auto is actually kind of a sweet spot (sometimes goes off into the weeds), but the designers and PM's I've been working with might as well YOLO. They have no idea if they're breaking things, but they gravitate between plan and auto mode.

- Fewer permission prompts is great, but it comes after a user has slogged through generation of a data-set to work against, like battle scars for paper cuts. It's the thermostat problem. The signal comes when the user is uncomfortable. And it's a way to learn me, but not me now.

I've had good fortune with Opus 4.8 and Fable just telling the system what phase of my life it's in. Things like "I'm going to go make dinner... Go profile the matrix or configurations and build the dataset for the next two hours while I'm away" have a pretty good hit rate. On the flip side "keep me in the loop and bring me your results before making structural changes" also articulates well with Fable. It will tread more carefully.

And these approaches are the ones we'd use with someone transitioning from SDE1 to SDE2. A little more autonomy, and the grounding in the bigger picture. Can we eventually translate to perfectly judging what the user wants in the moment based on incomplete signal?

No, but I'm glad you're trying. Keep the interaction model clear to your broad set of users, and we'll come along for the ride.

I guess that's the joke.

Heavies have been playing this "pretend internet money" game off and on for decades. In investment analysis, details matter.

Javascript systems have long had polyfills for varied browser feature comparability gaps.

Whether you agree with these, making probing detection via fingerprinting illegal would take away this lever. Making surreptitious tracking via fingerprinting illegal? Even for state actors?

Yeah, that's probably reasonable. If someone is going to wear a tracking collar in exchange for "free" services, a little disclosure makes sense.

Techniques that work for inexperienced engineers with high ability but limited judgment often work well with agentic coding systems.

- Give them clarity of purpose. Why are they doing what they're doing?

- Make explaining it back to you part of the job.

- Give them two-way doors. Make mistakes reversible.

- Put effort into thoughtful refactoring as an actual sub-task instead of just accepting piled on hacks.

- Make your operating rules crisp and make sure they store them in their memories.

- Be accountable for their work. It's not okay to crank out AI Slop and then say "Claude's fault".

We're all Software Development Managers now.

So, micromanage the LLMs if you want to, but you'll be missing out on chances to improve them for your purposes and, more importantly, to improve yourself as a manager.

In the early days of LLMs, we saw the classic hype-driven bi-modality of opinions. Folks were in the "fake news, fad" camp, or they were in the "omg, take over the world" camp.

Those of us closer to the space, with the awareness to know that there was some truth (and a lot of misjudgment) to go around, were in the middle of nowhere. When I co-wrote some driver code with Chat GPT, other engineers (and even one of our directors) told me to keep it quiet. At the same time I had directors and VPs asking me how we could accelerate adoption. For a while, I had access to a cheat code just because I had the audacity to not ask for permission. Folks were sure I would get in trouble for spending thousands per month in LLM operation, but a handful came along for the ride, burning tokens like firewood and learning along the way.

Tokenmaxxing is probably coming from at least a few things:

1. A course-correction for the practiced frugality that kept folks from jumping in and just learning at the ragged edge.

2. A willful and deliberate recognition that the best innovations in the later phases of a disruptive introduction often come from sparks of ideation in concentrations of activity. In other words, we don't know where good is, and we need to find it. (Charitable interpretation from the article)

3. Recognition that, even if they don't know why, leaders and product owners will get punished for not jumping in and, because of bullets 1 and 2, won't get punished for trying and missing. Even if they have no idea what they're doing, they're going to fake it until they make it (or slide into another job).

This last set is where the pain lives. An organization with healthy and increasing AI tool usage will see elevated token counts, but so too will one using LLMs to rewrite wikipedia articles without the letter "m" to keep token counts high. These are pathological behaviors brought on by conflated metrics.

We had discussions about this in the early LLM days, where my old team was looking to ship new capabilities for older products. There was a lengthy VP-level discussion about getting to "80% usage" of the new system vs the old. Because the new system was a superset of the old, I eventually said "we can do that immediately, but it's a cost goal, where we're just aiming to make our business more expensive to operate, rather than a value goal for our users". We didn't adopt the target, but folks were understandably frustrated that they didn't have a straightforward way to measure and report progress.

Tokenmaxxing is, inevitably, a conflated goal, but it's what we have right now. Take advantage of the moment, learn, build, and keep an eye on levers for efficiency.