Comment by noduerme
12 hours ago
The hell with with whatever speed boost I might get. I still write all my code by hand every day, and own what it does. I know it. And I don't have to worry about atrophy.
Could've outsourced a long time ago to humans, if I wanted to deal with reading code most of the time instead of writing it.
If programmer speed and efficiency was truly such a significant competitive factor, we wouldn't be packing them like sardines them in noisy and stuffy open floor plan offices.
I've worked places that actively acknowledged they were paying a productivity tax for people to have unexpected encounters, and they'd recover the losses at a higher level.
This. And there would be huge investments in productivity and reducing bureaucracy.
Do you have management pressure to use these tools? I don’t have any data but me and virtually every software engineer I talk to regularly is feeling or has felt pressure to use these tools.
I personally do not. But I don't work in the software industry. I write custom software in an industry that's as far away from tech as you can imagine. My management tells me what features they want, and doesn't care how it gets done. They only care that it works, and the priority is never to get a feature out fast. The priority is to never break their logistics software that's used 24/7. The deployment cycle is still fast, but bugs can be catastrophic, and it's on me to fix any bugs that crop up whenever something goes into production. Usually, when a bug filters up to me, it's within a few hours, because edge cases arise quickly. I know almost immediately what lines of code in which files are the most likely culprits. Because I wrote them. If someone else (or something else) wrote them, I'd have to go hunting exactly when time is critical and there's an open bug in a live deployment.
The term "vibe coding" is new, but I've described what I do as "jazz coding" for a couple decades.
FWIW, I'm responsible for our engineering team, and I'm the one starting to put some gentle pressure on the developers right now. Velocity used to be one of the bigger issues we had: Features used to be in development over weeks, while customers, product management, and engineers iterated on the feature, until it was finally deemed stable enough and shipped. With AI, we can shorten that cycle considerably, and get stuff out of the door in days or even hours instead. Doing so requires adapting your processes accordingly, give up some control over the details, take good care of tests, and do proper code reviews.
Given all that, I just cannot ignore AI as a development tool. There is no good justification I can give the rest of the company for why we would not incorporate AI tools into our workflows, and this also means I cannot leave it up to individual developers on whether they want to use AI or not.
This pains me a lot: On the one hand, it feels irresponsible to the junior developers and their education to let them outsource thinking; on the other hand, we're not a charity fund but a company that needs to make money. Also, many of us (me included) got into this career for the joy of creating. Nobody anticipated this could stop being part of the deal, but here were are.
> There is no good justification I can give the rest of the company for why we would not incorporate AI tools
Is there definitive proof of long term productivity gains with no detriment to defects, future velocity, etc?
If so I’d say you’re irresponsible at best to put this much trust in a tool that’s been around for a few months (at the current level). Absolutely encourage experimentation, but there’s a trillion dollar marketing hype machine in overdrive right now. Your job is to remind people of that.
Your team is creating code you don't really grok to "get stuff out the door". Guaranteed a month or year from now this is going to bite you in the ass, hard.
This is a starker tradeoff, but still the same logic that engineering leaders have used for years to eliminate time for exploration, learning, mentoring, role-switching, and every other activity that makes a better engineer but doesn’t move tickets off the queue. These developers are all going to work somewhere else in a few years, so why should we invest in growing their skills? This isn’t a charity, after all.
I’m sure you’re smarter than that, but a lot of leaders aren’t. And that’s based on the past, when they had an established playbook they could choose to follow, not the situation we’re in now where you have to make it up as you go.
2 replies →
So, you have a duty of care to make a safe workplace, at least in most countries.
Consider what a job with no joy means for the ongoing mental health of your staff, where the main interaction they have all day is with an AI model that the person has to boss around; with little training on norms. Depression, frustration, nonchalance, isolation, and corner cutting are going to be the likely responses.
So at the same time as you introduce new tooling, introduce the quality controls you would expect for someone utterly checked out of the process, and the human resources policies or prevention to avoid your team speed running Godwin's law because they dont deal with people enough to remember social niceties are important.
Examples off of the top of my head of ways to do this are: - Increased socialisation in the design processes. Mandatory fun sucks, a whiteboard party and collaboration will bring some creativity and shared ownership. - Budget for AI minimal or free periods, where the intent is to do a chunk of work "the hard way"; and have people share what they experienced or learnt - Make people test each other's work (manual testing) or collaborate, otherwise you will have a dysfunctional team who reaches for "yell in all caps to make sure the prompt sticks" as the way people talk to each other/deal with conflict.
The way to justify this to management above you is the cost of staff retention - advertise, interview, hire, pay market rates, equip, train, followed 6 months later by securely off boarding, hardware return, exit interview means you get maybe 4 months productivity out of each person, and pay 2 months salary in all of the early job mistakes or late job not caring, or HR debacle. Do you or your next level up want to spend 30% more time doing this process? Or would you rather focus on generating revenue with a team that works well together and are on board for the long term?
The answer most of the time is "we want to make money, not spend it". So do the math on what staff replacement costs are and then argue for building in enough slack to the process that it costs about half of that to maintain it/train the staff/etc.
Your company is now making a "50% efficiency gain" in the HR funnel, year over year, all by simply... not turning the dial up to 10 on forced AI usage.
Framed like that, sounds a lot better doesn't it?
2 replies →
> it feels irresponsible
And it is. You are going to end up with a wreck of a product and not a single person you can call upon to fix it. It is your choice and you will pay for it.
5 replies →
So you struggled to improve velocity without AI tools, are you worried that using the AI tools as a crutch will just lead to a death spiral of bad code being shipped increasingly faster? I've only ever seen the AI adoption approach work on fully functional teams.
The concern as well is that by forcing the AI onto developers, they eventually throw their hands up and say "well they dont care about code quality anymore, neither should I" and start shipping absolute vibeslop.
2 replies →
[dead]
You are feeling that pressure because the people that use them are more productive and the next pressure you are going to get is to remove yourself from the loop completely.
This mentality never worked in IT world. We've always had high pace of change and endless learning and adaptation to new tools and approaches.
Nobody has to worry about atrophy. That's the good thing about it: Things only atrophy when you don't need them any more.
Am I alone in thinking atrophy might not happen? I use a keyboard all day but it doesn't mean I can't write by hand anymore. Predictive text didn't make me forget how to spell. If i buy coffee it doesn't mean I forget how to make it
Real quick, how does paging work?
yup. no effort - no bliss. and for rare bouts of wanting to shepherd cats I just got meself some actual cats. At least they don't pretend to be engineers.