honr

Exactly. As for the article itself, I would take with a grain of salt as the author's previous company built some sort of software factory. I think we can give them the benefit of the doubt and move on.

With that out of the way, I think trying out developing software-building automation is a great learning experience, regardless of the final outcome. Beside [re]learning various ropes that might have been modernized recently, you are likely to end up with bonus [possibly tiny] helper tools that you can carry into your other software development projects. Or you might learn new [non technical] disciplines around software development life cycle.

It certainly has compaction (since the public launch I assume) and I HATE it. I have some remedies but nothing perfect yet. It never retains ALL the crucial bits. If a conversation runs into two compactions it is often a sign that I have to abandon it and retain whatever I can, to form a seed prompt for an adjacent conversation.

- That should nowadays be very obvious. You start any substantial work by doing research. LLMs are [perhaps surprisingly to some] good at that. They are also pretty good at doing the plumbing. That is a godsent in the hands of a good researcher and architect. And I don't have any qualms if tokens are "wasted" on research or on the precursor work. That doesn't replace reading good books on a subject but it DOES replace finding and filling knowledge gaps.

- But that shouldn't be confused with getting the LLMs to make the decisions. I believe that would quickly ruin a good design, unless the decisions are about truly inconsequential aspects, which are very rare in language and API design.

- I don't believe that (sharing) is to the detriment of LLM providers either. Not realistically. We would build faster and the questions / research directed at LLMs would be more sophisticated. Believe it or not, they can't cache questions as easily as websearch queries. If anything, I believe the more people learn to use LLMs effectively (rather than just to generate slop), the more their usage will be ingrained in daily life. Some of that will be redirected towards current LLM providers. But perhaps more of the economic share will increasingly go to hardware providers, as more and more people will be interested to run their own models.

I have never had a problem with kiwi skins (except when the kiwi is unripe; a natural mat with acids and possibly oxalate. NOPE).

But are you claiming you eat the whole fruit, or you throw out the tiny thorn?

I don't get your point. The planet will not realistically run out of either. The water price goes up, then soler + desal becomes more cost effective, then people get to use the material that covers 75% of the planet's surface a bit more. Similarly, when oil gets more limited the price goes up and the planet gets to keep its oil while people stop being able to afford burning more of it. Or perhaps this was exactly your point.

My personal opinions (not necessarily reflecting my company's):

1. Free-form capitalism is fundamentally incompatible with AI. In other words, competent AI brings a free-form (low regulation) capitalistic environment to total collapse. (This is actually not my own opinion; heard the details from several economists and it makes sense to me).

2. Hiding from AI will not be an option for long. It will affect many jobs (often by increasing productivity at a macro level; it can reduce some productivity here and there, obviously).

3. The concerns about costs of energy (of the current applications) are short term. Follow major Electrical Engineering conferences to see why. In short, several ideas can drastically reduce the energy / token inference costs (some about 100x). Some existing companies are working on those ideas and at least one has a proof of concept (since 2018) and they raised capital to scale, late in 2025. Of course, once AI inference becomes cheap (in terms of energy per token), more hardware will be doing that, so overall I don't know where the costs will go. That is, new applications might become popular, using overall more tokens and eating through the "moore's law" of Inference energy.

4. The only way to prevent mass NEGATIVE disruption on state / country level is to HOLD THE SITUATION IN HAND and fully and consciously take it toward a good end state. Which needs GENIUS level analysis, insight, and execution, from the administration. Some countries are going to fare this better than the others.

Like taalas.com (very recently acquired by AMD), or cerebras.ai (whole wafer is a chip)? As you said, I also think that is one of the main direction many companies (and academia) is moving to.

To me, the legal concerns seem blown out of proportion. If you use open weight models (of dubious origin) to generate code, you can still verify them with code review and tests and other methods, used to verify human output, right? That is still a great win, maybe not as much as having AI write all the code, but that would be a reasonable point in control vs quantity spectrum for most solid and well made products.

But if you let LLMs talk to people (customers, for example) directly, then yes, you need an LLM provider that you can hold responsible.

Haha, darn it, you threw me into a rabbit hole. I hooked M-x doctor to an LLM, and the funniest thing happened. The little piece of sh*t kept pretending to be emacs's own eliza / doctor. It took like 5-6 turns to convince it that I am okay and don't need the pretend psychotherapist "service" anymore.

This year, the migration projects I have worked on were some of the most fun. Migrations have changed from the death-by-1000-cuts that they were, to the which-AI-method-to-best-ensure-100%-fidelity. So, I don't believe the "very hard" part. Obviously it would involved recreating or reshaping many features that very involved in an integration to have a disruption-free move, but I think the complexity is manageable for most companies if they put in some effort.

Compute In Memory has been most of what electronics research (more accurately, the parts I am interacting with) talking about this year. There are a few trends and I am curious to see which ones survive in the market. RAM designers are hot in the market and job openings at the moment.

I haven't been directly involved with any large company CEOs, but the CEOs of smaller companies I have worked with have frequently been constantly dealing with responsibilities from many decisions they took (or didn't block). Some have personality traits that hide the pool of concerns beneath the surface. And a couple were genuinely taking the life in tourist mode (oblivious to any and all concerns beyond the very next steps).

The "AI CEO" problem is not fundamentally different from self driving car responsibility problems. You need a big entity to be on the hook (financially and legally) if you are really going for lowered responsibility on the decision machinery. I think it can work though (but with a LOT of effort), and that might be an interesting startup idea (we provide 90% of the CEO work via AI, you be in control of the remaining 10%, and responsible for maybe 20% of it; our "insurance" covers the other 80% of the responsibility).

True, I have seen that happen many times. When I want short answers, I always clarify that (e.g., give me short technical answer without pleasantries).

I'm often okay if the answer is longer but not hiding the real answer; a couple of paragraphs that I can skim the answer from instantly is okay. When it really buries it I have to follow up to express the format and type of answer I want.

I often compose prompts from various sources (my "AGENTS.md", "CURRENT_TASK", "CURRENT_PHASE", ...). Last year I was composing in markdown and that got very tedious very quickly. I tried various text and text-like formats, and it turned out HTML is already one of the best formats for this, including for an "AGENTS.md" (which I keep in HTML despite the required ".md" extension).

Of course, if you build up your prompt entirely by hand (copy pasting snippets, etc.) you can get away with markdown or plain text. That works okay for some harnesses, but it leaves too much control (or more accurately, opportunity to misunderstand) to the harness.