LLMs are like handwritten notes Kieran Klukas KieranKlukas2008-04-27male18, nix nerd, photographer, hardware kid, cyber operator<br>me@dunkirk.shUnited States of America

../llms<br>Published 2026-07-17By Kieran KlukasLLMs are like handwritten notes<br>This is my best attempt at formulating the thoughts that have been tumbling around my head for the past two years. It’s a bit pessimistic but I think that is kind of appropriate.<br>AI != LLMs. This is one of my biggest annoyances with the current state of “ai”. Every company wants to add some fancy new ✨ AI ✨ feature into their product and most of the time either they would be better served with a more traditional ml or rl model or even worse it could litterally be a tiny bit of good old fashioned conditional or regular expression.AI itself feels like a horrible misnomer. It is my deepest wish that LLMs had never been marketed or branded as inteligent entities. Linking LLMs to intellegance was a fatal mistake in my opinion as it subtly encouraged leaning on them more and more trusting them to behave like a human.My personal philosophy for LLMs / generative technology boils down to 3 points:Never ever use an LLM to write anything I present as my own writing.Refuse to use generative art and music tools.When using LLMs for code generation purposes seek to fully understand the code and never blindly trust it.My biggest worry with LLMs is the collective collapse of critical thinking and logical reasoning skills that is starting to show up. It is so easy to outsource your ideation and execution to LLMs especially in the software space and the ease of slipping into this really worries me. I see a pretty similar correlation between the strength of handwritten notes when compared to typed or recorded notes. When we handwrite notes we are forced to condense a rapid stream of spoken information constrained by the speed of our hands which causes our brain to remember the information much more reliably. Similarly when we write code we are bottenecked by the speed of our fingers on the keys but also by the rate at which we can solve the next problem. By forcing us to slow down and make decisions about what we want to type in and how we want to tackle a problem it leads to more maintainable code but also engrains the problem and our solution to it in our memory. We don’t necessarily remember everything perfectly but the concepts of how we tackled something stick with us and make us better programmers.LLMs have an even stronger effect on our brains. Since we aren’t bottlenecked by either the speed of our keys or the brainspace a several thousand line new file takes up it is much easier to generate spaghetti code. Because we don’t have to directly interact with the code we aren’t quite as driven to write maintainable easy to read code but also we are willing to expand scope and add features and ideas that we likely never would have before because it would have required too much work to maintain. The assumption is that LLMs will make maintaining this code easier in the future but so far we really aren’t seeing that be the case. LLMs tend to write very verbose idea specific code and don’t tend to be amazing at condensing and maintaining as they go on. It feels much like beating a pile of typesetting blocks with a rubber mallet and hoping it makes them all fall into place but instead it knocks over more letters and makes the page ten times bigger. The worst part though is that in most cases the output looks plausible. It is becoming increasingly hard to tell whether a mr is ai slop anymore. Oh sure there are still signs. Comments written a certain way, a ton of churn in code that might not have needed a refactor, a weird description. Looking for those signs and then deciding what to do about it takes up an increasingly longer amount of time and effort.There has been a lot of discussion in various places about the need for increased ability to filter and vouch for contributions and I think that makes a lot of sense but is also really sad to see. Before it used to be that the effort of understanding someone’s codebase, forking it, setting up the build environment, making your change, and then working with the maintainer to get something upstream was long and not really automatable. You could trust that someone put actual thought into designing their merge request because otherwise why else would they put in the time? I haven’t personally been in OSS for that long yet. I’m still very much a greenhorn but I remember the absolute joy of making my first contributions to projects after getting my github account. Were they great? Probably not! But there was care and I did truely want to learn how to do stuff better.The first time one of my projects got a MR from someone else I remember jumping up and down in literal joy because some stranger on the internet thought sonething I made was cool enough to spend valuable time from their day to add a feature. Now i’m more likely to feel a groan because I...