> Through field observations (N=13) and qualitative surveys (N=99)... Not a statistically significant sample size.
Professional software developers don't vibe, they control
91–100 of 259 posts
Re: Professional software developers don't vibe, they control
#92The title is doing a lot of work here. What resonated with me is the shift from “writing code” to “steering systems” rather than the hype framing. Senior devs already spend more time constraining, reviewing, and shaping outcomes than typing syntax. AI just makes that explicit. The real skill gap isn’t prompt cleverness, it’s knowing when the agent is confidently wrong and how to fence it in with tests, architecture,…
The stereotype that writing code is for junior developers needs to die. Some devs are hired with lofty titles specifically for their programming aptitude and esoteric systems knowlege, not to play implementation telephone with inexperienced devs.
Re: Professional software developers don't vibe, they control
#93I haven't seen the definition of an agent, in the paper. Do they differentiate agents from generic online chat interfaces?
Re: Professional software developers don't vibe, they control
#94Earlier quoted context omitted.
Is anyone else getting more mentally exhausted by this? I get more done, but I also miss the relaxing code typing in the middle of the process.
I think there are two groups of people emerging. deep / fast / craft-and-decomposition-loving vs black box / outcome-only. I've seen people unable to work at average speed on small features suddenly reach above average output through a llm cli and I could sense the pride in them. Which is at odds with my experience of work.. I love to dig down, know a lot, model and find abstractions on my own. There a llm will 1) no…
As a (self-reported) craft-and-decomposition lover, I wouldn't call the process "fast".
Certainly it's much faster than if I were trying to take the same approach without the same skills; and certainly I could slow it down with over-engineering. (And "deep" absolutely fits.) But the people I've known that I'd characterize as strongly "outcome-only", were certainly capable of sustaining some pretty high delta-LoC per day.
Re: Professional software developers don't vibe, they control
#95Earlier quoted context omitted.
I'm not remotely cutting edge (just switched from Cursor to Codex CLI, have no fancy tooling infrastructure, am not even vaguely considering git worktrees as a means of working), but Opus 4.5 and 5.2 Codex are both so clearly more competent than previous models that I've started just telling them to do high-level things rather than trying to break things down and give them subtasks. If people are really set in their…
I mostly agree, but today, Opus 4.5 via Claude code did something pretty dumb stuff in my codebase— N queries where one would do, deep array comparison where a reference equality check would suffice, very complex web of nested conditionals which a competent developer would have never written, some edge cases where the backend endpoints didn’t properly verify user permissions before overwriting data, etc. It’s still h…
Re: Professional software developers don't vibe, they control
#96Earlier quoted context omitted.
I think there are two groups of people emerging. deep / fast / craft-and-decomposition-loving vs black box / outcome-only. I've seen people unable to work at average speed on small features suddenly reach above average output through a llm cli and I could sense the pride in them. Which is at odds with my experience of work.. I love to dig down, know a lot, model and find abstractions on my own. There a llm will 1) no…
The sibling comments (from remich and sanufar) match my experience. 1. I do love getting into the details of code, but I don't mind having an LLM handle boilerplate. 2. There isn't a binary between having an LLM generate all the code and writing it all myself. 3. I still do most of the design work because LLMs often make questionable design decisions. 4. Sometimes I simply want a program to solve a problem (outcome-f…
My usual thought is that boilerplate tells me, by existing, where the system is most flawed.
I do like the idea of having a tool that quickly patches the problem while also forcing me to think about its presence.
> There isn't a binary between having an LLM generate all the code and writing it all myself. I still do most of the design work because LLMs often make questionable design decisions.
One workflow that makes sense to me is to have the LLM commit on a branch; fix simple issues instead of trying to make it work (with all the worry of context poisoning); refactor on the same branch; merge; and then repeat for the next feature — starting more or less from scratch except for the agent config (CLAUDE.md etc.). Does that sound about right? Maybe you do something less formal?
> Sometimes I simply want a program to solve a purpose (outcome-focused) over a project to work on (craft-focused). Sometimes I need a small program in order to focus on the larger project, and being able to delegate that work has made it more enjoyable.
Yeah, that sounds about right.
Re: Professional software developers don't vibe, they control
#97"I’m on disability, but agents let me code again and be more productive than ever (in a 25+ year career). - S22"
Once Social Security Administration learns this, there goes the disability benefit...
Re: Professional software developers don't vibe, they control
#98Excellent survey, but one has to be careful when participating in such surveys: "I’m on disability, but agents let me code again and be more productive than ever (in a 25+ year career). - S22" Once Social Security Administration learns this, there goes the disability benefit...
Re: Professional software developers don't vibe, they control
#99Earlier quoted context omitted.
Thanks Simon - always quick on the draw. Off your intuition, do you think the same study with Codex 5.2 and Opus 4.5 would see even better results?
Depends on the participants. If they're cutting-edge LLM users then yes, I think so. If they continue to use LLMs like they would have back in the first half of 2025 I'm not sure if a difference would be noticeable.
Re: Professional software developers don't vibe, they control
#100Earlier quoted context omitted.
Indeed it did; I remember those times. All else being equal I still think SWE salaries on average would of been higher if we kept it like that given basic economics - there would of been a lot less people capable of doing it but the high ROI automation opportunities would of still been there. The fact that "it sucked" usually creates more scarcity on the supply side; which all being equal means higher wages and in ou…
> ex big tech I mean, this seems like a pretty big thing to leave out, no? That's where all the crazy high salaries were! Also, there are still legacy places that more or less build software like it's 1999. I get the impression that embedded, automotive, and such still rely a lot on proprietary tools, finicky manual processes, low level languages (obviously), etc. But those are notorious for being annoying and not ve…
Making software easier and more abstract has allowed less technical people into the profession, allowed easier outsourcing, meant more competition/interview prep to filter out people (even if the skills are not used in the job at all), more material for AI to train on, etc. To the parent comment's point I don't think it has boosted salaries and/or conditions on average for the SWE - in the long run (10 years +) it could be argued that economically the opposite has occurred.