A very small thing just happened to me that I don’t think I would have noticed if I hadn’t been specifically trying not to use an LLM coding assistant.
I am trying to teach myself Godot and GDScript. I have some ideas for video games that I’ve had scribbled down for a while now but I’d never built enough of them to get a satisfactory prototype. I am comfortable enough in JS that I’ve now cobbled together some Phaser code into a working game, but I used an LLM to write most of it, I tweaked it just enough to get it running because I wanted a working prototype more than I wanted something polished. I was able to do this pretty quickly, but I (quickly) ran into the problem a lot of vibe coders run into, which is that I didn’t understand how the code actually worked. Debugging began to slow me down because I had to try to learn the code as I was debugging it. It was the difference between the relatively minor hassle of debugging my own code and the usually onerous, occasionally nightmarishly unpleasant chore of trying to debug someone else’s code, where you keep having to context switch from “how could this code be producing that behavior” mode to “what is this code even supposed to do” mode. I didn’t want to work on the project after a certain complexity boundary because making changes became exactly like one of the least enjoyable parts of my job, having to sift through huge amounts of unfamiliar code trying to cobble together enough context to enable the one minor change I want (then rinse, repeat).
So, I decided to start over in Godot, write in GDScript, use only the Godot editor, and use no LLMs while I figure out how to tell Godot what I want. Just me, the docs, and stack overflow, just like old days. Progress has been predictably slow, but I like it. Something about transitioning from generating huge blocks of code at a time and ripping through a generate -> edit -> test -> repeat cycle to writing everything by hand puts the slowness of it in a new light. This feel presumptuous to say because I know almost nothing about carpentry but it’s what I imagine it might feel like going from a day job where you have to crank out furniture pieces as fast as possible, then going home to your woodshop and spending a few hours with the hand tools, getting one piece just so. Something about having a comparison to the new way makes the old way feel more noticeably nicer.
While I am doing this old-fashioned coding, I am reading a lot more than I’m writing as usual for starting out in a new language. I’m also less familiar with resources that are available for Godot, so I spend more time scanning the internet trying to find the bit that answers the question I have. Just now I was looking up whether there’s a Tuple type in GDScript and I saw an example that, while it used an Array instead of a Tuple, also used the built-in Vector type. It wasn’t what I was looking for, and it didn’t solve the immediate problem at hand, but for the game I’m imagining I will almost certainly make use of Vector, so I made a note of it. And it occurred to me that this is a thing that happens a lot. I think that slow, semi-random accumulation of trivia and knowledge that happens over the years while you’re poring over old forum threads or rambling tutorials or ancient StackOverflow arguments is really useful for developing a deeper understanding of the tools you’re using, and I don’t think I ever appreciated it or even noticed it happening until now.
Thank for sharing your though. I feel the same. For example I’m working right know with vuejs and I don’t have experience with but I have the documentation open and I read it again and again. And also the more basic stuff like JavaScript, I read the doc too.
That’s my way to improve my skills and my work.
Just me, the docs, and stack overflow, just like old days.
While I am doing this old-fashioned coding,
I think I’ll go become a goat-herder
Any methodology becomes old-fashioned if it sticks around long enough to see the next new fashion. Though the new fashion has also made me seriously consider the goat herder route. Turns out it’s a tough industry to move into.
While I am doing this old-fashioned coding
What you are doing now is actually building software, learning about your tools, and designing a system that will solve your problem using the tools at your disposal. There is nothing old-fashioned about it.
Using an LLM to write code is like using Stable Diffusion to design a bridge. It might look like a great bridge, but it’s guaranteed to fall over sooner or later.
I use the term in mild jest, relative to the new fashion of having LLMs blast out huge broken tracts of code for me to detangle. I guess “old-fashioned” can mean outdated but that’s not what I mean here, just “the manner in which I wrote code before I had access to LLMs”
What will happen to all our devs when they never actually spend they never develop anything
I think we’ll course correct at some point but I do feel bad for devs entering the field right now. They’re getting pressured by the industry to become familiar with these tools because knowing the hot new thing is supposed to be how you get a job, but you skip the “let’s figure out how to build something cool with the legos we have” part and move straight into the (IMO much more tedious) “this ball of spaghetti has a broken strand somewhere, lets poke around until we find it” part. And I think, now that I’ve missed it, I can appreciate how much struggling with the build step helps, with maintenance and future new builds.
just give that Cloude code to Gemini to fix it
A shockingly common approach lol. Like if you just buy every brand of turd polish you can find and apply them all, eventually you’ll have something other than a turd. Except all the turd polishes are just the same turd blend in different solvents, so you keep coating your original turd in new layers of turd solution and are then shocked when you wind up with a different, larger turd.
I’ve only found success in LLM code (local) with smaller, more direct sections. Probably because it’s pulling from its training data the most repeated solutions to such queries. So for that it’s like a much better Google lookup filter that usually gets to the point faster. But for longer code (and it always wants to give you full code) it will start to drift and pull things out of the void, much like in creative text hallucination but in code it’s obvious.
Because it doesn’t understand what it’s telling you. Again, it’s a great way to mass filter Stack Overflow and Reddit answers, but remember in the past when searching through those, that can work well or be a nightmare. Just like then, don’t take any answer and just plug it in, understand why that might or might be a working solution.
It’s funny, I’ve learned a lot of my programming knowledge through the decades by piecing things together and in the debugging of my own or other’s coding, figured out what works. Not the greatest way to do it, but I learn best through necessity than without a purpose. But with LLM coding that goes wild, debugging has its limits, and there have been minor things that I’ve just thrown out and started over because the garbage I was handed was total BS wrapped up in colorful paper.
Yep! LLMs are an excellent tool for getting over a hump, maybe finding a new pathway to solve a problem. I scan the output and pick the bits I want to try. ChatGPT may spit 40 lines of broken code, but I only need that one thing I hadn’t thought of or didn’t know.
It’s no replacement for knowing what you’re doing. Almost all IT work is knowing enough to recognize good and bad ideas, knowing where to look for solutions. LLMs can’t replace experience.
The godot docs have their bad parts though. For example when it comes to godot shaders, at the time when I tried it, the docs were out of date. The doc listed some tokens that didn’t exist anymore and others where the functionality I observed differed from what the doc said and sometimes the doc didn’t document anything meaningful at all like “TIME - this is the time” without explaining the unit, format or interval or anything.
The book of shaders might be helpful for that stuff
I’ve had good luck with the docs so far, but I only just just got started with them so maybe I just haven’t encountered any issues yet. Overall though, for the level of quality they’ve managed to put on a FOSS tool I’m happy to grant them a few rough patches in the doc.
Overall though, for the level of quality they’ve managed to put on a FOSS tool I’m happy to grant them a few rough patches in the doc.
100% agree. It’s such a good game engine!




