Syntaf

Totally agree, my last answer was also in 2021; I remember trying to jump back in and just feeling like the quality of questions was so poor and all of the many "homework" questions felt dirty to answer because I'm clearly helping someone cheat.

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.

You’re making a straw man argument out of the nature of what jobs are for, of course they are to help a company make a profit.

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 don’t feel like reality is so interesting that CC devs are sitting in a room theorizing how to extract the most profit from their users.

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.

> they care about a product that works reliably.

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 heard some chatter about Warp some six months ago and decided to give it a try. Blew my mind that a terminal with an LLM wrapper side-panel raised $80M

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.

+1 to a lot of what you said here, especially this:

> 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.

Yeah if anything Opus 5 taught me how little benchmarks mean to the actual real world performance of these models.

"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....

Absolutely love temporal, but pretty shocked to see they have a $12.55B valuation.... feels nuts?

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.

> It's a place for assholes

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?

Yeah this article is quite shallow after having read it; delegating to a remote sub-agent sounds novel but how does it _actually_ perform?

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-...

I've almost entirely stopped using Opus 5, at least with Sonnet I know what i'm getting -- Fable for the complex stuff and Sonnet for the precision changes.

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.

I think this article posted to HN last week did a better job explaining things IMO https://earendil.com/posts/what-is-a-harness/

One of my favorite articles posted here for this year, it's a great read and really gives you an idea of just how dysfunctional azure is.

I don't have a strong argument for or against using MCP, it honestly comes down to familiarity.

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.

Great article and super relevant advice. As building becomes easier and easier in our career those with the agency to find problems worth solving become x10 more productive.

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.

Sorry I can't share what we're doing here directly!

I will however say that this page alone does a pretty good job of illustrating what an agent harness might look like: https://docs.agno.com/tools/overview

* System prompt

* Tool calls

* Model definition

Everything else (guards / etc) can just exist as code abstractions between the agent layer and the tool layer.

It’s actually encoded in an abstraction that we call “gates” which run before any tool call an agent makes, this allows us to prevent the tool call from happening and return a cited code + explanation on why their tool call was not executed

https://docs.agno.com/tools/overview

Yeah the CLI can provide schema for commands via the usual ‘—help’ syntax, so agents are able to discover + explore commands on their own.

As for an example: if our agent wants to book a journal entry to cash accounts for a client, it MUST provide receipt and directly link the transaction from the clients bank feed, if it attempts to do so without the requisite information we deny the tool call and ask the agent to escalate back to the client for proof of receipt.

Often times this results in the agent not doing the work and instead sending a message back to the client asking for proof of the transaction.

For humans on our platform there may be valid situations where we’d want to allow this, but for our agent this is a hard guardrail thus why it’s not just standard validation for any JE posting on our platform.

I’ve been working on a harness for accounting agents at my job recently and it’s been a pretty interesting experience.

We originally started with building a CLI tool so our LLMs could more easily interact with our platform. I cannot recommend enough the value of having an internal CLI. It’s both fun to build and extremely useful for agents.

We paired this with skills initially, but found that the way folks built skills was often too prescriptive and limited to the authors own specific function in the company. A 2k line long skill suffers from the same gaps as we do, if an agent is just following a laundry list it’s less likely to reason about the request it’s doing.

So we instead asked ourselves: what if we just _let_ the agent reason about the work to be done and only provided the tools + guardrails to gather context and perform accounting work?

Turns out frontier models are GOOD at what they do, they outperformed our highly prescriptive skills and were able to work across a larger set of tasks even without instruction on how to do those tasks.

It’s a breath of fresh air from the decade of CRUD I’ve worked on, harness engineering is very neat.

With a whole separate LLM? FWIW you can also consider using something deterministic like vale.sh [1] , it's pretty easy to write prose violation plugins [2]

[1] https://vale.sh/

[2] https://github.com/Syntaf/vale-llm-slop

TL;DR `hop claude/57680` will cd you into the worktree for the branch.

I've wrote this tool so I can do things like `hop claude/57680 && vim index.ts` and quickly edit a file on a branch without having to ask claude to make small adjustments.

Found this pretty nice to work with when you have a lot of worktrees going and otherwise would need to be tracking down where to cd into a given worktree to find and edit a file on a given branch.

Totally agree with your framing here, but that is also what I fundamentally consider "good" code -- it's code that solves the problem that your customers/business needs without making it _harder_ to solve the next problem.

There are valid situations where the best code you can write is code you never look at and throw out the next month; there are equally valid situations where the best code is well thought through and reasoned abstractions for an area you expect to become core to the business in the near future.

Fair point! I edited my comment, A&D -> Architecture & Design

> bad engineers were always a liability

This part of the article hits home for me. With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.

I am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it. I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.

Earlier in the year I put together a talk for my company on what the future of architecture & design means for us in the career, I'm very proud of it and will share here in case folks have their own thoughts to share on the topic: https://youtu.be/SIZrt9Rt05Q?si=W57eirniWmoSFeBu

My company is migrating repositories over to a self-hosted forgejo instance, currently very jealous of the engineers working on those migrated repos.

There was a great article awhile back that shed some light on just how dysfunctional azure is as a platform: https://news.ycombinator.com/item?id=47616242

If I had to guess it's because Github is sitting on top on infrastructure held up by toothpicks and duct tape

Hey HN, recent hype around the ASD-STE100 standard inspired me to think about a more deterministic way to lint my agent's prose. This vale style is inspired by the english standard and is an attempt at providing a standard for teams to lint their agent's prose against.

So let me get this straight, in this article we have:

- One guy selling shovels (AI “tools”) to clueless people

- Another guy who started and then folded his business in two months

- A chatGPT wrapper (it’s literally called chatPRD)

This is our evidence of the rise of solo million dollar companies? There are surely businesses out there but is AI really the driving reason here?

I’m convinced there is an entire sector of AI now built on scamming clueless people into thinking they can build their own AI B2B SaaS and purchasing tools & “things” without realizing building the product was always the easiest part.