Introduction
Introduction Statistics Contact Development Disclaimer Help
_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
Visit Hacker News on the Web
COMMENT PAGE FOR:
Vibe coding creates fatigue?
VerifiedReports wrote 10 hours 23 min ago:
No; stupid terms like "vibe coding" create fatigue.
damiangriggs wrote 16 hours 29 min ago:
Going fast is awesome. If you have a bit of caffeine in the morning,
turn on some tunes, and get into your workflow it's awesome. I get so
sucked into my coding projects that when I'm done I'm disoriented.
Nothing quite like being in the zone.
motbus3 wrote 17 hours 22 min ago:
Same for me.
I feel fatigue and I have also been reflecting about that as it
reminded me the same type of mind exhaust I felt when I was a manager.
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
uberman wrote 18 hours 22 min ago:
While the productivity can be exciting. I personally observe the sa.e
fatigue as described. I chock it up to the speed or frequency of
context switching as a result of faster implementation.
Sevii wrote 19 hours 10 min ago:
Claude Code latency is at the unfortunate balance where the wait is
long enough for me to go on twitter, but not long enough to do anything
really valuable. Would be more productive if it took minutes or under
5-10 seconds.
lenerdenator wrote 19 hours 37 min ago:
I find the increased speed to be an opportunity to slow down and focus
on certain things, particularly the architectural changes of the
feature I'm looking to introduce.
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.
gaigalas wrote 20 hours 46 min ago:
If you're automating code generation but not automating verification,
there will be a mismatch.
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.
blahbob wrote 20 hours 55 min ago:
In my experience, it depends on the task. As a hobby, I develop
personal projects (mostly web apps) where I'm not an expert in the
relevant technology. In this case, LLM-assisted coding is empowering -
and I don't think it's Dunning-Kruger, as I can understand the
generated code, and it "feels" good enough given my 20+ years'
experience in software engineering.
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.
spike021 wrote 20 hours 56 min ago:
I find vibe coding similar to visiting a country where I don't know the
local language very well.
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.
OptionOfT wrote 21 hours 10 min ago:
I see people with no coding experience now generating PRs to a couple
of repos I manage.
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.
simonw wrote 21 hours 11 min ago:
This morning I attended and paid attention to three separate meetings
and at one point had three coding agents running in parallel solving
some quite complex problems for me.
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.
scuff3d wrote 21 hours 12 min ago:
A guy at work did a demo of an agent work flow for some higher ups (we
have chatbots but haven't adopted agents yet). He raved about how after
writing a several hundred line spec, being extremely specific about the
technology to use, and figuring out where to put all the guardrails, he
was able to get Claude to generate weeks worth of code. When all was
said and done it was like 20k lines of code between implementation,
tests, and helper tools. Along the way he acknowledged you have to keep
a close eye on it, or it will generate functions that pass tests but
don't actually do their jobs, tests that pass but don't test anything,
and a bunch of other issues.
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.
inetknght wrote 21 hours 6 min ago:
Even asking it to do little tests, Claude 4.5 Sonnet Thinking still
ends up writing tests that do nothing or don't do what it says will
do. And it's always fucking cheery about it: "you're code is now
production-ready!" and "this is an excellent idea!" and "all errors
are now fixed! your code is production-ready!" and "I fixed the
compiler issue, we're now production ready!"
...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.
scuff3d wrote 20 hours 46 min ago:
Yeah that aggressive sycophancy is incredibly annoying. Someone
telling me I'm being a fucking idiot is more useful then "what a
fantastic observation! You're so right" for the millionths time.
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.
djmips wrote 12 hours 13 min ago:
I agree - that's why it's great to have a lot of experience so
that you can choose the correct way. I run into way more issues
and fatigue when I'm venturing into areas I'm not familiar with.
wendgeabos wrote 21 hours 14 min ago:
anecdata
cxromos wrote 21 hours 15 min ago:
true in my case. when i get into the zone while coding, i can go on and
on. while llm can help, there's a cognitive mismatch between coding
directions to llm and reading the code when it comes to continuing
coding. brain and the generated code aren't aligned. i prefer at the
moment, after coding a feature, to see if it can be improved using llm.
and it's of great help to write tests.
waltbosz wrote 21 hours 22 min ago:
> One reason developers are developers is the dopamine loop
> You write code, it doesn’t work, you fix it, it works, great!
Dopamine rush. Several dozens or a hundred times a day.
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.
tehjoker wrote 21 hours 25 min ago:
This is what loom workers experienced after the introduction of the
power loom, what factory workers experienced under Taylorism, what
Amazon workers experience today in many cases. Just working at a pace
that is unsustainable. This is why unions exist.
iceflinger wrote 21 hours 32 min ago:
Why is this written as a bullet pointed list?
nullorempty wrote 17 hours 29 min ago:
I do that when I am mentally exhausted. Not sure if that's the same
reason for the author.
AutumnsGarden wrote 21 hours 37 min ago:
There’s a lot of points I agree with but I think what’s important
is fully conceptualizing the mental model of your project. Then,
context switching doesn’t even induce much mental fatigue.
layer8 wrote 21 hours 27 min ago:
That’s only possible for relatively small projects.
retuy5668 wrote 21 hours 5 min ago:
Don't you have a fully conceptualized mental model of your body, to
the point that you are quite functional with it? Isn't your body
far, far, far more complicated than any software project could be?
How'd you reckon?
layer8 wrote 4 hours 8 min ago:
I only have the most vague mental model of my body [0], and I
also don’t bio-engineer its cellular innards, which would be
the rough equivalent of what a developer does in large software
projects.
[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.
cmrdporcupine wrote 21 hours 38 min ago:
I play stupid web games (generals.io I'm looking at you) while Claude
does its thing. Takes the edge off the pace a bit.
This fine for WFH/remote work. It didn't have great optics when I went
back to in-office for a bit.
euph0ria wrote 21 hours 6 min ago:
Same here :) love generals
khimaros wrote 21 hours 44 min ago:
Doctorow's "Reverse Centaur"
xnorswap wrote 21 hours 48 min ago:
I feel this.
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.
lubujackson wrote 19 hours 33 min ago:
I think it taxes your brain in two different ways - the mental model
of the code is updated in the same way as a PR from a co-worker
updates code, but in a minute instead of every now and then. So you
need to recalibrate your understanding and think through edge cases
to determine if the approach is what you want or if it will support
future changes etc. And this happens after every prompt. The
older/more experienced you are, the harder it is to NOT DO THIS
thinking even if you are intending to "vibe" something, since it is
baked into your programming flow.
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.
CPLX wrote 21 hours 33 min ago:
My least favorite part is where it runs into some stupid problem and
then tries to go around it.
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."
colechristensen wrote 21 hours 47 min ago:
Build tools to keep it in check.
vidarh wrote 21 hours 36 min ago:
Really, this. You still need to check its work, but it is also
pretty good at checking its work if told to look at specific
things.
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.
lelanthran wrote 6 hours 8 min ago:
I wouldn't mind see a collection of objectives and the emitted
output. My experience with LLM output is that they are very often
over-engineered for no good reason, which is taxing on me to
review.
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)
prmph wrote 19 hours 51 min ago:
So why can't the deterministic part of the agent program embed in
all these checks?
vidarh wrote 6 hours 57 min ago:
It increasingly is. E.g. if you use Claude Code, you'll notice
it "likes" to produce todo lists that rendered specially via
the TodoWrite tool that's built in.
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.
colechristensen wrote 17 hours 28 min ago:
It absolutely can, I'm building things to do this for me.
Claude Code has hooks that are supposed to trigger upon certain
states and so far they don't trigger reliably enough to be
useful. What we need are the primitives to build code based
development cycles where each step is executed by a model but
the flow is dictated by code. Everything today relies too
heavily on prompt engineering and with long context windows
instruction following goes lax. I ask my model "What did you
do wrong?" and it comes back clearly with "I didn't follow
instructions" and then gives clear and detailed correct reasons
about how it didn't follow instructions... but that's not
supremely helpful because it still doesn't follow instructions
afterwards.
colechristensen wrote 21 hours 30 min ago:
Tell it to grade its work in various categories and that you'll
only accept B+ or greater work. Focusing on how good it's doing
is an important distinction.
habinero wrote 21 hours 11 min ago:
It's very funny that I can't tell if this is sarcasm or not.
"Just tell it to do better."
vidarh wrote 6 hours 47 min ago:
Think of it as a "you should - and is allowed to - spend more
time on this" command, because that is pretty much what it
is. The model only gets so much "thinking time" to produce
the initial output. By asking it to iterate you're giving it
more time to think and iterate.
colechristensen wrote 21 hours 8 min ago:
Oh I'm not at all joking. It's better at evaluating quality
than producing it blindly. Tell it to grade it's work and it
can tell you most of the stuff it did wrong. Tell it to
grade it's work again. Keep going through the cycle and
you'll get significantly better code.
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.
Izkata wrote 19 hours 30 min ago:
An experiment on that from a year ago:
[1]: https://news.ycombinator.com/item?id=42584400
Zigurd wrote 21 hours 50 min ago:
I don't want to be that contrarian guy, but I find it energizing to go
faster. For example, being able to blast through a list of niggling
defects that need to be fixed is no longer a stultifying drag.
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.
lelanthran wrote 7 hours 27 min ago:
> I don't want to be that contrarian guy, but I find it energizing to
go faster. For example, being able to blast through a list of
niggling defects that need to be fixed is no longer a stultifying
drag.
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.
rightbyte wrote 10 hours 18 min ago:
> I don't want to be that contrarian guy, but I find it energizing to
go faster.
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".
WhyOhWhyQ wrote 16 hours 6 min ago:
Everyone in this conversation talks about different activities. One
version of vibe coding happens with Netflix open and without ever
opening a text editor, and another happens with thoroughly reviewing
every change.
etothet wrote 18 hours 40 min ago:
I 100% agree. It's been incredible for velocity and the capabilities
and accuracy of the models I've been (mostly from Anthropic) have
improved immensely over the last few months.
quotemstr wrote 19 hours 33 min ago:
> I don't want to be that contrarian guy, but I find it energizing to
go faster. For example, being able to blast through a list of
niggling defects that need to be fixed is no longer a stultifying
drag.
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" ( [1] ) 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.
[1]: https://thewritepractice.com/vomit-first-draft/
blitz_skull wrote 20 hours 11 min ago:
I think it's less "going fast" and more "going fast forever."
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.
solumunus wrote 9 hours 22 min ago:
This. I’m able to be more productive for long hours more
consistently than before. The occasions where I’m engineering for
8 solid hours are much more frequent now, and I’m certainly more
tired. Almost all of my time is now dedicated to problem solving
and planning, the LLM executes and I sit there thinking. Not
everyone’s brain or project is well suited for this, but for me
as a personality combined with the way my product is structured,
it’s a total game changer.
wiether wrote 19 hours 38 min ago:
Same feeling here!
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.
sixothree wrote 20 hours 29 min ago:
I am currently only vibe-coding my hobby projects. So if that
changes, my view could very well change.
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.
OptionOfT wrote 20 hours 35 min ago:
If you do this on your personal stuff, eh, I wouldn't do it, but you
do you.
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?
frio wrote 18 hours 30 min ago:
This is far and away the biggest problem I have atm. Engineers
blowing through an incredible amount of work in a short time, but
when an inevitable bug bubbles up (which would happen without AI!),
there's noone to question. "Hey, you changed the way
transactionality was handled here, and that's made a really weird
race condition happen. Why did you change it? What edge case were
you trying to handle?" -- "I don't know, the AI did it". This
makes chasing things down exponentially harder.
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.
QuercusMax wrote 19 hours 47 min ago:
A lot of that stuff can be handled by linters and static analysis
tools.
seattle_spring wrote 19 hours 11 min ago:
What are some examples of linters / static analysis catching
hallucinated solutions to problems?
I feel like it would just yield a well-formatted, type safe
incorrect solution, which is no better than a tangled mess.
steveklabnik wrote 18 hours 52 min ago:
A specific example: for some reason, when working on Playwright
scripts, Claude really likes to inject
await page.waitForLoadState('networkidle');
But this isn't good, and is not encouraged. So much so that
there's an eslint that suggests removing it. This means that by
running the linter, if Claude does decide to inject this, it
gets taken out, because the linter runs and then tells it so.
pyrophane wrote 20 hours 45 min ago:
> I recently used a coding agent on a project where I was using an
unfamiliar language, framework, API, and protocol.
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.
stonemetal12 wrote 18 hours 57 min ago:
> I didn’t feel confident enough to evaluate what the agent was
doing
So don't. It is vibe coding, not math class. As long as it looks
like it works then all good.
tjr wrote 18 hours 24 min ago:
Is there any software you think should not be developed with this
approach?
Zigurd wrote 19 hours 11 min ago:
SwiftKotlinDartGo blur together by now. That's too many languages
but what are you gonna do?
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.
QuercusMax wrote 19 hours 48 min ago:
I'm assuming this is the case where they are working in an existing
codebase written by other humans. I've been in this situation a lot
recently, and Copilot is a pretty big help to figure out
particularly fiddly bits of syntax - but it's also really stupid
suggests a lot of stuff that doesn't work at all.
Animats wrote 21 hours 9 min ago:
> I don't want to be that contrarian guy, but I find it energizing to
go faster.
You, too, can be awarded the Order of Labor Glory, Third Class.[1]
[1]: https://en.wikipedia.org/wiki/Order_of_Labour_Glory
Zigurd wrote 18 hours 56 min ago:
Had I been doing other than interesting exploratory coding, I would
agree with you. I can readily imagine standups where the "scrum
master" asks where our AI productivity boost numbers are. Big
dystopia potential.
p_v_doom wrote 8 hours 52 min ago:
People in some places already are doing that. The Dystopia is now
stuffn wrote 21 hours 11 min ago:
I think the counter-point to that is what I experience.
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.
OptionOfT wrote 20 hours 9 min ago:
Ergo instant tech debt.
Rperry2174 wrote 21 hours 22 min ago:
I think both experience are true.
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
agumonkey wrote 20 hours 1 min ago:
> the kind of "compression" of cognitive things
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.
visarga wrote 21 hours 19 min ago:
After 4 hours of vibe coding I feel as tired as a full day of
manual coding. The speed can be too much. If I only use it for a
few minutes or an hour, it feels energising.
observationist wrote 21 hours 27 min ago:
There's something exhilarating about pushing through to some
"everything works like I think it should" point, and you can often
get there without doing the conscientious, diligent, methodical
"right" way of doing things, and it's only getting easier. At the
point where everything works, if it's not just a toy or experiment,
you definitely have to go back and understand everything. There will
be a ton to fix, and it might take longer to do it like that than
just by doing it right the first time.
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.
damiangriggs wrote 16 hours 27 min ago:
I've noticed that as well. I don't memorize every single syntax
error, but when I use agents to help code I learn why they fail and
how to correct them. The same way I would imagine a teacher learns
the best way to teach their students.
bcrosby95 wrote 18 hours 37 min ago:
If you're hanging your features off a well trodden framework or
engine this seems fine.
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.
hansmayer wrote 19 hours 43 min ago:
> I'm not a professional SWE
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?
lelanthran wrote 9 hours 56 min ago:
>> 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.
> 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 :-/
observationist wrote 17 hours 1 min ago:
Exactly - I know enough to know what I don't know, since I've
been able to interact with professionals, and went down the path
of programming far enough to know I didn't want to do it. I've
also gotten good at enough things to know the pattern of "be
really shitty at doing things until you're not bad, and
eventually be ok, and if you work your ass off, someday you'll
actually be good at it".
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.
brailsafe wrote 18 hours 49 min ago:
By your response, it really seems like you read their first
sentence as advocating for vibe coding, but I think they were
saying something more to the effect of "While it's exciting to
reach those milestones more quickly and frequently, as it becomes
easier to reach a point where everything seems to be working on
the surface, the easier it then is to bypass elegant, properly
designed, intimately internalized detail—unavoidable if written
manually—and thus when it comes time to troubleshoot, the same
people may have to confront those rapidly constructed systems
with less confidence, and hence the maintenance burden later may
be much greater than it otherwise would be"
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.
westoncb wrote 19 hours 4 min ago:
It sounds more like you just made an overly simplistic
interpretation of their statement, "everything works like I think
it should," since it's clear from their post that they recognize
the difference between some basic level of "working" and a
well-engineered system.
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.
burningChrome wrote 19 hours 10 min ago:
>> even if it takes longer than the programming the conventional
way, who cares, right?
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.
tjr wrote 18 hours 51 min ago:
What do you mean by "the conventional way"?
burningChrome wrote 18 hours 21 min ago:
I was referencing OP's statement.
"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.
lukan wrote 21 hours 20 min ago:
"It was a non-trivial project, and I had to be paying attention to
what the agent was doing"
There is a big difference between vibe coding and llm assisted
coding and the poster above seems to be aware of it.
closewith wrote 18 hours 38 min ago:
Vibe coding is the name for LLM assisted coding, whether you like
it or not.
ModernMech wrote 4 min ago:
I disagree, "vibe" characterizes how the LLM is being used, not
that AI is being used at all. The vibe part means it's not
rigorous. Using an LLM to autocomplete a line in an otherwise
traditionally coded project would not be considered "vibe"
coding, despite being AI assisted, because the programmer can
easily read and verify the line is as correct as if they had
typed it character by character.
observationist wrote 17 hours 54 min ago:
Not all LLM assisted coding is vibe coding. Vibe coding goes
something like , throw it a prompt, then repeat "it works" or
"it doesn't work" or "it works, but I want Feature XYZ, also"
or repeated "ok, but make it better."
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.
closewith wrote 17 hours 46 min ago:
While that was the original intent when Andrej Karpathy
coined the term, it's now simply synonymous with LLM assisted
coding. Like many previously pejorative terms, it's now
become ubiquitous and lost its original meaning.
Nashooo wrote 18 hours 25 min ago:
One means (used to mean?) actually checking the LLM's output
one means keep trying until it outputs does what you want.
closewith wrote 17 hours 53 min ago:
That's the original context of the Andrej Karpathy comment,
but it's just synonymous with LLM assisted coding now.
lukan wrote 7 hours 12 min ago:
Not yet, but the more you will insist, the more it will be.
But what is your proposal for differentiating between just
prompting without looking at code vs just using LLM to
generate code?
closewith wrote 6 hours 15 min ago:
I'm not in favour of the definition, but like _hacker_,
the battle is already lost.
iwontberude wrote 18 hours 19 min ago:
Given that the models will attempt to check their own work
with almost the identical verification that a human engineer
would, it's hard to say if human's aren't implicitly checking
by relying on the shared verification methods (e.g. let me
run the tests, let me try to run the application with
specific arguments to test if the behavior works).
ahtihn wrote 18 hours 7 min ago:
> Given that the models will attempt to check their own
work with almost the identical verification that a human
engineer would
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.
louthy wrote 21 hours 27 min ago:
> But not having to spend hours here and there getting up to speed on
some mundane but unfamiliar aspect of the implementation
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.
bongodongobob wrote 21 hours 16 min ago:
It sounds like you've never worked a job where you aren't just
supporting 1 product that you built yourslef. Fix the bug and move
on. I do not have the time or resources to understand it fully.
It's a 20 year old app full of business logic and MS changed
something in their API. I do not need to understand the full stack.
I need to understand the bug and how to fix it. My boss wants it
fixed yesterday. So I fix it and move onto the next task. Some of
us have to wear many hats.
louthy wrote 21 hours 1 min ago:
> It sounds like you've never worked a job where you aren't just
supporting 1 product that you built yourslef
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â€�…
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.
theshrike79 wrote 4 hours 24 min ago:
Either you're a true 100x coder who can get a full
understanding of every single project and every effect it will
have through the full end to end stack.
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.
visarga wrote 21 hours 17 min ago:
>Red flag. In other words you don’t understand the implementation
well enough to know if the AI has done a good job.
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.
nosianu wrote 20 hours 58 min ago:
> What makes a code worthy of trust is passing tests
(Sorry, but you set yourself up for this one, my apologies.)
Oh, so this post describes "worthy code", okay then. [1] 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.
[1]: https://news.ycombinator.com/item?id=18442941
agumonkey wrote 19 hours 58 min ago:
I wonder if for a large class of jobs, simple unit tests will
be enough to be a negative that the llm output will try to
match. Test driven delegation in a way.. that said i share the
same worries as you. The fact that the LLM can wire multiple
files / class / libs in a few seconds to pass your tests
doesn't guarantee a good design. And the people who love vibe
coding the most are the one who never valued design in the
first place, just quick results..
jmalicki wrote 21 hours 20 min ago:
Learning an unfamiliar aspect and doing it be hand will have the
same issues. If you're new to Terraform, you are new to Terraform,
and are probably going to even insert more footguns than the AI.
At least when the AI does it you can review it.
lelanthran wrote 6 hours 24 min ago:
> Learning an unfamiliar aspect and doing it be hand will have
the same issues.
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.
pferde wrote 21 hours 17 min ago:
No, you can not. Without understanding the technology, at best
you can "vibe-review" it, and determine that it "kinda sorta
looks like it's doing what it's supposed to do, maybe?".
louthy wrote 21 hours 18 min ago:
> Learning an unfamiliar aspect and doing it be hand will have
the same issues. If you're new to Terraform, you are new to
Terraform
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-...
skdhshdd wrote 21 hours 31 min ago:
> But not having to spend hours here and there getting up to speed on
some mundane but unfamiliar aspect of the implementation
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.
vidarh wrote 21 hours 41 min ago:
Same here. I've picked up projects that have languished for years
because the boring tasks no longer make me put them aside.
Avicebron wrote 21 hours 42 min ago:
Can you share why it was non-trivial? I'm curious about how folks are
evaluating the quality of their solutions when the project space is
non trivial and unfamiliar
Zigurd wrote 19 hours 6 min ago:
It's a real, complete, social media client app. Not a huge project.
But the default app was clearly written by multiple devs, each with
their own ideas. One goal was to be cleaner and more orthogonal,
among other goals.
ares623 wrote 21 hours 40 min ago:
A little bit of Dunning-Kruger maybe?
marginalia_nu wrote 19 hours 23 min ago:
Dunning-Kruger isn't what you think it is[1]
[1]: https://skepchick.org/2020/10/the-dunning-kruger-effect-...
joseda-hg wrote 21 hours 23 min ago:
Non triviality is relative anyway, if anything admiting
complexity beyond your skills on your expertise field reads like
the inverse
LocalH wrote 21 hours 58 min ago:
Downtime for the conscious brain is paramount in life, as that allows
the sub-conscious to absorb and act on new information. I have no
science to point to, but I believe wholeheartedly that the conscious
and sub-conscious minds cannot access the same neurons at the same
time, it's like single-ported RAM. More than one thing in my life has
been improved by taking a conscious break and letting the subconscious
churn
johnsmith1840 wrote 21 hours 23 min ago:
I did alot of AI research around this (memory/finetuning)
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.
exitb wrote 10 hours 16 min ago:
That’s super visible in young children. If you teach one to ride
a bike, you don’t actually see much progress within a span of a
single session. The progress is there the next day.
zephyrthenoble wrote 21 hours 59 min ago:
I've felt this too as a person with ADHD, specifically difficulty
processing information. Caveat: I don't vibe code much, partially
because of the mental fatigue symptoms.
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.
Jeff_Brown wrote 21 hours 52 min ago:
Agreed. Some strategies that seem to help exist, though. Write
extensive tests before writing the code. They serve as guidance.
Commit tests separately from library code, so you can tell the AI
didn't change the test. Specify the task with copious examples.
Explain why yo so things, not just what to do.
habinero wrote 21 hours 14 min ago:
Yeah, this is where I start side-eying people who love vibe coding.
Writing lots of tests and documentation and fixing someone else's
(read: the LLM's) bad code? That's literally the worst parts of the
job.
Jeff_Brown wrote 17 hours 27 min ago:
Absolutely. Honestly some days I'm not sure the AI saves me any
time at all.
But on the other hand, writing thorough tests before coding the
library is good practice with or without an assistant.
ewoodrich wrote 19 hours 26 min ago:
I also get confused when I see it taken for granted that "vibe
coding" removes all the drudgery/chores from programming. When my
own experience heavily using Claude Code/etc every day routinely
involves a lot of unpleasant clean up of accumulated LLM slop and
"WTF" decisions.
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.
danielbln wrote 21 hours 23 min ago:
Also: detailed planning phase, cross-LLM reviews via subagents,
tests, functional QA etc. There at more (and complimentary) ways to
ensure the code does what it should then to comb through ever line.
zephyrthenoble wrote 21 hours 49 min ago:
Interesting, I haven't tried tests outside of the code base the LLM
is working on.
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...
Askiir wrote 19 hours 56 min ago:
The way I do it is write tests, then commit just the tests. Then
when you have any agent running and generating code, before
committing/reviewing you can check the diff for any changes to
files containing tests. The commit panel in Jetbrains for example
will enumerate any changed files, and I can easily take a peek
there and see if any testing files were changed in the process.
It's not necessarily about having a separate codebase.
JohnMakin wrote 22 hours 4 min ago:
There probably needs to be some settled discussion on what constitutes
"vibe coding." I interpret this term as "I input text into $AI_MODEL, I
look at the app to see my change was implemented. I iterate via text
prompts alone, rarely or never looking at the code generated."
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.
Kiro wrote 18 hours 3 min ago:
I think the difference between the two is shrinking by the day. At
this point I almost never need to address anything with the LLM's
solution and could easily just go straight to testing for most
things.
The key difference is still the prompts and knowing what to
reference/include in the context.
lelanthran wrote 6 hours 17 min ago:
> I think the difference between the two is shrinking by the day.
At this point I almost never need to address anything with the
LLM's solution and could easily just go straight to testing for
most things.
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?
Kiro wrote 3 hours 56 min ago:
I don't "believe" in anything. I'm just describing my situation,
where I'm trying to find ways to improve the solutions but seldom
find any. It's purely an observation and not me advocating for
one thing or another.
I still check the output but it is starting to feel like a sanity
check more than a code review.
keeda wrote 19 hours 10 min ago:
There was a huge discussion on this a few weeks ago, seems still far
from settled: [1] 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.
[1]: https://news.ycombinator.com/item?id=45503867
wvenable wrote 19 hours 14 min ago:
> rarely or never looking at the code generated.
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.
celeryd wrote 21 hours 51 min ago:
I don't see a distinction. Vibe coding is either agent assisted
coding or using chatbots as interpreters for your design goals. They
are the same thing.
johnsmith1840 wrote 21 hours 35 min ago:
"Vibe" has connotations of easy and fun neither of which are true
when building something difficult
christophilus wrote 21 hours 41 min ago:
No. One involves human quality control, and one omits it.
happytoexplain wrote 21 hours 55 min ago:
Yes, I'm getting increasingly confused as to why some people are
broadening the use of "vibe" coding to just mean any AI coding, no
matter how thorough/thoughtful.
iLoveOncall wrote 21 hours 24 min ago:
Words don't have meaning in 2025.
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.
lukan wrote 21 hours 18 min ago:
Words changed meaning all the time through history, it just
happens faster.
devnullbrain wrote 17 hours 54 min ago:
Yes but before 2005 we didn't have Reddit, so we didn't have
people who learned about prescriptivism from there and think it
means all discussion about taste and style is immoral.
zahlman wrote 19 hours 56 min ago:
There is a world of difference between natural semantic drift
and blatant disregard for accuracy by someone seeking to create
drama for attention.
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.
lukan wrote 19 hours 26 min ago:
"seeking to create drama for attention"
I do not think that is a new thing in human history, too. But
sure, the internet amplified it a lot.
pferde wrote 21 hours 9 min ago:
The two examples the grandparent post mentioned are not really
evolution, but rather making everything sound bombastic and
sensationalist. The end game for that trend is the cigarette
brand ad billboard in Idiocracy, where a half-naked muscular
man glares at you angrily and going "If you do not smoke our
brand, f* you!"
Sounds more like de-volution to me.
crazygringo wrote 21 hours 39 min ago:
It's because the term itself got overapplied by people critical of
LLMs -- they dismissed all LLM-assisted coding as "vibe coding"
because they were prejudiced against LLMs.
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.
kelipso wrote 20 hours 30 min ago:
Lol, I say I am vibe coding even when I create little code
snippets through AI that I have read and understood every line.
It’s a fun term!
habinero wrote 21 hours 20 min ago:
I mean, that's the joke. "vibe coding" only sounds cool if you
don't know how to code but horrific if you do.
NitpickLawyer wrote 21 hours 6 min ago:
> "vibe coding" only sounds cool if you don't know how to code
but horrific if you do.
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.
bigstrat2003 wrote 19 hours 41 min ago:
If you know how to program, vibe coding is useless. It only
ever can produce worse results than you could've made
yourself, or the same results but with more effort (because
reviewing the code is harder than creating it).
QuercusMax wrote 17 hours 49 min ago:
Depends on what you're doing. I've found it extremely
useful for creating the boilerplatey scaffolding I'm going
to be copying from somewhere else anyway. When I actually
get into the important logic and tests I'll definitely
write those by hand because the AI doesn't understand what
I'm trying to do anyway (since it's usually too novel).
tinfoilhatter wrote 19 hours 45 min ago:
What does "vibe" testing code entail exactly? Apparently you
don't look at code when you're "vibe" testing it based on
this statement:
> 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.
NitpickLawyer wrote 19 hours 15 min ago:
I stick by the og definition, in that when vibe coding I
don't look at the code. I don't care about the code. When I
said "vibe test it" I meant test the result of the vibe
coding session.
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.
QuercusMax wrote 17 hours 45 min ago:
This is one of the things I've seen it be very useful
for: putting together one-off tools or visualizations.
I'm not going to maintain these, although I might check
them into version control for historical reference.
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.
crazygringo wrote 21 hours 14 min ago:
Right but there are tons of examples of things that started out
as insults or negative only to be claimed as the proper or
positive name. Impressionism in painting, for a start. The
Quakers. Queer. Punk. Even "hacker", which started out meaning
only breaking into computer systems -- and now we have "Hacker
News." So vibe coding fits in perfectly.
In other words, everyone's in on the joke.
stonemetal12 wrote 18 hours 44 min ago:
> Even "hacker", which started out meaning only breaking into
computer systems
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.
crazygringo wrote 18 hours 30 min ago:
TIL, thanks! Growing up I was only aware of the criminal
version -- I didn't realize it grew out of an earlier
meaning. I just saw the shift in the tech scene in the
1990s and more broader culturally in the 2000s with "life
hacks" and hackathons. What's old is new again...
loloquwowndueo wrote 21 hours 49 min ago:
Like people using “bricked” to signal recoverable situations.
“Oh the latest update bricked my phone and I had to factory-reset
it, but it’s ok now”. Bricked used to mean it turned into
something as useful as a brick, permanently.
viccis wrote 21 hours 30 min ago:
I'm not sure how common this is in other countries, but Americans
would rather add another definition to the dictionary for the
misuse before they'd ever tolerate being corrected or (god
forbid) learning the real meaning of a word. I got dogpiled for
saying this about "factoid" the other day here, but sometimes
when people misuse words like "bricked" or "electrocuted", the
ambiguity does actually make a difference, meaning you have to
follow up with "actually bricked permanently?" or "did the shock
kill him?", meaning that semantic information has been lost.
habinero wrote 21 hours 20 min ago:
Languages evolve, my dude. It's common everywhere.
kelipso wrote 20 hours 27 min ago:
I think he is complaining about that exact philosophy maybe
being applied too broadly lol.
namrog84 wrote 21 hours 43 min ago:
I've also seen the term.
You've been permanently banned for 12 hours.
Instead of temporarily suspended.
Whatever happened to the word suspended for temporary and ban for
permanent and places say permanent with an expiration date.
nancyminusone wrote 21 hours 20 min ago:
My favorite one of these is "electrocuted" meaning "to be
killed by electricity".
Nobody alive has ever been electrocuted, but you will meet
people who claim to have been.
stronglikedan wrote 20 hours 44 min ago:
The modern definition includes "injured", so plenty of living
people have been electrocuted.
unshavedyak wrote 21 hours 58 min ago:
> There probably needs to be some settled discussion on what
constitutes "vibe coding." I interpret this term as "I input text
into $AI_MODEL, I look at the app to see my change was implemented. I
iterate via text prompts alone, rarely or never looking at the code
generated."
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.
layer8 wrote 21 hours 32 min ago:
Maybe read the original definition: [1] Or here: [2] Not looking at
the code at all by default is essential to the term.
[1]: https://x.com/karpathy/status/1886192184808149383
[2]: https://en.wikipedia.org/wiki/Vibe_coding
unshavedyak wrote 21 hours 0 min ago:
I agree, i'm saying any code it produces. Eg if you ignore 95% of
the LLM's PR, are you vibe coding? Some would say no, because you
read 5% of the PR. I would say yes, you are vibe coding.
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.
layer8 wrote 3 hours 57 min ago:
The question is, to what purpose are you looking at those 5%? I
reckon it’s because you don’t really trust the vibes. In
that sense, you’re not vibe-coding.
windex wrote 22 hours 12 min ago:
This is why I document my ideas and then go for a walk. It also helps
me stay within the quota limits.
esafak wrote 21 hours 48 min ago:
No joke. The quotas are good for humans! It's the new "my code's
compiling".
[1]: https://xkcd.com/303/
<- back to front page
You are viewing proxied material from codevoid.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.