This is a fascinating article about the history of software development. For me the key quotes are:

The thing that killed Waterfall was that discovering your spec was wrong months later, after lots of code had been written - and fixing it cost a fortune because writing code was the most expensive part of the process.

The key reason Agile was invented was to account for the high cost of writing code, so yes, that part of the Agile value proposition is no more.

The risk isn’t that AI development is inherently Waterfall. The risk is that organizations with latent Waterfall instincts will use spec-generation as license to do the bad thing they always wanted to do — front-load requirements, skip customer validation, equate a fancier document with a better outcome, and ship one massive thing every quarter.

This quote from the article really sums it up:

And to be clear, I don’t care whether you typed the code yourself. I care whether you understood it before you shipped it. I care whether you can explain why the bug happened, why this fix is the right fix, what the model might have missed, and what would make you roll it back.

Could you elaborate on this?

Thank you! I’ve updated the post with the TL;DR from the article.

An acronym for domain-driven design.

Depending on your level of programming experience, you might find the exercises at Exercism quite useful.

In case anyone is curious, this is the original post on X.

Could you give more context about what Vercel features you need - is the site statically generated, or do you also need Vercel Functions?

There are several European based alternatives to Vercel. It’s also worth having a read through or posting to [email protected]

Your comment reminded me of this article, The Software Quality and Productivity Crisis Executives Won’t Address, which discusses the lack of technical leadership when it comes to tackling technical debt, and that the solution is usually a rewrite.

Instead, most organisations don’t tackle technical debt until it causes an operational meltdown. At that point, they end up allocating 30–40% of their budget to massive emergency transformation programmes—double the recommended preventive investment (Oliver Wyman, 2024).

I agree but it depends on how teams create and refine their tickets. For example, you could have high level tickets, and someone picks one up and creates an implementation that’s not an appropriate fit for your architecture.

Thank you for not assuming my motivations. Could you please elaborate on what you mean by “oneshotted”? I share a lot of articles, so I’m not surprised you recognise my username.

I don’t specifically seek them out. I follow quite a few different programming blogs, and I am just sharing what people are posting about, and it just so happens a lot of people are posting about this topic.

Headless does not mean “no screen anywhere.” It means you are not required to use the company’s app or site to finish the job.

You might say: “Book a flight and a hotel in Tokyo.” A helper (with hooks into services, e.g. MCP or other agent APIs) talks to airlines and hotels for you. You might never see their homepage or their “join our club” popup.

Whilst I can see where the author is going with this, I can’t see some tasks, particularly booking concert tickets, being done by AI agents. Whilst it may be convenient for end users, it’s also open to exploitation by scalpers.

Not sure if you were even looking for paper reviews.

I didn’t write the article, I just shared it because I thought it was interesting.

I think you’re misconstruing the author’s argument, at no point does the author imply that Claude knows best, or that Electron apps are better. Their closing argument is certainly not an endorsement for Electron or AI slop.

Don’t get me wrong: writing this brings me no joy. I don’t think web is a solution either. I just remember good times when native did a better-than-average job, and we were all better for using it, and it saddens me that these times have passed.

I just don’t think that kidding ourselves that the only problem with software is Electron and it all will be butterflies and unicorns once we rewrite Slack in SwiftUI is not productive. The real problem is a lack of care. And the slop; you can build it with any stack.

Imagine being such a slop-brainwashed fanboi

Do you have any evidence for this? Looking through the post, and the author’s other blog post titles, there is very little mention of AI or Claude.

Instead of throwing labels at the author, it’s much more worthwhile to discuss their key argument about the challenges of developing native apps.

There are some really good tips on delivery and best practice, in summary:

Speed comes from making the safe thing easy, not from being brave about doing dangerous things.

Fast teams have:

• Feature flags so they can turn things off instantly
• Monitoring that actually tells them when something’s wrong
• Rollback procedures they’ve practiced
• Small changes that are easy to understand when they break

Slow teams are stuck because every deploy feels risky. And it is risky, because they don’t have the safety nets.

It"s working now

Guys, can we add a rule that all posts that deal with using LLM bots to code must be marked? I am sick of this topic.

How would you like them to be marked? AFAIK Lemmy doesn’t support post tags