When I was shopping in 2025, this was the only truck with that kind of output.

It's a little cheeky and seems a little undergrad-ish to me, but I wouldn't call that either absurdist or postmodern.

Also what's wrong with the ship of theseus? If _you're_ tired of hearing that kind of argument, that's fine, but why dismiss it? It's thought-provoking at least, and the kind of thought it provokes has, in my opinion, some practical import

Is this true? Code is structured output. At the very least it seems like a question of degree rather than kind.

While the LLMs we're using today are limited to sequenced text, it seems that a model like Jev could excel at coding on a more structural level (factoring, controls) by working within the constraints of an actual language specification and supplemental domain model. I don't know, though -- maybe that's too deep and complex.

On the other hand, there are claims that the best languages for robots tend to be terse (allegedly); I tend to regard a rich domain model (static types, not terse) as a major facet of high-quality code.

Discipline can be linked to system design standards and your review process, and it can be translated to measurable outcomes at scale and over time, regardless of how agents are involved: unplanned work, time to recovery, employee retention, etc. When outcomes like these become your priority, you see that you can't rely on taste alone.

How well would it work for a company that has the kinds of artifacts that you mentioned, but that lacks the quality/precision/accuracy that Hyper might need?

I'm especially thinking about mature companies that don't sell software and that have made a lot of mistakes and memorialized inconsistencies.

Is Hyper just a bad fit for them? Or could there be a path toward refinement and correction that eliminates ambiguities, etc.? For companies like this, Hyper could provide the clarity that such a company lacks day-to-day.

The only reasons to hesitate, imo, are (A) you're worried that it won't perform as well as you need on your servers, or (B) you're scared of npm supply chain attacks.

While the article mentions Moebius, I think this level of praise still merits an extra Incal callout, even if it just serves as a recommendation to those who want more of this stuff: https://en.wikipedia.org/wiki/The_Incal

You're right, it's possible. But you might be both overestimating the ease of onboarding and underestimating the variety of tasks and constraints devs are responsible for.

I've seen Claude knock out trivial stuff with a sufficiently good spec. But I've also seen it utterly choke on a bad spec or a hard task. I think these outcomes are pretty broadly established. So is the expectation that the tech will get better. Waiting isn't unwise.

Broadly speaking, I think this is a wise assessment. There are opportunities for productivity gains right now, but it I don't think it's a knockout for anyone using the tech, and I think that onboarding might be challenging for some people in the tech's current state.

It is safe to assume that the tech will continue to improve in both ways: productivity gains will increase, onboarding will get easier. I think it will also become easier to choose a particular suite of products to use too. Waiting is not a bad idea.

Silent failures and unexplained crashes are high on my list of things to avoid, but many teams just take them for granted in spite of the practical impact.

I think that a lot of orgs have a culture of "ship it and move on," accompanied by expectations like: QA will catch it, high turnover/lower-skill programmers commit stuff like this all the time anyway, or production code is expected to have some rough edges. I've been on teams like that, mostly in bigger orgs with high turnover and/or low engineering standards.

Our scenario: relatively simple monorepo, lots of docker, just enough bash, trunk-based dev strategy. It's great for that.

Is this any better now?