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.

> 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.

Same here. I've picked up projects that have languished for years because the boring tasks no longer make me put them aside.

> 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".

> 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.

> 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

> 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.

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

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

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.

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.

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.

> 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.

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?

> 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" (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.

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.

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.

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.

There was a huge discussion on this a few weeks ago, seems still far from settled: https://news.ycombinator.com/item?id=45503867

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.

> 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.

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.

> 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.

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.

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.

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.

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."

Build tools to keep it in check.

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.

No joke. The quotas are good for humans! It's the new "my code's compiling". https://xkcd.com/303/

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.

That’s only possible for relatively small projects.

I do that when I am mentally exhausted. Not sure if that's the same reason for the author.

Same here :) love generals