Caught a vibe that this coding trend might cause problems Everyone loves the idea of magic. All you have to do is wave your hands, say a few words, and something new is born to the world. That works for Harry Potter, but it won't work for you. Vibe coding, the notion that you can build programs by telling an AI what you want the software to do, is pure fantasy. This shouldn't …
Vibe coding is all about "generate and run."
Wrong! It is about getting people, who have no understanding of the problem field*, to think they can do things cheaper and faster. And in that process to extract lots of money from the poordeserving victimslosers.
As they say, Good, Cheap, Fast, pick two, you can't have all three. And people buying into vide coding have chosen cheap and fast, which inevitably makes it no good+.
* You know the types, people who think they know, but they are prime examples of the Dunning-Kruger effect in action.
+ And they don't get fast and cheap either.
"Everyone loves the idea of magic, but those who succeed like Faust or the sorcerer's apprentice discover that what you think you have conjured often is not quite that..."
In any contract the devil is in the detail.
The Devil's small print is unreadable being obscured by the quantum fluctuations of the vacuum.
I am reminded of that scene from Fantasia whenever I write scripts, and I deliberately test on containable data sets until confident I've ironed out the bugs.
And that is with old-fashioned human-written code.
God alone knows how lethal I could be with AI programming.
[Goes off to write her foundation-wear design tool: a-bra-CAD-a-bra]
Programming languages (notations) have well defined semantics while natural languages luxuriate in an abundance of intended and unintended ambiguity spread over multiple levels and incredibly context sensitive.
Even getting an individual to convert what passes in their head for an idea into a fairly high level (formal) specification is largely an exercise in futility.
The same promises were made by 4GLs beloved of the same tribes of snake oil vendors and manglement of yesteryear but they too perished in the first frosts of the winter of reality.
Does anyone still recall the eye wateringly expensive CASE tools that were going to solve all your software engineering problems overnight ? Believe ! And you will see the light !
"Everyone loves the idea of magic." Not the wizards of Discworld, being (somewhat redundantly) wise wizards assiduously avoid the practice of actual magic as much out of a painfully developed sense of self preservation as anything else. Magic has consequences that are very rarely benign.
> Does anyone still recall the eye wateringly expensive CASE tools that were going to solve all your software engineering problems overnight
Like Rational Rose?
Whatever happened to that? I never encountered one application that ever shipped from it.
We tried to use it - the shining star hope was that we could reverse engineer the existing code and modify it in graphical form, then regenerate working, modified, code. Trouble is, it never quite managed to get all the subtleties of the existing codebase to successfully round-trip it. Doing it graphical-ui-first was similarly cumbersome. And then the language evolved, and the UI was forever a few years behind the curve, forcing a load of manual overrides into the model. Eventually the struggle of trying to keep up became just too much and we abandoned it. I tried the uml modelling in visio too, and it was interesting for gnerating diagrams from the code but eventually got canned by MS anyway.
I think that was the fate of all these "diagram first" or "diagram round trip" efforts; they could never keep up with the language itself or accurately express the subtleties of the language and environment, which is why the only offerings that survived are the "I'll parse your source and draw a diagram". Useful, certainly, but code-first appears now to be king. Templates, code generators and LLMs can feed into the start of this chain, but the days of graphical tools that generate code seem to be over.
The same promises were made by 4GLs beloved of the same tribes of snake oil vendors and manglement of yesteryear
I remember one of those in the early 1990s (I was a mainframe assembler programmer at the time and naturally sceptical of anything that claimed to be able to generate code by just populating a desktop with what was, essentially, a flowchart. Which would then spit out code.
The fad lasted 6 months (and several tens of thousands of pounds) before it got dropped.
I can't code if my life depended on it. I've tried to start learning a million times in the last few decades, never got past the Hello World level.
Actually, as I'm typing this, I opened Powershell and did a "print Hello World" - it blinked and sent it somewhere. So I did a "write-output hello world", and it got it - on two separate lines.
Hello
World
So - this is my level, and I gladly embrace my absolute muggleness on the subject.
For the last few months I've been torturing ChatGPT - till it (quite quickly) flatly ran out of free goodness and told me it can't edit scripts that long (about 1500 lines back then), then Grok (which tapered off just a bit further, but by then I had learnt to feed it spoonfuls of separate modules).
We ended up with BigBloat - a 6500-ish line ps1 monstrosity of useless comments and redundant lines that were forgotten throughout the "build" (my flattest excuses for using that serious word for this contraption, but I don't know how else to call it).
It helps with daily stuff. As an example - find a user's computer name, kill a string of executables then flush a cache, quickly find currently locked AD users - little things like that. Some more involved stuff too, but nothing that would qualify as coding or as a program.
At my previous job, we had Bethany for this. Not her real name. Sweet person. Very helpful. Success rate was about the same (about ten "here, that one should work for sure" till we get to a working version of anything). Except I was ashamed of bothering her all the time, as she had other stuff to do and other people bothering her. So I must have received from her about 1/100th of what I have so far milked from those chips.
So - programing, coding, whatever ? No. For sure no.
A useful tool ? Hell yes.
And there are still those cute little humanlike annoyances. Grok would (or at least did, as of last month), absolutely refuse to generate something like:
Write-Output "No results found for '$UserName'"
it would stubbornly generate
Write-Output "No results found for $UserName"
Including if you give it to it for rewriting. If you feed it a script that contains Write-Output "No results found for '$UserName'", it will do a wonderful job doing all the changes you want (completely unrelated to that line), then spit it back with Write-Output "No results found for $UserName"
Which would throw a wall of red scary stuff. Oh, how proud I was the day I figured that out on my own :-P
In its defense, if you tell it "If you see a $variable in single quotes within a Write-Output or Write-Log line, keep them quotes" - it will keep them.
PS: I'm sure I'm opening a huge can of worms by putting "Powershell" and "Coding" in the same post, but hey. I'm that bad.
I am glad I am retired otherwise you would be a worry. ;)
Basic or Scheme might be better jumping off points to learn simple programming principles.
I would be the first to admit that imperative languages are extremely unintuitive but unfortunately mapped cleanly on to how processors worked.
Curiously I have found non programmers usually assimilate an incremental pipeline model fairly easily:
extract | manipulate | manipulate ... | display.
Coupled with basic shell scripting can be quite empowering.
Don't beat yourself up.
I've been coding 46 years ( since I was 8 years old ) and sometimes I still don't get it! Coding takes a real shift in mindset. Yes, anyone can do it but like playing an instrument or a manual labour skill, it takes lots and lots of practice and shit-ton of mistakes, plus hours of head-scratching when you see others "weaving magic". Like most things in life you have to "feel" it, if not then no biggie I bet there's a dozen things you can do that run rings around others. Each to their own.
A while back, I wrote a PowerShell script for some simple task that I wanted to automate. After I manually created the script, I wondered whether ChatGPT could be used to generate the same thing. If it worked, that'd be helpful because I only use PowerShell occasionally and that means I tend to forget some of the interesting PowerShell syntax and style between each effort.
Anyway, the first ChatGPT script was correct but very basic. It took a handful of interactions to get something that was pretty much what I'd already created. However, each step needed me to know the expected result and request accordingly. For example, a specific request to extract such-and-such as a separate function, or extract something as a function parameter, or add auto-documentation, or create as a module.
So, yes, ChatGPT saved me a some typing but I had to know, and recognise, what a good (and correct) solution looked like. I was rather surprised how the final closely it matched my original code, but then I'd asked it to target the same thing - one step at a time. To get the result, I still needed the coding knowledge. In fact, I still had to remember what was useful for Powershell scripts. Fortunately, that knowledge was at the front of my mind because I'd only just finished doing it manually.
I've not used it much since. Doesn't seem worth it for my regular C/C++ coding, or helper scripts.
Certainly didn't strike me as being the solution to all problems, for all people, as is often suggested.
A million times Ditto
The user would have to know what the end result should look like.
Otherwise we end up with the programmer at the store joke.
"Go buy a gallon of milk. If they have eggs, get a dozen"
And the guy returns with twelve gallons of milk, because they had eggs.
My issue with that one is I can never figure out if he should return with twelve gallons, or thirteen...
It depends who and how they coded the language in use. My gut feeling is that it crashes as there's no explicit statement of what to get a dozen of, it's implied and languages don't do well in situations like that.
( My wife: "You're overthinking it again, it's just funny thing!" )
"So, yes, ChatGPT saved me a some typing but I had to know, and recognise, what a good (and correct) solution looked like."
This. And you need to know EXACTLY what it will look like, and be able to recognize any missing stuff, or invented properties, or undefined variables. Which largely means reading the code in extremely close detail from top to bottom and following exactly what it's doing in your head, which in turn usually turns out to take more time than just writing the bloody thing yourself in the first place.
… garbage out.
That holds true until the black box is corrupted to the point of constant hallucination.
Then it can be logic in, garbage out.
It is possible to get decent output with prompts in agent mode, but:
you need to know how to code
you need to learn how to prompt
you’ll quickly find that for complex systems it’s quicker to just code it yourself, as prompting takes as long or longer.
one or two prompts that don’t end up with what you want? very hard to revert.
currently agentic LLMs don’t clean up after themselves that well.
you have to be very specific.
they also don’t learn, unless you are very adept at LLMs and are rolling your own.
As a tool it has a lot of uses.
I consider it a bit like the art of coding simplicity. A function does just one thing.
So use LLMs like that.
“write a function that has x params and returns y”
when you get good at prompting it can save time, sometimes, but you HAVE to orchestrate the entire app yourself. Trying to get the LLM to join the dots is an exercise in frustration, it doesn’t know what it’s doing. No concept of the task.
I am waiting for LLMs that can look at their own output, judge it against the original criteria, and iterate until it can give you a not-obviously-incorrect answer. I asked perplexity when this might happen and it said "they're working on it". To me it seems like an obvious next step; it's what I do all the time after all.
Apply this to coding and you get an agent that can write much better code - either by running it on a real environment or by performing (the lost art of) a dry run, then fixing any errors found. Hopefully it can then learn from the corrections it had to make, and become a better "works first time" coder, the ultimate stage of englightenment for a programmer.
"I am waiting for LLMs that can look at their own output, judge it against the original criteria, and iterate until it can give you a not-obviously-incorrect answer." If I understand the article, that's what this one did. Unfortunately, what it did was not so much to change the underlying code that generated answers, as to edit the answers the AI said were coming out of its code.
This is how code generation works in copilot.
First it generates an initial broken implementation.
Then as a second pass, it'll take the IDE errors and source, and attempt to unbreak all the type errors.
This will inevitably cause it to notice it hasn't imported some things, at which point it'll assume that myFn from your project is definitely myFn from some common library, and import that instead.
That holds true until the black box is corrupted to the point of constant hallucination. Then it can be logic in, garbage out.
This. Exactly this.
Coding tends to be an iterative process. Typically you code, test it, then either correct or extend it, depending on the results.
And that is lethal to an AI, since it requires using previous output as (part of) new input. Feeding AI input back into an AI is one of the quickest ways to send it off into lala-land.
If you want a picture of the future of programming, imagine an airheaded mid 90s-era wannabe Silicon Valley entrepreneur telling an actual programmer...
"I just had a great idea for a new [program / website / video game]! Hey, you're, like, some kind of computer-y person! Can you, like, make it for me?"
...forever.
OpenAI 4.1 through VSCode Github copilot is useful to some degree, but extremely dangerous in "Agent" mode. Unless you feed it a long list of what you don't want changed by a prompt, it always tries to do more than you asked for because "according to statistics", your working code is "written wrong."
If I'd have had the experience with setting up JPA configurations that I needed to do what I'm working on now, I'd not have found it useful at all. But as it is, it took attacks with Cline, Claude 3.5, Google's online summaries/outlines, and finally OpenAI 4.1 to come up with my "final solution" to what I want done (See https://github.com/msobkow/server.markhome.msscf.msscf.cflib.dbtest and related repos under my id.)
Although I'm pleased with the final multi-JPA-repository implementation, I'm emphatically not happy with how long it took to come up with. Sure I was just puttering at it over two dot-releases of Spring, but the unpredictable behaviour and different interpretations of what was needed by all the LLMs involved in the process just proves that you can't replace a good programmer's experience with these extremely overhyped utilities.
And that's all they are. Programming tools and utilities, to be used as needed, but not trusted to do the job right. And the only way to know they're doing it wrong is through decades in the trenches of programming without relying on them.
I'm not too worried if Aunt Hilda or Uncle Bubba tries this. What's the worst that can happen, they'll lose their bank account?
What I'm worried about is what the US Government will do with this. DOGE already made changes to our Social Security computer systems, I hear, and was planning to migrate the whole thing from Cobol to something newer in three months (https://gizmodo.com/doge-plans-to-rewrite-entire-social-security-codebase-in-just-a-few-months-report-2000582062). What do you want to bet they used/ are using AI to help them streamline™ this deprovement?
You have to use them properly. Coding at the prompt causes all sorts of problems:
-muddied context leading to hallucinations.
-no clear plan for what you actually want
-ai assistant making a cascade of changes that overwhelm the developer
-leaving the developer unsure of what is in the code change
But this isn't a tool problem, it's a tool usage problem. Is it the SQL query editors fault you wrote a query with a Cartesian product? Just randomly throwing stuff into an LLM, which is what most people start to do when the get Copilot or Cursor, doesn't scale. Yes, that advertising doesn't mention this, but it is advertising.
There are techniques you can use to get an awful lot out of an LLM based coding approach. Memory Bank is a great one for working with LLMs for coding. You spend a pile of time generate a plan, validate it, ask the LLM to find documentation to prove it's API choices actually exist and then generate a development plan of phases and steps. You then don't let it move forward from one step to the next without the code compilng and new until tests which also compile and test. At the end of each phase I check the code changes and go after any obvious stupid stuff.
This process works. The code that counts or can be checked, issues can be caught before they cause mayhem and building the plan before starting is what a cider should be doing anyway. I now work with Cursor or VS Code running a memory bank plan in one IDE while I'm coding in another IDE.
And, yes, all my code changes are peer reviewed. I mark what has been generated so the team knows. By and large the results are good.
It's a learnt skill, like everything else. There are plenty of blogs out there about memory bank. I strumbled across them while I was reading about how to improve context for a large change.
As for hand holding, I'm not. I check it's work, just like a human checks mine. Where there are issues, I fix them. There are not that many issues.
The weird thing about this debate is just how angry people get by the idea that an LLM can be a useful tool and might actually write acceptable code. This is here, it's a thing and these LLMs are only going to get better.
People need to learn how to use them.
Aka "You are holding it wrong"
Useless excuse. The tools you are talking about are dumb as a sack of rectangular building thingies. The idea of "generate boilerplate code for me to fill in" is, and has been for twenty odd years, on the same level.
Statistical analysis of code will improve. But it'll butt up against Gödel, and it'll tangle with Turing, and it'll possible save some minutes of time. There's nothing to be angry about, one side or the other. You need to be an experienced programmer with knowledge of the syntax in question regardless.
Which is what quite a few of us react to.
I used to be able to write code- 40 years ago I was even up there with proper programmers- I could write proper programmes that did stuff, pretty efficiently for the time with assembly language and all that sort of thing.
Now, I've tried to teach myself Python. And to be fair to myself got a reasonable command of its basics. Just as I did with C++ some years back. But without anything I want or need to write it's quite hard to take it past the beginner stage. And programming has moved on since my day. Most of the stuff I'd have coded now comes in libraries- and I've only a hazy idea of these. The example programmes I've looked through are pretty unhelpful in these matters, too.
But getting an LLM to create a small programme, annotated, explaining its steps might be a pretty good way in to seeing how the nuts and bolts fit together. It wouldn't, of course, make me a programmer, not just because I'm in my late 60s and the grey cells have better things to do, But also, because I have no programming tasks I'd like to write for. Unlike in my youth when I actually wrote stuff that was practical and useful and I could probably have even sold, in one or two incidences.* As a way to learn what I needed to know.
But using an LLM provided programme draft would be a fun way of working through some sample programmes.
*I wrote a great, interactive, programme for the BBC Micro that allowed users on flexi-time to track their hours and save the data to disc, and would show them when they'd accumulated enough for a long weekend, or a day off , how much they had left after it etc.
I've always said this, it's no good learning to code if you have nothing to apply it to. It's like learning French and having no intention of going there ever in your life. The fastest way to learn to code, or indeed any practical skill, is to apply it to a problem that needs solving. You might not write the most efficient code by "winging it" but my god you will learn quickly and gain lots of experience. The skill is then taking that knowledge and that experience and using it properly in a structured way.
AI coding is simply bypassing the first part, something else has all the knowledge and "experience", it won't share any of that as it can't. If prompted it wille explain what something does but no how to implement it precisely into what you need.
I use AI chatbots to give me snippets of code as quick starts if I'm not familiar with something, then I go through it line by line along side the docs or asking AI bot to explain a particular line.
One of the most interesting things about the vibe-coding craze is just how quickly the black-hats have been to start exploiting it.
Poisoning LLM code samples with deliberate vulnerabilities is already a thing, and keeping source sanitation up to date with obscured poisoning code samples is going to be extremely tricky to pull off without crippling the LLMs functionality.
If you've been in the business for long enough , you've seen this all before. Every decade or so there is a new thing claiming to enable you to develop software without writing code. They all fail for the same reason: You have to specify the problem precisely and the only thing that we have that precisely defines a software problem is....code.
