As soon as you include a network roundtrip in anything you're opening up a Pandora's box of slow connections, slow DNS queries, network outages, what-if-the-user-is-on-a-train problems, what-if-their-IP-changes-mid-flow problems, etc.

Reducing the network calls in any app has upsides and downsides. It isn't really true that SPAs are faster to render (as your example proves) but rendering speed isn't the only thing that matters.

Attributing this to the technology driving the browser experience is silly. You can make a brilliant user experience with React. You can make a terrible website with plain HTML.

The improvement comes from the change design, not tech.

Access to the tech is probably unequal if it's done privately, which leads to polarization of society where rich people get even more opportunities than poor people. If you want equality of opportunity and an approximately meritocratic society then building a system to prejudice outcomes before kids are even born isn't ideal (although money and education already does this to an extent, those can be countered a bit by government policy; literally growing humans with genetic advantages can't.)

There's a world of potential for choosing foetuses based on criteria that are ethically catastrophic (no girls, no people who are 'impure', etc). You can argue that it's still parental choice even if the parents are terrible people, but normalizing the tech could be a disaster if a future fascist government gets into power. Imagine if the choice was removed from the parents and taken over by the state.

The foetus doesn't get a choice. This is straying very close to anti-abortion rhetoric admittedly, but if you believe that people should get a say in the outcome of their life, then aborting pregnancies based on a possible outcome that might not manifest for decades is very questionable. A baby that gets terminated because current medicine can't stop an aggressive cancer is having the opportunity to wait for medicine to improve taken away from them. Even ignoring the abortion side of things, you can question whether it's right to make that decision on their behalf.

Increasingly though, parents can check, and they are doing, and that means they're getting to pick whether or not to carry a not-quite-perfect baby to term. Many are choosing to terminate and try again. Right now it's for obvious things like Downs, but the scope for what parents choose to terminate can, and probably will, escalate to other detectable problems.

The question is where that ends. Terminating due to a susceptibility to aggressive cancer? Maybe. Due to lower intelligence? Perhaps. Lower physical strength? Probability of autism? Unsymmetrical facial features (e.g. 'ugliness')?

Even if that were 100% true, it only collapses the coding effort to near zero. Anyone who's built and shipped a real product should know that coding is maybe 50% of the work, and on a mature product it can be much less.

I've also built a release notes app for my QA teams, a DORA metrics app, a thing to map UX journeys with Playwright, and a ton of games and stuff. AI got me back into enjoying building things again.

This isn't very compatible with also teaching children that they can't trust the majority of adults, and that every stranger is a potential danger.

There will always be a reason why people die, and it will never feel like we're doing enough.

It only worked for accounts that didn't have 2FA switched on. If your livelihood depends on your account and you're risking not turning on some pretty basic security features then you should accept partial responsibility.

That doesn't mean you couldn't carve out a niche providing hand built software to people it does matter to, because the software industry is large, but saying 'zero percent of the market isn't willing to pay for it' isn't really wrong. It's just a rounding error that does care.

(One massive caveat though ... the argument assumes that 'hand built' means 'higher quality than AI-assisted', and that's probably not true for >99% of developers.)

It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.

How can you tell that isn't what's happened from looking at the rise of tech?

I don't think you can point to the rise of tech as a casual just because it's popular. If people aren't having children they'll do something else instead. To say what that is you need more evidence that what people are doing.

This isn't really related to AI because it relates to manually coded things just as much, but on this point specifically this is only true for your very early I-gave-it-to-a-bunch-of-interested-people-to-try customers. It's much less true for your first paying customers, especially if the 'major issues' make their pain worse (e.g. data loss, time wasted, etc). You lose those ones for good, or until there's a critical mass of social proof to tell them the early problems are solved.

'I can dash out an early prototype with AI and then fix it later' is a dangerous mindset. If you're working in a small market with a limited number of customers you might piss off enough people that you won't be able to recover. There still has to be some level of quality. But it is a balance.

People have been having children later since about the 1930s. The change has been gradual, so it's only really hitting hard now because they've not had any children during the years when it's relatively easy, and now some can't. That could still be due to technology but not social media exclusively.

Coincidently though, this aligns pretty much perfectly to people's stability also shifting to happen later in life. Specifically the economic stability to raise a family on a single income. That's not really possible any more, so it shouldn't be a surprise that people don't do it.

Just to add a little factual data to this point, the fertility rate in England and Wales has been below two children per woman since the 1970s.

I imagine Claude could zero-shot a Chrome plugin for that.

It's not outside the realms of possibility that the price of the shares post-launch could collapse if the market decides they're over-priced. Shares in companies have been known to settle on valuations far below the IPO price in the past. At that point they won't represent ~5% of the total. Changing the index rules immediately before finding out what's going to happen feels like putting the cart before the horse.

Sure, but right now they don't know how the market will react, so changing the index rules before there's any data would be a measure of their heuristics (e.g. what they believe the market will do), not a measure of what the market is actually doing.

Presenting it as either a system that misses real problems or a system that has a huge number of false positives is a false dilemma. You can have a system that's designed to find all the problems and then optimize it to reduce the false positives. If you can't reduce the number then you optimize to identify false positives as fast as possible. Just ignoring the identified problems on the assumption that they're false is giant red flag and a signal that the org has a very a broken engineering culture (but, as you say, that's quite common.)