I never understood vibe coding (or ✨Agentic Coding✨) tbh.
May be I am too stupid, but I think as I code and code as I think. I do not usually formulate a plan before I start coding. I am categorizing architecture as code btw because, for me, architecture involves pseudo-code to some degree .
Even in college, I could never just understand lectures. I needed to write down the formulas and work out the derivations myself to grasp them. I know there are people who understand things right away, but I am not one of them.
So, now, when I see senior developers (which I am not) vibe code green field projects, I am just astounded as to how they manage the architecture + understanding + optimization + maintenance context.
I am just astounded as to how they manage the architecture + understanding + optimization + maintenance context.
They don’t. They fuck it the shit up. While AI huffers will not hesitate to tell me that actually a hypothetical blabla bla blabla, I have yet to see an agentic coder make something that holds up to reality, safety, reliability, or maintenance.
Because agentic coders are dogshit, that’s why. It’s like having a Roomba with a staple gun go fix up your carpentry. It’s dogshit.
Maybe if someone built a Roomba gaurdrail. Ensured the Roomba always marked its work with pencil first, then got human approval to proceed. Ensured the Roomba can’t drive away from its rails. Ensured the Roomba can automatically detect errors and undo+retry. Ensured the Roomba can (and more importantly: cant) do all kinds of shit… then maybe you can have a Roomba which adequately augments the work of a professional. You still don’t have a Roomba that can replace anybody, except maybe the professional’s new apprentice. Why the fuck would you want to replace an apprentice, though? Apprentices turn into an professionals, unlike Roombas.
I’ve done it because work is ✨desparate✨ and required I try it to learn it for some reason. I’m at a senior level. Generally I instructed it on the exact architecture and patterns I wanted, along with the broad classes and algorithms required. That meant it was left to do the individual procedure implementation that I might have instructed a junior developer to do while I managed more macro level concerns. It did surprisingly well, but this was on a greenfield project, so It would probably become excessively slow and error prone on a sufficiently large project.
For very specific projects I get it. If I want a tool that does X and X is easily verifiable, and I don’t want to learn anything from coding it, then AI might do it very well.
So, now, when I see senior developers (which I am not) vibe code green field projects, I am just astounded as to how they manage the architecture + understanding + optimization + maintenance context.
My experience is, they’re not. Like the article says they are just focused on MOAR and not on the quality of the output. It may take years for the unmaintainable code to cause problems, and they may have already been laid off by the time that happens, anyway .
I don’t write much code anymore, but when I did, there was a fair amount of embedded code, where fixing a bug is more costly than just pushing out a build to a production server. I actively sought out automation back then, but the purpose of the automation was to help cover edge cases and better test the embedded code for flaws that traced through multiple layers of code.
Whenever I start a new software project, it usually starts with a short period of experimentation when I try out several things. Then, I coalesce on an architecture in my head (and eventually document it), and once I do that I can add more structure to the code.
Given the state of the AI tools today, I can see myself using them to accelerate all the little fiddly parts of this (especially if I can give it a coding standard and have it stick to it). But I wouldn’t trust it more than that. I would always keep the archictecture separate, because I don’t trust the AI tools to change it on me for no good reason.
(especially if I can give it a coding standard and have it stick to it)
Hoooooh boy, that if is doing a lot of heavy lifting, in my experience. I’m constantly telling the stupid little stochastic fuck to follow basic coding standards I’ve given it.
I don’t use a lot of AI tooling outside of debugging and a little bit into command discovery, but fuck if the little shit isn’t constantly rewriting my code into a shit style that I hate and constantly correct.
One of my bosses has been a little Ai-pilled recently and he also contributes code.
I can tell which parts are his AI slop not from any git blame or anything but because of how it looks. You can see the stylistic differences in a block of code from one file to the next, and also it seems like AI likes to add comments to everything, and he just copy and pastes it all into the file. Those comments are often very different looking, too. So just stylistically everything is all over the place.
So, just like any team project.
Everyone has their own style, but Bob over here doesn’t change his style every day. Before, my boss had their own style, and if I ended up working on their code I’d try to match that just to keep things consistent. But now it’s all over the place.
AI slop just flops out whatever it feels like at any given time since it’s just cribbing everything from the internet.
I actively sought out automation back then
So did I, it was called C compilers so I didn’t have to do hand coded assembly. They turned out O.K. after the first few buggy generations.
Like the article says they are just focused on MOAR
Then they’re doing it wrong.
Those are all great habits.
But the time spent doing that is time not shipping code. Most companies don’t give a flying fuck about quality, they just want to ship as much as possible to make as much money as possible.
When the cost to ship trash code trends toward zero, then there will not be value in shipping trash code. Companies will need to focus on software that is actually competitive (in a qualitative way) because otherwise their customers will just self-vend the slop code.
Based on my time in the corporate world, the new meta will probably be about how well you can hide the slop in your SaaS until you have enough of their data in your servers to make migration impractical.
I think you have something backwards. When the cost to ship trash code trends to zero, the profit trends to infinity.
The cheaper it is to produce slop code, the less the demand there will be to buy it. Companies will self-vend instead of buying the slop being sold. Your profit margins are someone else’s inefficiency.
It’s hard to determine whether something is slop before you buy it.
Not beating the association between AI and scams with this one.
architecture involves pseudo-code to some degree
Clue: you can vibe-code pseudo-code. Hell, I vibe-coded a season of screen-plays for a TV series. Once you’re comfortable with the architecture and requirements, then have your agent do a “readiness review” to ensure it thinks you’ve specified everything well enough to code it, then have it plan implementation and execute the plan, and review the output to ensure it’s all consistent with all that documentation, and iterate on the reviews until you’re happy that the only “problems” it’s finding are inconsequential.
Then hand it over to an independent human test team. Like you always should have been doing without LLMs anyway.
I do not usually formulate a plan before I start coding
Oh noooo
Ha ha, may be that came out a bit wrong. What I meant is I don’t have a complete understanding of the architecture and the structure before I start coding. It is only when I write the first test and the first function that I start noticing the structure and the limitations. I can’t think of all the branches where the code might fail unless I start writing and realizing the
elses.This is the mark of a good engineer, don’t let anyone neg you for engaging with problems with your whole brain.
It is only when I write the first test and the first function that I start noticing the structure and the limitations
To an extent, you can do this with “the vibe” as well, you just have to stay engaged, do lots of reviews (by which I mean, have the LLM review for you and explain what it finds) and when you decide the architecture needs to be revised, do it - in writing. Your requirements and architecture should be “living documents” developed at least a little bit ahead of the code implementation, and if the current implementation is too far removed from your current vision of how things should fit, throw it out and re-implement from the requirements and revised architecture documents. That’s one huge benefit of a tool that writes code so quickly, it’s much less costly to throw it all out and start over.
It’s all vibes mannnn.
He was vibin’ before it was cool
My wife tells me vibin’ was always cool.
Coding for fun is fine. Not everything has to be optimized.
Edit: Oh it’s you. The weird AI guy.
I know of some companies where they write up a full spec in markup, and have the ai code from that. They claim it works well, but that seems like extra work.
Personally, most of my coding is maintenance and AI sucks at that. I can get the ai to give me good recommendation, but not usable code. I have had it do a good job writing utility scripts such as data extraction, and tests - it can even save me time
So if you have a greenfield project, and are able to give it sufficient context, people claim it can work …… I’m highly doubtful it’s maintainable though, and maintenance cost is far higher than the cost of initial creation. I really think these companies are digging a hole for themselves
Of course I’m taking advantage of this
- scheduling extra refactoring on the claim that maybe AI can be useful with cleaner code
- fun and games to give AI more context, in case that can make it useful
I wonder if someone will make bank by playing around with AI coding enough to understand what errors AI is most likely to make and then just market your services and contract out for emergency AI fixes. Tons of stress and would have to manage your own benefits, but I imagine oodles of money.
My company is working on one such product. So far AI has essentially no guardrails so can too easily go from potentially helpful to harmful. There’s nothing keeping it from sharing confidential data, like customer data, nothing looking at whatever dreck it’s pulling in from the internet, and nothing keeping it from doing harm internally. We can do that.
But most of the more immediate harm is poor practices that we’ve known for decades. Maybe consultants can make bank by pushing best practices we should have followed all along. That article that keeps coming around Lemmy about losing their production database and backup in 9 seconds is a great example. Sure, that LLM needed guardrails to stop that, but any normal best practices would also have prevented that
I’ve seen some baby steps
- LLMs with “planning” mode that shouldn’t make changes until approved …… except when they ignore that
- IDEs with sandbox where you need to whitelist allowed LLM invocations, except there’s too much noise so too many people allow all
- MCP servers with a read-only mode, or allowing configuring credentials to be read-only
Funny how Marx never actually worked, like, ever, so his first time is never.
Devs are reverse centaurs now.
Lines of code was never a good metric, but it looks like productivity to the C-suite. This will bite them (and everyone who uses the code) in the ass. After some spectacular fails it will be judgement that a Dev is most prized for, meanwhile, this.
Still, eight to ten productive hours a day in any sustained fashion is bullshit, more like 3-4 with a bunch of meetings, learning, deciphering etc. filling out the day.
Still, eight to ten productive hours a day in any sustained fashion is bullshit, more like 3-4 with a bunch of meetings, learning, deciphering etc. filling out the day.
That’s the norm for cube-farmed drones. As Work From Home I have more opportunity for focused development time and I can actually pull off a couple of 4 hour productive sessions in a day, but those distraction items still pile up.
Something interesting about vibe coding, lately, is that the LLMs are doing bigger and bigger chunks of work, and even when they come back with a prompt, frequently all you have to say is “continue” to keep them chewing away on a big development plan. This means, after you have got decent requirements and implementation plan in place, your minions do the work with minimal direction - freeing you for the important tasks like corporate documented training sessions, skimming through the inbox - I don’t like to simultaneously participate in a conference call and vibe code, but if it’s a passive “listen only” experience that’s usually multi-taskable with the periodic “continue” prompt.
Just like human written code, if you spend extra iterations vibe coding you can shake out more bugs, identiy DRY (Don’t Repeat Yourself) and SSOT (Single Source Of Truth) opportunities that make your LOC count leaner and your code easier to maintain.
If you just ship the first thing that seems to work… yeah, that’s going to look horrible when you revisit it after a few years.
I do a lot of “disconnected coding,” think scripts that do a long and complicated calculation, triggered manually by a few users, and aren’t online services. In these cases vibe coding is pretty great: if something doesn’t work the first time, I can iterate easily till it does. Very few consequences in getting it wrong other than time. My hand is also very firmly on the wheel and I have a lot of time to think about changes to fix issues or make things better.
Now for an online service with very specific requirements on how it handles inputs and produces outputs, at scale, with security issues, and millions of people using it…yeah I’d be pulling my hair out too if I had to vibe code all that.
I’d be pulling my hair out too if I had to vibe code all that.
Spoiler alert: the teams have been pulling their hair out doing all that for decades without vibe coding it.
till
Cha-ching!
You find yourself signing off on an overwhelming amount of raw code just to keep up with the output that’s expected these days.
Then you’re doing it wrong, very very wrong. And any management that expects you to “just read faster” is management you should be distancing yourself from at maximum possible speed.
No, you can’t review the volume of code that LLMs output, one engineer driving an LLM code generator can create code faster than 10 engineers can review it. However, one engineer driving an LLM code generator, then driving the same and other LLMs to review that code for correctness can.
You can, and also should, be developing documented requirements for EVERYTHING the code is doing - LLMs help accelerate that process too.
You can, and also should, be developing unit and integration tests which ensure that your implementation doesn’t regress as new features are added. LLMs help accelerate that process too.
You can, and also should, be using LLMs to review the requirements, implementation and tests to ensure they are all synchronized, aligned, saying what they do and doing what they say. LLMs help accelerate that process too.
You can, and also should, be doing all of the above for software developed without LLMs, but in my experience the vast majority of teams don’t do good implementation of all the pieces. LLMs are an opportunity to start.
