Robotics for picking and the general feasibility of grocery delivery in the US.

Ocado is good because their stock levels are far more accurate than the other supermarkets for online ordering, so you don't get as many substituted/missing items. This is sort of a side effect of having dedicated picking facilities Vs "real" supermarkets. I would not be surprised if they "lose" less stock as well compared to in supermarket fulfillment.

Then you have "is online grocery good in the US"? There's a lot of areas of the US that have reasonable density for this kind of service imo, and the road infrastructure is generally far superior to the UK which negates any loss of density (as you care about time between deliveries, not distance per se). I imagine the much better parking options in most suburbs in the US also helps efficiency (it's an absolute nightmare for a lot of the online delivery cos when there isn't off street parking in the UK and they have to park pretty far from the drop).

It sounds to me that Kroger just messed up the execution of this in terms of "marketing" more than anything.

I had the agent scan the UX of the app being built, find all the common flows and save them to a markdown file.

I then asked the agent to find edge cases for them and come up with tests for those scenarios. I then set off parallel subagents to develop the the test suite.

It found some really interesting edge cases running them - so even if they never failed again there is value there.

I do realise in hindsight it makes it sound like the tests were just a load of nonsense. I was blown away with how well Claude Code + Opus 4.5 + 6 parallel subagents handled this.

Like I prefer Opus 4.5 and Gemini 3 to the open weights models, but if Anthropic or Google upped the pricing 10x then everyone would switch to the open weights models.

Arguably you could say that the Chinese labs may stop releasing them, true, but even if all model development stopped today then they'd still be extremely useful and a decent competitor.

What’s the cost to run this stuff locally, what type of hardware is required. When you say virtually nothing, do you mean that’s because you already have a 2k laptop or gpu?

Again I am only asking because I don’t know. Would these local models run OK on my 2016 Mac Pro intel or do I need to upgrade to the latest M4 chip with 32GB memory for it to work correctly?

I've seen unbelievably complex logistics logic coded in... WordPress templates and plugins to take a random example. Actually virtually impossible to figure out - but AI can actually extract all the logic pretty well now.

what do you think "AI" is trained on exactly?

this is why they need a senior/seasoned developer behind them. for things that can simply be learned directly (e.g. from man/docs) it rocks, without guidance. for other things it needs guidance

Often these SaaS tools are expensive, aren't actually that complicated (or if they are complicated, the bit they need isn't) and have limitations.

For example, a company I know recently got told their v1 API they relied on on some back office SaaS tool was being deprecated. V2 of the API didn't have the same features.

Result = dev spends a week or two rebuilding that tool. It's shipped and in production now. It would have taken similar amount of time to work around the API deprecation.

Every SaaS feature in my experience ends up being a mess due to having to support a billion use cases, and figuring it out is more trouble than its worth, might not be able to do what you want, might be buggy.

But even if you do all that stuff, you end up with a mess that can be replaced with 5 lines of shell script. And many more people know shell scripting than figuring out the arcane BS that goes on inside that tool.

It's the eternal lowcode story.

> 'doesn’t make the beer taste better'

I'd say it did. Having a CI/CD pipeline where you don't have to wait for other people's builds, the build logic is identical to what's running on dev PCs, and everything is all-around faster, and more understandable (you can read the whole source) makes testing easier, and surprises less frequent.

All in all, making a hour-long CI/CD turnaround time into 5 minutes or less has been an incredible productivity boost.

Internally it gives us a competitive advantage of the data being in our system from the beginning of the pipeline through the rest of the system where the data would be needed anyway.

The idea here, however, is that machine developers are changing the calculus. If you need more machine developers it takes, what, a few days to produce the necessary hardware? Instead of 20+ years to produce the legacy human hardware. Meaning, for all intents and purposes, there is no observable limit to how much software machine can create, driving the cost towards zero.

Yeah, sure, the tech still isn't anywhere near capable enough to reproduce something like Salesforce in its entirety. But it is claimed that it is already there for the most trivial of services. Not all SaaS services are Salesforce-like behemoths. Think something more like patio11's bingo card creator. It is conceivable, however, that technology advancement will continue such that someday even Salesforce becomes equally trivial to reproduce.

Maintenance is not a meaningful cost unless you also want to continually have the software do more and more. That could tip the favour towards SaaS — but only if the SaaS service is in alignment with the same future you wish for. If you have to start paying them for bespoke modifications... Have fun with that. You'll be wishing you were paying for maintenance of your own product instead. Especially when said machines drive the cost of that maintenance to near-zero all the same.

It will not be. Even in this fairly broken state of affairs we are currently in, most non-technical people I spoke to already say that they have too much apps and too much machines with "intelligent" features.

And IMO when we have machines that can crank out a complete-but-better Salesforce, our civilization and race would be in an entirely another level and we would see such things as toys. Who needs that antiquated procurement and tracking expenses software, where's our 174th fusion reactor? What is even that in fact? Oh you mean that nail-sized addon we put on our main processing unit? Yeah we're not interested in ancient software history now. We need more juice to capture those gases around Jupiter for the wireless beaming of energy project! Our DAG-based workflow solver and the 5 AIs around it all said we can't do without it.

...So of course nobody wants to pay programmers. We've been viewed as expensive and unnecessary since the dawn of time. A necessary evil, more or less. But your last paragraph captures why many companies need them -- bespoke solutions. You can only add so many cloud services before your normal staff starts making mistakes on an hourly basis because they have to reconcile data between multiple systems whose vendors will always refuse to make integrations.

And even if many try to have their cake and eat it too -- i.e. have an IT friend they call only for those bespoke enhancements but only pay them during that time and not every month -- then this service will simply become more boutique and expensive, mostly compensating for the lack of salary. You'd do multiple stints for the year that would cover all your expenses and normal lifestyle, it would just not be through a monthly paycheck. Why? Because I think a lot of people will exit programming. So the law of supply and demand will ultimately triumph.

...Or we get a true general AI and it makes all of this redundant in 5 years.

It implies that there will be no need to share libraries (which is said including things like networked SaaS services). You can have your legions of machine developers create all the code you need.

Let's face it, sharing code sucks for a long list of reasons. We accept it because it is a significantly better value proposition than putting human labor into duplicating efforts, but if that effort diminishes to almost nothing, things start to change in a lot of cases. There are still obvious exceptions, of course. You probably couldn't throw your machine developers at building a Stripe clone. It's far more about human relationships than code. But bingo card creator?

It says nothing about creating software nobody wants or needs.

For anything that is billed by the human, O365 is the benchmark. I’m not paying some stupid company $30/mo for some basic process, I use our scale to justify hiring a couple of contractors to build 80% of what they do for $400-600k in a few months. Half the time I can have them build on powerapps and have zero new opex.

If they were a little more chill then I'd think they could make much more money. I personally would pay a few services, even as an individual, right now, if I knew I could always get a good database / JSON dump of everything at a 5-minute notice, and build my own thing on top of it.

They don't get this psychological aspect at all.

I really need to learn to look at an even bigger picture.

We've got an backend pipeline that does image processing. At every step of the pipeline, it would make copies of small (less than 10MB) files from an S3 storage source, do a task, then copy the results back up to the storage source.

Originally, it was using AWS but years ago it was decided that AWS was not cost effective so we turned to another partner OVH and Backblaze.

Unfortunately, the reliability and throughput of both of them isn't as consistent as AWS and this has been a constant headache.

We were going to go back to AWS or find a new partner, but I nominated we use NFS. So we build nothing, pay nothing, get POSIX semantics back, and speed has gone up 3x. At peak, we only copy 40GB of files per day, so it was never really necessary to use S3 except that our servers were distributed and that was the only way anyone previously could think to give each server the same storage source.

While this isn't exactly what the OP and you are talking about, I think it illustrates a fact: SaaS software was seen as the hammer to all nails, giving you solutions and externalizing problems and accountability.

Now that either the industry has matured, building in-house is easier, or cost centers need to be reduced, SaaS is going be re-evaluated under the context of 'do we really need it'?

I think the answer to many people is going to be no, you don't need enterprise level solutions at all levels of your company, especially if you're not anywhere near the Fortune 1000.

Nobody would hire the JP Morgan IT team to run a dentist practice IT workload. Likewise, AWS can save you money at scale, but if your business can run on 3 2U servers, it should.

Now, that's not exactly the same thing, but their paucity of skills made them terrified to do something like this before, they had little confidence they could pull it off and their exec team would just scoff and tell them to work on other revenue generating activities.

Now the confidence of Claude is hard to shake off of them which is not exactly the way I wanted the pendulum to swing, but its almost 500k yearly back in their pockets.

Especially for collaboration, access controls, etc. Not to mention they could do with unit testing.

That’s also the reason that so-called “Shadow IT” exists. Teams will do whatever they need to do to get their jobs done, whether or not IT is going to be helpful in that effort.

Where it might not be obvious is that IT in this context is not just pulling wires and approving tickets, but is "information technology" in the broader sense of using computers to solve problems. This could mean creating custom apps, databases, etc. A huge amount of this goes on in most businesses. Solutions can range from trivial to massive and mission-critical.

My view is that it's not a failing, any more than "software development can't be estimated" is, but a fact of life. Every complex organization faces the dilemma of big versus little projects, and ends up having to draw the line somewhere. It makes the most sense for the business, and for developer careers, to focus on the biggest, most visible projects.

The little projects get conducted in shadow mode. Perhaps a benefit of Excel is a kind of social compromise, where it signals that you're not trying to do IT work, and IT accepts that it's not threatening.

There's a risk, but I think it's minimal. Risk is probability times impact, measured in dollars. The biggest risks come from the biggest projects, just because the potential impact is big. Virtually all of the project failures that threaten businesses come from big projects that are carried out by good engineers using all of the proper methods.

The team that needs it ends up managing things itself without central IT support (or visibility, or security etc..)

Think being given a locked down laptop and no admin access. Either get IT to give you admin access or buy another laptop that isn't visible to IT and let's you install whatever you need to get your job done.

The latter is often quicker and easier.

You have to remember that an SaaS, just like shrink-wrap software, reflects someone else's model of of a process or workflow and the model and implementation evolve per the timeline/agenda of its publisher.

For certain parts of certain workflows, where there's a highly normative and robust industry standard, like invoicing or accounting or inventory tracking, that compromise is worthwhile and we've had both shrink-wrap and SaaS products servicing those needs for a very very long time. We see churn in which application is most popular and what it's interface and pricing look like, but the domains being served have mostly been constant (mostly only growing as new business lines/fashions emerge and mature).

Most of the stuff that remains in a "core sheet" could benefit from the attention of a practiced engineer who could make it more reliable and robust, but almost always reflects that the represented business process is somehow peculiar to the organization. As Access and FoxPro and VBA and Zapier and so many tools have done before, LLM coding assistants and software building tools offer some promise in shaking some of these up by letting orgs convert their "core sheets" to "internal applications".

But that's not an opportunity for SaaS entrepreneurs. It's an opportunity for LLM experts to try to come in and pitch private, bespoke software solutions for a better deal than whatever the Access guy had promised 20 years ago. Because of the long-term maintenance challenges that still plague code that's too LLM-colored, I wouldn't want to be that expert pitching that work, but it's an opportunity for some ambitious folks for sure.

We had this decades ago, it was called dBase, but FoxPro (pre-Microsoft) was great too. Visual For Pro or MS Access were a brutal downgrade of every good aspect of it.

Imagine if today some startup offered a full-stack(TM) platform that included IDE, a language with SQL-like features, visual UI designer, database; generated small standalone binarires, was performant, and was smaller than most web homepages.

There are modern options, like Servoy or Lianja, but they're too "cloudy" to be considered equivalents.

Edit: seems like there's OpenXava too, but that is Java-based, too hardcore for non-professional programmers IMO. The beauty of xBase was that even a highschooler could whip out a decent business application if the requirements were modest.

I think it's about looking at what you're building and proactively suggesting/prototyping what else could be useful for the business. This does get tricky in large corps where things are often quite siloed, but can you think "one step ahead" of the product requirements and build that as well?

I think regardless if you build it, it's a good exercise to run on any project - what would you think to build next, and what does the business actually want. If you are getting closer on those requests in your head then I think it's a positive sign you are understanding the domain.

It would be helpful, as you suggest, to start shifting away from "I code based on concrete specs" to "I discover solutions for the business."

Thanks for the reply (and for the original essay). It has given me a lot to chew on.

See also how all (?) Brits pronounce Gen Z in the American way (ie zee, not zed).

Also, demand wasn't over-estimated in the 2000s. This is all ex-post reasoning you use data from 2002 to say...well, this ended up being wrong. Companies were perfectly aware that no-one was using this stuff...do you think that telecoms companies in all these countries just had no idea who was using their products? This is the kind of thing you see journalists write after the event to attribute some kind of rationality and meaning, it isn't that complicated.

There was uncertainty about how things would shake out, if companies ended up not participating then CEOs would lose their job and someone else would do it. Telecoms companies who missed out on the boom bought shares in other telecom's companies because there was no other way to stay ahead of the news and announce that they were doing things.

This financial cycle also worked in reverse twenty years later too: in some countries, telecoms companies were so scarred that they refused to participate in building out fibre networks so lost share and then ended up doing more irrational things. Again, there was uncertainty here: incumbents couldn't raise from shareholders who they bankrupted in fiber 15 years ago, they were 100% aware that demand was outstripping supply, and this created opportunities for competitors. Rationality and logic run up against the hard constraints of needing to maintain a dividend yield and the exec's share options packages.

Humans do not change, markets do not change, it is the same every time. What people are really interested in is the timing but no-one knows that either (again, that is why the massive cycle of irrationality happens)...but that won't change the outcome. There is no calculation you can make to know more, particularly as in the short-term companies are able to control their financial results. It will end the same way it ended every time before, who knows when but it always ends the same way...humans are still human.

Well, the estimate was higher than the reality, by definition it was over-estimated. They built out as if the tech boom was going to go on forever, and of course it didn't. You can argue that they made the best estimates they could with the information available, but ultimately it's still true that their estimates were wrong.

For short searches, the revenue per token is zero. The next step is $20 per month. For coding it's $100 per month. With the competition between Gemini, Grok, ChatGPT... it's not going higher. Maybe it goes lower since it's part of Google's playbook to give away things for free.