codeinabox

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.

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

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

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.

The issue was they changed their server URL and added www, so I've updated the link accordingly.