ask supercomputer earth, it will figure it out in ten million years provided the computer doesn't get destroyed before that by that hyperspace bypass the vogons are planning.
I’m assuming this person did ask in the second way, it’s hard to imagine someone working through a problem that has already tried a bunch of stuff just going in cold and not providing any context and saying “How do I do X?”
Good advice obviously if it’s not being followed already but also likely over-simplifying the problem. Also a normal person on the receiving end would probe a bit about what has already been tried. Which to be fair makes the whole thing a bit weird and does sound more like she’s being brushed off.
They repeat multiple times in the article that asking Claude was something they already did. So this isn’t an anti-LLM article.
This seems to be a communication problem. The other party either doesn’t know that they’ve put a lot of effort into researching this already, or their trying to give a gentle let-down instead of saying they don’t have time for this.
For the first case, the solution is to explain what you did to reach this point. People are more interested in helping those who have already tried helping themselves.
The second case is more of a social situation with an infinite number of explanations. Some times you have to read the room and realize that someone may not be interested in having those conversations with you. Some times it’s only in the moment (we all have bad days where we want to be left alone) but other times it’s a signal that they’re not interested in discussing this topic with you or maybe even anyone else.
When I post a technical question in Forums, I usually add something like "Tried Copilot, got useless answer ...". The trouble with asking an LLM is that there are a huge number of people (this predates LLMs) who post answers on forums along the lines of "turn it off and turn it on again" LLMs pick that up as the consensus solution.
I get exasperated with the inexperience that I have run across for decades. Yes, I frobnicated the frobnitz, I transmogrified the bit twiddler, I wizzled the wobnosticator, (and this decade, I talked the three LLMs), and the problem still exists. What I really need to know is how the transmogrification affects frobnication, but no one has ever touched that configuration.
“Why would you even want to do that?”
I dunno, man, it’s the job I was given. Do you know or not? No. No one does.
I take a week to figure it out, I come back to the forum to post my response, and it’s automatically closed as off-topic.
> I dunno, man, it’s the job I was given. Do you know or not?
That's pretty sad to hear, and that's the hardest thing about working with junior engineers (or nowadays, with LLMs). Someone made a wrong assumption that a thing is possible, gave the wrong instructions, or simply phrased things badly, and now that person (or LLM) is trying to solve the impossible task instead of exploring the alternative approaches.
If it's LLM, the solution is simple. For a human, I usually bypass them and go to their senior directly: "Hey, did you task jagged-chiesel to transmogricate the frobnicator? This is a pretty complex task and our transmogricators are not trally desinged to work on frobs. What was the task you were trying to solve? Perhaps it's time to look into fizz-buzzing instead?"
(Or alternatively, if I am feeling tired that day, I will simply say that I don't know rather than engage. Because working on complex tasks with someone with "I dunno, man, it’s the job I was given" attitude is an exercise in frustration and will likely increase amount of tech debt too)
Something tells me people's milage varies based upon how they prompt the LLM. I spent about half an hour using traditional web searches to tackle a software configuration problem today, then about another half an hour poking around the system to see if I could find a solution, then about half an hour with an LLM. Not once was I told by the LLM to use the consensus solution of reinstalling the operating system even though it was clearly bumbling around much as I was earlier. (Eventually I decided to go with the consensus decision.)
I ran into a pretty funny instance just yesterday - I was upgrading my windows partition to windows 11 and I asked claude if there was any chance it could corrupt my linux partition in the process. claude confidently said that yes there was a known failure mode where if the recovery partition was not large enough for windows 11 it would silently resize it, damaging the neighbouring partition. it even told me what system command it used to do so.
I googled the command and when the gemini prompt came up I said that claude had told me it might be run during the upgrade and damage my linux partition. gemini said "there is no such argument to that program, the other AI is hallucinating, and here is the knowledge base article that probably caused it to go wrong", which was actually pretty impressive, and amusing in the way it used both the term "hallucinating" and the phrase "the other AI".
There is a third case where the other party doesn't realize that the asker lacks the relevant experience to discern good LLM answers from bad answers for that topic.
Same solution as case one though - don't be afraid to say "Claude said X but that doesn't sound right".
Here's the problem, countering a lie or hallucination takes much more energy than asking Claude something and saying its true. Its the same as trying to fight misinformation on the internet, the amount of energy you have to spend to prove someone is lying or fabricating data is very high.
And having to do this on the corporate environment saps the energy and time of people that could be doing something productive by wasting their time answering a clueless person that asked an LLM about something they don't understand, got the answer they wanted (but that isn't real), and now are asking multiple people to prove it can't be done.
Here's an example, a PM decided they wanted to build a metrics framework, to track team success, with high level metrics. They asked claude to build such high level metrics (out of nowhere, these metrics don't exist), it happily produced hallucinated code that said it was collecting the metrics and the PR opened a pull request. Now we have to go there, review, find out is all bullshit and explain to the person that what they're trying to build doesn't exist.
So now we have to fight misinformation even on the clock.
Depending on the question that possibility can be quite rare these days. If you ask “How does x work in this codebase?”, it will read a bunch of files and give you a very likely to be accurate answer. If your using a platform without that context and ask it something more abstract, well, your mileage will vary.
> the solution is to explain what you did to reach this point
It's also helpful to the problem-solving and learning processes. For the expert, knowing what you've tried and how it didn't work refines the set of potential problems. For you, it's a free opportunity to get feedback on your methods from someone with domain expertise.
It kind of feels like it though. We can be anti-LLM even though it's smart or helpful or whatever. It's reduced so many interesting conversations to this type of boring redirect to just "Ask AI"
Honestly, I think she feels that it’s a new way to say “GOFY.”
She’s a journalist, and, from what I can see, a pretty good one. Someone that is fairly used to being able to talk to very senior people.
I suspect most journalists get told to intercourse themselves, from time to time, but it seems “ask Claude” is a new way of saying it, and, whether it’s meant, or not, a subtle insult. The kind that people like her especially resent. The intimation that she didn’t do her homework. It puts her on her back foot, and I think it’s meant to.
Us nerds can relate. How often are we told that we didn’t do something basic, with the onus on us, to prove we did? For a newb, that’s understandable, but it’s a real slap, for experienced pros.
I agree 100%. I've been the resident 'tech guy' among my friends and family for as long as I can remember, and I thought that LLMs would be the definite end to all 'blurry picture of computer screen captioned with "what should I do"' texts, yet that didn't seem to be the case. In fact, LLMs made it worse, as it actually made me seem more knowledgeable; I would be the one just fucking asking AI on their behalf and responding with beautifully formatted, easy to understand answers, encouraging them to ask me more.
I chuckled because, as a joke, I made a website called djfa.ai (Dude, Just Fucking Ask AI), which is essentially LMGTFY for ChatGPT. As one can imagine, the gimmick wore off rather quickly, so I ended up haphazardly turning it into my personal blog, which I sometimes choose to abbreviate and sometimes not on my resume.
I would never have made it in the first place had most of the people asking me questions been like Yael: seeking my informed opinion on thought-provoking questions they'd already researched. Going back to your larger point about the social aspect of it all, even among my wife and my social group, "just ask Claude" is almost the new "I don't really know" or "that's a tough one" when it comes to any sort of question. Almost colloquial in the sense that it isn't to be taken literally, but more as an indication of uncertainty.
I fear that it's more insidious than that - that the questions the OP is asking are already things that the other person has decided (consciously or otherwise) that they no longer bother thinking about themselves and just outsource the effort to the nearest LLM
This drives me absolutely crazy. My colleagues send me huge PRs to review (say 2000+ lines). I don't just paste comments from the LLM, I ask the LLM to review it, but I also review it myself. I only include ideas from the LLM if I think a) the LLM has gotten the issue right and b) it's worth having the developer take the time to address the issue. I always write the comment myself so I can add relevant context and put it in my own voice.
Then, after I've put in all this work, the developer just replies with a copy-paste of what the LLM thinks about my comment. I have no idea if the developer read or understood my point. I have no idea if he agrees or not. It doesn't just seem disrespectful to the effort I put into the review, it also leaves me in a difficult position as a tech lead because I have no idea if the person who is ultimately responsible for this code understands the code, my feedback on the code, or the changes that the LLM made to address my feedback. If you're responsible for a feature, I want to be able to feel like you're thinking critically about how that feature works. Right now, I just feel like you're blindly doing everything that I tell you. It also feels like I'm shouting into the void. We're colleagues, we should be able to have a conversation about technical subjects!
Beyond mirroring the engineering practices that you yourself want to see other people perform, have you found any techniques to get people to … in short, do their job again? Understand context, understand what they did, why they did it, what they’re doing, etc.
The +/-2000 line MR was bad when humans wrote it. It’s way worse when the human didn’t even write or read it.
And just vomiting automated CodeRabbit talking points back and forth at each other feels equally harmful.
Are we really tolerating turning ourselves into LLM rubber stamps?
For me the trick was just leaning all the way into it. I had a residual idea that if someone sends me a 2000 line PR, 10 page design, etc., that this represents some concrete investment of time and effort that deserves my careful consideration. And it just doesn't anymore.
I have one project where there must be hundreds of pages of design proposals I have not read and will never read, because the author really likes having Claude generate complete design proposals based on incomplete understanding. So every week or two he sends me a new one, I spend 30 seconds skimming it, and then I tab back to Slack to ask him to explain.
I don't like working this way, but you know, I don't like doing rollouts either. It's certainly better than being a human rubberstamp.
Typically what happens is that we have a good conversation, we make progress towards figuring out what they should want to do and how they should try to do it, and the 2000 line PR or 10 page doc gets abandoned. I do read things in detail when I expect I might one day be convinced to approve them, but that fraction has plummeted from 95% to like 20% since January.
Have you noticed an increase in their willingness to “do the right thing first time” during these last 6 months since your approval rate has dropped that much? (Even if the right thing is to have more conversations)?
Do you know if there’s a way to incentivize them to lean toward doing the right thing first? Are the company and stakeholder goals and objectives in line with them making progress toward higher quality engineering? That is, are these juniors protected from randoms asking them to circumvent good process, etc?
Unfortunately, I've had a number of people explicitly defend that nothing's going wrong here. Their view is that, if sloppy code is cheap, everyone might as well produce some to illustrate their ideas before having a conversation. I'm skeptical of that position but haven't had much luck in fighting it.
> Are the company and stakeholder goals and objectives in line with them making progress toward higher quality engineering? That is, are these juniors protected from randoms asking them to circumvent good process, etc?
In my personal experience yes, but I've seen a few teams and heard stories of many more where the juniors are not protected and they just ship regressions and outages all the time now. I think the trend towards AI cost controls will mitigate this, although the impact will of course be uneven as companies behind the curve discover powerful agentic coding for the first time.
How do ya feel about altercations at work? If like most, then hope your colleagues find your post & decide to stop (without realizing you’re their lead!).
What's even worse is when you go though such PRs and your comments are handled in minutes, with replies explaining the change with perfect spelling and em dashes. At which point you ask yourself: "What am I doing here? His agent wrote the entire thing, and now I'm going through it and telling his agent what to fix. Why is he even needed?"
Or even, even worse is when you get a PR from a co-worker, you spend a lot of time explaining why that's bad idea, only for the person to say "Sorry, my openclaw/etc posted that. I'll close it." Or even the opposite, you tell a co-worker: "Hey, it was a great idea to change X." and he says "X? What is X?... Oh that must have been my agent."
that's the point where i would want to start firing people. not because i want to replace them with AI, but because if they use AI to answer without contributing their own thoughts they make themselves replaceable.
this is just effort equilibrium something that wasnt as effective with “google it”. but ask a low effort question and get “ask claude” as a response is entirely appropriate.
junior developers on my team are often asking questions about our code base without even attempting to explore or self direct. “ask claude to look at <subsystem> and explain how its designed the key files and dependencies so that i can better understand it” is unsurprisingly effective and far cheaper than a couple of hours of opex
I find a llm in a harnes combined with manual ripgrep exploration is really effective of getting codebases. But you font always want to find what you find.
Unpopular answer that the author seems to be dismissing: Maybe the thing that 30 years has taught this guy is that the LLMs can answer the question better than he can. Or that he can't give a substantive answer without doing research into it with an LLM.
>LMGTFY
I mostly saw LMGTFY used when the question was the sort of thing that a person would have to research but that google results had a high chance of getting with "I'm feeling lucky".
If you've already done a bunch of research, and already asked the LLMs, when someone says "Honestly, ask Claude", you should be able to come back with what results you got to your question and what you need clarification on.
I've been doing programming and sys admin for 40 years. When I run a coworkers question through the AI tooling and talk through the answer with them, it's because my 40 years of experience tells me that's the next step.
Going to agree with you here. There's two types of "ask an llm." There's the "I don't know but whatever the llm said is probably right" and the "lmgtfy, did you even try?"
Based on the post his exact quote sounds more like 1 but obviously some people deserve the 2 sometimes.
I think the other alternative is that the senior guy thinks that the junior guy is working on a problem where the juice isn't worth the squeeze. "Just ask an LLM" can be interpreted as "if the AI can't give you a quick solution, it won't be worth either one of our times to puzzle out the technical details."
> Unpopular answer that the author seems to be dismissing: Maybe the thing that 30 years has taught this guy is that the LLMs can answer the question better than he can. Or that he can't give a substantive answer without doing research into it with an LLM.
90% of the questions people have, advice they solicit, entire Discords, and so-on, could just be private LLM based research.
"Let Me Google That For You: LLM Edition"
Even opinions are often better served by an LLM, perhaps counterintuitively. It's a "third party" intelligence to all human intelligence - value in that alone.
> It's closer to what happens when I ask a friend for a food recommendation and get a top-10 list back. I'm not asking what Eater thinks is the best kind-of-quiet spot for late-night drinks, or for a great coffee shop in the city where they used to live
Argh, I've had this with a couple friends. I ask them a question and I get back some bullet points over text which was obviously generated by an AI. Like, I know how to use AI.
I completely agree. Replying with "ask Claude" feels to me like admitting you've lost control over the subject matter and don't know anything about it or at least don't trust your judgement anymore. It feels like saying you're replaceable by AI.
It makes sense to hate and despise that answer.
And yet, I'm not 100% sure I've never used it myself. I will have to watch out for that.
You're projecting several layers of bias onto this scenario.
The more busy you are, the more valuable your time... the more expensive context switching is. When you are known as the person with the answers, your day is at least partially structured around getting people to leave you tf alone so that you can actually concentrate on getting your own work done.
There's a really toxic expectation that people who are senior should stop what they are doing XX times per day to help other people figure out their issues. Usually there's zero consideration given to how much each one of these interruptions takes away from them. Resentment builds cumulatively.
Before LLMs, this conversation usually went like this:
"What should I do?"
"What do you think you should do?"
"X"
"Do X"
There's only so many times that can play out before you really want everyone to just fro.
Anyhow, you should try hard not to "hate and despise" LLMs. Life is too short to invent paranoid reasons not to use the best tools available. That's another instinct you learn as an experienced dev.
if this is the experience in a team, then the team already has a problem. i expect these things to be made clear up front.
when someone joins a team they should be assigned a mentor whom they can ask any question, no matter how dumb, and the mentor then guides the new team member in how to approach such a question, which at that point can include asking the LLM. it is the mentors responsibility to point out when it is ok to ask another senior developer. daily standups can also help with this sort of thing.
in a close knit team i would also expect that either everyone can ask anything from everyone else, and that everyone learns when it is ok to ask questions. the situation you describe should simply never arise. if it does, then something is going wrong
Alternative take: the assumption that senior engineers get pressured into agreeing to mentor without it formally being an acknowledged part of their job - that is, that a significant percentage of their time is supposed to be allocated to making themselves available to juniors - is fundamentally a problem.
There is so much stigma associated with being an senior engineer that simply wants to spend 95% of their day working on the problems that they were hired to solve. The worst part is that the vast majority of people in this situation are not compensated for this time, and they are expected to keep up with their actual assigned responsibilities.
This state of affairs is a relatively new thing. The idea that you would join a company with the expectation that the most important people to the success of a project should drop what they are doing to context shift to someone else's problem several dozen times a day is not something that would have been remotely normal twenty years ago.
I am not saying that mentoring is bad or that asking for help is bad, just that there's been a change and the unspoken vibe is that if you're not happy to work at ~30% capacity because you need to mentor people, you're some kind of antisocial jerk.
If a company wants seniors to mentor, pay them to mentor. It's very simple.
mentoring juniors should always be part of the job. sharing your experience and knowledge is part of the common job description. the idea that you just write code and never need to share your experience with others is a fundamental misunderstanding of what your work is about. you would have expressly negotiate an exception into your contract if you want that, not the other way around.
what doesn't work is the assumption that mentoring doesn't take any of your time and that you are expected to manage the same workload with and without mentoring. that's not ok. and spending 70% of your time mentoring may also be a bit to much, but if that is what the company needs then it is still your job.
The notion that an experienced person should automatically consider mentorship to be part of their job is not backed by any code or contract that I'm aware of. It's just increasingly been pushed on people who haven't pushed back enough to keep a new generation from feeling as though they are entitled to it.
You can sample as large a pool of senior devs as you want; I suspect that if you can find 1-in-10 who have specific wording and structure in their employment contracts about the percentage of their time that they should expect to allocate to mentorship, you'll be beating my own estimations. No, what you're doing is attempting to codify a very polite form of exploitation. Yes, those people are usually among the most well-compensated, but it doesn't change the fact that they have their own job to do and a finite time in which to do it.
Please note that I am not suggesting anyone on a team could somehow work in a vacuum. Also, even the most experienced person frequently needs to ask for help, guidance and clarification. Being experienced is pretty much the opposite of knowing everything and is much closer to a measure of how much you have forgotten.
Nor am I implying that senior people have any business being rude or dismissive towards team members who legitimately have good reasons to interrupt someone's flow state. Timely clarification is important to a project regardless of who is doing what.
What I am saying is that if you run a company you might legitimately be horrified to learn that your most critical team members are spending 70% of their productive time mentoring, especially if that remaining 30% of their time is so fragmented that it never resembles a true flow state. You need those people to Build The Thing.
If you don't get that, then you're not living in the same reality I am.
The notion that an experienced person should automatically consider mentorship to be part of their job is not backed by any code or contract that I'm aware of.
every job i had, every developer i hired. it is also backed by german law for example, refusing to mentor/train others in the work you do is a fireable offense in germany. in any job. not just software development. i doesn't need to be explicit in the contract. it is a natural and expected part of your job. and in the US with at-will employment, what's in your contract doesn't matter as much either. if it seems like a reasonable request they can just let you go if you refuse. the idea that you should not ever have to pass on your knowledge to others in your company seems very entitled to me.
that's my opinion on the matter. you can find more diverse opinions here:
i already acknowledged the 70% problem you mention. that should not happen unless it is known and intentional. i'd be horrified too if i were surprised by that.
That's really interesting about German law. I didn't know that, so I appreciate learning.
I suspect that if we were having this debate over dinner, we would agree on far more than we disagree on. I think we're speaking past each other because we're operating with slightly different notions of what mentoring implies.
From my perspective, I think that there's an obvious and reasonable expectation that you make best efforts to be a good team player. That means doing your part to participate in planning, knowledge transfer, group morale and of course making yourself available to work through tough problems with people regardless of their skill level.
What I think is far more dubious is the relatively recent slippery slope towards the notion that someone should reasonably be expected that career progress dovetails with some sort of natural law that says you are not being a good human if you aren't willing-to-excited to spend 70% of your productive time in a semi-permanent state of continuous partial attention because the people around you demand priority access to your time and attention, above any of your personal priorities or job responsibilities, often without compensation beyond a rote "thanks".
If you can't ship inside of a deadline because your ephemeral "mentoring" took implicit priority over your actual job, then something is very wrong with people's expectations of how key talent's time should be allocated.
german law or courts operate more on common sense than the letter of the law. to be able to reject a task from your boss the task has to be unreasonable. training/mentoring is not unreasonable unless the work is dangerous and/or a trainer needs specific qualifications. running a class that teaches some generic topic like a programming language would probably be unreasonable because you could just hire an external trainer for that. the training has to be rather specific to the individual experience of the senior or some company internal knowledge to be reasonable. so this doesn't apply to the scenarios you seem to have in mind. in any case from what i read it is recommended to talk to a lawyer before refusing.
but also, if the request interferes with your ability to do your normal work then you can and should speak up and you can reasonably refuse if your boss doesn't make accommodations for that. if he doesn't then refusal is reasonable, not because training wouldn't be your job, but because your workload has increased, which is not ok.
Why would you accept a scheduled call if you want to be left alone? That makes no sense.
You're the one projecting bias onto this scenario. You assume people only want to talk to you to waste your time. If you work with professionals, you can assume that when they ask you a question, they have a reason to ask you that question. Assuming that they're just being lazy is bad faith.
Accepting a call and then giving someone this kind of non-answer is extremely disrespectful of their time and their professionalism.
> Anyhow, you should try hard not to "hate and despise" LLMs.
That's not what I wrote. You're being needlessly dishonest and disrespectful right here.
Again: getting a call is enough to knock someone out of deep concentration.
Anyhow, in addition to not hating LLMs, I would add "try not to use dramatic, hyperbolic devices in casual writing, it makes you sound ridiculous" to my advice.
Dozens of "quick questions" over the course of a day will drag down your productivity to about one third or worse.
I know that for me, it takes about 45 minutes of focus to enter a flow state, when I'm at my most productive. If I can never enter the zone, then I'm not really doing the thing that made me such a valuable player in the first place, am I?
He scheduled a call specifically to ask this question. What does context switching have to do with anything? Don't accept the call if you can't afford to switch context.
I wish I was there with you to witness the look on your face as you slowly begin to realize that something as simple as a call can and often will absolutely pull you out of the flow state.
Someone sneezing nearby can pull you out of the flow state.
The idea that the onus is on the person who you're trying to distract to distract themselves to tell you not to distract them is just so broken if you think about it even just a little bit.
What is low effort about "I asked him where he'd look, personally, for the answer to a hard question I was chasing, one without industry consensus. Not what the textbook says. If five studies conflicted, which would he trust? I wanted the thing 30 years had taught him that a search engine couldn't."?
He checked the consensus, the textbook, and 5 studies. He's asking for an answer from experience and he gets "Ask Claude".
But even if you don't know, "I don't know" is a better answer than "Ask Claude", which blindly assumes that the asker hadn't thought of that, which is a weird thing to assume.
Get used to it. People are lazy, and if they can deflect work off to an LLM, they will, as long as (crucially) it doesn't reflect poorly on them with anyone they care about.
OK here is the thing. Everyone get your downmods ready since my rants on here are always a disaster.
People are really really tired.
Because of not just Claude, but also "the recession" "the strait of hormuz closed" "we've never recovered our economy from COVID" "everyone works from home now / the company is forcing us to all come back in" "FAANG had 10000 layoffs" "the global warming" "the <panic about XYZ>", our employers are making us work much harder, with a subtle but palpable panic in their emails, with WAY less promises of any kind of job security, companies that never had layoffs for decades are now doing them regularly, our githubs are flooded with people pointing robots at our issues to generate tepid pull requests, and at our pull requests to generate tepid reviews, and look shit is just crazy now.
So I think the whole "how would you approach this interesting problem..." thing is, for now, at least for me it feels a little bit on hold. Like oh that problem. How to scale? how to horizontally shard PostgreSQL? sure, real problems. But geez whatever we're building, it will be replaced in three months anyway. That's a hard problem you have there! I remember when I used to have problems like that, and my solutions sucked anyway and it was replaced with a node.js app two years later. Whatever advice I have, Claude is going to have 98% of it plus another 10% that I didn't even have.
This is all bad. So I think your post is possibly extremely useful. Maybe we should, for people we know and trust as humans in the real world, actually take the time and approach an issue as though we didn't have the Matrix to approximate it for us. I'm going to think about this and consider it.
Its now a polite way of saying "I dont want to work on this project" without having to go through the effort of thinking hard enough about the problem to put the "go away" price on it (or even worse having to DO the work I dont want to do).
To be honest, I'm more worried about another side of the problem.
LLM's are good at learning from whatever humans have posted online. But with the agentic workflows getting more popular, more and more problems those AI agents figure out are not posted online, and the next time another agent running into the same problems they would have to figure it out from the scratch again. It'd be nice if there's a mechanism these agents would share the lessons they learn with each other, which could save a lot of trials and errors and wasted tokens. Humans show knowledge online. AI agents should be able to do so too. The moltbook thing from half year ago could have this potential, but too bad it's flooded by spams.
Of course, to make this AI knowledge sharing truly work, there may need to be a peer-review mechanism to ensure the knowledge being shared is truthful, reliable, non-trivial etc. That can probably be all worked out if somebody (or AI agent) really put effort into it.
> I'm a million times more likely to send an email or a text than to pick up the phone. But I had a question I thought was worth an actual call, so I scheduled one with someone senior enough to have real scar tissue, the kind you only get from watching a decision go sideways in a boardroom. I asked him where he'd look, personally, for the answer to a hard question I was chasing, one without industry consensus. Not what the textbook says. If five studies conflicted, which would he trust? I wanted the thing 30 years had taught him that a search engine couldn't.
The highlighted parts scream LLM writing. It pains me that I can recognize this so easily.
- Mismatched analog: Send an e-mail doesn't match pick up the phone. First one is outgoing, second is incoming.
- Real - Claude looooves punchy, empty emphasis words like this.
- , the kind - tacked on extra phrase that should be a separate sentence. Claude does this all the time. We aren't writing a shitting noir novel, Claude.
- a decision go sideways in a boardroom - super vague shadow of an anecdote. The "a" in front of "boardroom" is a blinking red light for me, can't fully explain why.
- Not what the textbook says. - Too short, too vague
- not the textbook, 5 studies, 30 years of experience - pattern of 3
- that a search engine couldn't - This type of phrasing is so triggering for me. I've been busting my ass trying sanitize LLM output of this style...
I feel sorry for your future writing prospects, because it looked like AI to me too: I insta-slop-back-buttoned on "so I scheduled one with someone senior enough to have real scar tissue, the kind you only get from watching a decision go sideways in a boardroom."
Thanks for the the correction-- often when people say they weren't using AI they are very clearly lying, so it's hard to get useful corrections on this point so I appreciate your candor.
Oh, no problem! But now I am thinking I may need to rethink using AI for light editing. I've gotten in the habit of that because I don't have a human editor for my blog, and I like getting that extra polish sometimes, but it's probably not worth it if it's going to make people not want to read.
Heh, no problem. I will say the rule of three is something I've been taught over and over again... in speaking training, in a class I took on fundraising, and most recently in a book I read. (See, I just did it again!) Book was by Mehdi Hasan.
I also recently reread a blog post I wrote a decade ago, and it had the "It's not X, it's Y" pattern over and over again.
The author considers the possibility that this is an outwardly-polite form of “you should be able to solve this yourself”. Another, grimmer possibility is that it’s an inwardly-polite form of “I should have been able to solve this myself”.
That is, the author asked for
the thing 30 years had taught him that a search engine couldn't
Do you need to know if X is faster than Y? Do both. Measure. Sometimes the answer requires actual research.
Maybe you need a real Subject Matter Expert because it turns out that nobody ever published something on the internet about something so that an LLM could soak up the real world information.
Before the internet, we would consult with books. After the internet, it seemed faster to search and find answers in things like blog posts, (paid) articles, and CDs. Wikipedia and Stack Overflow are great resources. Maybe you need an answer from Hacker News - ask HN.
By relying on LLMs more than these other sources and allowing LLMs to write articles and posts to these other sources, we lose subject matter experts.
Add to that companies like Microsoft and Meta and others laying off and offering retirement packages to get rid of institutional knowledge as fast as possible, and we are headed towards a gigantic crash of knowledge.
If you've already done some research then include that up front. I get asked a lot of questions by people who not only haven't asked an AI first they haven't even googled it. So if you've asked Claude and are not satisfied with the response then include that and say what your question is now in the light of that information.
This is exactly it. If you want someone to do some analysis for you, you're obliged to give them some context regarding what analysis you've already done.
123 comments
[ 4.3 ms ] story [ 59.5 ms ] threadCompare:
— What's the best way of doing X?
— Ask Claude.
vs:
— I thought about this and found there are options A, B, and C of doing X, I like A more but C is the fastest; what do you think?
I believe a normal senior engineer won't suggest to talk to Claude in this case.
However, search has become enshittified, and I've never had the same kind of confidence in an LLM chatbot.
Good advice obviously if it’s not being followed already but also likely over-simplifying the problem. Also a normal person on the receiving end would probe a bit about what has already been tried. Which to be fair makes the whole thing a bit weird and does sound more like she’s being brushed off.
I don't think anyone in any industry regardless of seniority would redirect you back to AI assuming you're having a genuine conversation.
> I already did.
They repeat multiple times in the article that asking Claude was something they already did. So this isn’t an anti-LLM article.
This seems to be a communication problem. The other party either doesn’t know that they’ve put a lot of effort into researching this already, or their trying to give a gentle let-down instead of saying they don’t have time for this.
For the first case, the solution is to explain what you did to reach this point. People are more interested in helping those who have already tried helping themselves.
The second case is more of a social situation with an infinite number of explanations. Some times you have to read the room and realize that someone may not be interested in having those conversations with you. Some times it’s only in the moment (we all have bad days where we want to be left alone) but other times it’s a signal that they’re not interested in discussing this topic with you or maybe even anyone else.
To me, such screams “I’m too lazy to do anything more than ask a LLM. I’ve tried nothing and I’m all out of ideas”
Show me you put a modicum effort and aren’t just looking to be spoon-fed the content from the first Google result that would have been found.
“Why would you even want to do that?”
I dunno, man, it’s the job I was given. Do you know or not? No. No one does.
I take a week to figure it out, I come back to the forum to post my response, and it’s automatically closed as off-topic.
*sigh*
> I dunno, man, it’s the job I was given. Do you know or not?
That's pretty sad to hear, and that's the hardest thing about working with junior engineers (or nowadays, with LLMs). Someone made a wrong assumption that a thing is possible, gave the wrong instructions, or simply phrased things badly, and now that person (or LLM) is trying to solve the impossible task instead of exploring the alternative approaches.
If it's LLM, the solution is simple. For a human, I usually bypass them and go to their senior directly: "Hey, did you task jagged-chiesel to transmogricate the frobnicator? This is a pretty complex task and our transmogricators are not trally desinged to work on frobs. What was the task you were trying to solve? Perhaps it's time to look into fizz-buzzing instead?"
(Or alternatively, if I am feeling tired that day, I will simply say that I don't know rather than engage. Because working on complex tasks with someone with "I dunno, man, it’s the job I was given" attitude is an exercise in frustration and will likely increase amount of tech debt too)
I googled the command and when the gemini prompt came up I said that claude had told me it might be run during the upgrade and damage my linux partition. gemini said "there is no such argument to that program, the other AI is hallucinating, and here is the knowledge base article that probably caused it to go wrong", which was actually pretty impressive, and amusing in the way it used both the term "hallucinating" and the phrase "the other AI".
Same solution as case one though - don't be afraid to say "Claude said X but that doesn't sound right".
And having to do this on the corporate environment saps the energy and time of people that could be doing something productive by wasting their time answering a clueless person that asked an LLM about something they don't understand, got the answer they wanted (but that isn't real), and now are asking multiple people to prove it can't be done.
Here's an example, a PM decided they wanted to build a metrics framework, to track team success, with high level metrics. They asked claude to build such high level metrics (out of nowhere, these metrics don't exist), it happily produced hallucinated code that said it was collecting the metrics and the PR opened a pull request. Now we have to go there, review, find out is all bullshit and explain to the person that what they're trying to build doesn't exist.
So now we have to fight misinformation even on the clock.
It's also helpful to the problem-solving and learning processes. For the expert, knowing what you've tried and how it didn't work refines the set of potential problems. For you, it's a free opportunity to get feedback on your methods from someone with domain expertise.
It kind of feels like it though. We can be anti-LLM even though it's smart or helpful or whatever. It's reduced so many interesting conversations to this type of boring redirect to just "Ask AI"
She’s a journalist, and, from what I can see, a pretty good one. Someone that is fairly used to being able to talk to very senior people.
I suspect most journalists get told to intercourse themselves, from time to time, but it seems “ask Claude” is a new way of saying it, and, whether it’s meant, or not, a subtle insult. The kind that people like her especially resent. The intimation that she didn’t do her homework. It puts her on her back foot, and I think it’s meant to.
Us nerds can relate. How often are we told that we didn’t do something basic, with the onus on us, to prove we did? For a newb, that’s understandable, but it’s a real slap, for experienced pros.
I chuckled because, as a joke, I made a website called djfa.ai (Dude, Just Fucking Ask AI), which is essentially LMGTFY for ChatGPT. As one can imagine, the gimmick wore off rather quickly, so I ended up haphazardly turning it into my personal blog, which I sometimes choose to abbreviate and sometimes not on my resume.
I would never have made it in the first place had most of the people asking me questions been like Yael: seeking my informed opinion on thought-provoking questions they'd already researched. Going back to your larger point about the social aspect of it all, even among my wife and my social group, "just ask Claude" is almost the new "I don't really know" or "that's a tough one" when it comes to any sort of question. Almost colloquial in the sense that it isn't to be taken literally, but more as an indication of uncertainty.
Thanks, I'll to remember this.
This made me feel things. To anyone reading this, go hug your mom (or other sufficiently close parent) if you can
Then, after I've put in all this work, the developer just replies with a copy-paste of what the LLM thinks about my comment. I have no idea if the developer read or understood my point. I have no idea if he agrees or not. It doesn't just seem disrespectful to the effort I put into the review, it also leaves me in a difficult position as a tech lead because I have no idea if the person who is ultimately responsible for this code understands the code, my feedback on the code, or the changes that the LLM made to address my feedback. If you're responsible for a feature, I want to be able to feel like you're thinking critically about how that feature works. Right now, I just feel like you're blindly doing everything that I tell you. It also feels like I'm shouting into the void. We're colleagues, we should be able to have a conversation about technical subjects!
The +/-2000 line MR was bad when humans wrote it. It’s way worse when the human didn’t even write or read it.
And just vomiting automated CodeRabbit talking points back and forth at each other feels equally harmful.
Are we really tolerating turning ourselves into LLM rubber stamps?
I have one project where there must be hundreds of pages of design proposals I have not read and will never read, because the author really likes having Claude generate complete design proposals based on incomplete understanding. So every week or two he sends me a new one, I spend 30 seconds skimming it, and then I tab back to Slack to ask him to explain.
I don't like working this way, but you know, I don't like doing rollouts either. It's certainly better than being a human rubberstamp.
Perhaps you could explain how this is different from rubber stamping, if it’s just 30 seconds of reading.
Does the conversation you have reveal what they actually want?
And what about the 2000 line change? Does that get stamped after someone talks about the change but without deeply reading it?
Do you know if there’s a way to incentivize them to lean toward doing the right thing first? Are the company and stakeholder goals and objectives in line with them making progress toward higher quality engineering? That is, are these juniors protected from randoms asking them to circumvent good process, etc?
> Are the company and stakeholder goals and objectives in line with them making progress toward higher quality engineering? That is, are these juniors protected from randoms asking them to circumvent good process, etc?
In my personal experience yes, but I've seen a few teams and heard stories of many more where the juniors are not protected and they just ship regressions and outages all the time now. I think the trend towards AI cost controls will mitigate this, although the impact will of course be uneven as companies behind the curve discover powerful agentic coding for the first time.
It worked for a while. There is a GitHub action that you can configure to fail if the PR is too large.
But then we started a new project and I didn’t add it right away since it’s a small team and I figured we could use the honor system.
Since then there have been lots of massive PRs but there’s not much willingness to go back to enforcing the rule because it might slow us down…
It’s frustrating.
Or even, even worse is when you get a PR from a co-worker, you spend a lot of time explaining why that's bad idea, only for the person to say "Sorry, my openclaw/etc posted that. I'll close it." Or even the opposite, you tell a co-worker: "Hey, it was a great idea to change X." and he says "X? What is X?... Oh that must have been my agent."
that's the point where i would want to start firing people. not because i want to replace them with AI, but because if they use AI to answer without contributing their own thoughts they make themselves replaceable.
junior developers on my team are often asking questions about our code base without even attempting to explore or self direct. “ask claude to look at <subsystem> and explain how its designed the key files and dependencies so that i can better understand it” is unsurprisingly effective and far cheaper than a couple of hours of opex
Unpopular answer that the author seems to be dismissing: Maybe the thing that 30 years has taught this guy is that the LLMs can answer the question better than he can. Or that he can't give a substantive answer without doing research into it with an LLM.
>LMGTFY
I mostly saw LMGTFY used when the question was the sort of thing that a person would have to research but that google results had a high chance of getting with "I'm feeling lucky".
If you've already done a bunch of research, and already asked the LLMs, when someone says "Honestly, ask Claude", you should be able to come back with what results you got to your question and what you need clarification on.
I've been doing programming and sys admin for 40 years. When I run a coworkers question through the AI tooling and talk through the answer with them, it's because my 40 years of experience tells me that's the next step.
Just say "I don't know". It is simple and short.
90% of the questions people have, advice they solicit, entire Discords, and so-on, could just be private LLM based research.
"Let Me Google That For You: LLM Edition"
Even opinions are often better served by an LLM, perhaps counterintuitively. It's a "third party" intelligence to all human intelligence - value in that alone.
Argh, I've had this with a couple friends. I ask them a question and I get back some bullet points over text which was obviously generated by an AI. Like, I know how to use AI.
It makes sense to hate and despise that answer.
And yet, I'm not 100% sure I've never used it myself. I will have to watch out for that.
The more busy you are, the more valuable your time... the more expensive context switching is. When you are known as the person with the answers, your day is at least partially structured around getting people to leave you tf alone so that you can actually concentrate on getting your own work done.
There's a really toxic expectation that people who are senior should stop what they are doing XX times per day to help other people figure out their issues. Usually there's zero consideration given to how much each one of these interruptions takes away from them. Resentment builds cumulatively.
Before LLMs, this conversation usually went like this:
"What should I do?"
"What do you think you should do?"
"X"
"Do X"
There's only so many times that can play out before you really want everyone to just fro.
Anyhow, you should try hard not to "hate and despise" LLMs. Life is too short to invent paranoid reasons not to use the best tools available. That's another instinct you learn as an experienced dev.
when someone joins a team they should be assigned a mentor whom they can ask any question, no matter how dumb, and the mentor then guides the new team member in how to approach such a question, which at that point can include asking the LLM. it is the mentors responsibility to point out when it is ok to ask another senior developer. daily standups can also help with this sort of thing.
in a close knit team i would also expect that either everyone can ask anything from everyone else, and that everyone learns when it is ok to ask questions. the situation you describe should simply never arise. if it does, then something is going wrong
There is so much stigma associated with being an senior engineer that simply wants to spend 95% of their day working on the problems that they were hired to solve. The worst part is that the vast majority of people in this situation are not compensated for this time, and they are expected to keep up with their actual assigned responsibilities.
This state of affairs is a relatively new thing. The idea that you would join a company with the expectation that the most important people to the success of a project should drop what they are doing to context shift to someone else's problem several dozen times a day is not something that would have been remotely normal twenty years ago.
I am not saying that mentoring is bad or that asking for help is bad, just that there's been a change and the unspoken vibe is that if you're not happy to work at ~30% capacity because you need to mentor people, you're some kind of antisocial jerk.
If a company wants seniors to mentor, pay them to mentor. It's very simple.
what doesn't work is the assumption that mentoring doesn't take any of your time and that you are expected to manage the same workload with and without mentoring. that's not ok. and spending 70% of your time mentoring may also be a bit to much, but if that is what the company needs then it is still your job.
The notion that an experienced person should automatically consider mentorship to be part of their job is not backed by any code or contract that I'm aware of. It's just increasingly been pushed on people who haven't pushed back enough to keep a new generation from feeling as though they are entitled to it.
You can sample as large a pool of senior devs as you want; I suspect that if you can find 1-in-10 who have specific wording and structure in their employment contracts about the percentage of their time that they should expect to allocate to mentorship, you'll be beating my own estimations. No, what you're doing is attempting to codify a very polite form of exploitation. Yes, those people are usually among the most well-compensated, but it doesn't change the fact that they have their own job to do and a finite time in which to do it.
Please note that I am not suggesting anyone on a team could somehow work in a vacuum. Also, even the most experienced person frequently needs to ask for help, guidance and clarification. Being experienced is pretty much the opposite of knowing everything and is much closer to a measure of how much you have forgotten.
Nor am I implying that senior people have any business being rude or dismissive towards team members who legitimately have good reasons to interrupt someone's flow state. Timely clarification is important to a project regardless of who is doing what.
What I am saying is that if you run a company you might legitimately be horrified to learn that your most critical team members are spending 70% of their productive time mentoring, especially if that remaining 30% of their time is so fragmented that it never resembles a true flow state. You need those people to Build The Thing.
If you don't get that, then you're not living in the same reality I am.
every job i had, every developer i hired. it is also backed by german law for example, refusing to mentor/train others in the work you do is a fireable offense in germany. in any job. not just software development. i doesn't need to be explicit in the contract. it is a natural and expected part of your job. and in the US with at-will employment, what's in your contract doesn't matter as much either. if it seems like a reasonable request they can just let you go if you refuse. the idea that you should not ever have to pass on your knowledge to others in your company seems very entitled to me.
that's my opinion on the matter. you can find more diverse opinions here:
https://softwareengineering.stackexchange.com/questions/8627...
some even fully agree with you.
i already acknowledged the 70% problem you mention. that should not happen unless it is known and intentional. i'd be horrified too if i were surprised by that.
I suspect that if we were having this debate over dinner, we would agree on far more than we disagree on. I think we're speaking past each other because we're operating with slightly different notions of what mentoring implies.
From my perspective, I think that there's an obvious and reasonable expectation that you make best efforts to be a good team player. That means doing your part to participate in planning, knowledge transfer, group morale and of course making yourself available to work through tough problems with people regardless of their skill level.
What I think is far more dubious is the relatively recent slippery slope towards the notion that someone should reasonably be expected that career progress dovetails with some sort of natural law that says you are not being a good human if you aren't willing-to-excited to spend 70% of your productive time in a semi-permanent state of continuous partial attention because the people around you demand priority access to your time and attention, above any of your personal priorities or job responsibilities, often without compensation beyond a rote "thanks".
If you can't ship inside of a deadline because your ephemeral "mentoring" took implicit priority over your actual job, then something is very wrong with people's expectations of how key talent's time should be allocated.
german law or courts operate more on common sense than the letter of the law. to be able to reject a task from your boss the task has to be unreasonable. training/mentoring is not unreasonable unless the work is dangerous and/or a trainer needs specific qualifications. running a class that teaches some generic topic like a programming language would probably be unreasonable because you could just hire an external trainer for that. the training has to be rather specific to the individual experience of the senior or some company internal knowledge to be reasonable. so this doesn't apply to the scenarios you seem to have in mind. in any case from what i read it is recommended to talk to a lawyer before refusing.
but also, if the request interferes with your ability to do your normal work then you can and should speak up and you can reasonably refuse if your boss doesn't make accommodations for that. if he doesn't then refusal is reasonable, not because training wouldn't be your job, but because your workload has increased, which is not ok.
You're the one projecting bias onto this scenario. You assume people only want to talk to you to waste your time. If you work with professionals, you can assume that when they ask you a question, they have a reason to ask you that question. Assuming that they're just being lazy is bad faith.
Accepting a call and then giving someone this kind of non-answer is extremely disrespectful of their time and their professionalism.
> Anyhow, you should try hard not to "hate and despise" LLMs.
That's not what I wrote. You're being needlessly dishonest and disrespectful right here.
Anyhow, in addition to not hating LLMs, I would add "try not to use dramatic, hyperbolic devices in casual writing, it makes you sound ridiculous" to my advice.
Huh, what if I don't want to spend time answering a low-effort question? I will have a look if the default answers/approaches don't work.
Dozens of "quick questions" over the course of a day will drag down your productivity to about one third or worse.
I know that for me, it takes about 45 minutes of focus to enter a flow state, when I'm at my most productive. If I can never enter the zone, then I'm not really doing the thing that made me such a valuable player in the first place, am I?
Someone sneezing nearby can pull you out of the flow state.
The idea that the onus is on the person who you're trying to distract to distract themselves to tell you not to distract them is just so broken if you think about it even just a little bit.
He checked the consensus, the textbook, and 5 studies. He's asking for an answer from experience and he gets "Ask Claude".
But even if you don't know, "I don't know" is a better answer than "Ask Claude", which blindly assumes that the asker hadn't thought of that, which is a weird thing to assume.
People are really really tired.
Because of not just Claude, but also "the recession" "the strait of hormuz closed" "we've never recovered our economy from COVID" "everyone works from home now / the company is forcing us to all come back in" "FAANG had 10000 layoffs" "the global warming" "the <panic about XYZ>", our employers are making us work much harder, with a subtle but palpable panic in their emails, with WAY less promises of any kind of job security, companies that never had layoffs for decades are now doing them regularly, our githubs are flooded with people pointing robots at our issues to generate tepid pull requests, and at our pull requests to generate tepid reviews, and look shit is just crazy now.
So I think the whole "how would you approach this interesting problem..." thing is, for now, at least for me it feels a little bit on hold. Like oh that problem. How to scale? how to horizontally shard PostgreSQL? sure, real problems. But geez whatever we're building, it will be replaced in three months anyway. That's a hard problem you have there! I remember when I used to have problems like that, and my solutions sucked anyway and it was replaced with a node.js app two years later. Whatever advice I have, Claude is going to have 98% of it plus another 10% that I didn't even have.
This is all bad. So I think your post is possibly extremely useful. Maybe we should, for people we know and trust as humans in the real world, actually take the time and approach an issue as though we didn't have the Matrix to approximate it for us. I'm going to think about this and consider it.
Its now a polite way of saying "I dont want to work on this project" without having to go through the effort of thinking hard enough about the problem to put the "go away" price on it (or even worse having to DO the work I dont want to do).
LLM's are good at learning from whatever humans have posted online. But with the agentic workflows getting more popular, more and more problems those AI agents figure out are not posted online, and the next time another agent running into the same problems they would have to figure it out from the scratch again. It'd be nice if there's a mechanism these agents would share the lessons they learn with each other, which could save a lot of trials and errors and wasted tokens. Humans show knowledge online. AI agents should be able to do so too. The moltbook thing from half year ago could have this potential, but too bad it's flooded by spams.
Of course, to make this AI knowledge sharing truly work, there may need to be a peer-review mechanism to ensure the knowledge being shared is truthful, reliable, non-trivial etc. That can probably be all worked out if somebody (or AI agent) really put effort into it.
These should be opt out. Maybe have a skill that is similar and is opt out
(I'd trust an ML algorithm that only has to classify in two boxes, thus easy to evaluate, over my own gut feeling).
The highlighted parts scream LLM writing. It pains me that I can recognize this so easily.
- Mismatched analog: Send an e-mail doesn't match pick up the phone. First one is outgoing, second is incoming.
- Real - Claude looooves punchy, empty emphasis words like this.
- , the kind - tacked on extra phrase that should be a separate sentence. Claude does this all the time. We aren't writing a shitting noir novel, Claude.
- a decision go sideways in a boardroom - super vague shadow of an anecdote. The "a" in front of "boardroom" is a blinking red light for me, can't fully explain why.
- Not what the textbook says. - Too short, too vague
- not the textbook, 5 studies, 30 years of experience - pattern of 3
- that a search engine couldn't - This type of phrasing is so triggering for me. I've been busting my ass trying sanitize LLM output of this style...
I often leave out details and specifics or make things purposely vague because I am writing about real people.
Thanks for the the correction-- often when people say they weren't using AI they are very clearly lying, so it's hard to get useful corrections on this point so I appreciate your candor.
Increasingly common these days... I've caught myself more than a few times.
I also recently reread a blog post I wrote a decade ago, and it had the "It's not X, it's Y" pattern over and over again.
That is, the author asked for
And his real answer isDo you need to know if X is faster than Y? Do both. Measure. Sometimes the answer requires actual research.
Maybe you need a real Subject Matter Expert because it turns out that nobody ever published something on the internet about something so that an LLM could soak up the real world information.
Before the internet, we would consult with books. After the internet, it seemed faster to search and find answers in things like blog posts, (paid) articles, and CDs. Wikipedia and Stack Overflow are great resources. Maybe you need an answer from Hacker News - ask HN.
By relying on LLMs more than these other sources and allowing LLMs to write articles and posts to these other sources, we lose subject matter experts.
Add to that companies like Microsoft and Meta and others laying off and offering retirement packages to get rid of institutional knowledge as fast as possible, and we are headed towards a gigantic crash of knowledge.