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.

That would only be a minor marker. A major marker would be whatever the Chinese equivalent(s) of Amazon are (Alibaba? etc.) going that route successfully. From academic / industrial conference presentations it appears Chinese services are banking on automation far more than an entity like Amazon does.

That being said, I don't know what exact state the industrial automation technology is there and I can only extrapolate (or do websearch, which didn't lead to enough details; I only found things like https://www.youtube.com/watch?v=JnUGgc8R3ng).

When something like https://www.allegrohand.com is mass produced and used industrially, I bet the last mile (meter?) would change a bit, and full automation would be easier and less finicky.

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.

I am still not getting the point or we are talking past each other.

When I am providing information for humans, I CAN go with semantic HTML (that 9kB Markdown becoming maybe 10KB semantic HTML). I can also go with "framework" layers and turn that into a massive 1MB crap which when rendered by the end user's browser maybe shows most of my content plus ads plus supply chain attacks I unintentionally pulled through with one of the "framework" layers, ahem, nodeJS, ahem.

When I am providing data for both humans and AI agents, XML and other formal data formats might be good choices. If the data happens to be mostly text, then HTML and Markdown both work, but HTML is easier to compose (with programs). If you don't need composition at all, markdown or plain text are obviously easier to hand-craft.

Only in the last scenario, where you don't need to combine information and are directly writing snippets of text, Markdown comes out as a decent option. I honestly don't have a clue how often that happens in practice. Maybe for casual writers (which may be a big market that I am blind to)? As soon as I want to put in a plain table in the data, Markdown gets in the way.

I found HTML itself works [slightly] better with some LLMs (that I happen to frequent). So, when scraping, I parse the resulting html, simplify it, and produce simpler html contents (closer to semantics of what I guessed the real content was). Given processing tools for html are far more mature, I tend to keep content in semantic, low structure html.

We are comparing different things.

I am comparing expressing information in semantic HTML or in Markdown. HTML doesn't bloat it much, and it is easier to work with (programmatically in python, ts, go, java, etc.; including parsing and composing and formatting). I am not talking about web apps, which commonly have more "app" than "information".

And the ratio is really closer to 1.1x tokens than 1.2x, unless the information you are expressing is highly structured. Typically 1 structural element (html tag, markdown marks such as ###) ends up being each 1 token. HTML often has the matching closing tag, and that is really what the difference in number of tokens boils down to. Feel free to run your own tests and compare (I ran a few and it was within 1.09-1.14x).

I am not sure if that is the main value add. I have repeatedly heard that taking responsibility and being on the hook for the decisions (even if AI hands you the decision and all the research and homework that went into it) is the most important feature.

I guess starting with and/or developing a good network is one of the main ways they can gain the confidence for taking responsibility.

Aah, I thought we are talking about prompting or providing information to AI agents in either html or md form, and comparing the two.

Assuming that is what we are talking about, HTML is easier to work with than Markdown, unless you are writing it by hand. That is, composing semantic HTML is more ergonomic than composing a Markdown formatted document from components / snippets, programmatically. The libraries are just better and more versatile in most programming languages. Typically you go from HTML or Markdown to AST, then you compose them to end up with the final tree, then you format the tree to HTML or Markdown. LLMs treat them basically identically (context in HTML or context in Markdown), so I have ended up forming complex prompts / context parts using HTML.

No, it's just that I wasn't very clear.

HTML I can view in any browser / webview / etc. Good markdown viewers are fewer / more special, or end up translating md to html for display.

And by composing, I didn't mean writing by hand. We are talking about prompting, right? Or that is what I thought we are talking about. Composing HTML "components" into a final prompt HTML is easier than composing markdown snippets into the final prompt. That is because with HTML there are several ergonomic libraries to parse HTML to AST and to format AST back to HTML. The libraries (for parsing to AST and back to strings) are more limited with markdown.

Is that even true? I most often use HTML. HTML is about 5%-20% more tokens than a similar Markdown. As a rule of thumb, the number of tags/structural tokens doubles, when going from markdown to html, while the rest don't change much. On the other hand, I can view HTML without any extra/unusual tools. And composing HTML when I need a bit of structure is far easier than composing markdown.

Accurate short answers / text are always harder than long answers, for human or AI. I know several authors and editors who write a lot longer at first, then spend a multiple of the initial time compressing it via a back and forth process to something dense. Sort of like weaving the initial threads.

I found this can work with AI. You get it to generate a lot more at first, and then do several passes over it to compress and squeeze out the noise while keeping the core information. With AI, at least with my prompts, it takes some effort (on my end) to get it to really really cut down the noise and not cut everything out.

If that is confusing to you, you are probably not ready for politics :-) Politicians act with hypocrisy or twisted plans (where the most straightforward conclusion is not necessarily the truth) all the time. Random example from yesterday: the same person who said 19 T deficit is too much before being elected, contributed to moving the deficit to above 40 T.

However, I also highly doubt Schumer would be in Epstein files. People seem stuck on the meme that being in Epstein files is the main reason why someone acts one way or another. This degenerate over-simplification has to stop.

This has been one of the billion(s) dollar questions of 2026. There have been a few approaches emerging throughout the year (heuristics to hard-divide work, using better languages with dependable contracts, task management protocols, and organizational agent roles). None has won so far, though, but some appear (or claim) to be close.

I mildly disagree. You still have to validate what the browser gives you. The user could have edited the "strong contract" using browser dev tools.

So, let the user type, then validate in javascript if you want instant feedback (by changing colors, say, to red / orange), but ideally don't fully block it from being seen by the server. And do the real validation on the server side. This is what I found to be fairly robust, while allowing mitigations if a bad rollout breaks something (delivering to clients is slower than updating something on the server side, most often).

The theory is trivial for anyone with a Number Theory background. That's not the point. Picking a good and interesting problem and going all the way to an elegant optimal solution, AND presenting it well, is all that counts. Without the good presentation and proof, it could look like a hack / weird trick to a random reviewer. I have personally seen a few good algorithms of this sort being dismissed in codebases because they were hard for people to understand (or more precisely, the author hadn't been skilled / diligent enough to leave a good demonstration linked in the code).

I wish there was a place for good algorithms like this, where, unlike plain wikipedia, the good visualized proof could stay and serve. Or perhaps there are such places and I don't know about them.

Bret Victor did a bunch of work around visualizations ~12 years ago (IIRC) for teaching and showing math, but I am not sure if there was any following on that path.

...didn't have the vocabulary...

That is exactly the key or the sign there. Even with a couple of decades of engineering expertise, when I try to do / research something that I don't know enough about, I find myself in the exact position of not having the vocabulary.

To the point that I sometimes have to ask the AI "nicely" to cut the pleasantries and be ruthless against nonsense, whether from its/their side or from mine.

They have been on a path to nuclear weapons in two weeks... for 30 years. What's new?

Jokes aside, nukes are not that much of a deterrence these days. The moment you use them you get destroyed yourself. On the other hand, armies of smart drones and bots would win wars the way even ground forces can't. Why would anyone in this day and age invest in nukes is beyond me.

A nuclear Iran would eventually lead to a nuclear middle east, including all the ISIS and Al Qaeda types, which would be extremely dangerous for the whole world. Better not to have any nukes in the whole region. The good thing is that both countries can totally disrupt each other even without nukes. So, I believe, a stable but competitive equilibrium would/will eventually reach on its own, if external forces stop bringing fuel to the fire.

I have worked with many Israelis and Iranians... and I can hardly tell them apart. At least the ones in the US think almost exactly alike. And from my perspective neither are actually very religious.