That sounds like Léon – The URL Cleaner, which I use on a daily basis.

This quote from the article very much sums up my own experience of Claude:

In my recent experience at least, these improvements mean you can generate good quality code, with the right guardrails in place. However without them (or when it ignores them, which is another matter) the output still trends towards the same issues: long functions, heavy nesting of conditional logic, unnecessary comments, repeated logic – code that is far more complex than it needs to be.

AI coding tools definitely helpful with boilerplate code but they still require a lot of supervision. I am interested to see if these tools can be used to tackle tech debt, as often the argument for not addressing tech debt is a lack of time, or if they would just contribute it to it, even with thorough instructions and guardrails.

Thank you! When I stumble across the Neovim posts, I try to share them here if I think someone will find them useful.

This quote really sums up the situation:

This is a technical and business challenge, but also an ethical crisis. Anyone who cares to look can see the tragic consequences for those who most need the help technology can offer. Meanwhile, the lies, half-truths, and excuses made by frontend’s influencer class are in defence of these approaches are, if anything, getting worse.

Through no action of their own, frontend developers have been blessed with more compute and bandwidth every year. Instead of converting that bounty into delightful experiences and positive business results, the dominant culture of frontend has leant into self-aggrandising narratives that venerate failure as success. The result is a web that increasingly punishes the poor for their bad luck while paying developers huge salaries to deliver business-undermining results.

The developer community really needs to be building websites that work on all devices and connections, and not just for those who can afford the latest technology and high-speed internet connections.

I’m curious what this means for business insurance across the board as generative AI is so pervasive, and lots of businesses of all sizes are using it, but will their insurance policies cover any incidents that happen as a result?

On a related note, if I subcontracted someone to perform a task, and there were defects, they would be contractually liable for that. However, if someone used ChatGPT to help with a task, they would have a tough time trying to take OpenAPI to court.

The way the author described programming in 2025 did make me chuckle, and I do think he makes some excellent points in the process.

It’s 2025. We write JavaScript with types now. It runs not just in a browser, but on Linux. It has a dependency manager, and in true JavaScript style, there’s a central repository which anyone can push anything to. Nowadays it’s mostly used to inject Bitcoin miners or ransomware onto unsuspecting servers, but you might find a useful utility to pad a string if you need it.

In order to test our application, we build it regularly. On a modern computer, with approximately 16 cores, each running at 3 GHz, TypeScript only takes a few seconds to compile and run.

As the author notes, it is very impressive what generative AI can produce these days.

The frontier of what the LLMs can do has moved since the last time I tried to vibe-code something. I didn’t expect to have a working interpreter the same day I dreamt of a new programming language. It now seems possible.

However, as they point out, there’s definitely downsides to this approach.

The downside of vibe coding the whole interpreter is that I have zero knowledge of the code. I only interacted with the agent by telling it to implement a thing and write tests for it, and I only really reviewed the tests. I reckon this would be an issue in the future when I want to manually make some change in the actual code, because I have no familiarity with it.

What about developers who are required to use AI as part of their job?

I stumbled upon this article as I was having issues with my LSP setup for TypeScript projects. However, in my case, it appears the bug is in the plug-in nvim-lspconfig.

His experiences reveal a pattern: AI can rapidly produce 70% of a solution, but that final 30% – edge cases, security, production integration – remains as challenging as ever. Meanwhile, trust in AI-generated code is declining even as adoption increases.

I’m very much intrigued by this contradiction where where adoption of AI is increasing, but the trust in the code it generates is declining. Is it a case of the more developers use AI coding tools, the more they become aware of the shortcomings and problems?

I’m guessing that the author said this to warn people not to rely on this technique, as it’s not part of the specification. Does it behave consistently across all browsers?

I know what you mean. Quite often when I’ve worked in a project where there is a pull request template, a lot of the time people don’t bother to fill it out. However, in an ideal world, people would be proud of the work that they’ve delivered, and take the time to describe the changes when raising a pull request.

I’m confused why people are voting down an article about AI in an AI community, discussing small language models, which are much better in terms of energy consumption and the environment.

I stumbled upon this article after reviewing a pull request, where someone was unit testing the abstract base class. I’m of the opinion that base classes should not be tested. We don’t want to be testing the architecture of an application, we want to be testing the behaviour. The author sums this up nicely with this point:

For tests, though, it shouldn’t matter whether the classes under test share the domain logic or duplicate it. Tests should view all production code as a black box, and approach verifying it with a blank slate. Otherwise, such tests will start couple to the code’s implementation details.

I’m not an architect, but I do dislike how much of development work has AWS wrangling, dealing with the architectural hoops that are mentioned in the article

I am wondering about this too. The article, ActivityPub on a (mostly) static website, goes into detail about what is involved.

Things are getting easier. Many of the JavaScript runtimes support TypeScript out of the box now.

Oh, it’s not my own blog, I just stumbled upon it, and wanted to share the post.

Back in the day, I used CakePHP to build websites, and it had a tool that could “bake” all the boilerplate code.

You could use a snippet engine or templates with your editor, but unless you get a lot of reuse out of them, it’s probably easier and quicker to use an LLM for the boilerplate.

I also make use of ‘⚠’ to mark significant/blocking comments and bullet points. Other labels, like or similar to conventional comment prefixes, like “thought:” or “note:”, can indicate other priorities and significance of comments.

Thank you for introducing me to conventional comments! I hadn’t heard of them before, and I can see how they’d be really useful, particularly in a neurodiverse team.