Robert Munn (@robertdmunn)

Here's an email I sent recently in reaction to the blog post below about the current issues with AI and LLMs in particular. The blog post is lengthy but a worthwhile read if you want to understand the broader issues people in tech see with the state of AI. ---- There was a prominent speaker at a recent AI conference saying part of what he said - that they aren't going to reach true AGI using LLMs, and researchers should focus on something else going forward. I'll dig the article up if I can find it. For our purposes as a coding assistant, an LLM is a useful but limited tool. As I said before, it's a bit like a djinni - capable of doing lots of things very quickly, but dangerous to use. The best thing you can do to use one effectively and safely is to use it to create small, narrow bits of code, e.g. "Loop over this structure and output the keys and values. If there are nested objects, destructure them." It generates a relatively small amount of code that you can review quickly, saving you the time of writing the looping logic manually. An area I use them is when I want to generate something that follows a specific pattern where I can provide a template. A good example would be providing a table ddl and saying "generate dao, gateway, service, controller, and remote api files for this table ddl. Here are templates to use as a guide." The downside of giving it this much leeway is that it may or may not generate exactly what I need. I think it hits around 80% of the code I need. The reason is pretty obvious once you think about it. The LLM doesn't know all of the business rules you want in the application. In this example, providing the DDL and the templates gets you part of the way there, but any decent engineer knows that the business rules around one table may differ from those around another. The main question for me is whether using AI saves time. I think it is easier to prove the time savings using an LLM to generate a small bit of code where you can quickly review and see what it did rather than the latter example where you generate multiple potentially large files that need to be reviewed and hooked into your application. The need to review so much code inevitably increases the risk of bugs in the application. Not necessarily runtime bugs, more likely business logic bugs that are both harder to detect and potentially more dangerous. I haven't even touched on the current shiny keys syndrome - vibe coding. There are people advocating for building applications just by prompting an LLM in an iterative manner until you arrive at the running application that you want. The Tea application disaster is a useful example here of the potential dangers of vibe coding. I can't think of any worse outcome for the users of that application than what happened. There are other examples of similar issues (one guy left his ChatGPT API key in clear text in the application), but the point remains the same. An LLM is no substitute for a knowledgeable engineer translating business requirements into code. I think the utility of LLMs isn't quite played out yet, there are useful things to be done with agents and automation, but the overall problem remains the same - you still need an engineer to translate business requirements into code. Vibe coding doesn't get you there. Ironically, by generating something that works, it creates dangerous overconfidence in the technology, leading to potential disaster. I don't think anyone is anywhere near actual intelligence comparable to a person in the way groups like OpenAI advertise services meant to replace a researcher. While there is a lot of impressive stuff being done, it's mostly impressive on the surface. When you dig deeper, it seems like there is no there there, as the author of the blog post suggests. https://malwaretech.com/2025/08/every-reason-why-i-hate-ai.html