I'm old enough to remember the arrival of RDBMS, once IBM primed the space with DB2.
There was a pitched battle over features like row-level locking as competitors like Sybase, Ingress and Oracle scrapped it out. New features arrived on a monthly cadence, with immense engineering effort behind them. The winners (Oracle mostly) won a great moat which led to them to where they are today.
The fact that so many AI companies can produce amazing coding tools so quickly shows there is no moat, supporting your theory.
That is impossible to fund. At some point someone will decide to stop throwing money on the firepit that's the current business model and then hardware prices crash back to earth as 60-70% of the global demand disappears overnight.
The hardware miniaturization gains have finally dried up, though.
I am pretty certain that the current state of the art silicon feature size won't shrink again for at least another decade or two.
It normally takes about a decade to mature a tech which can create a smaller feature size into something commercially viable for mass production scale, and no further improvements have been in the pipeline for that long now.
So it's like the "next piece" indicator while playing Tetris is just blank.
It is more of a regulatory capture byproduct to prop up an artificial token driven Ponzi scheme.
There is a serious alternative to NVIDIA "AI" hardware dropping out of China in February 2027. There is no moat, but a whole lot of unpaid debts in the near future.
I honestly have no expert knowledge about this stuff. What I say is based only on intuition.
- China is heavily, heavily incentivised to enhance their own chip making
- Looking at the rate Chinas has expanded into just about every single other
space, and from quantity to quality, I just think it is impossible that they
don't compete on equal grounds pretty soon.
- I don't buy the insurmountable moat of TSMC
Reminiscent of tank warfare in WW2. The soviet T-34 was not remarkable in any particular way, but the sheer volumes it was produced in made it a very serious enemy to German tanks. As Stalin said "quantity has a quality all of its own".
I feel that abandoning your car at an intersection and fleeing the scene in front of armed officers as a presidential drive by was about to arrive - in Dallas of all places - could have had far worse consequences.
Wonderful name. You may know this, but Kai means food in Maori. Many words and many, many place names also embed it, e.g Moana == sea, so Kaimoana is seafood.
Yes, I'd like to see the "cheap shade" that could span as far as shown in the pics as well as survive strong gales. It wouldn't be like a cheap shade in your back yard.
As a SaaS vendor, interacting with our customers about SAML usually involves:
a) them knowing what they want because they already have SAML-based SSO and it works for them; and
b) our contact on their side being some unfortunate support dude who got given SAML as their subject area for whatever reason, and who knows very little about it, and who is 4 levels in the org away from anyone empowered to make decisions as significant as moving away from SAML.
As a SaaS customer, interacting with SaaS vendors tends to entail:
1. Finding out a company wants several grand to flip the "allow SAML" switch on the tenant config, and a few thousand a year in additional licensing to leave it on. (I had a vendor both tell me it "takes five minutes" to get it set up, and then quote me $4,800 to "implement" it.)
2. Having to yell at the SaaS vendor for routing the identity connection between two or three other identity providers in different various clouds because, you know "modern stuff". (A vendor I am working with has not less than five different accounts to access various parts of their infrastructure, none of which are connected at all. I assume people there listened to "switch to OIDC" nonsense, completed half the job, and now have OIDC sites and SAML sites forever.)
3. Discovering the SaaS vendor knows how Entra works, how Okta works, and how Google auth works, and having no idea how SAML works. Or OIDC or anything else for that matter.
4. Eventually finding an engineer far enough from the sales and implementation teams who can answer how the product actually works. :D This point is reached after a lot of yelling.
> 1. Finding out a company wants several grand to flip the "allow SAML" switch on the tenant config, and a few thousand a year in additional licensing to leave it on. (I had a vendor both tell me it "takes five minutes" to get it set up, and then quote me $4,800 to "implement" it.)
If I’m paying for at least one Senior to build and support this awful enterprise authentication pattern, I’m looking at around 200k per year in total cost - you damn well bet I’m billing you for it!
The total cost to employee a Senior Software Engineer, and I mean a real one, not some kid with three years experience, including benefits, taxes, etc. easily gets up to 200K in a normal city at a non-FAANG job.
Im sorry if your UK salaries are much smaller, but I’m not P Diddy taking anyone’s piss out here m8!
Not denying that, but if its a full time job for that person to monitor the keycloak machines for a typical SaaS vendor then something's wrong at mill cobber (may have used that wrongly as not English)
It's worth looking at similar industries with enormous electricity requirements such as aluminium smelting, where the plant can be located in a friendly country but the product is owned and controlled back in the US.
Aluminium is often described as "congealed electricity". Ship bauxite to wherever power is cheap and stranded, turn it into metal, and ship the metal out. Here in NZ, Tiwai Point is the textbook case, with London-based Rio Tinto running a smelter on the other side of the world that exists mainly because Manapōuri hydro had nowhere else to go.
AI data centres can be just the same - even more so, since the plant's assets (its chips) are virtually perishables, so there is less concern about assets becoming stranded if the host goes rogue. All the US needs is friendly and stable allied countries with cheap power.
How long will it take to convince them that it is worth it to get into long-running relationships with the US. How long before another populist is elected who will rip up agreements for weird reasons and you have to renegotiate them?
The skills to drive AI are much the same as they were for business analysts in the old days. Domain knowledge, insight into user requirements, knowledge of modern UI paradigms, ability to write detailed, consistent requirements docs/ design docs.
There is a deep bench in the industry of these senior-ish people. Many have left to become baristas, dive instructors or hobby farmers, scarred by the pain of building large complex software systems using human labour and absurd Agile rituals. But they could slot straight back in, it's like riding a bike.
AI development is the new waterfall. Its just that the lower level that the BA hands off to, which used to be roomfuls of devs, is now a superhuman who can implement those designs at lighting speed and come back hungrily for more.
But if by senior you mean someone who is just a junior with more experience, someone who's not really in touch with the business's needs and who just works off stuff fed to them by PMs or the like - then yeah, agreed.
Another thing is that orgs will want to keep around somebody who 1) can be held responsible when things go wrong 2) has a reasonable understanding of the system that's their domain end-to-end 3) can reliably diagnose failures and fix them, regardless of how the code was written.
That's not a role that can reasonably be filled by a junior and management armed with agents doesn't really fit either.
> But they could slot straight back in, it's like riding a bike.
Yeah, not quite. There's a ton to learn about how to control an LLM while it's writing code, and even more to learn about how to manage a set of agents.
9 months ago I was comparing it to running a dev team, but now it has changed and there are practices and processes that are unique to managing agents.
e.g. a team of software devs have the self-awareness to not take a single marginally-relevant point in a spec document and spend 20% of their team effort to build an entire subsystem to meet it without checking. The process and rituals that we used to use to make sure that a software dev team was making progress and would hit the project deadline are now largely useless, but we need new ones to make sure the agents are not heading off into unnecessary rabbit holes.
I'm not saying those ex-seniors would not be able to get back in the saddle. I'm just saying there's been more change in the last 9 months than there has in the last 30 years, so it may take a period of adjustment.
But I don't think the things that burned them out before will have changed. Dealing with non-tech executives was always the worst part of the job, and LLMs can't help with that, and are even making it worse ("ChatGPT says this should only take a couple a hours and you're using Typescript instead of Go! Why? Fix it!").
The "a ton to learn about how to control an LLM" is remarkably similar to learning how to work with a new team of humans, perhaps easier. LLMs though eccentric are far more predictable than most humans.
What I love most about AI development is the lack of pushback when you see a completed new feature, realise it was a dumb idea and just pivot hard to something different.
A human would (rightfully) call you out for wasting time and resources. AI slurps up your feedback and dives in again with the same vigour.
> There's a ton to learn about how to control an LLM while it's writing code, and even more to learn about how to manage a set of agents.
So? The experts have a only few months of experience anyway, gained the slow way (via experimentation). It's not like someone can't pick up those skills in a week.
Sat in many meetings talking about CORBA and COM. And XML is the gift that just keeps giving. Thank god that stuff is in the rear view mirror.
However in the age of AI I don't know if it matters too much that SOAP is the interchange. It is easy enough to build clients against it. It works. It's probably quite secure. Who cares?
reply