Vibe coding creates fatigue?(tabulamag.com) |
Vibe coding creates fatigue?(tabulamag.com) |
I recently used a coding agent on a project where I was using an unfamiliar language, framework, API, and protocol. It was a non-trivial project, and I had to be paying attention to what the agent was doing because it definitely would go off into the weeds fairly often. But not having to spend hours here and there getting up to speed on some mundane but unfamiliar aspect of the implementation really made everything about the experience better.
I even explored some aspects of LLM performance: I could tell that new and fast changing APIs easily flummox a coding agent, confirming the strong relationship of up-to-date and accurate training material to LLM performance. I've also seen this aspect of agent assisted coding improve and vary across AIs.
I'm not a professional SWE, I just know enough to understand what the right processes look like, and vibe coding is awesome but chaotic and messy.
If frameworks don't make sense for what you're doing though and you're now relying on your LLM to write the core design of your codebase... it will fall apart long before you reach "its basically working".
The more nuanced interactions in your code the worse it'll do.
There is a big difference between vibe coding and llm assisted coding and the poster above seems to be aware of it.
It was already obvious from your first paragraph - in that context even the sentence "everything works like I think it should" makes absolute sense, because it fits perfectly to limited understanding of a non-engineer - from your POV, it indeed all works perfectly, API secrets in the frontend and 5 levels of JSON transformation on the backend side be damned, right ;) Yay, vibe-coding for everyone - even if it takes longer than the programming the conventional way, who cares, right?
The exuberance of rapid early-stage development is mirrored by the despair of late-stage realizations that you've painted yourself into a corner, you don't understand enough about the code or the problem domain to move forward at all, and your AI coding assistant can't help either because the program is too large for it to reason about fully.
AI lets you make all the classic engineering project mistakes faster.
It depends. No one is running their brain at full-throttle for more than a few hours on end.
If your "niggling" defects is mostly changes that don't require deep thought (refactor this variable name, function parameters/return type changes, classes, filename changes, etc), then I can see how it is energising - you're getting repeated dopamine hits for very little effort.
If, OTOH, you are doing deep review of the patterns and structures the LLM is producing, you aren't going to be doing that for more than a few hours without getting exhausted.
I find, myself, that repeatedly correcting stuff makes me tired faster than simply "LGTM, lets yolo it!" on a filename change, or class refactor, etc.
When the code I get is not what I wanted even though it passes the tests, it's more mental energy to correct the LLM than if I had simply done it myself from the first.
A good example of the exhausting tasks from today - my input has preprocessing directives embedded in it; there's only three now (new project), so the code generated by Claude did a number of `if-then-else-if` statements to process this input.
My expectation was that it would use a jump table of some type (possibly a dictionary holding function pointers, or a match/switch/case statement).
I think a good analogy is self-driving cars: if the SDC requires no human intervention, then sure it's safe. If the SDC requires the human to keep their hand on the wheel at all time because it might disengage with sub-second warnings, then I'm going to be more tired after a long drive than if I simply turned it off.
It's often that just getting started at all on a task is the hardest part. That's why writers often produce a "vomit draft" (https://thewritepractice.com/vomit-first-draft/) just to get into the right frame of mind to do real writing.
Using a coding agent to fix something trivial serves the same purpose.
At some point you realize if you want people to trust you you have to do this. Otherwise you’re just gambling, which isn’t very trustworthy.
It’s also got the cumulative effect of making you a good developer if done consistently over the course of your career. But yes, it’s annoying and slow in the short term.
You, too, can be awarded the Order of Labor Glory, Third Class.[1]
Is that contrarian though? Seems like pretty normal corparate setting bragging to me. (Note: I am not accusing you of it since your boss or collegues does not read this).
On the variant of "I am bad at not working too hard".
You didn’t find that to be a little too much unfamiliarity? With the couple of projects that I’ve worked on that were developed using an “agent first” approach I found that if I added too many new things at once it would put me in a difficult space where I didn’t feel confident enough to evaluate what the agent was doing, and when it seemed to go off the rails I would have to do a bunch of research to figure out how to steer it.
Now, none of that was bad, because I learned a lot, and I think it is a great way to familiarize oneself with a new stack, but if I want to move really fast, I still pick mostly familiar stuff.
I was ready to find that it was a bit much. The conjunction of ATProto and Dart was almost too much for the coding agent to handle and stay useful. But in the end it was OK.
I went from "wow that flutter code looks weird" to enjoying it pretty quickly.
So don't. It is vibe coding, not math class. As long as it looks like it works then all good.
AI removes boredome AND removes the natural pauses where understanding used to form..
energy goes up, but so does the kind of "compression" of cognitive things.
I think its less a quesiton of "faster" or "slower" but rather who controls the tempo
compression is exactly what is missing for me when using agents, reading their approach doesn't let me compress the model in my head to evaluate it, and that was why i did programming in the first place.
But I 100% agree. It's liberating to focus on the design of my project, and my mental model can be of how I want things to work.
It feels like that switch to test driven development where you start from the expected result and worry about the details later.
To your point, you can blow through damn-near anything pretty quickly now. Now I actually find myself problem-solving for nearly 8 hours every day. My brain feels fried at the end of the day way more than it used to.
I used to be like: "well, this thing will take me at least half a day, it's already 16:00, so I'll better do something quiet to cooldown to the end of the day and tackle this issue tomorrow". I'll leave the office in an regular mood and take the night to get ready for tomorrow.
Now I'm like: "17:30? 30 minutes? I have time to tackle another issue today!" I'll leave the office exhausted and take the night to try and recover from the day I had.
I agree it can be energizing because you can offload the bullshit work to a robot. For example, build me a CRUD app with a bootstrap frontend. Highly useful stuff especially if this isn't your professional forte.
The problems come afterwards:
1. The bigger the base codebase generation the less likely you're going to find time or energy to refactor LLM slop into something maintainable. I've spent a lot of time tailoring prompts for this type of generation and still can't get the code to be as precise as something an engineer would write.
2. Using an unfamiliar language means you're relying entirely on the LLM to determine what is safe. Suppose you wish to generate a project in C++. An LLM will happily do it. But will it be up to a standard that is maintainable and safe? Probably not. The devil is in the mundane details you don't understand.
In the case of (2) it's likely more instructive to have the LLM make you do the leg work, and then it can suggest simple verifiable changes. In the case of (1) I think it's just an extension of the complexity of any project professional or not. It's often better to write it correct the first time than write it fast and loose and then find the time to fix it later.
Red flag. In other words you don’t understand the implementation well enough to know if the AI has done a good job. So the work you have committed may work or it may have subtle artefacts/bugs that you’re not aware of, because doing the job properly isn’t of interest to you.
This is ‘phoning it in’, not professional software engineering.
At least when the AI does it you can review it.
Red flag again! If your protection is to "understand the implementation" it means buggy code. What makes a code worthy of trust is passing tests, well designed tests that cover the angles. LGTM is vibe testing
I go as far as saying it does not matter if code was written by a human who understands or not, what matters is how well it is tested. Vibe testing is the problem, not vibe coding.
But we're seeing that this becomes OK in the workplace, and I don't believe it is.
If you propose these changes that would've normally taken you 2 weeks as your own in a PR, then I, as the reviewer, don't know where your knowledge ends and the AI's hallucinations begin.
Do you need to do all of these things? Or is it because the most commonly forked template of this piece of code has this in its boilerplate? I don't know. Do you?
How can you make sure the code works in all situations if you aren't even familiar with the language, let alone the framework / API and protocol?
* Do you know that in Java you have to do string.Equals instead of == for equality?
* Do you know in Python that you assigning a new value to a function default persists beyond the function?
* And in JavaScript it does not?
* Do you know that the C# && does not translate to VB.NET's And?This has always been a problem in software engineering; of course -- sometimes staff have left, so you have to dig through tickets, related commits and documentation to intuit intent. But I think it's going to make for very weird drags on productivity in _new_ code that may not counter the acceleration LLMs provide, but will certainly exist.
vs. what this author is doing, which seems more like agent assisted coding than "vibe" coding.
With regard to the subject matter, it of course makes sense that managing more features than you used to be able to manage without $AI_MODEL would result in some mental fatigue. I also believe this gets worse the older you get. I've seen this within my own career, just from times of being understaffed and overworked, AI or not.
I've found that if an LLM writes too much code, even if I specified what it should be doing, I still have to do a lot of validation myself that would have been done while writing the code by hand. This turns the process from "generative" (haha) to "processing", which I struggle a lot more with.
Unfortunately, the reason I have to do so much processing on vibe code or large generated chunks of code is simply because it doesn't work. There is almost always an issue that is either immediately obvious, like the code not working, or becomes obvious later, like poorly structured code that the LLM then jams into future code generation, creating a house of cards that easily falls apart.
Many people will tell me that I'm not using the right model or tools or whatever but it's clear to me that the problem is that AI doesn't have any vision of where your code will need to organically head towards. It's great for one shots and rewrites, but it always always always chokes on larger/complicated projects, ESPECIALLY ones that are not written in common languages (like JavaScript) or common packages/patterns eventually, and then I have to go spelunking to find why things aren't working or why it can't generate code to do something I know is possible. It's almost always because the input for new code is my ask AND the poorly structured code, so the LLM will rarely clean up it's own crap as it goes. If anything, it keeps writing shoddy wrapper around shoddy wrappers.
Anyways, still helpful for writing boilerplate and segments of code, but I like to know what is happening and have control over how my code is structured. I can't trust the LLMs right now.
I take breaks.
But I also get drawn to overworking ( as I'm doing right now ), which I justify because "I'm just keeping an eye on the agent".
It's hard work.
It's hard to explain what's hard about it.
Watching as a machine does in an hour what would take me a week.
But also watching to stop the machine spin around doing nothing for ages because it's got itself in a mess.
Watching for when it gets lazy, and starts writing injectable SQL.
Watching for when it gets lazy, and tries to pull in packages it had no right to.
We've built a motor that can generate 1,000 horse power.
But one man could steer a horse.
The motor right now doesn't have the appropriate steering apparatus.
I feel like I'm chasing it around trying to keep it pointed forward.
It's still astronomically productive.
To abandon it would be a waste.
But it's so tiring.
This statement resonates with me. Vibe coding gets the job done quickly, but without the same joy. I used to think that it was the finished product that I liked to create, but maybe it's the creative process of building. It's like LEGO kits, the fun is putting them together, not looking at the finished model.
On the flip side, coding sessions where I bang my head against the wall trying to figure out some black box were never enjoyable. Nor was writing POCOs, boilerplate, etc.
They ask a business question to the AI and it generates a bunch of code.
But honestly, coding isn't the part that slowed me down. Mapping the business requirements to code that doesn't fail is the hard part.
And the generated PRs are just answers to the narrow business questions. Now I need to spend time in walking it all back, and try to figure out what the actual business question is, and the overall impact. From experience I get very little answer to those questions.
And this is where Software Engineering experience becomes important. It's asking the right questions. Not just writing code.
Next to that I'm seeing developers drinking the cool-aid and submitting PRs where a whole bunch of changes are made, but they don't know why. Well, those changes DO have impact. Keeping it because the AI suggested it isn't the right answer. Keeping it because you agree with the AI's reasoning isn't the right answer either.
It's now 11:47am and I am mentally exhausted. I feel like my dog after she spends an hour at her sniff-training class (it wipes her out for the rest of the day.)
I've felt like that on days without the meetings too. Keeping up with AI tools requires a great deal of mental effort.
To people with little to no practical software experience, I can see why that seems incredible. Think of the savings! But to anyone who's worked in a legacy code base, even well written ones, should know the pain. This is worse. That legacy code base was at least written with intention, and is hopefully battle tested to some degree by the time you look at it. This is 20k lines of code written by an intern that you are now responsible for going through line by line, which is going to take at least as long as it would have to write yourself.
There are obvious wins from AI, and agents, but this type of development is a bad idea. Iteration loops need to be kept much smaller, and you should still be testing as you go like you would when writing everything yourself. Otherwise it's going to turn into an absolute nightmare fast.
...almost as if it's too eager to make its first commit. Much like a junior engineer might be.
It's not eager enough to iterate. Moreover, when it does iterate, it often brings along the same wrong solutions it came up with before.
It's way easier to keep an eye on small changes while iterating with AI than it is with letting it run free in a green field.
Usually that requires saying something, seeing if the other person understands what I'm saying, and occasionally repeating myself in a different way.
It can be real tiring when I'm with friends who only speak the other language so we're both using translator tools and basically repeating that loop up to 2-3 hours.
I've found the same situation with vibe coding. Especially when the model misunderstands what I want or starts going off on a tangent. sometimes it's easier to edit the original query or an earlier step in the flow and re-write it for a better result.
Choosing, analysing, verifying, talking to others rather than thinking in a sequential and organised way.
One of the reasons I moved away of that position was this constant fatigue by the end of the day. I was happy on seeing things moving forward but it felt that it took more energy to do less
If you're able to blaze through feature tickets using GenAI on existing projects of any major complexity, there's almost certainly something which would produce better code that you're skipping.
I have plenty of info and agents for Claude Code to take into account when I use it to make features in our projects, but what it can't know is the cadence of what our business partners expect, the unknown unknowns, conversations that humans have about the projects, and the way end-users feel about the project. My job is to direct it with those factors in mind, and the work to account for those factors takes time.
This fine for WFH/remote work. It didn't have great optics when I went back to in-office for a bit.
Maybe the fatigue comes from that mismatch?
The classical vibe coder style is to just ignore verification. That's not a good approach as well.
I think this space has not matured yet. We have old tools (test, lint) and some unreliable tools (agent assisted reviews), but nothing to match the speed of generation yet.
I do it by creating ad-hoc deterministic verifiers. Sometimes they'll last just a couple of PRs. It's cheap to do them now. But also, there must be a better way.
Coolest bit of research I cam across was what the brain does during sleep. It basically reduces connection during this. But it also makes you hallucinate (sleep). This was found in researching fish and also training LLMs there's great value in "forgetting" for generalization.
After studying it in LLMs for awhile I also came to your same conclusion about my own brain. Problems are often so complex you must let your brain forget in order to handle the complexity in the same sense I also believe this is the path to AGI.
How'd you reckon?
However, when it comes to my professional work on a mature, advanced project, I find it much easier to write the code myself than to provide a very precise specification without which the LLM wouldn't generate code of a sufficiently high quality.
Then lots of people were introduced to the term "vibe coding" in these conversations, and so naturally took it as a synonym for using LLMs for coding assistance even when reading the code and writing tests and such.
Also because vibe coding just sounds cool.
A negative but courteous remark is "slamming", a tweet is an "attack", etc.
So yeah I'm not surprised that people conflate any use of AI with vibe-coding.
Personally I think "vibe-coding" has semantically shifted to mean any AI-assisted coding and we should just run with it. For the original meaning of vibe-coding, I suggest YOLO-Coding.
Agreed. I've seen some folks say that it requires absolute ignorance of the code being generated to be considered "vibe coded". Though i don't agree with that.
For me it's more nuanced. I consider a lack of review to be "vibed" related to how little you looked at it. Considering LLMs can do some crazy things, even a few ignored LOC might end up with a pretty "vibe coded" feelings, despite being mostly reviewed outside of those ignored lines.
Or here: https://en.wikipedia.org/wiki/Vibe_coding
Not looking at the code at all by default is essential to the term.
My interpretation is that you can look at the code but vibe coding means ultimately you're not writing the code, you're just prompting. It would make sense to prompt "I'd like variable name 'bar' to be 'foo' instead." and that would still be vibe coding.
The key difference is still the prompts and knowing what to reference/include in the context.
Do you believe that atrophy is not a real thing?
I've found that LLMs massively over-engineer things, regardless of the prompt used. How do you counter that without going back and forth at least a few times?
I could see other elements of isolation being useful, but this kind of feels like a lot of extra work and complexity which is part of the issue...
The other tax is the intermittent downtime when you are waiting for the LLM to finish. In the olden days you might have productive downtime waiting for code to compile or a test suite to run. While this was happening you might review your assumptions or check your changes or realize you forgot an edge case and start working on a patch immediately.
When an LLM is running, you can't do this. Your changes are being done on your behalf. You don't know how long the LLM will take, or how you might rephrase your prompt if it does the wrong thing until you see and review the output. At best, you can context switch to some other problem but then 30 seconds later you come back into "review mode" and have to think architecturally about the changes made then "prompt mode" to determine how to proceed.
When you are doing basic stuff all of this is ok, but when you are trying to structure a large project or deal with multiple competing concerns you quickly overwhelm your ability to think clearly because you are thinking deeply about things while getting interrupted by completed LLM tasks or context switching.
Like when I'm asking it to run a bunch of tests against the UI using a browser tool, and something doesn't work. Then it goes and just writes code to update the database instead of using the user element.
My other thing that makes me insane is when I tell it what to do, and it says, "But wait, let me do something else instead."
Make it stop. Tell it to review whether the code is cohesive. Tell it to review it for security issues. Tell it to review it for common problems you've seen in just your codebase.
Tell it to write a todo list for everything it finds, and tell it fix it.
And only review the code once it's worked through a checklist of its own reviews.
We wouldn't waste time reviewing a first draft from another developer if they hadn't bothered looking over it and test it properly, so why would we do that for an AI agent that is far cheaper.
Even using it to spitball ideas can be a problem. I was using Claude to bounce ideas off of for a problem I was working on it, and it was dead set a specific solution involving a stack and some complex control logic was correct, when it reality it would have made the entire solution far more complicated. All I really needed was a sliding window into an array.
[0] Which becomes painfully obvious when one ages, as all kinds of things start to hurt, and one doesn’t have a good understanding of why exactly, and how to stop it.
Which is why you spend time upfront becoming familiar with whatever it is you need to implement. Otherwise it’s just programming by coincidence [1], which is how amateurs write code.
> and are probably going to even insert more footguns than the AI.
Very unlikely. If I spend time understanding a domain then I tend to make fewer errors when working within that domain.
> At least when the AI does it you can review it.
You can’t review something you don’t understand.
[1] https://dev.to/decoeur_/programming-by-coincidence-dont-do-i...
I don't think so. We gain proficiency by doing, not by reading.
If all you are doing is reading, you are not gaining much.
[1] https://skepchick.org/2020/10/the-dunning-kruger-effect-misu...
I still check the output but it is starting to feel like a sanity check more than a code review.
(Sorry, but you set yourself up for this one, my apologies.)
Oh, so this post describes "worthy code", okay then.
https://news.ycombinator.com/item?id=18442941
Tests are not a panacea. They don't care about anything other than what you test. If you don't have code testing maintainability and readability, only that it "works", you end up like the product in that post.
Ultimate example: Biology (and everything related, like physiology, anatomy), where the test is similarly limited to "does it produce children that can survive". It is a huuuuuge mess, and trying to change any one thing always messes up things elsewhere in unexpected and hard or impossible to solve ways. It's genius, it works, it sells - and trying to deliberately change anything is a huge PITA because everything is interconnected and there is no clean design anywhere. You manage to change some single gene to change some very minor behavior, suddenly the ear shape changes and fur color and eye sight and digestion and disease resistance, stuff like that.
Hilarious. Understanding the code is literally the most important thing. If you don't understand the code then you can't understand any unit tests you write either. How could you possibly claim test coverage for something you don't understand?
I suspect you primarily develop code with dynamic languages where you're reinventing type-systems day-in day-out to test your code. Personally, I try to minimise the need for unit-tests by using well-defined types and constraints. The type-system is a much better unit-tester than any human with a poor understanding of the code.
I feel like it would just yield a well-formatted, type safe incorrect solution, which is no better than a tangled mess.
await page.waitForLoadState('networkidle');
Hopefully you aren't discouraged by this, observationist, pretty clear hansmayer is just taking potshots. Your first paragraph could very well have been written by a professional SWE who understood what level of robustness was required given the constraints of the specific scenario in which the software was being developed.
Which to me, as a professional SWE, seems like a very engineer thing to think about, if I've read both of your comments correctly.
The neat thing about vibe coding is knowing that I'm shitty at actual coding and achieving things in hours that would likely have taken me months to learn to do the right way, or weeks to hack together with other people's bubblegum and duct tape. I'd have to put in a couple years to get to the "OK" level of professional programming, and I feel glad I didn't. Lucky, even.
Longer than writing code from scratch, with no templates or frameworks? Longer than testing and deploying manually?
Even eight years ago when I left full-stack development, nobody was building anything from scratch, without any templates.
Serious questions - are there still people who work at large companies who still build things the conventional way? Or even startups? I was berated a decade ago for building just a static site from scratch so curious to know if people are still out there doing this.
"conventional programming"
Key Characteristics of Conventional Programming:
Manual Code Writing
- Developers write detailed instructions in a programming language (e.g., Java, C++, Python) to tell the computer exactly what to do.
- Every logic, condition, and flow is explicitly coded.
Imperative Approach
- Focuses on how to achieve a result step by step. Example: Writing loops and conditionals to process data rather than using built-in abstractions or declarative statements.
High Technical Skill Requirement
- Requires understanding of syntax, algorithms, data structures, and debugging. No visual drag-and-drop or automation tools—everything is coded manually.
Longer Development Cycles
- Building applications from scratch without pre-built templates or AI assistance. Testing and deployment are also manual and time-intensive.
Traditional Tools
- IDEs (Integrated Development Environments) like Eclipse or Visual Studio. Version control systems like Git for collaboration.
> It was already obvious from your first paragraph - in that context even the sentence "everything works like I think it should" makes absolute sense, because it fits perfectly to limited understanding of a non-engineer - from your POV, it indeed all works perfectly, API secrets in the frontend and 5 levels of JSON transformation on the backend side be damned, right ;)
I mean, he qualified it, right? Sounds like he knew exactly what he was getting :-/
In my 40 years of writing code, I’ve worked on many different code bases and in many different organisations. And I never changed a line of code, deleted code, or added more code unless I could run it in my head and ‘know’ (to the extent that it’s possible) what it will do and how it will interact with the rest of the project. That’s the job.
I’m not against using AI. I use it myself, but if you don’t understand the scope fully, then you can’t possibly validate what the AI is spitting out, you can only hope that it has not fucked up.
Even using AI to write tests will fall short if you can’t tell if the tests are good enough.
For now we still need to be experts. The day we don’t need experts the LLMs should start writing in machine code, not human readable languages
> I do not need to understand the full stack.
Nobody said that. It’s important to understand the scope of the change. Knowing more may well improve decision making, but pragmatism is of course important.
Not understanding the thing you’re changing isn’t pragmatism.
Or you were never under time pressure and always had enough time to do it.
Either way, I'm jealous for you. For me it's "here's code that Bob wrote 10 years ago, it's not working. Customers are complaining and this needs to be fixed yesterday".
"Sorry I need to understand what it will do and how it will interact with the rest of the project, that'll take a few days and I can't fix it before that" wasn't an option. You fix the immediate issue, run whatever tests it may have and throw it to QA for release approval.
Most likely the fix will work and nobody has to touch that bit in a few years. Should we spend time to understand it fully and document it, add proper and comprehensive tests? Yep. But the bosses will never approve the expense.
If I had an AI agent at point, it could "understand" the codebase in minutes and give me clues as to what's the blast radius for the possible fix.
It's hard to state how good I am without sounding like an arsehole, so here goes... I am certainly a very experienced engineer, I've coded from the age of 10 and now at 50 I'm 'retired' after selling the company that I founded. I started in the 8bit era doing low level to-the-metal coding and ended it building an internationally used healthcare SaaS app (with a smattering of games engineering in-between). I've been a technical proof-reader for two Manning books, have at least one popular open-source project, and I still write code for fun and am working on my next idea around data-sovereignty in my now infinite free time... so yeah, I'm decent, and I feel like I've gained enough experience to have an opinion on this.
But also you're not reading what I wrote. I never said "a full understanding of every single project and every effect it will have through the full end to end stack", which I explicitly dealt with in my last reply, when I said: "It’s important to understand the scope of the change. Knowing more may well improve decision making, but pragmatism is of course important."
If the scope is small, you don't need "a full understanding of every single project and every effect it will have through the full end to end stack". But in terms of what it does touch, yeah you should know it, especially if you want to become a better software engineer, and not just an engineer with the same 1 years worth of experience x 30.
It should also not take "a few days" to investigate the scope. If it's taking you that long then you're not exercising the capability that allows you to navigate around unfamiliar code and understand what it's doing. That knowledge accumulates too, so unless you're working on a completely different project every single day, you're going to get quicker and quicker.
I have seen pathological cases where a dev that worked for me went so far down the rabbit hole that he got nothing done, so it has to be a pragmatic process of discovery. It should entirely depend on the extent to which your change could leak out into other areas of the project. For example, if you had a reusable library that had some core functionality that is used throughout the project and you wanted to change some of its core behaviour, then I'd want to find all of the usages of that library to understand how that change will affect the behaviour (if at all). But equally, if I was updating a UI page or control that has limited tentacles throughout the app, then I'd be quite comfortable not doing a deep dive.
> "here's code that Bob wrote 10 years ago, it's not working. Customers are complaining and this needs to be fixed yesterday".
I've been in that exact situation. You need to make a decision about your career. Are you just going to half-arse the job, or are you going to get better? If you think continuing as you are is good for your career, because you've made your idiot boss happy for 5 minutes before they give you the next unreasonable deadline, then you're wrong.
The fact is the approach you're taking is slower. It's slower because you and the team of engineers you're in (assuming everyone takes the same approach) are accumulating bugs, technical debt, and are not building institutional knowledge. When those bugs need dealing with in the future, or that technical debt causes the application to slow to a crawl, or have some customer-affecting side-effects, then you're going to waste time solving those issues and you're sure as hell gonna want the institutional knowledge to resolve those problems. AI doesn't "understand" in the way you're implying. If it did understand then we wouldn't be needed at all.
> Most likely the fix will work and nobody has to touch that bit in a few years. Should we spend time to understand it fully and document it, add proper and comprehensive tests? Yep. But the bosses will never approve the expense.
So you work for a terrible boss. That doesn't make my argument wrong, that makes your boss wrong. You can obviously see the problem, but instead of doing something about it, you're arguing against good software development methodology. That's odd. You should take umbrage with your boss.
The best engineers I have worked with in my career were the ones that fully understood the code base they were working on.
Sounds more like de-volution to me.
Not to mention all the attempts we see nowadays at deliberate redefinition of words, or the motte-and-bailey games played with jargon vs. lay understandings of a concept.
I do not think that is a new thing in human history, too. But sure, the internet amplified it a lot.
Ie you could say you vibe'd 95% of the PR, and i'd agree with that - but are you vibe coding then? You looked at 5% of the code, so you're not ignoring all of the code.
Yet in the spirit of the phrase, it seems silly to say someone is not vibe coding despite ignoring almost all of the code generated.
I don't care about the 5% difference. I care about the bulk, the amount of bugs and poor logic that can slip in, etc. I have no attachment to the term "vibe coded", but it's useless to me if it doesn't describe this scenario.
Vibe implies missing knowledge or experience - LLMs are a great equalizer, on the level of handguns or industrialization. Everyone can use them, some can use them well, and the value of using them well is enormous.
A real SWE is going to say "ok, now build a new function doing XYZ" and in their agents.md they'll have their entire project specs and baseline prompt framework, with things like "document in the specified standard, create the unit test, document how the test integrates with the existing features, create a followup note on any potential interference with existing functionality, and update the todo.md" and so forth, with all the specific instructions and structure and subtasks and boring project management most of us wouldn't even know to think of. Doing it right takes a lot of setup and understanding how software projects should be run, and using the LLMs to do all the work they excel at doing, and not having them do the work they suck at.
I only know the binary "that works" or not, for most things I've vibe coded. It'd be nice to have the breadth of knowledge and skills to do things right, but I also feel like it'd take a lot of the magic out of it too, lol.
I still think it saves me time on net and yes, it typically can handle a lot on its own, but whenever it starts to fuck up the same request repeatedly in different ways, all I can really do is sigh/roll my eyes and then it's on me alone to dig in and figure it out/fix it to keep making progress.
And usually that consists of incredibly ungratifying, unpleasant work I'm very much not happy to be doing.
I definitely have been able to do more side projects for ideas that pop into my head thanks to CC and similar, and that part is super cool! But other times I hit a wall where a project suddenly goes from breezy and fun to me spending hours reading through diffs/chat history trying to untangle a pile of garbage code I barely understand 10% of and have to remind myself I was supposed to be doing this for "fun"/learning, and accomplishing neither while not getting paid for it.
But on the other hand, writing thorough tests before coding the library is good practice with or without an assistant.
Disagree. Vibe coding is even more powerful if you know what you're doing. Because if you know what you're doing, and you keep up with the trends, you also know when to use it, and when not to. When to look at the code or when to just "vibe" test it and move on.
> When to look at the code or when to just "vibe" test it and move on.
I'm really curious how you're ensuring the code output by whatever LLM you're using, is actually doing what you think it's doing.
In other words, everyone's in on the joke.
No. The Etymology of Hacker in the technical scene started at MIT's Tech Model Railroad Club in the late 1950s/early 1960s, "hack" described clever, intricate solutions, pranks, or experiments with technology.
A hacker is one who made those clever solutions, pranks, and technology experiments. "Hacker News" is trying to take it back from criminal activity.
That's not the case at all though. The LLM doesn't have a mental model of what the expected final result is, so how could it possibly verify that?
It has a description in text format of what the engineer thinks he wants. The text format is inherently limited and lossy and the engineer is unlikely to be perfect at expressing his expectations in any case.
Instead of temporarily suspended.
Whatever happened to the word suspended for temporary and ban for permanent and places say permanent with an expiration date.
Nobody alive has ever been electrocuted, but you will meet people who claim to have been.
I want to see this code written to some objective, to compare with what I would have written to the same objective. What I've seen so far are specs so detailed that very little is left to the discretion of the LLM.
What I want to see are those where the LLM is asked for something, and provided it because I am curious to compare it to my proposed solution.
(This sounds like a great idea for a site that shows users the user-submitted task, and only after they submit their attempt does it show them the LLM's attempt. Someone please vibe code this up, TIA)
But it's also a balance of avoiding being over-prescriptive in tools that needs to support very different workflows, and it's easy to add more specific checks via plugins.
We're bound to see more packaged up workflows over time, but the tooling here is still in very early stages.
The thinking should probably include this kind of introspection (give me a million dollars for training and I'll write a paper) but if it doesn't you can just prompt it to.
Here's a recent example where I used this pattern: I was working on a (micro) service that implements a chat based assistant. I designed it a bit differently than the traditional "chat bot" that's prevalent right now. I used a "chat room" approach, where everyone (user, search, LLM, etc) writes in a queue, and different processes trigger on different message types. After I finished, I had tested it with both unit tests and scripted integration tests, with some "happy path" scenarios.
But I also wanted to see it work "live" in a browser. So, instead of waiting for the frontend team to implement it, I started a new session, and used a prompt alongt he lines of "Based on this repo, create a one page frontend that uses all the relevant endpoints and interfaces". The "agent" read through all the relevant files, and produced (0 shot) an interface where everything was wired correctly, and I could test it, and watch the logs in real-time on my machine. I never looked at the code, because the artifact was not important for me, the important thing was the fact that I had it, 5 minutes later.
Fun fact, it did allow me to find a timing bug. I had implemented message merging, so the LLM gets several messages at once, when a user types\n like\n this\n and basically adds new messages while the others are processing. But I had a weird timing bug, where a message would be marked as "processing", a user would type a message, and the compacting algo would all act "at the same time", and some messages would be "lost" (unprocessed by the correct entity). I didn't see that from the integration tests, because sometimes just playing around with it reveals such weird interactions. For me being able to play around with the service in ~5 minutes was worth it, and I couldn't care less about the artifact of the frontend. A dedicated team will handle that, eventually.
I recently ran across a package in my team's codebase that has a bunch of interrelated DB tables, and we didn't already have a nice doc explaining how everything fits together - so I asked the AI to make me a detailed README.md for the package. I'm currently reviewing that, removing a bunch of nonsense I didn't ask for, and I'm going to run it by my team. It's actually pretty good to start with because the code and DB models are well documented, just piecemeal all over the place, and half of what the AI is doing is just collating all that info and putting it in one doc.