I try to stay well read on AI, and I regularly use Claude, but I’m not so convinced by this article. It makes no mention of the bubble that could burst. As for the models improving aren’t the improvements slowing down?

More importantly, the long term effects of using AI are still unknown, so that for reason the adoption trajectory could be subject to change.

The other factor to consider is that the author of this article is a big investor in AI. It’s in his interest to generate more hyperbole around it. I have no doubt that generative AI will forever change coding, but but I have my skepticism about other areas, especially considering the expensive controversy of Deloitte using AI to write reports for the Australian government.

I find articles like this about agentic engineering both compelling and anxiety inducing. It’s staggering what people are achieving with agents toiling away in the background. However, it also leaves me feeling insecure, as I have many ideas that I would love to build, and previously my excuse was a lack of time, and now I worry I have no excuse when an agent could potentially build it whilst I sleep.

What I’m saying is the post is broadly about programming, and how that has changed over the decades, so I posted it in the community I thought was most appropriate.

If you’re arguing that articles posted in this community can’t discuss AI and its impact on programming, then that’s something you’ll need to take up with the moderators.

In fact, this garbage blogspam should go on the AI coding community that was made specifically because the subscribers of the programming community didn’t want it here.

This article may mention AI coding but I made a very considered decision to post it in here because the primary focus is the author’s relationship to programming, and hence worth sharing with the wider programming community.

Considering how many people have voted this up, I would take that as a sign I posted it in the appropriate community. If you don’t feel this post is appropriate in this community, I’m happy to discuss that.

My nuanced reply was in response to the nuances of the parent comment. I thought we shared articles to discuss their content, not the grammar.

Regardless of what the author says about AI, they are bang on with this point:

You have the truth (your code), and then you have a human-written description of that truth (your docs). Every time you update the code, someone has to remember to update the description. They won’t. Not because they’re lazy, but because they’re shipping features, fixing bugs, responding to incidents. Documentation updates don’t page anyone at 3am.

A previous project I worked on we had a manually maintained Swagger document, which was the source of truth for the API, and kept in sync with the code. However no one kept it in sync, except for when I reminded them to do so.

Based on that and other past experiences, I think it’s easier for the code to be the source of truth, and use that to generate your API documentation.

There are plenty of humans using em dash, how do you think large language models learnt to use them in the first place? NPR even did an episode on it called Inside the unofficial movement to save the em dash — from A.I.

There is much debate about whether the use em-dash is a reliable signal for AI generated content.

It would be more effective to compare this post with the author’s posts before gen AI, and see if there has been a change in writing style.

This quote on the abstraction tower really stood out for me:

I saw someone on LinkedIn recently — early twenties, a few years into their career — lamenting that with AI they “didn’t really know what was going on anymore.” And I thought: mate, you were already so far up the abstraction chain you didn’t even realise you were teetering on top of a wobbly Jenga tower.

They’re writing TypeScript that compiles to JavaScript that runs in a V8 engine written in C++ that’s making system calls to an OS kernel that’s scheduling threads across cores they’ve never thought about, hitting RAM through a memory controller with caching layers they couldn’t diagram, all while npm pulls in 400 packages they’ve never read a line of.

But sure. AI is the moment they lost track of what’s happening.

The abstraction ship sailed decades ago. We just didn’t notice because each layer arrived gradually enough that we could pretend we still understood the whole stack. AI is just the layer that made the pretence impossible to maintain.

Even if the bubble pops, the existing large language models will remain, as will AI assisted coding.

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.

I can very much relate to this statement. Many contracts I’ve worked on in the last few years, have been transformation programmes, where an existing product is rewritten and replatformed, often because of the level of tech debt in the legacy system.

I originally shared this after stumbling upon it in one of Martin Fowler’s posts.

The article reminds me of how my mother used to buy dress patterns, blueprints if you will, for making her own clothes. This no code library is much the same, because it offers blueprints if you wanted to build your own implementation.

So the thing that interests me is what has more value - the code or the specifications? You could argue in this age of AI assisted coding that code is cheap but business requirements still involve a lot of effort and research.

To give a non-coding example, I’ve been wanting to get some cupboards built, and every time I contact a carpenter about this, it’s quite expensive to get something bespoke made. However, if I could buy blueprints that I could tweak, then in theory, I could get a handyman to build it for a lower cost.

This is a very roundabout way of saying I do think there are some scenarios where the specifications would be more beneficial than the implementation.

Thank you everyone for your input. I have created a separate community, [email protected], for AI coding related discussions.

I agree with you on that point, and the same could be said about the meat and dairy industry. However I don’t think the answer is censoring discussions about cooking beef or chicken.

You can’t compare racist posts, which are a form of hate speech and a breach of this instance’s code of conduct, with discussions about topics that you don’t agree with.

Good question. I have asked this very question https://programming.dev/post/45013854

Expensive as hell! 🤑

Yegge describes Gas Town as “expensive as hell… you won’t like Gas Town if you ever have to think, even for a moment, about where money comes from.” He’s on his second Claude account to get around Anthropic’s spending limits.

I can’t find any mention online of the per-account limits, but let’s conservatively assume he’s spending at least $2,000 USD per month, and liberally $5,000.

I am not surprised that there are parallels between vibe coding and gambling:

With vibe coding, people often report not realizing until hours, weeks, or even months later whether the code produced is any good. They find new bugs or they can’t make simple modifications; the program crashes in unexpected ways. Moreover, the signs of how hard the AI coding agent is working and the quantities of code produced often seem like short-term indicators of productivity. These can trigger the same feelings as the celebratory noises from the multiline slot machine.

Where did you get the impression that the author is an inexperienced developer and finance bro? The introduces himself as someone who started programming from the age of eleven.

I’m Michael Arnaldi, Founder and CEO of Effectful Technologies — the company behind Effect, the TypeScript library for building production-grade systems. I’ve been programming most of my life. I started at 11 with the goal of cracking video games. Since then, I’ve written code at every level: from kernel development to the highest abstractions in TypeScript.

I think the most interesting, and also concerning, point is the eighth point, that people may become busier than ever.

After guiding way too many hobby projects through Claude Code over the past two months, I’m starting to think that most people won’t become unemployed due to AI—they will become busier than ever. Power tools allow more work to be done in less time, and the economy will demand more productivity to match.

Consider the advent of the steam shovel, which allowed humans to dig holes faster than a team using hand shovels. It made existing projects faster and new projects possible. But think about the human operator of the steam shovel. Suddenly, we had a tireless tool that could work 24 hours a day if fueled up and maintained properly, while the human piloting it would need to eat, sleep, and rest.

In fact, we may end up needing new protections for human knowledge workers using these tireless information engines to implement their ideas, much as unions rose as a response to industrial production lines over 100 years ago. Humans need rest, even when machines don’t.

This does sound very much like what Cory Doctorow refers to as a reverse-centaur, where the developer’s responsibility becomes overseeing the AI tool.