Finally tried this for real since the new flet.dev (Python with a Flutter UI and using pyodide and so forth to allow making web pages and some suitable technology for making apps).
Current effort is 3 credit card payments in, which has me debating on a subscription…
Asked it to document things in a literary style, and trying to get the tool installed locally (but it wants a venv — why can’t we all just get along?), and trying to puzzle out how to move the app to my github…
That’s usually a +1 for me if it wants a virtual environment(venv/conda). I like to keep project requirements isolated from my system environment.
I’ve seen people mention Vibe but don’t know much about it. Been trying out Claude after a software developer I look up to( a super coder in my book ) who works for a very large game developer said he no longer codes much and spends most of his time directing Claude to do the coding. Blew me away when I heard him say that and he’s the type of guy who does it all, unit tests, SCM and documentation.
I just want one system environment where everything works.
Since I’m already 3 x $20 down, I’m on the cusp of breaking down and buying a subscription since the appearance is now quite ghastly (though really, I just want it to finish what I’ve asked and document so that I can take over…)
While waiting for credits to refill, I took apart what I had and made a very simple test project by hand (and a bit of searching and copy-pasting, &c.):
which outputs:
flattening_toolpath.nc
to one’s Downloads folder. Tested in Edge and Waterfox (I was still breaking and fixing it until just now).
Please note that I haven’t had time to test the G-code yet (but it seems okay based on NCnetic’s plot as shown in the screengrab). It’s supposed to run w/ the current tool, and cut from the negative of the stepover in X and Y in straight lines to the right iterating until the Y-axis has moved to be greater than Depth + stepover and as far as Width + stepover.
Constructive criticism and bug reports are welcome.
I’ll look into adding a grid and scaled preview presently.
I would argue that “Vibe coding” is a strict subset of using an LLM (one of many forms of AI in the more than half a century of AI being a formal discipline) in which you do not validate what the LLM gives you. You just yeet the code into production. In my estimation, at least when third parties are exposed to the result, this is one example of “AI slop”, defined as when one human pushes the results of an LLM at another person without taking responsibility for the content.
Using an LLM to assist with filling in details you don’t know, don’t remember, or don’t value producing by hand, in a context in which you can and do validate the details, doesn’t match that definition, and is fundamentally different.
People rationally disagree about every form of using LLMs for coding, vibe coding or not, and I leave space for that disagreement, but I do think that it’s valuable to distinguish a human validating and standing behind LLM-assisted coding from just yeeting the output at another human and making them bear the consequences.
Probably I’m just feeling overly sensitive on this whole thing since we had to put in place a blanket ban on software announcements on the Carbide 3D forums which is something which we are still feeling through.
Still not sure how I feel about the whole entirely-coded in AI thing (which is where I would put the dividing line for Vibe-coding) — apparently some folks do it quite successfully, but as noted, I tried a fairly simple project, burned through $90 of tokens, and reached a point where each attempt to address a failing caused regressions/problems — arguably, that is on me as not being a particularly good “Prompt Engineer”.
I also don’t like the code which is generated (but I’m not a particularly talented/skilled/experienced programmer) and am not finding it easy to work with (or understand), and I’m also annoyed that when I asked for documentation/comments it made a separate file which had a much higher level view than I was expecting.
We will have to see what the future holds and what I can eke out when the tokens refill.
Vibe coding is being used successfully but you need deep pockets as you mention.
My son is a software engineer working at a relatively new startup.
They use AI to generate the draft code. Then send it back into an AI to QA it. Then back to AI to clean and update. Then an AI agent to stress test the code to see where it breaks and then one last AI time to clean up and update with a different agent. Don’t want to even think how much all these tokens cost.
These are all at high levels of programming. My son has 15 years of coding experience, has taught at the local college, worked at different companies and for the government as a programmer, …etc. My point being he is a senior level programmer babysitting software making new software. He tells me he can produce finished software products faster by magnitudes using AI as compared to doing it the traditional way.
Yeah, apparently Uber affords their senior devs $1,000 worth of tokens each month for their choice of three different LLMs or some such, so I guess I shouldn’t feel bad about stalling out at a miniscule fraction of that.
I can kind of see doing some sort of hybrid — have the LLM do an initial chunk of code similar to what one might get from an example in a book and work forward from that.
The expectations are clear at my workplace that all software developers shall use LLMs aggressively.
LLMs have allowed me to work in a new area in which I’m not specifically experienced, and bring my general knowledge to bear in ways that have allowed me to substantially improve that software beyond what those natively expert in the domain of the tools and frameworks in use have done. I’ve been able to lead successful efforts to make the software far more robust — even though I’m not an expert in the language or frameworks.
I’ve been able to brow-beat the machine into producing code of high enough quality that it’s within reason that a human could maintain it. It is possible with experience to tell it to do better in specific ways.
The default code quality deteriorates rapidly without actively correcting the machine’s actions. It’s really bad at following the DRY principle. Unless you strongly direct it otherwise, it writes many subtly different copies of the same thing in hundreds of places through the code, making the user experience subtly inconsistent. (This is generally true of multiple LLMs.)
On the good side, almost everyone hates writing tests even if they love tests existing, and the robot can usually be easily convinced to write tests — though often testing the same thing in ten different brittle ways. I have to challenge it, “what does this test add?” and it says “oh, you are right, it is useless” (though usually not acknowledging that it’s worse that useless because it slows down the test suite and speed is critical). It’s also good at adjusting brittle tests; you just have to make sure that what it’s changing then to makes sense.
Sometimes, it will remove code and then write a permanent test to ensure that the code was removed, and leave it in there to run indefinitely. Lots of stupid excess like this sometimes makes me feel like the CI providers must be paying them kickbacks! 
(I know they aren’t, it’s just a joke…)
For work that requires large quantities of structural but mechanical change, LLMs are hard to beat. A few people were able to do some of this semantic transformation with tools like Coccinelle, but LLMs make this generally not that hard. I just had the robot army build almost 8000 lines of hardening that would have taken me probably 20x as long to do by hand. It was in a code base moving fast enough that actually I would never have finished because I’d have hit a conflict by the time I was finished fixing the previous conflict and trying to merge…
I now rarely hand-code at work. But I never vibe-code as I define it. If the robot does something that requires knowledge I don’t have to effectively review, I go to a domain expert, tell them what I have reviewed myself and what I don’t understand, so that I’m being honest about what I can stand behind and what I can’t, and what I’m asking for. I don’t just say that I “wrote” it and ask them to review it as such. To me, that would be anti-social…
It really matters which model I’m using. With Claude, if I accidentally use a dumb model like sonnet, it can go off the rails and waste my time unless the change is purely mechanical. Opus or fable do better right now. (The details of which models can do what seem to change about monthly, though…) I’ll often tell opus to use sonnet subagents to do work not requiring judgment, and opus for subagents that do require judgment. Being really aggressive about using subagents tends to conserve token space in the parent agent. When an agent runs low on tokens, it gets dumb before it runs out. It’s like a filesystem getting really slow before it completely runs out of space…
We have multiple AI agents reviewing our code at work. They often disagree, and even one agent will ask for a change and then the other agent will complain about the change and insist on it being reverted. This is an amazingly accurate re-implementation of one of the annoying traits of human reviewers.
Personally, I have been doing an experiment asking Gemini to build me a specific piece of ham radio software. It did… ok initially. But I’m not that impressed with it often. I have to keep an eagle eye on its output. It regularly creates regressions, changes behavior when I ask for a pure refactor, drops tests for no reason; it’s like working with a bright but half-witted intern with shifting and bad opinions. Ultimately I just have to take over and drive more. It was still a net win for time vs hand-coding, but less so. At least “add tests for current behavior, refactoring and adding interfaces to make more code testable” is usually within its happy place, as long as I review carefully that it hasn’t just gotten opinionated. When it starts giving me lectures on software architecture that are wildly misplaced (this is, after all, literally my job) I have to slap it down really hard to make it stop. And sometimes it just can’t see how to do a simple task and I just take the wheel and tell it to stand down.
Yeah, that almost sounds like more work than just writing it oneself.
But it can ‘type out’ code at brutally fast speeds in large quantities. Michael confirms what I’ve thought when a really good coder friend told me he didn’t physically code any more and uses Claude AI instead. He’d said it’s still a lot of work but it’s now in the domains of planning, directing and validating. Things he’s always done except now he’s having to ‘verbalize’ it to the AI developer.
My take-away is that skilled developers still need to be in control of the AI and any company which thinks otherwise won’t be around past v1.x code release date. If schools and businesses stop computer science training and hiring because “AI can do the coding” there’s going to be a reconning.
reckoning, but yes, agreed.
I’ve been more interested in the low-level stuff for a while, so my usage definitely doesn’t play to the strengths of LLM.
Very true. The largest issue will be years from now when the seasoned coders who can actually read what the AI produces and make the correct changes are no longer around because everyone has only used AI for coding.
One of my biggest frustrations, as Michael has pointed out, is AI loves to change the code even when it is not asked to do so.
All the old idioms still apply, garbage in garbage out, the tool is only as good as the operator, and the right tools for the right jobs.
Well… Sometimes it is more tiring. The hardest part is reading and understanding potentially voluminous code. But it’s not a new problem exactly; we’ve had developers for decades who throw code at others in an unhelpful way. It’s just that the LLMs can do that more. On the other hand, you can often get the LLM to “explain” the code in a way that makes it useful, and sometimes you can get them to remove the vast swathes of useless comments that obscure the code and replace them with occasional actually useful comments. My experience with developers like this was that they were not so willing to explain. But the comments. Oh, the comments.
But at least with the more expensive models, they honor their instructions enough to make it possible to move substantially faster even after dealing with their oddities.
You still have to hold their virtual feet to the fire though!
A lot of the coding job becomes more like being a manager. This is easier for me than some folks because I’ve been both a manager and a developer for over a quarter of a century. Folks who didn’t enjoy management sometimes don’t like managing the 
army either.
I’m not sure that follows now. For example, a ham, OZ1LAV Steffen, has been building some very complex software for the M5Stack Tab5 for controlling a particular ham radio. He’s been doing the experiment of doing the whole thing with Claude. When I read the code a few months ago, I found it human-readable. He’s been able to carefully juggle fairly sparse resources to build something fairly complex and complete in hardware typical of an embedded system.
A year+ ago, I said that LLMs were OK for “green field” build-from-scratch but couldn’t handle complex subtle existing code. Today, I think they are sometimes better in mature code bases because they have more patterns to follow, whereas when they are being used to build something from scratch, they will come up with something but sometimes it’s a mish-mash of patterns that they mindlessly copy and paste from stack overflow, and you really have to push them to do better.
Now, none of that means that any particular developers should choose to use them. This is a personal choice, at least where it’s not dictated as an aspect of the work environment.
One of the things some people miss when using LLMs is the direct practice of writing code. I like writing code. But while I’ve actually been very particularly good at quickly applying a pattern across large code bases, to the point that it’s been a specialty of mine for my whole working career, once the pattern is established, it’s just work for me, no longer fun. So telling the LLM “read the pattern I just wrote in these three files and apply it throughout the rest of the code base” relieves tedium even for me — and it’s even faster at it than I have been. Not trustworthy though. The amount of monitoring I have to do to tell it to stop being lazy is frustrating.
In general, LLMs have been trained on so many humans telling other humans to be lazy and 'splaining at them about YAGNI (ya ain’t gonna need it) etc. has turned into some spectacularly bad advice from LLM agents that results in bad architecture. The agents can’t seem to realize when I’m being an architect setting new, robust patterns, and even though there’s only one instance here I know this is going to be copied in the future. They get offensively opinionated about how they know more than I do. They remind me of some of the worst smart developers with no judgement I’ve worked with over the years.
A huge concern right now is that already-experienced developers can steer these agents effectively. This is reducing the opportunity for less-experienced developers to learn the lessons the hard way that the currently-experienced developers had. Absolutely none of the already-experienced developers are getting younger. I am concerned that the industry as a whole has no effective plans for bringing up the next generation of developers with good judgement.
Still the best explanation I’ve seen of how to work effectively with LLMs is https://drensin.medium.com/elephants-goldfish-and-the-new-golden-age-of-software-engineering-c33641a48874 — there are minor things that I disagree with, like comments at least every ten lines, since I think AI is rabidly eager to substitute horrible narrative irrelevant comments everywhere instead of writing clear code that mostly doesn’t need comments but the big picture is, I think, particularly relevant.
All that said — from the context of someone required to use LLMs at work — I completely respect those who make different principled decisions about how they are going to use LLMs. I’m as salty as anyone about not being able to buy RAM or flash for less than an arm and a leg right now. 
And the economics around the LLM datacenter explosion just don’t compute, even ignoring the environmental costs. I frankly assume that there’s going to be a combination of a business collapse of those who don’t win and some fundamental hardware changes that change the economics in the next couple years, and I hope the damage is constrained somehow.
