Syntaf
Joined 11 years ago
Joined 11 years ago
I don’t think the CC’s teams have hidden motives to optimize for token inefficiency as the OP I replied to implies.
A reality where a secret cabal of CC engineers are trying to find the most token inefficient ways to build the best harness on the market sounds quite interesting to me, but not realistic.
I’m much more inclined to believe they just don’t _care_ about cost, and profit is an ancillary benefit to their functionality above all else.
Just recently they released auto idle-compaction for large sessions about to miss the cache window. If they were so profit driven I can’t imagine they’d have built this to begin with, that’s free tokens from your perspective.
I actually disagree here, what matters most is procurement & distribution. You can sell absolute dog water software (see: Teams[1]) and capture a market with the right procurement and distributions pipelines.
The sad reality IMO is that the quality of software matters much less than we (the engineers) would hope it does.
[1] https://web.archive.org/web/20260322032609/https://www.theve...
I'm sure there's some impressive stuff in there that the warp team built but also the second my own _terminal_ tried to get me to subscribe to a monthly plan I uninstalled that shit so fast.
> I used to tell myself that plan mode mitigated that, but I usually ended up mentally glossing over the generated plans anyway.
At a certain point I realized I far preferred delegating the first implementation pass to agents and reviewing the _code_ instead of a plan up front. If you had asked me this question ~2 years ago I'd think anyone would be insane to hand off discretion like this, but frontier models are just so _good_ nowadays.
Let's say you launch 10 working sessions in a day, would you rather:
* Review 10 plans, and _then_ review 10 PRs, and _then_ maybe adjust the approach on 1-2 and merge the other 8
* Review 10 PRs, and maybe adjust the approach on maybe 4 and merge the other 6
The first option just feels like needless attention for the sake of feeling in control; but the reality is that these models are becoming just as good if not better as us humans and our reckoning is here. Our codebase has enough linters, hooks, and guards such that generally the agent just follows our blessed patterns already, so what is plan mode actually doing beyond giving me a false sense of security? I'm still going to read the code anyways.
"Better" in every sense of the benchmarks and absolutely horrible results in my day-to-day work.
The verbosity, goal post moving, tendency to leave work unfinished, over focusing on unrealistic root causes when debugging, etc... etc...
It was the first time I actually pinned my models back because I just could not work with 5 for the price and performance it gave me. Hoping 5.5 is better this time around....
We're using temporal as the foundation for agents running on our platform doing accounting work for clients, it's proven extremely effective and I love how durable workflows are within temporal.
+100 on the technology, but realizing they are also VC funded makes me a little more cautious when it comes to vendor lock in.
Sounds like you're contributing to your own narrative here. The only self-centered douche canoe of a comment I see in this thread is from you.
HN has its share of good & bad, but I've generally enjoyed talking to some of the people on this site; much more than sites like Reddit which imo fit your description much much better.
Also.... who hurt you?
I'm personally skeptical of optimizing for minimal token consumption, the closer to a vanilla setup I am the more confident I feel I'm always getting the best performance out of my models.
Just look at how JetBrains measured rtk and found that while an individual call saves tokens, agents on average perform *more* turns and use *more* tokens to accomplish one task[1]
[1] https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-...
The verbosity of Opus 5 isn't even my issue, it's consistency. For every 10 tasks Opus 5 accomplishes, there's at least one task that Opus 5 does just an atrocious job of, or a debugging investigation that it just completely goes off the rails on.
In my own opinion, a CLI tool is going to be much more familiar ground for engineers -- I wouldn't expect the 200+ engineers at my company to all have read and understood the paradigms of the MCP protocol but I _would_ expect all of us to have a strong understanding of CLI tools and what a good/bad tool is.
Like other people in this thread are also saying, the more you master this skill the more often you'll have people finding *you* to give them their problems, which only makes this easier.
I actually got hounded / insulted on a couple of my last answers for not providing timely responses to their comments on my answer and that was the last straw.