If you don’t have the resources to write and understand the code yourself, you don’t have the resources to maintain it either.

Any monkey with a keyboard can write code. Writing code has never been hard. People were churning out crappy code en masse way before generative AI and LLMs. I know because I’ve seen it, I’ve had to work with it, and I no doubt wrote (and continue to write) my share of it.

What’s never been easy, and what remains difficult, is figuring out the right problem to solve, solving it elegantly, and doing so in a way that’s maintainable and sustainable given your means.

Code is not an artefact, code is a machine. Code is either a living thing or it is dead and decaying. You don’t just write code and you’re done. It’s a perpetual first draft that you constantly iterate on, and, depending on what it does and how much of that has to do with meeting the evolving needs of the people it serves, it may never be done. With occasional exceptions (perhaps? maybe?) for well-defined and narrowly-scoped tools, done code is dead code.

So much of what we call “writing” code is actually changing, iterating on, investigating issues with, fixing, and improving code. And to do that you must not only understand the problem you’re solving but also how you’re solving it (or how you thought you were solving it) through the code you’ve already written and the code you still have to write.

So it should come as no surprise that one of the hardest things in development is understanding someone else’s code, let alone fixing it when something doesn’t work as it should. Because it’s not about knowing this programming language or that (learning a programming language is the easiest part of coding), or this framework or that, or even knowing this design pattern or that (although all of these are important prerequisites for comprehension) but understanding what was going on in someone else’s head when they wrote the code the way they wrote it to solve a particular problem.

It frankly boggles my mind that some people are advocating for automating the easy part (writing code) by exponentially scaling the difficult part (understanding how exactly someone else – in this case, a junior dev who knows all the hows of things but none of the whys – decided to solve the problem). It is, to borrow a technical term, ass-backwards.

They might as well call vibe coding duct-tape-driven development or technical debt as a service.

🤷‍♂️

#AI #LLMs #vibeCoding #softwareDevelopment #design #craft

@aral six months ago I would have agreed completely. And I still do for anything that goes into production, or is to be used by anyone but myself. But single use little apps has become my best friend...

I work a lot with databases at the moment, and one of the most hellish things is to switch modes (mentally) between automatic sorting using regex and whatnot, manual tweaking to things that don't get caught by regex and others scripts, different data views to see what's going on where, etc.

By vibe coding small Textual apps, using code I could never write or maintain myself, I can read from a live database, and write to a live database. The app can do any changes I want, using any keyboard shortcuts I want.

So when I inspect entries in a database, and "oh crap there are a hundred mangled replicas of the same entry here, but no columns are the same!!" - instead of spending 20 minutes figuring out how a script can detect duplicate content across different columns, I can spend 3 minutes vibing a new version of my app, that is basically just Tinder for databases. Right arrow = keep, left arrow = discard, up arrow = good data. I can now sort 100 entries in less than a minute.

I would never claim the app is good, I would never sell it, heck I probably wouldn't even give it to anyone because it would as you rightly say be hell (or impossible) to maintain or improve. It crashes sometimes, but it doesn't matter because it writes directly to db, so all changes are saved.

There *are* things AI can be used for, that involve a clueless monkey just asking it to do things. Like write good SEO metadata for a website. Like looking through a complicated repo and giving me different sorts of maps and flowcharts depending on what I need to look for and understand. Like reading a 40mb plain text file and finding out what sort of CSV it originally was supposed to be, before someone gabled it through 15 different encodings. In that last example, I would never of course use LLMs to recreate the data structure (slow, unnecessary use of energy, lots and lots of errors, etc). But having a machine tell me the structure, visually in a TUI, so I can get the regex right the fourteenth time instead of the 140th time, dude I'm here for it.

@me @aral

Your example reminds me of those flimsy plastic shopping bags.

Made for single use, really handy if you forgot to bring a bag, firm chance of falling apart before you reach the kitchen, but(!) at that moment the cheap and quick way to get stuff home...

... and causing immeasurable damage for centuries on a global scale.

The right acronym for AI should be EC. Externalized Cost.

PS: I claim no moral high ground to stand on; not about plastic bags, nor AI usage. I too live in this world.

@avuko @me @aral No AI == Idiot Assistant.
@jaypeach53 @avuko @aral Which "AI" are you talking about? BERT? Scikit-learn? Whisper? .....Gaussian splatting?

Do you think all subtitles on social media videos should be transcribed by humans rather than a Whisper-model, for example? Or humans should manually detect spam mail instead of scikit? Come on...
@avuko @aral that's a fair analogy. Especially since what I do, which is not vibe-coding entire sites, solutions, backends etc, but ~10 prompts that gives me a machine I can use a lot could be comparable to using a couple of plastic bags 100 times before throwing them away.