61–70 of 174 posts
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.
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.
Earlier quoted context omitted.
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.
Words changed meaning all the time through history, it just happens faster.
Sounds more like de-volution to me.
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…
You, too, can be awarded the Order of Labor Glory, Third Class.[1]
Earlier quoted context omitted.
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.
It's very funny that I can't tell if this is sarcasm or not. "Just tell it to do better."
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.
Earlier quoted context omitted.
> 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 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…
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.
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 implementati…
...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.
Earlier quoted context omitted.
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…
I mean, that's the joke. "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.
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.
That’s only possible for relatively small projects.
How'd you reckon?