There's no advertising here, there's just aggressively trying to drain each person's wallet as much as possible and seeing how far you can get before they change behaviour.

One example: my friend and I both requested rides using the same app, standing next to each other to the same street in the same neighborhood 3-4 miles away. He owns a car and rarely uses car services, I do not and it's my primary transportation. The quoted cost of his ride was half mine. It was shocking.

Something like the next iteration of Cerebras hardware paired with HBM for KV cache + HBF for weights could be incredibly strong here and much more likely to see away to make into a product with some lifetime compared to "let's bake a old model into a very, very large number of custom chips, design all the interconnects from scratch, and pray". Maybe in 10-15 years once this all matures.

Now if that works out that means in '29/'30 we could easily see a run on NAND that's even worse than the current DRAM price issues, on top of the current increases. Fun times if that happens.

Let's say a magic set of chips comes along to host this. Maybe it's 2-3x more efficient in size and power. You're still talking a form factor that's a good chunk of a rack, draws tens of kilowatts, and could actually be sold at a similar if not higher price point because the OPEX is so much lower.

It may be useful but it's certainly uneconomic to spend >$1m to self host the model, plus ongoing power and maintenance costs, plus the cost to adapt whatever building you're in to be able to power it.

It's entirely possible for a 2-3 month project if one senior person was left the hell alone to do it to take a dozen people five years.

Small plants in the middle of nowhere, especially municipal ones? You're lucky if it was designed this century and not 50-100 years ago. Everyone's just trying to keep old stuff running at absolute minimum cost.

It's quite reliable, and does not require paying for a team of people who wants to try new things. Once this happens for a long while there's no one in the building left who's going to advocate for change, since the only thing all that fancy new technology brings is the next 5 years of nobody getting a bonus because operational metrics weren't being met anymore.

You have to try really hard to convince these people that the thing that they have seen on a daily basis to work just fine for the past twenty years is no longer good enough, because all their evidence says that it is. And you should also listen to them much more than people who just want to use the latest thing typically do, because they do have the decades of experience seeing how things actually fail.

1. Line of credit - we are not billed until we take delivery of tested product. 2. Willingness to handle high mix, low volume products. One product line example: a dozen SKUs with 95-98% parts in common on 2 PCBs, a single set of parts (that we aren't billed for up front) and quoting to build 20 of SKU 1, 50 of SKU 2, 10 of SKU 3, etc. without charging 2-3x the price.

We manufacture in the research / test equipment / defense space and I've heard similar things from other small hardware companies that are like us.

A new 2010 Toyota likely wouldn't even be legal to sell today in many jurisdictions, and this is in fact one part of the problem.

Another part of the problem is that all the big automakers need to design a new car roughly every 5 years in order to keep from losing the ability to design one at all, as people age and retire. What's really been settled on is that "minor updates every year and a major update every 5-6 years" actually does work in terms of keeping know-how to design these things, as well as handle supply chain problems.

For example, if a chip you need goes EOL and you have to redesign around that, it's much better to have that happen in the last 1-2 years of your manufacturing, you do a last time buy to get through that last year, and move on. Much harder to do on a longer lifecycle: that 2010 design, sold new in 2026, and operated until 2040+. How many suppliers go out of business over 30 years, or stop making a critical component?

This is especially useful when projects are wound down. Let's say you've contracted to an org for support or management on a project that you want to kill, you've already obligated some amount of funds, and you don't really want to make that organization angry by ripping millions away from them (the pool of contractors is not large). What to do? Well, you could take Joe and give him a raise by suggesting he work for the contractor instead of you directly. Money's already spent, anyways. So you save your own money that you can use for your pet projects or whatever, Joe gets a raise, the contractor doesn't get a termination that pisses everyone off. Everyone happy, right? Smh.

What about the $10k/year offshored employees that are getting replaced by AI call centers? If that were the break even, then once you close down the whole building and develop the systems to not need them, then how much would inference costs have to go up before all that gets unwound and handed back to humans? It's more than you think - there's real margin there.

With your gym, for example, when it's new, you can do all the work you want. Once people are using it every day (especially if it's a 24/7 facility!) how exactly do you get in to do major work without making a bunch of people annoyed that half the gym is out of service for three weeks? You don't, until it gets to the point that people would prefer the downtime ... and this takes a surprising amount of grime.

If the break-even price to actually provide the service wasn't actually economic compared to humans, would there be nearly as much of a market? That's the real question. OpenAI is basically betting that they can live long enough that AI systems get built around them, which creates enough of a lock-in that they still have customers when prices increase by a lot.

This has given really good results in terms of helping decide whether to extract these helper functions or not - they have to both be memorable enough in name and arguments that the code calling them can understand what's going on without always having to dive in, and also provide a meaningful compression of the logic above so that it can be comprehended without having to jump across many hundreds of lines.

2. Brand quality went down to equivalent or less of no-name dropshipped goods in order to keep similar dollar prices for goods.

3. Cost of real estate spiked incredibly, putting even more pressure on retail margins.

4. American logistics is seriously good, in cities 24-hour delivery can be common even for small or inexpensive things.

5. Once there wasn't a quality or convenience reason to prefer the shopping mall, many were already struggling quietly, they just hadn't run out of cash yet.

6. The pandemic happened right as all these things converged, accelerated all of them, and wasn't really recoverable.

This allows for a business model for the authors to provide contracted support for the product, and keeping SQLite as a product/brand without having to compete with an army of consultants wanting to compete and make money off of their product, startups wanting to fork it, rename it, and sell it to you, etc.

It's pretty smart and has, for a quarter century, resulted in a high quality piece of software that is sustainable to produce and maintain.

It would not be unusual for the person being told to write the process document to be brought into a room with a notebook, be shown written or electronic materials in the room, take notes in a provided notebook, have that notebook be handed over after the meeting for a (non-technical) security review, then receive the notebook pages some days/weeks later and have those notes be what is used to develop the document. Security culture is good for security but bad for error-free processes involving people.

And it turns out the quality of output you get from both the humans and the models is highly correlated with the quality of the specification you write before you start coding.

Letting a model run amok within the constraints of your spec is actually great for specification development! You get instant feedback of what you wrongly specified or underspecified. On top of this, you learn how to write specifications where critical information that needs to be used together isn't spread across thousands of pages - thinking about context windows when writing documentation is useful for both human and AI consumers.