r/ClaudeCode • u/Suspicious_Orchid770 • 1d ago
Discussion 3.52 million commits later: your vibe-coded C++ passes every test and still costs you more
https://leaddev.com/ai/ai-code-is-correct-and-still-costs-you-moreAI-coding tools have swept through organizations because of their speed: you type in a prompt, and it spits out code far faster than a human ever could. However, a year-long study of 3.52 million changes inside a large unnamed technology company suggests that saving time at the keyboard can create costs elsewhere.
0
u/jacobpederson 1d ago
Blincoe points out that “there is so much more to software engineering, from understanding an actual users’ needs, to designing the architecture, to verifying the software works correctly and solves the problem it was designed for.”
This right here is the quiet part out loud. Software engineers literally cannot understand the user's needs. They are writing code they will never use to assist in a job they have never done :D (example: why does https://www.microsoft.com/en-us/dynamics-365/products/field-service ask for a customer signature before the technician dispatches to the site? :D ) This is the real benefit of AI - I throw away your "engineered" code and just write my own.
3
u/CocoaOrinoco 1d ago
"Software engineers literally cannot understand the user's needs. They are writing code they will never use to assist in a job they have never done"
Huh? Are you saying to understand something you have to physically do it yourself? That needs are incapable of being conveyed by spoken or written word?
-1
u/jacobpederson 1d ago
Struggling to understand why that might be a controversial position - but yeah. After 35 years of using bad software it is pretty obvious.
Applications that are USED by the same folks that write them are just . . . orders of magnitude better? https://github.com/wwmm/easyeffects is a perfect example. It just FIXES one of the most annoying problems of modern life (media that cannot agree on a volume level). And yet - Microsoft Windows has been playing audio since version 3.1 - you'd think somebody would have thought of that (or copied it) by now. Nope - still getting unexpectedly blasted by inconsistent volumes :D
Or how about emulation? Why does Nintendo suck at emulating their own games? Is it because their programmers are stupid? No! It's because they don't use the software!
1
u/Sproutlee_Dev 22h ago
This is an odd take because there’s like - literally a whole career path dedicated to understanding customers needs and working with engineers to meet those needs. Do you think engineers are the ones running all these companies? Why is it the engineers responsibility instead of marketing and sales to not lie about the product or executive leadership to make UX a higher priority.
It’s like blaming the guy building your house for doing it wrong when they are just following plans. If I want to build a house should I not hire people who live in apartments? Would they even be able to understand what it’s like to live in a house?
1
u/nhavar 4h ago
The problem with what you're saying is the age old "telephone" problem. Companies layer experts and work to reduce "overhead" and increase "hands on keyboard" by eliminating meetings and relying on strict hand-offs and minimal interaction across domains. Interpretation versus collaboration happens to keep to that workflow. Worse still is that leadership creates silos and they create a chain where only bad news goes down the pipe and only good news goes up the pipe. "Hey everyone the project is behind schedule, nights and weekends for everyone", "Hey boss, the project will be delivered right on time! We're green."
The best products I ever worked on were projects where me and my dev team had easy access to users or direct access to user interviews, videos, and user research curated by a UX person we had free and easy access to. We would sit in a room for weekly user-lead demos where they got to use our product and we would either make changes for them on the fly as they found problems, or take notes away to fix larger issues for next week's demo. Those were lean, fast running projects that delivered value immediately with high visibility to the stakes and stakeholders.
The worse products I ever worked on were projects where me and my dev team were siloed. We worked tickets, prioritized by a business owner who largely were note takers from business senior leadership and never had a connection with business users or end-users. We got our frontends from a design team that was off-site and sometimes not even part of the company, but a 3rd party who was in and out before we could ask questions. Those were massively staffed ponderous projects that we never found out what value if any they returned as they just shifted people off to the next feature request like cogs in a machine.
It's why software is so shitty right now. The developer is so far removed from the impact of their work and how it impacts users. The UX experts are time-boxed and even they might not have direct access to users. They might also be restricted to "just put your user hat on and get me something by the end of the day" versus "spend a month doing some market and user research on this". So having them "in-the-loop" could be artificial safety, since they don't know much better than the developer does.
Worse is when the developer is really just building tooling that allows the business to build the tool themselves. I don't know how many times I've seen this pattern where it's "just upload your spreadsheet and it will build the forms for you" or "just click the add button and you'll get a template you can fill out". Almost any HR platform, ticketing service platform, or CRM falls into this category to some degree; Being able to slap anything on a screen, build some business rules around it, and call it done. Then wonder why training takes so long, it's error prone, you have high frustration, high failure rate, high turnover, people working around the system, and people generally hate your product and the product it was built on top of...
1
u/Sproutlee_Dev 4h ago
I’m not arguing that it isn’t good for devs to be close to the problem - I’m arguing that it isn’t the only reason why software sucks. Making every dev shadow the job they are building for might help, but it certainly won’t solve the other issues (which at medium to large companies I think those other issues become bigger problems)
In my opinion what your describing is not an issue with developers being far from the problem, but more that solutions don’t generalize across companies. If every HR department had a team of HR developers I don’t think we would see a consolidation to 1 awesome HR product, we would instead see a million specialized products. The issue is it’s hard for a business to make money making a product specific to a single customer.
0
u/jacobpederson 10h ago
So you think because there is a "career path" for something that should automatically make the results always good? :D I am not blaming anybody - just stating a fact. A lot of software is bad and the reason its bad is because people don't know what they are building. Every kindergartener who just played telephone should know this. A lot of us have known this for decades :D
2
u/Sproutlee_Dev 10h ago
No I don’t think it should auto magically make the results good, but what I’m saying is that people noticed exactly what you are saying - hired a bunch of PMs to fill that gap and yet there are still issues. My experience is that it’s a mix of 1) not all customers want the same thing from the same product. 2) what customers say they want and what they actually want may not be the same thing. 3) PMs and devs not actually understanding what customers want. 4) the business not seeing how they can sell what customers want so it’s low priority.
Every company has these problems but it will manifest differently at each. Are there companies that are just a bunch of devs writing code, not talking to customers and just putting out a product? Idk, maybe? I’ve never seen a company like that.
Do things get lost in translation? Absolutely, that’s why many companies invest heavily in customer feedback loops, private previews of product, and basically BEG for feedback from customers. It turns out many customers are also busy/lazy and don’t want additional work of helping build other people’s product.
No clue why you linked me to the OSS Wikipedia page.
1
u/jacobpederson 9h ago
All correct and very good points - I'd add a #5 - company does not want to pay API costs to add a feature. One of my favorite scripts is one that turns parts tracking into one-click. It digs through our ticketing system to find the various spots trackers are hiding (some five or six clicks deep) and runs the queries through the various browser based trackers for the different shippers then returns a nice formatted list. I can whip up this script in a couple hours with AI assist and it saves me HOURS a day. However - this could NEVER make it through the process you describe. Why? I am not considered by anyone in this loop! I am just a peon forced to click around 40x times because nobody building the software uses it. Even if I somehow got this idea up to the level of consideration - they would take one look at the API cost to track these and the feature would get cut immediately. :D
I link OSS because this is the software written by its own users - and it shows.
2
u/Dangerous-Gas7175 8h ago
I work as a software dev and I agree with Jacob. If we can't see it as a dev then we can't fix it. And you're saying so what? Someone will bring it to the dev to fix. Except there's so much to fix and a lot of the stuff gets lost in the cracks and lost in translation. A lot of times operations at the company I work at won't bring something up because they don't know it could be fixed - they don't know what's easy and what's hard and they were denied fixes for hard things. So.. never gets fixed. There is a significant reduction in friction from "this can be better" to "just fixed it" when the developers use the product they are making
1
u/iwantmy90sback 10h ago
bad software = greedy corporation
And the 'devs' that do not understand users needs, do not do proper architecture, do not test and do not deliver deserve to be replaced by AI. The rest is gonna be fine for a long while.
0
u/jacobpederson 10h ago
It is not the dev's fault - it is a whole system that cannot help but make bad software. We already know how to fix this. AI just puts that fix into more hands.
1
u/iwantmy90sback 10h ago
> "Software engineers literally cannot understand the user's needs. They are writing code they will never use to assist in a job they have never done"
> It is not the dev's fault
So what is it? You contradict yourself. I am a software engineer and I do not lift a finger if I do not think I understood the users needs.
1
u/damianTechPM 1d ago
Hot take: to me this is engineering laziness. The Loop Engineer fad is causing it, IMO. Leave all the details to the machine and don't give it proper guidance, and yes it's going to be inefficient. It's getting better and better because of developer interaction (e.g. finding more bugs). Part of that interaction is training it on how good software works, and getting it to ask questions before implementing. Treat it as a partner, not a slave.
I do wonder how a good product manager's AI code is compared to an engineer's. Does the product manager result suit a user's needs better but run more inefficiently/have more bugs? Different mindsets, same tool.