"74% of executives said they had more confidence in AI’s advice than in that of colleagues or friends, and 44% said they would defer to its reasoning over their own insights"

it's sad that c-suite believes the advice given by an LLM for a Platonically ideal software stack that looks nothing like the actual implementation moreso than their own ICs. it just reads as more evidence that LLMs are better at replacing leadership than anybody else

never understood why someone would trust Claude's take on your codebase after it's read a 2% snippet of it over the advice of someone who has years worth of experience, who knows all the weird kludges and other quirks that were shipped MVP and never truly tackled as debt, whose done risk assessments and mapped dependencies and has the rough outline of all ADRs involved

I think it's always been true that bad leadership tends to become out-of-touch with the reality of the business over time especially if they don't know how to cultivate good working norms, favoring sycophants instead. with LLMs, that trend seems like it'll just get worse and worse

▲

Manfrednotfunny 19 hours ago | parent | next [-]

C* can mean anything.

The CTO of my last company thought that an API request under 1 second is okay as the customer at that endpoint wouldn't mind anything under 1 second.

I explained to him that under 1 second for this particular task is crazy high. He explained to me that it works fine as it is and its only one customer (the company customer) complaines to him about this issue every few month.

I fixed the SQL query, the problem was gone forever.

The same CTO got lulled into some weird talks with some AWS Account Manager for no reason. He told me what we should do and i explained to him how all of this (nicely of course) doesn't correlate to what we have, do and need.

I'm often enough surprised that our society runs.

▲

noir_lord 18 hours ago | parent | next [-]

> I'm often enough surprised that our society runs.

It runs because there are just enough people who know what they are doing and quietly do it often against headwinds in just about all the places they need to be.

Which works until it doesn't, We've gradually been removing those people in the name of "efficiency" with somewhat predictable systemic results across the board.

▲

episteme 17 hours ago | parent | prev | next [-]

Sounds like the CTO is right though? Why prioritize this? Surely there are way more important things to do. You are judging him for not thinking it’s important because you said so, that’s not strong argument.

▲

Manfrednotfunny 4 minutes ago | parent | next [-]

No he was not.

The fix was a few hours, the customer called him regularly. The CTO had no understanding that a basic SQL Insert shouldn't take a second.

This fix smoothed all response times on all queries and that customer never called aabout this issue again.

▲

rwmj 3 hours ago | parent | prev | next [-]

If the CTO was right about the premise it'd be fine, but much more likely he pulled the "everyone is happy with 1s" out of his arse and then used his position/authority to bully the team.

▲

owebmaster 16 hours ago | parent | prev [-]

That's how you chase efficiency/quality which is one of the CTOs responsibility. Small effort for huge gains are the most optimal changes.

	▲	jfreds 15 hours ago \| parent [-]
		Huge gains? What was the impact of this change, considering the only context that we have is that it was not important to the customer? Answer should be expressed in terms of cost, revenue, profit. I don’t doubt the CTO was exercising poor judgement, but I do doubt that op was communicating his concerns in a way that was tailored to the audience

▲

paimapi 19 hours ago | parent | prev | next [-]

there was an engineering director at my previous company (and who was former Amazon) who wrote his first PR with Claude

it had 30k lines of diff and was a complete refactor of how one of our core features worked

the staff eng he tagged to code review it politely declined to do so and given that this director was let go fairly recently, I'd like to imagine that the PR will exist as a fun surprise for any future maintainer running cleanup

▲

renegade-otter 19 hours ago | parent | prev [-]

Most things get done in spite of management, not because of it.

▲

MontagFTB 19 hours ago | parent | prev [-]

> it just reads as more evidence that LLMs are better at replacing leadership than anybody else.

I believe this counts as having “more confidence in AI’s advice than in that of colleagues”

	▲	paimapi 12 hours ago \| parent [-]
		leadership as a category functions on low-to-minimal subject matter expertise. you don't want c-suite merging code into production, they should be handling the business interests and direction based on their training and general, high-level, trickled-up understanding of how teams are cohering on strategy that generalized, trickled-up understanding is also something that's much more easily replaced by an LLM. it was easy for me to spin up a program governance skill paired with a deterministic set of tests in a few weeks. it crawls team channels, project trackers, etc, identifying date drifts, updates, and missing milestones. add an analytical layer of why and how it all fits together in the roadmap and you've functionally obsoleted a lot of the non-technical bureaucrats whose only purpose is to tell someone what other people are doing - from Director to C-Suite, from C-Suite to shareholders of course you want to keep the people around with the technical depth to construct a roadmap but when was the last time senior leadership in your org actually did any of the substantive work on roadmaps? it's all team leads with the leadership layer serving as the arbitrary rubber stamp on the plans someone else created when it comes to knowing that there's a dependency on the component you're altering the data contract on, the LLM is useless unless there is pre-existing context or unless you command the LLM to burn your pile of tokens on it tracing every bit of logic in your codebase. unless you want to do nothing but this level of discovery all of the time, you'll need an engineer with lived experience of working in the codebase. here this averaged understanding is useless - you need context, you need granular expertise, all things an LLM fundamentally lacks for your specific codebase and your specific requirements