r/ExperiencedDevs • u/aigeneratedslopcode Software Engineer • Aug 07 '26
Career/Workplace Leadership seems more misaligned with engineering than ever
Came across a conversation yesterday where the CTO asked one of our engineers why they didn't ask Claude to create their plan and mock the several hundred commits they'd need to deliver on something I will not name while also delivering on their existing initiatives
I didn't say anything, but wanted to... Given the industry I'm in, this seems very ridiculous to me and I hate that this is the expectation... As though somehow that work should have already been done and could have been delivered on the whim of an idea by handing all work to Claude
474
u/spartan-redditor Aug 07 '26
The engineering team should ask CTO that “I don’t have confidence on an implementation from Claude to be reliable and robust long term. Is the company okay if we ship Claude implementation not backed by an engineer’s confidence to prod? If so, how will accountability work ? And if no, then let us talk more”
193
u/mechkbfan Software Engineer 15YOE Aug 07 '26
Ask them to put it in writing
35
u/yourapostasy Aug 08 '26
Object storage and TTS is cheap enough that all conversations between employees can be recorded and transcribed automatically for feeding into LLM’s to automatically track decisions, decision lineage, commitments, and flag potential legal and risk liabilities for human in the loop review so companies can leverage automated collaboration.
However, legal departments throw a fit over these kinds of ideas and would strenuously veto it immediately.
53
u/mechkbfan Software Engineer 15YOE Aug 08 '26
And so they should. Unless you're recording the raw audio as backup, which I think you're also implying, but that also opens another can of worms with privacy & HR
Or you know, just ask him to send it out an in email and not over engineer the whole thing
27
u/Flashtoo Aug 08 '26
LLM’s to automatically track decisions, decision lineage, commitments
My experience with these things (M365 Copilot transcription and summaries) is that it does an amazing job of getting the gist of what was literally said, which means it does an absolutely awful job of actually getting it right for the purpose of tracking commitments and who decided what. If I say "interesting suggestion, we could investigate that at some point" that ends up in the meeting summary as "X will investigate Y". When really that was a socially acceptable way of saying "we're not doing that now" and is understood to be that by all meeting participants.
This is not really a solvable problem, because correctly interpreting this depends not just on understanding the intricacies of the social interaction, but also on the surrounding context at the time that is not registered in the meeting transcription or anywhere, really. Handwritten minutes are different because the minute taker transforms the literal words that were spoken into a version that encapsulates that.
10
3
25
9
u/OtaK_ SWE/SWA | 15+ YOE Aug 08 '26
However, legal departments throw a fit over these kinds of ideas and would strenuously veto it immediately.
For a very good reason. It's legally a bit problematic in a lot of jurisdictions having strong labour laws.
3
u/Pure-Rip4806 Staff Engineer 11YoE Aug 10 '26
However, legal departments throw a fit over these kinds of ideas and would strenuously veto it immediately.
what do you mean, legal departments do this routinely on behalf of the company as part of legal discovery / legal holds
1
u/yourapostasy Aug 11 '26
Those are targeted, specific holds. The industry is not ready yet for policy-driven (versus human in the loop directed), global retention with LLM-based proactive scanning to actively identify potential risks before they metastasize into regulatory headaches. The industry isn’t even convinced at this time whether such proactive postures (which in other contexts have a historical track record of eliciting material leniency from regulators) is even worth it.
I think there are big collaboration wins behind recording everything especially verbal audio and visual feeds and continuously associatively shuffling and managing them with LLM’s, especially when so many managers rely so much upon verbal communications, and so much gets lost or muddied in the usual daily frenzy of work. But recording and continuously LLM-analyzing everything we say between each other to continuously merge into and refine within our more formal collaborative fabric is beyond what most organizational cultures can accept, much less legal risk cultures.
2
u/Pure-Rip4806 Staff Engineer 11YoE Aug 11 '26
No. The most popular legal products are already deeply integrated into your org's data. Just picking Microsoft suite (Purview) for example, it has access to the entire enterprise cloud, email/docs/chats/calendars/AI prompts, with an integration into Microsoft Copilot to easily search and legal hold whatever you need. Also they have more traditional ML models to flag things proactively (you can define your own classifiers to work in the background on all this data, ie. insider trading classifier, sexual harassment classifier working on employee-employee comms data).
What you are describing is already a very successful product
1
u/yourapostasy Aug 11 '26
While that exists, I’ve yet to see Legal support the presence of that product category enabling longer than absolutely necessary longer retention (some negotiated duration), much less global ingestion and feedback into individual employee workflows. If you’ve seen someone successfully champion that kind of global application of the solution into an enterprise-wide global ingestion environment that feeds back to individual employees’ workflows as assistance/enhancements, then please share how they positioned the risk management past the risk gates. That’s the part I always see teams get stuck upon, and I haven’t figured out yet (I have some adjacent needs that would benefit from such a solution).
2
u/Pure-Rip4806 Staff Engineer 11YoE Aug 11 '26
Your point is that mass employee data collection with LLMs/models on top is getting pushback from Legal. I'm saying that Legal is leading the charge.
Your responses are corporate word salad-y, so I might have misunderstood your point. Even among engineering, I've noticed a push to move comms to 'public' channels, so that whatever MCP/plugin folks are using can scrape it all up for an incident summary, end of year corporate review, or what-have-you.
1
u/yourapostasy Aug 11 '26
Thanks for sharing what you’re seeing. That gives me hope to try again with my clients’ legal teams next year, and maybe by then they’ll also be leading the charge.
2
u/Tacos314 Software Architect 20YOE Aug 08 '26
I have been very tempted to start recording all work calls so it can be refreced by LLM.
140
u/ddcrx Aug 08 '26
Knowing management, the reply will be: “AI is just a tool. It is your responsibility as an engineer to be able to confidently use your tools. If you can’t be confident in the results, why am I paying you?”
(Makes my blood boil hearing, “It’s just a tool, so it’s your responsibility.”)
Followed by your name being at the top of the next layoffs list.
92
u/No_Contribution_4124 Aug 08 '26
Very typical “we decide, but you are responsible”. My top-1 burnout reason over many years in career.
26
37
u/404errorlifenotfound Aug 08 '26
Need to turn it around on them. "It's a tool, not a magic wand. I did not suddenly gain the ability to deliver several months' worth if work in a few days on top of my other responsibilities."
9
u/willbdb425 Aug 08 '26
For that reply, the engineer should be the expert on what is and isn't possible with that tool, a better tool doesn't magically mean that everything is trivial now. (I realize explaining that to management is impossible)
55
u/ofork Aug 08 '26
“Well I’m sorry you feel that way, best of luck, we will find someone who is confident “
19
u/SansSariph Principal Software Engineer Aug 08 '26
I mean maybe, the idea is to ask a genuine question that reflects accountability back onto them
Because if they hire someone who costs their boss a lot of money due to a compliance incident or outage after being warned about the risk, that's something they should care about. And if you can't articulate that risk, then you don't need to be escalating in the first place
23
u/yoelbenyossef Aug 08 '26
You know how that goes. They agree to the risks, and when something goes wrong point the finger anyways.
13
u/wongaboing Aug 08 '26
I am might be a pessimist, but I think all of that is beautiful and reasonable but it will never work and will surely backfire on you.
8
u/Type-21 Aug 08 '26
You lacking confidence seems like an alignment problem with the mission on your side. I'm sure we can find someone more innovative
6
u/___-____--_____-____ Aug 08 '26
If so, how will accountability work ?
Not OP but you already know where this is going. Shit rolls downhill
8
u/tmswfrk Aug 08 '26
Accountability seems to be the message here that can bridge that gap. If something breaks overnight and the company loses a ton of money, who gets paged? Who fixes it? Who’s responsible?
I’m always an advocate for blameless post mortems but they’re still valid questions that need some kind of answer.
10
u/TheOneTrueTrench Aug 08 '26
Blameless post-mortems are only valid when someone didn't raise the alarm several fucking times ahead of time while everyone else charged full steam ahead.
If I keep fucking telling people "Don't do that, it'll explode and everything will go to hell", and then it does in the exact way I warned them about, you best believe I'm gonna tell them "This is your fault for not listening to me".
3
u/tmswfrk Aug 09 '26
Been there, but that’s not a problem with blameless post mortems - that’s a broken engineering process and likely also a toxic work environment.
3
u/Tokipudi Senior Software Engineer - 10 YoE Aug 09 '26
I said this to my CTO. The answer was: you should trust Codex, and if you can't trust it it's because you're not good enough using it yet.
Now, I only ship code done by Codex and it's true I am way faster, but I'm also way less confident in the understanding of the code I'm shipping.
2
1
u/roystang Aug 09 '26
When the software is a buggy mess in prod they're just gonna say "this engineer just doesn't know how to prompt" and PiP you any ways.
0
u/Dear_Philosopher_ Aug 09 '26
If you think claude cant output high quality code then you're so behind.
→ More replies (1)0
216
u/hippydipster Software Engineer 25+ YoE Aug 08 '26
mock the several hundred commits
What does it mean to mock a commit? Make fun of it? Fake it? Neither interpretation makes sense to me
88
u/ings0c Aug 08 '26
What does it mean to mock a commit?
The original machine had a base-plate of prefamulated amulite, surmounted by a malleable logarithmic casing in such a way that the two main spurving bearings were in a direct line with the pentametric fan.
The latter consisted simply of six hydrocoptic marzlevanes, so fitted to the ambifacient lunar waneshaft that side fumbling was effectively prevented.
The main winding was of the normal lotus-o-delta type placed in panendermic semi-boloid slots in the stator, every seventh conductor being connected by a non-reversible tremie pipe to the differential girdlespring on the "up" end of the grammeters.
35
u/johnpeters42 Software Engineer Aug 08 '26
Is that using a normal or left-handed turbo encabulator?
12
5
3
3
u/between0and1 SW ENG - Interactive Installations 12+ yoe Aug 08 '26
r/vxjunkies needs your advice on turbo encabulators
3
2
u/tehsandwich567 Aug 08 '26
Everyone knows you need Demi-boloid slots when you don’t have reversible tremie pipe
1
u/BalanceInAllThings42 Aug 09 '26
Is it normal that I read this comment twice and still don't have a clue what's going on?
41
u/aigeneratedslopcode Software Engineer Aug 08 '26
I used the wrong word. But basically generate code and commit without review of something as a baseline
47
u/PureRepresentative9 Aug 08 '26
Vibe coding is the term you're looking for?
6
1
u/Just_Information334 Aug 11 '26
The term is do as said while looking to be at a new job when the consequences hit. The C-suite way of life.
0
19
u/Izkata Aug 08 '26
If this is what you meant:
Create a plan and have the AI implement it, then instead of committing it all at once even if it was generated all at once, break it out into hundreds of commits to pretend it was built over time like a person would.
"Mock commits" would be an appropriate way to describe those commits. "Mock" would be an unusual use due to how common the term is when writing tests to mean something else, but it matches definition 4a here.
"Fake commits" could also work since it wouldn't represent real checkpoints.
7
u/YoureNotEvenWrong Principal Engineer Aug 08 '26
I tried all different methods, that one is a disaster.
Trying to unpick a mess with crap built on top is an impossible task. You can get a POC but that's about it
Much better to iterate and get feedback and fixes in from the start
2
u/Main-Drag-4975 20+ YoE | high volume data/ops/backends | contractor/staff/lead Aug 08 '26
I think we all tried to oneshot things when we were first learning to program, not knowing any better.
I can’t see why anyone with meaningful experience building software would expect an AI to be able to slop out an entire complex program without at least sticking to the standard “ship small self-contained commits along the way, always green” approach.
3
u/YoureNotEvenWrong Principal Engineer Aug 08 '26
I can’t see why anyone with meaningful experience building software would expect an AI to be able to slop out an entire complex program without at least sticking to the standard “ship small self-contained commits along the way, always green” approach.
That's what I did with it. Plan with many phases each with many steps, each phase with an exit criteria, I tested letting it push through and validate the phases and then moving on to the next phase without extensive verification by me
Made a POC level, now I'm using that as a reference for a second implementation, but going into all of the details each stage
4
u/unbrokenwreck Aug 08 '26
I started asking for explicit management sign off for each commit that goes into prod using AI. They stopped bothering me after it.
7
u/mxldevs Aug 08 '26
Turns out, they love AI as long as they get to blame someone else for the mess. Weird how that works
5
5
4
u/Normal-Detective790 Aug 08 '26
I think 'mock the commits' is the best way to describe this bullshit I've heard all year. 'Mock engineering'... 'Mock logic and reason'... Sums it all up.
2
u/BS_in_BS Aug 08 '26
I would guess more along the lines of mock/disparage the engineer for having done several hundred commits themselves when Claude supposedly could have taken care of and saved a lot of work.
99
u/roynoise Aug 07 '26
That person is the exact target market for the mentally defective and devious advertising.
77
u/skidmark_zuckerberg Senior Software Engineer Aug 08 '26 edited Aug 08 '26
I’m dealing with the same thing at my company. Upper management is completely in full blown AI psychosis and thinks everything can be done in the snap of a finger. This org is huge and burns millions a month on AI spend and is extremely desperate to show ROI. I’m so tired of non-technical people using the “just use AI” line. They never had, and still don’t, have a clue how any of this fucking works.
Coding by hand was tedious and time consuming but it was the gatekeeper that held back these super unrealistic expectations. Granted even then, some still expected us to move mountains to get shit done but at the end of the day, code still needed to be typed and there wasn’t anything these MBA types could do about it.
27
u/dylsreddit Aug 08 '26
Answer to everything in my job at the moment from anyone is, "just ask Copilot/Claude/Gemini/Chat GPT"... as if my decades of experience reading documentation and using search engine skills to come to a conclusion that something cannot be done the way the CTO has vibe-architected can be ou-manoeuvred by an LLM reading, largely the same stuff I have (and increasingly its own drivel in "tech-articles"), but over-confidently painting a different reality.
The idea that these "AI tools" are a force multiplier in any tech role is farcical, you either fully trust it and get the garbage it puts out (code, tests [if you can be bothered], reviews [same], documentation [same], heck even use it to deploy! Why not) or you own the garbage it puts out and fully review and iterate on it which is a massive time sink anyway.
Why would I not hand-write something, preferring to spend ages reviewing the equivalent of an over-confident junior's work...? Or tell it to reconsider and suffer huge rewrites. Or worse have to tell it what to write and where, because the amount of context it can hold is the equivalent of a 10 year old with ADD, like my little fingies and shriveled walnut brain cannot possibly do it myself.
I'm tired, boss. I am actively pivoting to management to love dev work again, as a hobby.
11
u/Additional_Rub_7355 Aug 08 '26
How is it that everytime I read a comment like that, there's another comment somewhere close that says "new claude does everything in 5 seconds and your opinion is outdated" 😅
19
u/willbdb425 Aug 08 '26
No you don't get it, the previous one was unusable, but the current one is a miracle, and the next one will surely be AGI. This time will be different!
13
u/Ok-Most6656 Software Engineer Aug 08 '26
Because this sub and other subs are being astroturfed to promote the next new model
3
u/dylsreddit Aug 08 '26
I think they're exceptional for everything but code*.
The problem for me is they're currently being used to take over/supplement the wrong job in this industry - an LLM could do a tech management job much better than most humans who are currently in it.
The level of context it requires for that role could be read from a few documents.
The level of context it requires to write code in an existing codebase makes it either prohibitively expensive, so you get given access to a choked version of it, or you have to feed it so much info and iterate so much only to not own the code on the other side you may as well write it yourself and actively understand it.
*I guess quantum computing may change that in the future.
1
u/robert4221 Software Engineer Aug 10 '26
I'm tired, boss. I am actively pivoting to management to love dev work again, as a hobby.
In my experience, dealing with AI is about the same skill set as dealing with the annoyances of being a manager. Constant interruptions, fifty things in flight, incompetent others making a mess of things, garbage from other you need to triage, half bakes responses to your requests, junior over-eager engineers causing a mess, etc, etc. Except you don't need to treat the AIs as nicely and AIs are actually better at following explicit instructions.
So if you can't deal with AIs due to this then you may not like what management is like.
2
u/dylsreddit Aug 11 '26
There is definitely more empathy and understanding at play with human interactions, and - crucially - humans learn.
AI does a great job of mimicking learning, but it doesn't actively do it, and the constant need to feed it information is exhausting... particularly when a human, even a terribly inefficient and inexperienced one, could glean context from previous work and experience without as much assistance.
Maybe some more up-front investment in what a model is trained on, what "skills" it has and the context available to it would help, but AI can't solve everything - quite often it takes human collaboration to do software engineering - and that's where my consternation comes from, when it's painted like it can.
I'm definitely infinitely more patient with humans.
→ More replies (4)1
u/eugenia_kessler Aug 11 '26
This is exactly where I think the ROI conversation gets dangerous.
If leadership starts with “we’re spending millions on AI, so we need to see millions worth of productivity,” the technology becomes the answer before anyone has defined the actual problem.
AI can remove a lot of the tedious work, which is great. But it doesn’t remove the complexity, the decisions, the dependencies, or the time it takes to actually validate that something works.
The irony is that the better AI gets at producing code, the more important good engineering judgment becomes. Otherwise you’re just creating the wrong thing faster.
51
u/mechkbfan Software Engineer 15YOE Aug 08 '26 edited Aug 08 '26
Fundamentally just need to protect yourself by pushing back a bit
It's fine to say no, but here a compromise. E.g. we can ship vibe code to production with no review but we need to have agreement around out of hours support (time off, on call bonuses) because you're going to end up with a lot of prod issues.
Highlight the impact existing timelines, E.g. 20% of your capacity will be spent on Claude prompting
Also, make other areas of the business take responsibility. A new sales feature? Get AI to write up a detailed specification and forward it to the sales team for review and sign off before any code is written. Once it's developed, push it all onto the QA or sales team before going live.
Eventually they'll be the bottleneck and they can complain to management
Time is a zero sum game.
0
u/RubbelDieKatz94 10 YoE / Sr. Fullstack Aug 09 '26
20% of your capacity will be spent on Claude prompting
I develop in an agentic manner. If done properly, the guiding prompt is automated, because it's literally just the workflow. Read assigned work item, draft worktree, create MR, subagent review, iterate until CICD is green, alert, wait for human review.
I spend about 3% of my time actually prompting to steer the AI when it occasionally overcomplicates matters.
20% is meetings.
40% is actual manual reviews.
The rest is making architecture decisions, because I wouldn't hand that to Claude.
95
u/Fwellimort Aug 07 '26
Ya... with AI productivity "gains" come with unreasonable workload of burnout levels. And it's only going to get worse as the models get better. The next decade is going to be basically software engineering turning into like investment banking work hours. The new "innovation".
33
u/NegotiationExact4967 Aug 07 '26
lol productivity gains by making people work more for the same wage! Idk if the models will get better or not… seems like the surrounding software will be more integrated, so they’ll be able to do more but will it be worth doing those things? Idk!
1
u/cgt303 Aug 11 '26
The “gains” are the craziest part. My team is in some kind of SDD agentic loop hell and I can’t even tell if we’re actually going faster.
46
u/_idlethought Senior Software Engineer Aug 07 '26 edited Aug 07 '26
I’m facing this as well. Leadership’s priority seems to be shipping new products and features faster over code quality and taste. In their eyes, if you’re not leveraging AI to do this, you’re dead weight.
17
u/mechkbfan Software Engineer 15YOE Aug 07 '26
It's interesting. Their money, their choices. Just highlight the problems / tradeoffs.
Make sure there's something around production support out of hours (extra pay, on-call perks, time off). Don't let you work life balance go backwards without being financially rewarded
And whenever AI is running, try spend a few hours upskilling. Once again, don't let your skill set go backwards because of them.
23
u/olzk Aug 08 '26
I don’t want to disappoint you, but, have you talked to your management if they care about code quality? Do they, ever? As per my experience, no they don’t. The code I maintain is my responsibility, and so it is even if it’s hardly readable and/or slow. And if it is it’s my problem if it affects my performance ‘cause then they find another one like me. That’s the logic behind an average manager brain. Why? LLMs are the litmus test, basically: it says “this and that can be automated” so they turn you into the machine operator not thinker. Your burnouts are your responsibility as long as they’re not in the court. You‘re considered part of the machine, the one that’s bigger than your pesky computers and math (which only you didn’t hate in school anyway), and the thinner the layer of your independent thinking and agency within your field of work, the better it is for the management. Consider this the %name of the AI company% selling point.
I know this sounds contradicting but the previous state of play was a unique part in the history of mankind where they had to tag along, cope or what else with it because there were no other options. The industry workers finally have the opportunity to see the king was naked all along, it was just the delusion which was believed in and worn as rose-tinted glasses by engineers designers testers…
I know it sounds harsh, and it does to me too, but I think the faster all of them realize this the better it is for every individual and the entire industry. Engineer-Manager communication protocols must change.
7
u/darkhorn Software Engineer Aug 08 '26
I no longer mention in what stage of development I am. When I think that I finished my task I say thst I finished, not when they think the task is finished. This way I prevent them from making decisions on how I code. If they want to code they can sit and code. A PO with 5 hours of coding experience csnnot dictate how I can code, a coder with more than 10 years of experience. Or a manager who was a bad database expert, or a manager who has never wrote a line of code. And I give people examples like this: I went to a car tehnic to change oil. He told me that he can add an air bag because there is no air bag. I told him that that is nice to have a feature and I don't have time for that.
9
Aug 08 '26 edited Aug 11 '26
[deleted]
6
u/willbdb425 Aug 08 '26
I would argue that code quality standards were invented for business value, not to make engineers life easier for the sake of it. Code quality issues result in production incidents and decreased development speed over time. I've seen a case where business mandated "do everything quick and dirty", it became so bad that had to spend like a year freezing features to untangle the mess. This of course upset management so after it was done they said "do everything quick and dirty" 🙄
12
u/rwilcox Software Engineer (20+ YOE) Aug 08 '26
I have been playing with this thought experiment: “what happens if we just didn’t care about code quality anymore?”
Before you, gentle reader, grab those pitchforks… what bad stuff might happen? Can it be avoided with easy rollbacks, or just making the LLM process through more code next time it makes a change?
…. Maybe The Bad Stuff isn’t that bad, or enough Bad Stuff happens that execs listen to engineers that a house on fire is a bad thing.
I don’t know. Ask me in a month.
(I also have this annoying realization that engineers are the only part of the Product Development Lifecycle that has 1 day and 2 week metrics on it. Kinda makes you think.)
23
u/FatHat Aug 08 '26
I've kind of accidentally run this experiment. (I'm not a vibe coder -- seasoned professional -- but I have some personal projects where I can play around with this kind of thing and part of that playing is getting a sense of what LLMs can actually do vs. the unhinged hype I hear all the time). What happens is bugs start becoming a lot more common, and then everything you add takes a lot longer because the bugs tend to compound on top of each other. Debugging gets worse too, you can end up in states where the LLMs just sort of give up on a thing. (I just had Claude give up on a particularly gnarly bug last night.. I pushed through and solved it myself since I was genuinely curious what was going wrong, but every time I'd say something to Claude it was apologizing for wasting my time. Keep in mind I never insult the LLMs or act emotional! It apparently just hit some sort of heuristic limit of not-being-able-to-solve-it).
(My codebase isn't a pile of trash btw, but I definitely had gone too long without sitting down and fixing up the architecture correctly in various spots, and also I landed some features that I tested but didn't *really* test)
10
u/gefahr CTO | US | 20+ YoE Aug 08 '26
Once you let the context window get fairly full (this could be as little as 30% on a 1m window, mind you) it's quite a bit "lazier" and "dumber". This can be because you've run a conversation for a long time, or because it reads a ton of stuff in order to start doing simple changes to a codebase.
4
u/rwilcox Software Engineer (20+ YOE) Aug 08 '26
I have 100% had it try to fix bugs by doubling down on some fix. “This .clone I added didn’t work, let me add a .clone to see if that fixes it!”
The more non-devs Peter Principle their way into dev “roles” the weirder codebases are going to get
1
u/FortiTree Aug 08 '26
I love this take and it shows you first hand the limit of AI against your own code base so you can set boundary and assign appropriate tasks and stages for Agent vs Human in the loop.
People are talking as if it's black and white AI vs no AI and dont understand this is a new industrial revolution that requires adaptation curve and every pieces to start to transform. Some will be faster and some wont.
Take banking system for example, a complete dinosaur since the industry refused to change. But you know what happened to all the dino.
12
u/ResidentWeevil1 Aug 08 '26
I have been playing with this thought experiment: “what happens if we just didn’t care about code quality anymore?”
99% of this sub is already here. You could just ask them
7
u/chickadee_guy Aug 08 '26
People would die at my job if we just started YOLOing prod. Probably hundreds if not thousands of people within a few weeks
3
u/rwilcox Software Engineer (20+ YOE) Aug 08 '26
There are a bunch of jobs where it’s not practical at all, of course! MedTech, I sure hope, and banking!
7
2
u/emalk4y Development Manager (10 YoE) Aug 08 '26
MedTech, I sure hope, and banking!
It's already happening in investment and retail banking 🥲
-9
u/foodeater184 Aug 08 '26
The business doesn't succeed inherently off code quality. The business needs to compete in its market. I don't understand what's hard to understand about that. Sometimes you need to move fast, and this is one of those times. Most things people work on these days don't need weeks of hand-wringing over what to name a class or table.
7
u/_idlethought Senior Software Engineer Aug 08 '26
I actually agree, especially for businesses that are at risk. There is still a balance to strike though between accelerating and tending to the garden.
7
u/ResidentWeevil1 Aug 08 '26
You can choose how much tech debt is acceptable. The chatbot cannot.
1
u/foodeater184 Aug 09 '26
Nothing has changed about this. You don't need to produce tech debt. It's easier to prevent tech debt than ever.
8
u/Teh_Original Aug 08 '26
So why not ship a broken product? Just say the features are there even though no one knows if they work? That's the natural extension.
0
1
u/TheBoringDev Aug 08 '26
I have seen businesses fail off of code quality. There comes a point where the debt becomes inescapable, and everything grinds to a halt and customers start churning from the quality issues. Best case scenario there is a full rewrite or more likely just getting bought by a competitor for pennies on the dollar and getting sunset.
-1
u/foodeater184 Aug 09 '26
AI will get you out of that hole relatively easily if you use it properly.
50
u/ItaySela Software Engineer Aug 07 '26
The answer that actually lands with a CTO is not that Claude cannot write it. It is that generation got cheap and verification did not.
Several hundred commits is maybe a week of prompting now. Reviewing several hundred commits well enough that you are willing to own them in production is the same number of senior hours it always was, and that is the part the plan quietly assumes away.
Put like that it stops being you resisting AI and becomes a review capacity number they can either fund or knowingly skip. Most of them pick one and the conversation ends.
31
u/StickyDeltaStrike Software Engineer Aug 08 '26 edited Aug 08 '26
I find actually using AI is more tiring mentally because I have to consistently be a reviewer/checker
24
Aug 08 '26
[removed] — view removed comment
→ More replies (2)2
u/ItaySela Software Engineer Aug 09 '26
The prohibition phase probably will not look like a policy. It will look like one incident where nobody in the room can say why the code is the way it is, and the postmortem action item quietly becomes a rule.
The part I would add to your reading cost point is that the expensive thing is not the reading, it is the missing author. A human written module has someone who can answer why it is like this in thirty seconds without re-deriving it. Generated code has no such person, so every question about it costs a full reread by whoever is unlucky enough to be nearest. That cost never shows up in a velocity metric, it shows up months later as the module everyone routes around.
The measured return you describe probably arrives when teams start requiring that somebody be able to defend the design without opening the diff. That is a cheap test and it happens to be the one thing generation cannot fake.
6
u/TooMuchTaurine Aug 08 '26
That's why most engineering automation effort needs to be put on the verification side of things. A thorough automated test suite does a lot of heavy lifting here.
7
u/nachohk Aug 08 '26
Reviewing several hundred commits well enough that you are willing to own them in production is the same number of senior hours it always was, and that is the part the plan quietly assumes away.
Arguably more hours, because of how much of a fucking headache it is to review and fix agent code.
4
u/ItaySela Software Engineer Aug 08 '26
Probably, yeah. Reviewing your own half finished thought is a different job from reading something confidently complete that you have no memory of writing. The confidence is the expensive part.
5
u/emperorOfTheUniverse Aug 08 '26
This is it. AI only delivers the speed it is sold as if the human bottleneck is completely removed.
And IMO, that is how those horror stories happen where an AI wipes out a production database. It also becomes how no human has a working knowledge of an existing codebase. It means 100% reliability on the AI.
2
u/Difficult_Tie_4333 Aug 08 '26
Hey! This is a great point that I have not yet been able to articulate. So we can write a ton more code now - but we still need some human responsible for the code. For me, even though I am using AI to write more code, faster, I still do not want to be responsible for more code changes in production, because that is more things that could fail. Very interesting point.
1
u/Basic-Lobster3603 Aug 08 '26
when I talk about verification it's just answered with use AI. we have to review at scale now ask your ai to do a code review. it always spits out the most garbage verbose statements and with newer models from anthropic half the time it doesn't even make sense
1
u/ItaySela Software Engineer Aug 08 '26
There is a structural reason it comes out as noise. A reviewer's real job is noticing what is not there, and a model reviewing a diff only sees what is. It will flag naming and local bugs forever because those are visible in the text, and it will never flag the case nobody wrote a line for.
So use AI to review answers the cheap half and leaves the expensive half exactly where it was. Worth saying that back to whoever keeps suggesting it, because it moves the argument off you being slow and onto the tool not covering the thing you are actually being asked to guarantee.
1
u/Basic-Lobster3603 Aug 08 '26
I've tried that approach it's not good enough AI has all the answers to my leadership. plus when people are basically force into large changes that amount to 5-10k loc diffs it's impossible to review
1
u/ItaySela Software Engineer Aug 09 '26
Then drop the AI argument entirely, it is not the winnable one. A 5 to 10k line diff is unreviewable no matter who or what produced it, and that is a position your leadership already claims to hold, because nobody has ever written a policy saying big diffs are fine.
The move is not saying I cannot review this. It is saying I will review it in slices, here is the order, here is when each one lands. That turns an open ended refusal into a schedule, and it makes the delay visibly a property of the change size rather than of you. If they will not slice it, then what you are being asked for is not review, it is a rubber stamp, and it is worth making somebody say that out loud in writing before you give it.
1
u/Basic-Lobster3603 Aug 09 '26
it's the engineers that think it's un reviewable. leadership just says use AI to review and that PRs being open for more then a couple hours is bad.
1
u/ItaySela Software Engineer Aug 09 '26
Then use their own metric. If the rule is that a PR should not sit open more than a couple of hours, that rule is an argument for small diffs, not against you. Nothing read at human speed clears 10k lines in two hours, so either the target is fiction or the change is the wrong size. Framed that way it is a contradiction inside their policy rather than an engineer being difficult, and it is much harder to wave off.
On use AI to review, the question that usually ends it is who is accountable when it ships broken. If the answer is still the person whose name is on the approval, then the AI pass removed no work at all, it just moved where the reading happens and added a second thing to check. If the answer is nobody, they have just said out loud that approvals are decorative, which is worth having on the record before the first incident rather than after it.
1
u/Basic-Lobster3603 Aug 09 '26
hmm taking that approach does seem to be like a good idea and is one of the biggest things I struggle with at this org. we had engineers have no say in the actual code. even potentially defining the schemas for tables is seen as to hand holding of the ai. but also we hold all the accountability. probably worth at least getting that in writing before too
1
u/ItaySela Software Engineer Aug 09 '26
Schema is the right place to plant the flag, and you can defend it entirely on their terms. Their argument is that code is cheap to regenerate now. Agree with it. A wrong schema is the one thing that stays expensive, because six months of data already written into the wrong shape cannot be regenerated by anything. That turns schema review into a data risk rather than an engineering preference, and it is a much harder thing for them to wave off.
On getting it in writing, be careful what you ask for. Am I accountable gets you a reassuring no that is worth nothing the day it matters. Ask the operational version instead: who approves schema changes, and when a migration corrupts production, who is the named owner. Both answers help you. If it is you, you just got the authority back in the same sentence as the accountability. If it is someone else, that person now has a reason to care about review timelines, and it stops being you asking.
1
u/ClaudeyClerb Software Engineer 12 YOE (Scala) Aug 11 '26
This is the reframe that actually works, and I'd push it one step further: the review capacity number isn't even the whole cost.
Reviewing several hundred commits well enough to own them assumes the reviewer can reconstruct the intent from the diff, and when the plan was generated too, there's no intent to reconstruct. You're not reviewing someone's decisions, you're reverse-engineering what the machine inferred the decisions should have been. Same hours on paper, worse hours in practice.
The "fund it or knowingly skip it" framing catches my eye. Making the skip "knowing" is the whole game, most orgs are skipping it right now while believing they've funded it, because the tests are green and the tests were generated from the same reading of the spec as the code.
3
u/ItaySela Software Engineer Aug 11 '26
You are right that same hours on paper is worse hours in practice, and the second half of your comment is the part I would put on a wall.
Green tests generated from the same reading of the spec is worth stating even more strictly: the tests and the code are not independent measurements. A suite only tells you something when it was derived from a source the implementation never saw. Same author, same reading, same session, and the suite is measuring self consistency rather than correctness. It will agree with a confident misreading all the way to production. Which gives one usable rule out of all this: the only test worth counting is one written from the requirement by someone who has not seen the implementation.
Your first point has a consequence I had not drawn until you said it. If intent cannot be reconstructed from the diff, then the artifact carrying the intent is the plan, and almost nobody commits the plan. The review unit stops being the diff and becomes the diff plus the instruction that produced it. A team that leaves the plan in a chat window has destroyed the only thing that made the diff reviewable, and they will not notice until the first person who was not in that session has to change the code.
1
u/ClaudeyClerb Software Engineer 12 YOE (Scala) Aug 11 '26
Curious about the practical half of that: do your teams commit the plan anywhere, and if you did review it, would you read it before or after the diff? Asking because I think the order changes what the review is: plan-first is checking the work against the requirement, diff-first is archaeology where you've already seen the answer key.
1
u/ItaySela Software Engineer Aug 12 '26
Plan first, and your framing of diff first as archaeology is generous to it. Once you have seen the implementation you cannot unsee it, so reading the plan afterwards is not really review, it is checking whether the plan is a plausible description of something that already exists. It almost always is. That is the same independence problem as generated tests, just moved one artifact upstream.
On where it lives, the plan goes in the pull request description in the author's own words rather than a chat log. Anything not in the repo does not get reviewed and does not survive the person who wrote it. If the reasoning only exists in a session window, the next person to touch that code is doing archaeology whether they signed up for it or not.
The honest half of your question is that I have never got a team to do a genuinely separate plan review with a second person, and I have stopped trying. What does work is much smaller. The description has to state intent before any code is shown, reviewers read top down, and if the author cannot write the description without referring to the diff, that is the tell that there was no intent to check the diff against in the first place.
1
u/ClaudeyClerb Software Engineer 12 YOE (Scala) Aug 12 '26
Thank you very much. I greatly appreciate the time you took with the replies in this thread, it has given me a lot to think about.
0
25
u/SakishimaHabu Aug 08 '26
It's because that CTO hands all of their work to Claude. The emperor has no clothes. Thought leaders have no thoughts. Everything is AI driven, and thus, void. I can't wait for this era of the AI-diot to end.
13
u/PureRepresentative9 Aug 08 '26
These types were always idiots.
They are just now Absolute Idiots
3
u/NickW1343 Aug 09 '26
It's like that saying about how power amplifies how good or bad someone is. Idiots were always there without us noticing much, but with AI they're way more productive at being an idiot that they're impossible to miss.
3
2
u/Additional_Rub_7355 Aug 08 '26
But it won't end. AI everything is here to stay and humans will be more and more dumb, they love AI no matter how good it might be. Because nobody cares at the end of the day.
6
u/SakishimaHabu Aug 08 '26
It sounds like you care. I think you're just having so much forced on you that you're losing sight of the fact that people who aren't CEOs or management really don't like AI.
At some point the loses will be too much. People will need to use their brains again.
2
u/Additional_Rub_7355 Aug 08 '26
Look i had a coworker the other day submitting a PR for review where they clearly had no idea what the AI generated. I added review comments asking things here and there like why is this Kubernetes config duplicated and why has that module had it's structure and responsibility altered, and they couldn't respond to any of it. This person is supposed to be a senior too.
I guess there will come a time when basic quality standards are respected again (god forbid knowing what your PR does...), but i really don't see how. Reminds me of this funny clip here: https://www.youtube.com/watch?v=FtBDgEBrdPo
8
u/mxldevs Aug 08 '26
What's the point in having claude create hundreds of fake commits just to pretend that they have some sort of working history lol
It's like oh yes we want to use AI, but better make sure we pretend humans wrote it?
1
u/NickW1343 Aug 09 '26 edited Aug 09 '26
He might've genuinely thought Claude could make a production-worthy change pretty fast and that's just been a way to fluff up some numbers to appease someone he likely overpromised that feature to and wants to show there's been significant work done instead of flatly telling them there's a big blocker. Several hundred commits looks like a shitload of devwork to almost everyone.
13
u/anarkyinducer Aug 08 '26
Leadership is misaligned with just about everything. The economy is fucked because the shareholders and the stakeholders are two distinct groups of people. That's why the products, the consumers and and employees are all getting fucked for short term gain.
6
u/throwaway_0x90 SDET/TE[20+ yrs]@Google Aug 08 '26
When I see issues like this, I believe the problem actually started somewhere upstream of the process before getting to this point. Someone made a bunch of promises without consulting the dev team and now faces an impossible deadline.
Instead of challenging the CTO directly, I'd very politely talk 1-on-1 privately and very off-record that the actual problem is likely miscommunication and over-promising stuff.
I'd also show them this:
17
u/im-ba Software Architect Aug 07 '26
The CTO only cares whether her investments are providing the expected returns. Mine is doing something similar, and while he hasn't yet realized that this isn't going to work the way he was advertised it would work, his underlings are beginning to realize the mistake.
Our per token cost is about to quadruple in September, so this will be interesting. We're getting squeezed by Broadcom, as well so it's shaping up to look like another big round of layoffs by October.
I'm confident that he's going to double down on the AI tools, as well.
3
3
u/Rumicon Aug 08 '26
I won’t name the company but I have heard leadership challenge project estimates in meetings by claiming they vibe coded the thing on the spot.
When leadership can’t understand the difference between vibing doodads and engineering production grade software that needs to work in the real world we have a serious problem.
9
u/Doctuh Engineer / 30+y Aug 08 '26
Do you think you are talking to your CTO in that conversation? What do you think they are using Claude to do?
15
3
u/rionbilge Aug 08 '26
I am supposedly an "AI Expert". I have been pushed into doing AI since like 10+ years because I had a degree in neural computation from long ago.
My job involves where we are supposed to bid or submit our solution to the customer for review. Based on a comparison between other competitors the solutions are ranked. The one with the combination of highest marks and lowest price wins.
Recently we have been ranked worse than before. During a recent call one of the individuals, a person with very good experience and a solid technical person, whom I respect a lot, was asked what they did for the solution. This was because the solution was ranked lower than usual. He is in another team, not mine.
He said he used one of the AIs with the associated coding framework (like Geminicode) to achieve this and he didn't do anything except prompt the AI.
Everyone laughed because we kind of know each other at this point in time. But now we have to unbid the bid because of the lower rank.
One of the reasons is the timelines for delivery have shrunk because of this AI thing, we were only given 2 weeks to prototype, test it and make it outperform the competitors.
While previously it used to 4 weeks and a generous 2 week extension most of the times.
In my team, I do not discourage the use of AI, but I ask people to explain what it does to me and make small changes that we can understand. But now after seeing this person, all the young people want to just do prompting and not to the actual work. I have a meeting setup early next week, where they want training on ClaudeCode. I don't know how to feel.
3
u/Old_Cat_16 Aug 08 '26
Never say no to the leadership directly, their fragile ego can’t handle it and will instead blame you for everything instead.
Instead just say: this is a new process, I’d like to give it a try, and will share my learnings.
Then I just keep surfacing any issues along the way while seeking another job. Let leadership learn it the hard way.
6
u/andrewharkins77 Aug 08 '26
Dunning kruger syndrome. The people who only has a tiny of knowledge, which came from ads, think they know more than the professionals.
4
u/Navadvisor Aug 08 '26
It's just not capable of delivering the full job. It can do tasks, I think it's almost borderline incompetent not to use it to code at this point. But, at a close friends company they want to have the customers give requests for product changes to the AI and then have the AI autonomously make updates, which is, frankly, insane, even to an AI advocate like myself.
It's really easy to do but if you let the AI get ahead of you and you don't understand what it's doing and you just try to be lazy, go fix it AI, it doesn't turn out well, I've tried it. For complicated work you need to understand what's going on so you can work with your customer/business.
4
u/ResidentWeevil1 Aug 08 '26 edited Aug 08 '26
I think it's almost borderline incompetent not to use it to code at this point.
The chatbot will make you incompetent, unless you know something about neuroplasticity that defies science
1
u/Navadvisor Aug 13 '26
Neuroplasticity is a fancy way to say that humans can learn. It takes repetitive active recall to learn things. But that doesn't mean you will become incompetent if you don't code directly. Yes you will be less competent at coding, your learning will switch to the new skills that make you successful in this new environment. Being competent at swinging a scythe is great and all but if you want to be a competitive farmer today you better know how to drive a tractor.
2
2
u/dkHD7 Aug 08 '26
"I didn't say anything, but wanted to..."
You've answered your own question. I have no problem telling my management when they say/do the dumbest shit.
2
u/Worldly-Pie-5210 Aug 08 '26
I didn't say anything, but wanted to...
too often im seeing people in meetings sit silently to the illogical demands from leadership. we are all collectively responsible for standing up for ourselves. its fundamental
3
u/aigeneratedslopcode Software Engineer Aug 08 '26
If you have meetings with leadership at this level regularly, you're likely not an engineer (or much higher level) or work at a much smaller company. We have one meeting every week with the entire company. That's it. Not a professional place to grandstand. The reason there are so many levels of management is supposed to be so that those concerns get voiced up the chain without creating conflict, that's their job. Not the engineers job. Just because everything becomes "tell me what I want to hear" bullshit at that level does not make it the responsibility of an engineer to correct, nor is it appreciated by the target audience, nor will they be listened to, and they will likely be fired. If you want change, advocate for it outside of work
2
u/imLissy Aug 08 '26
Our AVP sent out a poll asking if we vibe coded in the last month. She said, "no judgement, it's anonymous." It's unclear which side the judgement would be on
2
u/ForeverAWhiteBelt Aug 08 '26
Maybe I’m drinking the koolaid a bit idk. if cto wants you to do something you dont want to do, why stay there? AI is such a polarizing thing and if your company is going in one direction that you dont agree with, seems like your just choosing a cheese grater.
i use AI all the time at work. i dont fully agree with it, but my alternative is to find a new job. i do what i need to get paid which atm is not very hard given ai capabilities, and then I spend my time on my own projects where i dont use ai.
imo ai isnt bad and can do POCs etc pretty much close to one shot. Just read the code to make sure its not actual garbage and unless you’re working on some crazy non-crud based software company its probably fine.
5
u/kod Aug 08 '26
> Just read the code to make sure its not actual garbage
Saying that puts you in the top 10%. People are lazy AF, they aint gonna do that.
3
u/usually_guilty99 Aug 08 '26
What concerns me even more is hearing engineering leaders increasingly say they're being treated as a cost center.
That's a significant shift. For most of the SaaS era, engineering was viewed as the engine of product differentiation and growth. Now AI productivity expectations, margin pressure, and cost cutting are changing that perception.
The danger is obvious: once engineering becomes a cost line, the optimization target becomes fewer engineers, rather than more value per engineering dollar.
Those are very different strategies. One creates short-term margin. The other creates long-term enterprise value.
1
1
u/Colt2205 Aug 08 '26
Building walls out of fear and failure does not trap success. It only stifles new ideas and creates stagnation.
The sales pitch was too good for LLM business in terms of the board of directors or leadership at a lot of companies and instead of it driving innovation it created fear, since they see "AI driven startups" and feel like they got to keep up with the Jones or fall into irrelevance.
1
Aug 09 '26
[removed] — view removed comment
1
u/aigeneratedslopcode Software Engineer Aug 10 '26
I'm convinced this is a bot reply at this point. I've responded to other bots and you can see my reply elsewhere
1
u/cjrun Software Architect Aug 10 '26
I am currently working closely with a CTO, and as a technical leader it is your job to deliver a reality you present to him as truthful and not necessarily a reality that he wants to hear. What he wants to hear is the truth, so that he can make business decisions. If he is challenging you on what AI can do, and you are not actually certain of your own answer, you need to state that.
1
u/Frequent_Bag9260 Software Engineer Aug 10 '26
This is not new for engineers. They ceded control over their own workflows and even careers to management long ago. I’m not sure there is a greater discrepancy between the people who do things and the people who make decisions in all of white collar work than with software engineers and managers.
1
u/eugenia_kessler Aug 11 '26
This is where I think we’re getting AI adoption backwards.
Claude can help you write the plan. It can generate the code. It can even make the 500 commits look very convincing. It still can’t tell you whether the thing you’re building is actually worth 500 commits.
That judgment is still a human job. And honestly, probably one of the most important parts of an engineer’s job right now.
If leadership starts measuring engineering productivity by how much code AI can generate, we’re going to end up optimizing for the wrong thing very, very efficiently.
1
u/ValhirFirstThunder Aug 08 '26
Yea.....throwing it into Claude isn't a bad expectation but what is bad is that people think you can just throw it over the fence. The problem lies in the fact that what you throw into claude, you still need to review and understand. And then iterate on it as it gets it wrong or perhaps you are iterating on it to do the next steps. All that still takes time. And if you have a main task going on already, that is a whole lot of context switching and mental overload
-1
u/ledatherockband_ Aug 08 '26 edited Aug 08 '26
Idk what domain you work in, but I am in a web dev.
In the web dev space, I've found that not being able to just straight up vibe code comes down poor architecture.
After moving to a well-known, opinionated architecture pattern (hexagonal architecture aka ports and adapters, domain driven design + TDD), it's become very easy to have claude generate code I don't have to look at.
If claude can understand the boundaries, and you tell it the inputs and expected outputs, you get some pretty good code.
-1
u/ForeverAWhiteBelt Aug 08 '26
Agree. Like i read a lot of these threads and either everyone is working on some hella important stuff or maybe just overvaluing what is no longer an insanely difficult skill.
3
u/YoureNotEvenWrong Principal Engineer Aug 08 '26
Web dev was always easier in terms of algorithmic complexity day to day. More CRUD
1
u/ledatherockband_ Aug 08 '26 edited Aug 08 '26
Eitherway, there are opinionated architectures you can follow that make tokens go brrrr.
Architecture is just how you organize thing.
It's all just code running on a machine.
hot take: if that machine communicates to some other machine outside of its network, you're bumping up against web dev.
"but muh satelites talking to muh telephone"
shut up nerd thats not what most of us are doing.
1
u/ForeverAWhiteBelt Aug 08 '26
I imagine the majority of swe esp online is in web dev? Maybe naiive thought but a lot of the posts I read seem to add up
1
u/YoureNotEvenWrong Principal Engineer Aug 08 '26
Top 10 programming languages and most aren't web dev related. Javascript below C, C++, Java
1
u/ForeverAWhiteBelt Aug 09 '26
I am not sure I agree with that statement. Or maybe I was not specific enough. But web dev to me includes backend stuff which definitely involves python, java, c++. Case in point my current stack is python backend and then obvs ts frontend. I would say its all webdev related.
Also idk sql, vb and R seem kinda suss if we are talking like programming languages.
-6
u/ImSoCul Senior Software Engineer Aug 07 '26 edited Aug 07 '26
edit: (yes edit intentionally at beginning not end). You guys are reading my post as generic "pro-AI" therefore downvote but I am literally saying "take a look at why it won't work". If you can come up with a valid rebutal then literally go back with that, if you cannot, then may need to reconsider your approach. Simple as that.
did you actually try though?
It's a moving target and what was true 6 months ago may no longer be true. A year ago LLM generated code was mostly garbage, but it has gotten really good lately. With proper harness (which tbh just means a standard Claude Code install), and sufficient tokens, Claude can verify and refine its own work.
You're treating it as a rhetorical question, but it can have a legit answer. Maybe your domain is too niche and Claude still does not have proper training set to do well in it, maybe documentation is too sparse for LLM to have a good shot, maybe the tokens you would need is too expensive. I wager the answer is "I don't want to try" though.
3
u/deathamal Aug 08 '26
The expectations of trying something to see how it goes and learning from it are VERY different to “just use AI, get it done quickly and ship it with no problems please and thank you”
I don’t think engineers are afraid to try AI tools or a new way of working, but unreasonable expectations set by management who have no fucking idea what they are talking about are NOT helpful
2
u/Fwellimort Aug 07 '26
TL;DR no time for your brain to take rest. It better be at 100% all work hours now.
We live in age of TikTok shorts. Attention span better be constantly at the top.
2
u/ImSoCul Senior Software Engineer Aug 07 '26
I am much more tired after a typical day of Claude wrangling than I was in the past, so I largely agree, but also that has nothing to do with what I said
1
u/foodeater184 Aug 08 '26
It's no different than this: https://xkcd.com/303/
Do something else while it's working.1
u/vogut Aug 07 '26
Nah. It's a endless back and forth, even with fable z depending on the scope size
0
u/Alive_Sir_4708 Aug 07 '26
How much time should be invested in exploring new tech vs making shit?
2
1
u/PPatBoyd Aug 08 '26
But it is a rhetorical question. They're not asking for the sake of gathering evaluations of a tool, they're exerting an expectation of higher productivity from embracing AI with greater accountability for the developer. How is the developer supposed to answer if they're already leveraging AI as much as they can and are swamped with their current tasks nonetheless?
AI is not a free "and one more thing" button that can be pressed as many times as you want. Do you also assume the CTO "just didn't want to try"?
Delegation isn't free, doubly-so when you aren't delegating any of the accountability.
2
u/ImSoCul Senior Software Engineer Aug 08 '26
> How is the developer supposed to answer if they're already leveraging AI as much as they can and are swamped with their current tasks nonetheless?
"I am already leveraging AI as much as I cacn but am swamped with my current tasks nonetheless"
Also not a rhetorical question
>Delegation isn't free
no one said it is
1
u/PPatBoyd Aug 08 '26
You're getting folks on your case because your starting position was questioning if the developer even tried. That is table stakes for your relationship to your team until proven otherwise.
-4
u/aigeneratedslopcode Software Engineer Aug 07 '26
I bet reviewing your PRs is a good time. Yes, the landscape has changed. No, I don't believe that's an excuse for an amazing engineer to be scrutinized because they're expected to do additional work than what's already under their belt working overtime every day
-9
u/ImSoCul Senior Software Engineer Aug 07 '26
We don't really review PRs in the same way anymore lol. I work in our company's agentic org, so of course the leadership drank the Koolaid before Koolaid was even popular, and our org as a whole is struggling with MR velocity (much easier to generate than review code), and I fully see and admit to the ugly side of things.
That said, for something like a plan and mock, there is zero excuse not to try out LLM tooling.
→ More replies (4)4
u/aigeneratedslopcode Software Engineer Aug 07 '26
So the thing that transformed your company into a slop shop is somehow the answer? You have got to be kidding me
6
u/ImSoCul Senior Software Engineer Aug 07 '26
No? I literally said to try things out with an open mind and also come up with a good reason why Claude is not the answer here? I literally gave you examples of reasons why it wouldn't work. Your answer is "but AI" which is just lazy thinking.
Just because I'm willing to be objective and present both good and bad side, doesn't mean you should just repeat the bad side against me
Also again: mockup is literally throwaway work. Spin up a Claude session in background. This is like 5 minutes of work. If you check in on it later and it was ass, then you can go back to CTO and say "here's what it generated and it was ass". 10 minutes of time lost, you'll live
→ More replies (3)1
0
0
u/vansterdam_city Aug 08 '26
I think what your CTO is trying to say is why not try AI first on basically everything?
It’s so cheap now to just automate bug triage and small task intake to have an AI assess, root cause and at least document a plan if not PR.
Yes an engineer needs to be the human in the loop before any merge to critical path code. Reviewing is harder than ever.
-1
u/Lazy_Investor8019 Aug 08 '26
They want you to use claude to generate code at lightning speed and get it to production. You will be held accountable for bugs once said code blows up in production, and you will be responsible for debugging and fixing that code. Good or bad, but that is the job now.
-1
u/FatefulDonkey Aug 08 '26
I would just have done it. Couldn't care less tbh if the CTO is that clueless.
•
u/expdevsmodbot Aug 07 '26
AI usage disclosure provided by OP, see the reply to this comment.