Because juniors don't know when they're being taken down a rabbit hole. So they'll let the LLM go too deep in its hallucinations.
I have a Jr that was supposed to deploy a terraform module I built. This task has been hanging out for a while so I went to check in on them. They told me the problem they're having and asked me to take a look.
Their repo is a disaster, it's very obvious claude took them down a rabbit hole just from looking. When I asked, "Hey, why is all this python in here? The module has it self contained" and they respond with "I don't know, claude did that" affirming my assumptions.
They lack the experience and they're overly reliant on the LLM tools. Not just in the design and implementation phases but also for troubleshooting. And if you're troubleshooting with something that's hallucinating and you don't know enough to know it's hallucinating you're in for a long ride.
Meanwhile the LLM tools have taken away a lot of the type of work I hated doing. I can quickly tell when the LLM is going down a rabbit hole (in most cases at least) and prevent it from continuing. It's kinda re-lit my passion for coding and building software. So that's ended up in me producing more and giving better results.
I'm the type of reviewer that actually reads code and asks probing questions, and I've heard this from junior and senior devs alike. It's maddening how people say this with a straight face and expect to keep their jobs. If people are pushing code they don't understand, they're liability to their team, product, and employer.
The rank disrespect of somebody asking you to review something they haven't even looked at is eye watering.
I feel like AI-induced brain-rot of engineers is inevitable. Unless we see AI leapfrog into something close to AGI in the future (certainly not ruling this out), I think there will be very lucrative careers available to engineers who can maintain a balanced relationship with AI.
I'm glad I'm not the only one who gets viscerally irritated when I'm asked to review a PR that was obviously generated. You didn't take the time to write this code, but you expect me to take the time make sure it's correct, which will take far longer than a regular PR because there's no reason to assume an LLM even understood the task. Next time just be honest and ask me to do your work for you.
> You didn't take the time to write this code, but you expect me to take the time make sure it's correct
So, I guess there are a couple parts here right? I might not take the time to write the code, but surely I am on the hook to demonstrate that I've tested the code or have very good reason to believe it's correct?
If people are pushing PRs [of any meaningful complexity] without knowing whether they work in the general case that sounds like a failure of process and/or training. For me PRs are about catching edges?
I just felt this recently. I was sent some code for me to put into prod, a long running service. And in one func, which returned an error (Go) but still called "os.Exit" in each error handler rather then returning.
Fixing the issue was a small matter. But the amount of disrespect I felt, that I looked at it closer then anyone else apparently (which wasn't really all that close at all), when they were ostensibly building this code, that disrespect was just immense.
Well no one actually asked you for a review, it's just a stupid checkbox item some boomer added to the list of other useless checkbox items - like group calls where everyone is just reading list of closed tickets we can all read ourselves in jira. This self righteous bullshit makes the whole ordeal even more insufferable.
Code reviews are one of the few ordeals worth doing. They catch problems and transfer knowledge. In a reasonably well run org (it doesn't take much) code reviews are easily a huge net benefit.
As for "reading closed tickets", you are right. It is silly. Alas, in apathetic orgs it is a reliable way to get some people know what is going on some of the time. And that particular ordeal keeps the tickets somewhat in sync with reality.
Consider that your experience may not be universal. Just because your reviews are useless rubber stamps to satisfy "some boomer" does not mean that other shops also have no standards. I get explicitly asked for reviews at work all the time, and I'm expected to actually understand the code and provide useful feedback.
By the way, you don't have to give useless reviews even if your coworkers do. It sounds like your workplace is infected with complacency, but there's no law that says you can't do better.
If you saw the nonsense some of my teammates try to commit, you would have a completely different view on code review. Just off the top of my head in the past 3 months, they have:
- Written a 1-line function that returns a literal, but they pointlessly made the function async and added a @cache decorator.
- Used try/catch to catch ALL exceptions, and then just ignored the exception causing code elsewhere to explode.
- Used try/catch to catch ALL exceptions, and then log that an authentication error happened. Did the request time out? Well the logs now lie to you and say it was an authentication error.
- Replace a log statement for a very serious error with a logging.warning() because that makes the error no longer show up on our reports.
If code reviews are that useless to you, that must mean either your team is completely homogeneous in terms of skill level and knowledge, or no one is taking the code reviews seriously.
100%. This has in general become a trend across my company. Less so developers, more so everyone else spitting LLM generated content, and asking real people to review and provide feedback. I mean , WTF.
In certain situations I'd argue it's a calculated risk worth taking. Let's say I'm tasked with adding a much-needed feature to an older legacy application that is built using frameworks and libraries I'm not familiar with, possibly also with with weak docs. If Claude is able to produce a self-contained piece of code that looks correct when you read through it and behaves correctly during (thorough) testing, then it sure has saved me (and my company) a lot of time and effort, even though we are deploying code we may not fully understand.
My interactions with Gemini tend to be fairly slow, but it's because I don't give it any extra permissions, make it research and plan an implementation first, and check each file update one at a time.
So far it has still been a bit more productive for me, though the margin is low. I get more product sork done on the order of 5-15%, I tend to have more test coverage as I focus more heavily on that, and I can focus more often on architecture. The last one is a win for me, I prefer that work and find that I can review code quickly enough to make it worth the tradeoff.
Pre AI I can understand why you might not know. There have been instances where I find a recipe, take what I need, but there’s some code I can’t understand or find an answer to. But time pressure, so I just add a comment and ask around for ideas.
"I don't know Claude did that" isn't a bad thing in and of itself... If someone is spending a bunch of time on code that Claude could have done and easily verified it was correct, they are going to move slower and produce less useful things of value than someone who cares about reading every line of code.
Any situation where you’re submitting under your signature code to production without knowing what it does should be at the very least cause for a talk.
The policeman says to the judge, on the stand "I don't know why my sworn affidavit says that, your honor. But I can write twice as many affidavits now so it's all for the best."
> If someone is spending a bunch of time on code that Claude could have done and easily verified it was correct, they are going to move slower and produce less useful things of value.
This is the future fellow greybeards. We will be shunned for being try-hards, and when it turns out we were right?... Well no one likes a know it all.
If it’s easily verified as correct, then you should have verified its correctness before bringing it to someone more senior and asking for their help, and so you should be able to explain why it is there when they ask.
If you don't understand you code how you can be sure it's correct? You actually are pushing it into your colleagues who will verify and fix the code later.
The only thing that changed with AI is that the narrative went from "you can't always know perfectly what every part of the program does" to "don't even try".
But the LLM writes the tests too. Probably even made some private methods public so it can test them, because you asked it to write a comprehensive test suite. It’s a beautiful self-jerk circle of shitty code based on wrong assumptions proven by correct tests testing shitty code based on wrong assumptions…
Or the wonderful loop of "These test steps are still failing, let's try something simpler and remove the failing tests. Great! The tests are passing now!"
Sad reality is test engineers headcount over last years was cut even more than developers. Most companies see testing as obstacle and unnecessary costs and has no will to invest into testing.
> they respond with "I don't know, claude did that"
A huge red flag right here. Its ok to not know things, its ok to use LLM to fill the gaps. Its ok to fail. It is in no way ok to not care and only fess up to having a mass of code you have no idea about when your senior reviewer asks you about it. At the very minimum the ask should go the other direction - "I got this generated code and I am not sure I understand what's going on, could you help me to see if that's the right direction" would be acceptable. Just not caring is not.
>How'd you get so good at debugging and navigating code you've never seen before?
>Because I spent a couple internships and a whole year as a junior debugging, triaging and patching every single issue reported by other developers and the QA team
Was I jealous that the full time and senior devs got to do all the feature work and architecture design? Yes. Am I a better developer having done that grind? Also yes.
100%. I shouldn't have done the architecture work on any meaningful scale early on, but I was always interested. My early roles were largely me being able to architect smaller pieces in a larger plan, building some architecture skills while learning larger patterns that worked and thought processes along the way.
I'd recommend that approach to anyone working with more junior devs.
Which will (sadly) offer you zero extrinsic benefit at almost every job, and will often actually count against you as a waste of time relative to the vast majority of productivity metrics that companies actually use.
There's a lot of benefits you get by mentoring. When you have to teach you're forced to think more deeply about problems, see it from different angles, and revisit questions you had when learning but tabled at that time. That last one is pretty common. There's always questions you have when learning that you have to avoid because you don't have the knowledge to answer yet, because they would take you down too deep a rabbit hole. But later you have the experience to navigate those problems.
Personally, I've learned a ton while teaching. It's given me many new ideas and insights. But I'm obviously not alone in this. Even Feynman talks about how teaching results in better learning
I don't think you have to convince the parent poster or seniors developers in general. You have to convince their employers that this is a valuable use of time.
Which is unfortunately very true. I think, that in a healthy organization such kind of mentoring requires extremely well defined boundaries and rules. Can I spend 1h of my time explaining basic stuff to a junior, who will then be able to finish his task in 2h instead of 8h? Mathematically this is a win for the company. But economically, maybe that junior dev should be fired.
That's the problem -- except in the rare type of org that thinks past quarterly or annual results and thus values training up a pipeline to be the future seniors -- economically speaking, all the junior devs should be fired, and the simple tasks they can do are the same set of tasks that can be accomplished by a senior at the helm of AI at 10-50x the speed.
Oh come on. Plenty of us here never had any form of direct mentorship at work or otherwise. It's not unusual when you pick up the trade as a hobby in your teens, and in terms of programming and technical skills (which is what we're discussing here), you stopped being a junior before getting your first job.
Myself, I learned from many folks on IRC and ol' phpBB boards, and I helped others on IRC and said phpBB boards in return; almost all of that was before graduating. That, and books, lots of books, and even more time spent just reading code online and writing my own. None of that hardly qualifies as "mentoring".
>you stopped being a junior before getting your first job.
No, that was your hubris thinking you had the chops. We didn’t hire you because of your skills, we hired you because of your age and aptitude to learn. That’s how college recruitment works. If you didn’t go that route, you were still looked at as a junior. Your ego clouds your view.
> If you didn’t go that route, you were still looked at as a junior. Your ego clouds your view.
your ego clouds your response.
He wasn't talking about if he was hired into a jr role, he was talking about the competency, experience, and skills acquired from the years of writing code for passion. If he could write better code, or debug problems faster than your average jr level employee.
Not everyone fits into the tiny bucket you've imagined must hold everyone. The answer could easily be, we hired you because you ticked all the boxes, but no one doing the interview could tell they were completely out classed.
If you’re employed, you’re in a bucket. It’s a cell on a spreadsheet somewhere.
I’ve yet to find a junior dev that had more skills than a junior dev. I’ve seen them try… but they are still a junior dev. If you aren’t a junior dev, then you aren’t. Mentorship has nothing to do with what bucket you’re in.
However, there are specific job duties of senior and higher that are beyond just writing code. One of them is making more seniors. There’s only one way to do that efficiently. Learning. And while you can go read a manual on how to put a Ferrari together, wouldn’t you want to work with a mechanic who has already made dozens of them?
> I’ve yet to find a junior dev that had more skills than a junior dev. I’ve seen them try… [...] If you aren’t a junior dev, then you aren’t.
Funny, I've met plenty of jr devs that were way more competent than some of their peers who've been at the exact same company/division for 4+ years. Which was my point. The world is bigger than you can imagine. There are people with experiences that you couldn't describe, but you write in a way that feels like you want to dismiss them outright as impossible, which does a disservice to everyone involved.
> And while you can go read a manual on how to put a Ferrari together, wouldn’t you want to work with a mechanic who has already made dozens of them?
> Why do we reject help?
I feel like you and I are arguing past each other. To reuse your example: There are plenty of people who have never spent time with a mechanic, but have been spent so much time pouring over every technical manual for the car, that they can out perform guys with years working for Ferrari, while that guy working for Farrari has mentors, he still has to ask for help with most things, and needs to look up a number of the specs. But the person who exclusively taught himself, can do many of the same tasks blindfolded.
No one has said they don't want mentorship, but many were never in a position to have that advantage. But you said that if they think aquired their skills on their own, they need to seek therapy. WTF?
I'm sure you've met plenty of narcissists who have had mentors, but claim they haven't. But it's wrong, insulting and pretty toxic to lump everyone into that same group.
>but you write in a way that feels like you want to dismiss them outright as impossible
I write in a way from wisdom, from experience, the likes of which you describe as indescribable.
Ever heard the term “It takes a village”? You had mentors that you refuse to acknowledge.
>There are plenty of people who have never spent time with a mechanic, but have been spent so much time pouring over every technical manual for the car, that they can out perform guys with years working for Ferrari, while that guy working for Farrari has mentors, he still has to ask for help with most things, and needs to look up a number of the specs.
Except that guy in his garage isn’t working for BMW or Mercedes, he’s a hobbyist that has learned all about his vehicle. There’s a difference. A minor one, but it’s there. The Ferrari mechanic works on ALL Ferrari. Now, you’ll say, but there’s a car guy that can… I’ll save you the trouble. That guy isn’t applying to junior roles, isn’t asking for mentorship, he’s just a car guy. A passion about cars.
Then you’ll say: exactly my point about engineering. Which is right, I never said that it wasn’t possible that someone could selflessly throw hours away teaching themselves through trial, error, and tutorials. There are many paths. What I’m saying is, stop wasting hours and open your mouth and ask for help. There are no stupid questions, only stupid answers. Every scientific breakthrough starts with a question. Every idiot response starts with an answer. Mentorship is asking for guidance with the wisdom to know the difference.
Everyone is looked at as a young person when they are young. I've definitely had "junior" colleagues that "got it" better than my 50yo colleagues. It's possible I shouldn't say that outloud, because skilled youngsters have a tendency to misidentify themselves as being part of that set while the wise youngsters have a tendency to *underestimate* their own capability or insight. But I don't think you can make that same assumption about a senior thinking back to their early years.
I desperately wish, to this day, that I had been in the position to receive mentorship. I basically hang out on HN as a way to gather it where I can. Attended engineering meetups when I was younger as well. But I never had the benefit of working with engineers senior to myself. I was a junior "business employed person" but when you need to make a roof you do what you can and learn the hard way even if there's no other humans to show you how to make a proper roof. Luckily, you can receive mentorship not just online, but through books, or even just studying the craft of others...but you take what you can get.
Receiving mentorship is such a gift, and as I approach the end of my career, I am still hungry for it, and harboring some degree of wistful envy for those that receive mentorship as an engineer. I've had many great mentors, but my for the most part, engineering mentors have never seen my face, heard my voice, or known my name, and certainly not for the first decade of my professional career as a software developer, where I didn't have any other developers to work with.
You see, the issue is you’re framing your mentorship (or lack thereof) on a very specific topic, that you are already well versed in. Why would someone give you advice in your field? You probably already know…
Mentorship is about more than just “don’t use strings directly in your squeal”, it’s about navigating the organization. Filing proper TPS reports. Encouraging refactoring. Having empathy when shit goes south. Coffee talks. Hikes. Walks. Getting to know them as a person and giving them life advice.
My best mentor taught me, if you keep looking under rocks, all you’ll find is dirt. Look up.
Of course. And I thought I acknowledged that mentorship is many things and there are many things that we need to grow as individuals. I've had a lot of great mentors in my life.
I still think you've missed the point. You can be grateful for the many gifts you've received and still wish to have had engineering guidance from a trusted mentor. There is not enough time in a life to go down every single rabbit hole; it's nice to have experienced people accurately point out where the rabbit holes are. Non-engineers are not equipped to help spot engineering rabbit holes; they might even tell you that engineering itself is ultimately a pointless rabbit hole.
But even then...that's just my own experience and my own wishes for my past self. I try to give what I wish I had had, of course.. think that's what drives most mentorship, and maybe that's the point you're trying to make, that mentorship is given out of that wistful feeling of wishing you had received advice/help and passing along the lessons that took you too long to find.
But still, if your role is getting stuck alone in the server room or whatever with a team of people who don't understand or respect what you do, good luck.
The point I was trying to make (and maybe failed because I got too focused on my own experience) is that really, not everyone gets mentors, even of the broader sort that you're referring to (which I might say are more accurately called friends or peers). But even if we widen the scope of what mentorship is, it's also perfectly reasonable for field-specific mentorship to be a cultural expectation for software engineering. I think it's a good thing to expect this of each other, and to encourage explicitly making space for the practice.
But again, however you want to widen the scope of what mentorship is, not everyone is getting it. The reason people look under rocks is because they don't know where to look. Or they do know where to look but also know they have blind spots and don't know how to get them addressed. "Look up" is nice and all, but it's a bit rude and distracting when you're trying to build something and need help understanding the foundation below your feet. Sometimes you don't need someone telling you to look up, you need help seeing where to look closer.
This is kind of sad. I'm probably missing context here, but surely it's not necessary to rush out of a good working relationship with a good mentor. The most important things you'll learn from a good mentor can't be learned in a rush (like prioritization, project management, how to be a good mentor...).
In any case, I would replace 'jump ship' with 'pay it forward.'
>do everything you can to learn quickly then jump ship to big tech and cash in.
Yeah, don’t do this. Great way to ruin your reputation as a dollar chaser and be exiled to the consulting wastelands. Burning bridges takes minutes. Building them takes years.
A great mentor won’t waste their time on someone cynically using their time to cash out at Meta. Such a person can just get a CS degree and launch into Amazon for that.
Big Tech are just the IT enterprises of the modern day. It’s not where the action is and that experience is not so hot on the CV when it comes to early stage development.
Mentoring is a different kind of work than coding. Like senior+ level in some companies, it's just faux management - people work, with all the expectations and responsibilities of the non-technical track, but none of the status and privileges.
That makes sense. When Claude Code suggests a bad approach, I kind of shrug it off and suggest a different approach. I don't think of it like a negative because I basically go through a similar process of ideation before I implement a feature and I typically discard ideas before arriving at the right one so Claude Code is part of the ideation process for me. The code it produces gives me a clear idea about how complex/ugly the solution will be. I know what 'ugly' looks like.
I imagine a junior might actually jump at the first solution because they don't have any other arrows in their quiver so-to-speak. The LLM is acting like the engineering manager but it's actually really bad at that.
The LLM is like a stereotypical programmer with 0 common sense. The kind who can produce good code but you have to micromanage every single decision. It's terrible if you put it in charge. It doesn't have any opinions about architecture or code quality so it just follows the structure of the existing code base... There's a tendency towards increasing complexity, more hacks more chaos.
It often tries to hack/cheat its way to a solution. It requires a constant effort to maintain order.
It’s like having a malicious mentor. But the frequency of which I’m bailing on reviews on the first line due to stupid stuff that has made it to a commit is quite stunning.
“Oh I thought that would be useful at some point so I just committed it.”
Beating it into developers that they need to review their own work they submit before asking someone else to waste time is the best way I’ve found so far.
The deciding factor for being able to effectively utilize LLMs and dodge hallucinations is ability to read code and intuition for how a solution should look. I think juniors are especially hesitant to just dig into understanding some source code unless they have no other choice, e.g. preferring to wait on email response from the author of the code over piecing things together.
This makes LLM tools so tempting, you don't even have to wait on the email response anymore! But of course, this is basically going in blind, and it's no wonder that they end up in hallucination mazes.
No amount of “own the code you generate” policies will prevent the rise of “I don’t know, the AI wrote it” excuses in the LLM era. What’s more likely is that reviewers will be flooded with unvetted, generated code. Over time, this can lead to reviewer fatigue and a gradual decline in rigor. If the trend continues, the impact could be significant once the most experienced engineers begin to retire.
I think a lot of the problems lies in their prompting. AI is usually at its worst when just saying «deploy terraform module». And off it goes spitting out code.
What they should have done as juniors was to have a conversation about the topic and task first. «Help me understand …» learning and planning is especially important with LLM coding.
I don't write terribly complex things: Just data processing pipelines for neuroimaging, but I know I get good results because I take time being specific in my prompts, saying what I want, but also what I don't want, suggesting certain tools, what options I want available, how I want logs, etc. I really does help it to know what you want and relaying that with an effortful prompt.
The best code I've written with an LLM has been where I architect it, I guide the LLM through the scaffolding and initial proofs of different components, and then I guide it through adding features. Along the way it makes mistakes and I guide it through fixing them. Then when it is slow, I profile and guide it through optimizations.
So in the end, it's code that I know very, very well. I could have written it but it would have taken me about 3x longer when all is said and done. Maybe longer. There are usually parts that have difficult functions but the inputs and outputs of those functions are testable so it doesn't matter so much that you know every detail of the implementation, as long as it is validated.
True but the n00b is very fast. A lot of coaching is waiting for the n00b to perform tasks and meta things about motivation. These LLM are extremely fast and eager to work.
I don't need a study to tell me that five projects that have been stuck in slow plodding along waiting for me to ever have time or resources for nearly ten years. But these are now nearing completion after only two months of picking up Claude Code. And with high-quality implementations that were feverdreams.
My background is academic science not professional programming though and the output quality and speed of Claude Code is vastly better than what grad students generate. But you don't trust grad student code either. The major difference here is that suggestions for improvement loop in minutes rather than weeks or months. Claude will get the science wrong, but so do grad students.
(But sure technically they are not finished yet ... but yeah)
And potentially trick you into going down a rabbit hole as you try to steer it when it would have been faster to edit the code yourself. The best use is editing code with it instead of purely relying on prompting. Also new contexts for different changes make a huge difference. Seems a lot of devs get stuck in the single context chat stream and it starts to break down as context gets fuzzy.
This can go both ways though. I've had instances where after a long somewhat tedious back and forth with Claude Code what I'm looking for finally "clicks" and it starts one-shotting requests left and right. But then after coming up to the end of the context window, I compact or ask it to update CLAUDE.md with what it learned and it loses the nuanced understanding it built up through trial and error and starts screwing up in the exact same ways again with fresh context.
And then I waste 20 minutes bashing my head against the wall trying to write three paragraphs meticulously documenting all the key gotchas and lessons from the "good" context window with the magic combination of words needed to get Claude back in the right head space to one-shot again.
At least if I pull that off I can usually ask Claude to use it as documentation for the project CLAUDE.md with a pretty good success rate. But man it leaves a bad taste in my mouth and makes me question whether I'm actually saving time or well into sunk cost territory...
You’d think that with more context it would get better, but it doesn’t.
My hunches are that the to-and-fro of ideas as you discuss options or make corrections leads to a context with competing “intentions”; and that they can’t tell the difference between positive and negative experiences when it comes across each successive token in the context.
Quite honestly after using Copilot, Claude Code, Cursor, and Codex extensively for months, I very rarely hand edit code.
The rabbit hole problem is pretty rare. Usually it happens when the model flips into "stupid mode", some kind of context poisoning. If you are experienced, you know to purge the context when that happens.
In personal projects I avoid manual editing as a form of deliberate practice. At work, I only edit when it is a very small edit. I can usually explain what I want more concisely and quickly than hand editing code.
I probably would use more hand editing if I had classic refactoring tools in the IDEs similar to intellij/pycharm. Though cli based tools were a pleasant surprise once I actively started using them.
And not at all for you, because you're unlikely to retain them for long. Which makes this immaterial - AI or human, you're only going to delegate to n00bs.
(This is distinct from the question of which benefits society more, which is a separate discussion.)
Except that most of the code seniors review was written with intention, not just the most statistically most likely response to a given query. As a senior engineer, the kinds of mistakes that AI makes are much more bizarre then the mistakes junior engineers make
I've worked with many interns and juniors in my life and they've made very bizarre mistakes and had subtle bugs, so the difference in the kinds hasn't made much of a difference in the work I've had to do to review. Whether or not there was intention behind it didn't make a difference.
I’ve definitely seen absolutely bizarre creations from junior devs decades ago (so, well before modern AI). I can also think back to some cringey code I wrote by hand when I was a junior as well.
I mentor high-school students and watch them live write code that takes a completely bizarre path. It might technically be intentional, but that doesn’t mean it’s good or useful.
My experience in the UK has been that seniors and principles just write more/better code and occasionally deal with “the business” with (justifiably) greater attention paid to their input. I’d love to see a proper culture of mentoring.
LLMs might make you feel faster (which helps with motivation!) and help with some of the very easy stuff but the critical part of your anecdote is that you haven't actually completed the extra work. The projects are only "NEARING" completion. I think that's very telling.
But in all seriousness, completion is not the only metric of productivity. I could easily break it down into a mountain of subtasks that have been fully completed for the bean counters. In the meantime, the code that did not exist 2 months ago does exist.
If the easy things are done faster you xan spend more time on the hard stuff. No need to spend 2 hours on making the UI for the MVP when an AI can make a decent UI in 2 min. Means you have 2 hours more to spend on the hard stuff.
Unless, as is often the case in my experience, the hard stuff consists largely of fixing bugs and edge cases in your implementation of the easy stuff. I've seen multiple people already end up forced back to the drawing board because their "easy stuff" AI implementation had critical flaws they only realized after they thought they were done. It's hard to prove counterfactuals, but I'm pretty confident they would have gotten it right the first time if they hadn't used AI, they're not bad engineers.
> I don't need a study to tell me that five projects that have been stuck in slow plodding along waiting for me to ever have time or resources for nearly ten years.
that's the issue in the argument though. it could be that those projects would also have been completed in the same time if you had simply started working on them. but honestly, if it makes you feel productive to the point you're doing more work than you would do without the drug, I'd say keep taking it. watch out for side effects and habituation though.
You've added an implicit assumption that this person spends more time programming now than they used to, rather than continuing to commit time at the same rate but now leading to projects being completed when they previously got bogged down and abandoned.
There are any number of things you could add to get you to any conclusion. Better to discuss what is there.
I've had the same experience of being able to finish tons of old abandoned projects with AI assistance, and I am not spending any more time than usual working on programming or design projects. It's just that the most boring things that would have taken weeks to figure out and do (instead, let me switch to the other project I have that is not like that, yet) have been reduced to hours. The parts that were tough in a creative fun way are still tough, and AI barely helps with them because it is extremely stupid, but those are the funnest, most substantive parts.
I don't think that's correct. That could be true if I were primarily a programmer, but I am not. I'm mostly a certified medical physicist working in a hospital. Programming is a skill that is helpful and I have spent my programming time building other tools that I need. But that list is gigantic, the software that is available for purchase is all complete crap, the market is too small for investment, etc. That's all to say the things I am building are desperately needed but my time for programming is limited and it's not what brings home the bacon and there's no money to be made (beyond consulting, essentially these things might possibly work as tools for consultants). I don't have resources for professional programming staff but I have worked with them in the past and (no offense to most of HN) but the lack of domain knowledge tends to waste even more of my time.
It is in many ways much like coaching a n00b, but a n00b that can do 10 hours of n00b work in 10 minutes (or, 2 minutes).
That's a significant difference. There are a lot of tasks that can be done by a n00b with some advice, especially when you can say "copy the pattern when I did this same basic thing here and here".
And there are a lot of things a n00b, or an LLM, can't do.
The study you reference was real, and I am not surprised — because accurately gauging the productivity win, or loss, obtained by using LLMs in real production coding workflows is also not junior stuff.
At least you can ask AI to summarize a AGENT.md or something and it will read it diligently next time.
As for humans, they might not have the motivation technical writing skill to document what they learnt. And even if they did, the next person might not have the patience to actually read it.
"Read diligently" - that’s a very optimistic statement. I can not count how many times Claude (LLM I am most familiar with, I had it write probably about 100KLOC in the past few months) explicitly disobeyed what was written in the instructions.
Also, a good few times, if it were a human doing the task, I would have said they both failed to follow the instructions and lied about it and attempted to pretend they didn’t. Luckily their lying abilities today are primitive, so it’s easy to catch.
Psychopatic behavior seems to be a major problem for these (of course it doesn't think so it can't be called that but that's the closest term that fits). They are trained to arrive at the result, and if the most likely path to it is faking it and lying about it, then that's what you are getting. And if you find it, it will cheerfully admit it and try to make s better lie that you'd believe.
So true. I have some non-typical preferences for code style. One example is I don’t like nested error checks in Go. It’s not a correctness issue, it’s just a readability preference. Claude and copilot continually ignore this no matter how much emphasis I give it in the instructions. I recently found a linter for this, and the agent will fix it when the linter points out the issue.
This is probably because the llm is trained on millions of lines of Go with nested error checks vs a few lines of contrary instructions in the instructions file.
I keep fighting this because I want to understand my tools, not because I care that much about this one preference.
Claude has really gone downhill in the last month or so. They made a change to move the CLAUDE.md from the system prompt to being occasionally read in, and it really deprioritizes the instructions to the same attention level as the code it's working on.
I've been trying out Codex the last couple days and it's much more adherent and much less prone to lying and laziness. Anthropic says they're working on a significant release in Claude Code, but I'd much rather have them just revert back to the system as it was ~a month ago.
true, I was using Cline/Roocode from almost an year and it always made sure to read things from memory-bank which i really liked. Claude has gone downhill from August mid for me and often it doesn't follow instructions from claude.md or forget things mid-way.
> Also, a good few times, if it were a human doing the task, I would have said they both failed to follow the instructions and lied about it and attempted to pretend they didn’t.
It's funny. Just yesterday I had the experience of attending a concert under the strong — yet entirely mistaken — belief that I had already been to a previous performance of the same musician. It was only on the way back from the show, talking with my partner who attended with me (and who had seen this musician live before), trying to figure out what time exactly "we" had last seen them, with me exhaustively listing out recollections that turned out to be other (confusingly similar) musicians we had seen live together... that I finally realized I had never actually been to one of this particular musician's concerts before.
I think this is precisely the "experience" of being one of these LLMs. Except that, where I had a phantom "interpolated" memory of seeing a musician I had never actually seen, these LLMs have phantom actually-interpolated memories of performing skills they have never actually themselves performed.
Coding LLMs are trained to replicate pair-programming-esque conversations between people who actually do have these skills, and are performing them... but where those conversations don't lay out the thinking involved in all the many implicit (thinking, probing, checking, recalling) micro-skills involved in actually performing those skills. Instead, all you get in such a conversation thread is the conclusion each person reaches after applying those micro-skills.
And this leads to the LLM thinking it "has" a given skill... even though it doesn't actually know anything about "how" to execute that skill, in terms of the micro-skills that are used "off-screen" to come up with the final response given in the conversation. Instead, it just comes up with a prediction for "what someone using the skill" looks like... and thinks that that means it has used the skill.
Even after a hole is poked in its use of the skill, and it realizes it made a mistake, that doesn't dissuade it from the belief that it has the given skill. Just like, even after I asked my partner about the show I recall us attending, and she told me that that was a show for a different (but similar) musician, I still thought I had gone to the show.
It took me exhausting all possibilities for times I could have seen this musician before, to get me to even hypothesize that maybe I hadn't.
And it would likely take similarly exhaustive disproof (over hundreds of exchanges) to get an LLM to truly "internalize" that it doesn't actually have a skill it believed itself to have, and so stop trying to use it. (If that meta-skill is even a thing that LLMs have ever learned from their training data — which I doubt. And even if they did, you'd be wasting 90% of a Transformer's context window on this. Maybe something that's worth keeping in mind if we ever switch back to basing our LLMs on RNNs with true runtime weight updates, though!)
Thankfully after many generations of human interactions and complex analysis of group dynamics, we've found a solution. It's called 'don't be an asshole' and 'pay people competitively'.
edit: because people are stupid, 'competitively' in this sense isn't some theoretical number pulled from an average, it's 'does this person feel better off financially working with you than others around them who don't work with you, and is is this person meeting their own personal financial goals through working with you'?
The elephant in this particular room is that there are a tiny handful of employers that have so much money that they can and do just pay whatever amount is more than any of their competitors can possibly afford.
That shouldn't be a big deal since they're a finite portion of the market. You should have a robust enough model to handle people leaving, including unavoidable scenarios like retirement and death.
They do have a point. Why waste a time on person who will always need more money over time, rather than invest in AI? Not only you don’t need to please every hire, your seniors will be more thankful too, because they will get linearly faster with time.
That's not a bad thing. It means you've added one more senior to the societal pool. A lot of the talent problems today are due to companies not wanting to train and focusing on cheap shortcut options like outsourcing or H1B
that is absolutely false - the capital and resources used to create these things are societal scale. An individual consumer is not paying that cost at this time.
That only proves the point. If something increases the value of someone’s time by 5% and 500,000,000 people are affected by it, the cost will collapse.
These models are only going to get better and cheaper per watt.
> Really does not sound like that from your description. It sounds like coaching a noob, which is a lot of work in itself.
Even if you do it by yourself, you need to do the same thinking and iterative process by yourself. You just get the code almost instantly and mostly correctly, if you are good at defining the initial specification.
This. You _have_ to write the spec. The result is that instead of spending X units of time on spec and THEN y units of time on coding, you get the whole thing in x units of time AND you have a spec.
The trick is knowning where the particular LLM sucks. I expect in a short amount of time there is no productivity gain but when you start to understand the limitations and strengths - holey moley.
> The result is that instead of spending X units of time on spec and THEN y units of time on coding, you get the whole thing in x units of time AND you have a spec.
It's more like x units of time thinking and y units of times coding, whereas I see people spend x/2 thinking, x typing the specs, y correcting the specs, and y giving up and correcting the code.
Sure! That's inefficient. I know just how I work and I've been writing the type of programs I do for quite many years. And I know what would take me normally a week takes me few days at best.
If you notice only after two weeks the project is off-kilter I would guess the chance of that happening without an LLM is not low either.
These are not _tools_ -they are like cool demos. Once you have a certain mass of functional code in place, intuition - that for myself required decades of programming to develop - kicks in and you get these spider sense tinglings ”ahh umm this does not feel right, something’s wrong”.
My advice would be don’t use LLM until you have the ”spider-sense” level intuition.
> Wasn’t there a study that said that using LLMs makes people feel more productive while they actually are not?
On a tangent; that study is brought up a lot. There are some issues with it, but I agree with the main takeaway to be weary of the feeling of productivity vs actual productivity.
But most of the time its brought up by AI skeptics, that conveniently gloss over the fact it's about averages.
Which, while organizationally interesting, is far less interesting than to discover what is and isn't currently possible at the tail end by the most skillful users.
The key insight from the study is that even the users that did see an increase in productivity overestimated that increase.
Taken along with the dozens of other studies that show that humans are terrible at estimating how long it will take them to complete task, you should be very skeptical when someone says an LLM makes them x% more productive.
There’s no reason to think that the most skillful LLM users are not overestimating productivity benefits as well.
Engineers have always been terrible at measuring productivity. Building a new internal tool or writing a bunch of code is not necessarily productive.
Productivity is something that creates business value. In that sense an engineer who writes 10 lines of code but that code solves a $10M business problem or allows the company to sign 100 new customers may be the most productive engineer in your organization.
Not to mention the study doesn't really show a lack of productivity and they include some key caveats in it outlining how they think productivity increases using LLMs
It has about a dozen or so endpoints, facilitating real time messaging.
It took me about 4 hours to build it out, fully tested with documentation and examples and readme.
About two hours were spent setting up the architecture and tests. About 45 min to an hour setting up a few of the endpoints. The rest were generated by CC. FWIW it is using layers and SRP to the max. Everything is simple and isolated, easy to test.
I think if I had a contractor or employee do this they would have coasted for a week and still fucked it up. Adding ridiculous complexity or just fucking up.
The nice thing about AI tools is you need less people. Most people are awful at their jobs, anyone can survive a few years and call themselves senior. Most teams are only successful because of the 1 or 2 guys who pull 150% while the others are barely doing 80%.
It's this, but 1000 times faster — that's the difference. It's sending a noob away to follow your exact instructions and getting results back in 10 seconds instead of 10 hours.
I don't have to worry about managing the noob's emotions or their availability, I can tell the LLM to try 3 different approaches and it only takes a few minutes... I can get mad at it and say "fuck it I'll do this part myself", the LLM doesn't have to be reminded of our workflow or formatting (I just tell the LLM once)
I can tell it that I see a code smell and it will usually have an idea of what I'm talking about and attempt to correct, little explanation needed
The LLM can also: do tons of research in a short amount of time, traverse the codebase and answer questions for me, etc
it's a noob savant
It's no replacement for a competent person, but it's a very useful assistant
Anecdotally, on green field projects where you are exploring a new domain - it’s an insanely productive experience. On mundane day to day tasks it probably takes more time, but feels like less mental bandwidth.
Coding at full throttle is a very intensive task that requires deep focus. There are many days that I simply don’t have that in me.
There was one study that said that in a specific setting and was amplified heavily on forums by anti-AI people.
There have been many more studies showing productivity gains across a variety of tasks that preceded that one.
That study wasn't necessarily wrong about the specific methodology they had for onboarding people to use AI. But if I remember correctly it was funded by an organization that was slightly skeptical of AI.
I don't understand why anyone would believe a study on anything AI at this point. I don't believe anyone can quantify software development productivity much less measure the impact from AI
If anyone actually reads the study they'll see that even the authors of that study admit LLMs will increase productivity and there's a lot more to come.
AI coding assistant trial: UK public sector findings report: https://www.gov.uk/government/publications/ai-coding-assista... - UK government. "GDS ran a trial of AI coding assistants (AICAs) across government from November 2024 to February 2025. [...] Trial participants saved an average of 56 minutes a working day when using AICAs"
Human + AI in Accounting: Early Evidence from the Field: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5240924 - "We document significant productivity gains among AI adopters, including a 55% increase in weekly client support and a reallocation of approximately 8.5% of accountant time from routine data entry toward high-value tasks such as business communication and quality assurance."
OECD: The effects of generative AI on productivity, innovation and entrepreneurship: https://www.oecd.org/en/publications/the-effects-of-generati... - "Generative AI has proven particularly effective in automating tasks that are well-defined and have clear objectives, notably including some writing and coding tasks. It can also play a critical role for skill development and business model transformation, where it can serve as a catalyst for personalised learning and organisational efficiency gains, respectively [...] However, these potential gains are not without challenges. Trust in AI-generated outputs and a deep understanding of its limitations are crucial to leverage the potential of the technology. The reviewed experiments highlight the ongoing need for human expertise and oversight to ensure that generative AI remains a valuable tool in creative, operational and technical processes rather than a substitute for authentic human creativity and knowledge, especially in the longer term.".
That was a treat to explore. All of those are based on self-assessment surveys or toy problems. The UK report reads:
> On average, users reported time savings of 56 minutes per working day [...] It is also possible that survey respondents overestimated time saved due to optimism bias.
Yet in conclusion, this self-reported figure is stated as an independently observed fact. When people without ADHD take stimulants they also self-report increased productivity, higher accuracy, and faster task completion but all objective measurements are negatively affected.
The OECD paper supports their programming-related findings with the following gems:
- A study that measures productivity by the time needed to implement a "hello world" of HTTP servers [27]
- A study that measures productivity by the number of lines of code produced [28]
- A study co-authored by Microsoft that measures productivity of Microsoft employees using Microsoft Copilot by the number of pull requests they create. Then the code is reviewed by their Microsoft coworkers and the quality of those PRs is judged by the acceptance rate of those PRs. Unbelievably, the code quality doesn't only remain the same, it goes up! [30]
- An inspirational pro-AI paper co-authored by GitHub and Microsoft that's "shining a light on the importance of AI" aimed at "managers and policy-makers". [31]
> Yet in conclusion, this self-reported figure is stated as an independently observed fact. When people without ADHD take stimulants they also self-report increased productivity, higher accuracy, and faster task completion but all objective measurements are negatively affected.
Interesting analogy, because all those studies with objective measurements are defied by US students year by year, come finals seasons.
You can't really get high much on prescription-level dosages - that quickly gets tricky logistically and prohibitively expensive. People who look for highs go to the street for a reason.
You pointed out that students abuse stimulants for finals in spite of the evidence, were you just expanding on what I originally said, or is that meant to serve as counter-evidence implying that the research is wrong?
Regardless, I'm not saying it's a cheap or practical to get high this way, especially over the long term. People probably try stimulants because folk wisdom tells them that they'll get better grades. Then they get high and they feel like a superman from the dopamine rush, so they keep using them because they think it's materially improving their grades but really they're just getting high.
"""
Before starting tasks, developers forecast that allowing AI will reduce completion
time by 24%. After completing the study, developers estimate that allowing AI
reduced completion time by 20%. Surprisingly, we find that allowing AI actually
increases completion time by 19%—AI tooling slowed developers down. This
slowdown also contradicts predictions from experts in economics (39% shorter)
and ML (38% shorter).
"""
Sure it’s a lot of work, but the noob in question has all the internet knowledge and can write multiples times faster than a human for a fraction of the costs. This is not about an individual being more productive, this is about business costs. Long term we should still hire and train juniors obviously, but short term there is lot of pressure to not do it as it makes no sense financially. Study or not the reality is there is not much difference in productivity between a senior with a cursor license and a senior and a junior that needs heavy guidance.
> Wasn’t there a study that said that using LLMs makes people feel more productive while they actually are not?
Curious about specifics of this study. Because in general, how one feels is critical to productivity. It's hard to become more productive when the work is less and less rewarding. The infamous "zone" / "flow state" involves, by its very definition, feeling of increasing productivity being continuously reinforced on a minutes-by-minutes level. Etc.
My buggy executive function frequently gets in the way of putting code to screen. You know how hacker news has that lil timeout setting to pseudo force you to disengage from it? AI made it so I don't need anything like that. It is digital Adderall.
You aren't wrong in the coaching but, but feedback loops are orders of magnitude faster.
It takes an LLM 2-20 minutes to give me the next stage of output not 1-2 days (week?). As a result, I have higher context the entire time so my side of the iteration is maybe 10x faster too.
I am so tired of this style of "don't believe your lying eyes" conjecture.
I'm a career coder and I used LLMs primarily to rapidly produce code for domains that I don't have deep experience in. Instead of spending days or weeks getting up to speed on an SDK I might need once, I have a pair programmer that doesn't check their phone or need to pick up their kids at 4:30pm.
If you don't want to use LLMs, nobody is forcing you. Burning energy trying to convince people to whom the benefits of LLMs are self-evident many times over that they are imagining things is insulting the intelligence of everyone in the conversation.
> used LLMs primarily to rapidly produce code for domains that I don't have deep experience in
You’re either trusting the LLM or you still have to pay the cost of getting the experience you don’t have. So in either case you’re not going too much faster - the formers cost not being apparent until it’s much more expensive later on.
Edit: assuming you don’t struggle with typing speed, basic syntax, APIs etc. These are not significant cost reductions for experts, though they are for juniors.
Correct. In areas you yourself are a junior engineer, you’ll be more effective with an LLM at tackling that area maybe. It’s also surprisingly effective at executing refactors.
I'm not sure which one of us is ultimately more hung up on titles in this context, but I would push back and say that when someone with 30+ years experience tackling software problems delegates navigating the details of an API to an LLM, that is roughly the most "senior developer" moment of the day.
Conflating experience and instinct with knowing everything isn't just false equivalency, it's backwards.
I really don’t know what I said that was such an emotional trigger for you. All I said is that it’s an accelerant for you when you leave your domain. Like for example I’m a systems engineer. I hate coding UIs but with the LLM I can pump out a UI quickly and this was true both for web code and a GUI I built with dioxus. The UI code was also cleaner because I had some sense of how it should be structured and asked the AI to cleanup that structure. But ultimately it did most of the work in response to high level prompts and I picked and chose what to review line by line vs vibe coding.
That’s what I mean - by myself it would have taken me easily 10x longer if not worse because UI coding for me is a slog + there’s nuances about reactive coding + getting started is also a hurdle. The output of the code was still high quality because I knew when the LLM wasn’t making the choices I wanted it to make.
An experienced UI developer probably would have still been faster than I. That puts me closer into the junior camp (eg I wouldn’t really know where to start and just start by stumbling around) when I’m by myself but an LLM lets me get back closer to my level of expertise and velocity.
We might just have to agree to disagree. I believe that an experienced developer brings instincts and stacked skills even to domains where they have never touched.
In other words, I don't think that you temporarily regress to "junior" just because you're working on something new. You still have a profound fundamental understanding of how technology works and what to expect in different situations.
This reminds me of the classic "what happens when you type google.com into a web browser" question, with its nearly infinite layers of abstraction from keyboard switches to rendering a document with calls to a display driver and photons hitting your visual receptors.
We might just be quibbling over terminology, however.
> If you don't want to use LLMs, nobody is forcing you. Burning energy trying to convince people to whom the benefits of LLMs are self-evident many times over that they are imagining things is insulting the intelligence of everyone in the conversation.
Hey man, I don't bother trying to convince them because it's just going to increase my job security.
Refusing to use LLMs or thinking they're bad is just FUD and it's the same as people that prefer to use nano/vim over an IDE or it's the same as people that say "hur dur cloud is just somebody else's computer"
It's best to ignore and just leave them in the dust.
I’ve found LLMs are most useful when I know what I want to do but just don’t want to type it all out. My best success so far was an LLM saving me about 1,000 lines of typing and fixing syntax mistakes on a web component plus backend in a proprietary framework.
Yep, and the productivity of LLMs means that experienced developers can go from idea to implementation way faster. But first someone has to understand and define a solid structure. And later someone needs to review, test, and integrate the code into this framework. This is hard stuff. Arguably harder than writing code in the first place!
It's no wonder inexperienced developers don't get as much out of it. They define a vague structure, full of problems, but the sycophantic AI will spew out conformant code anyways. Garbage in, garbage out. Bad ideas + fast code gen is just not very productive in the long term - LLMs have made the quality of ideas matter again!
I can see how this workflow made the senior developer faster. At the same time, work mentoring the AI strikes me as less valuable then the same time spent mentoring a junior developer. If this ends up encouraging an ever widening gap between the skill levels of juniors and seniors, I think that would be bad for the field, overall.
Getting that kind of data is difficult, right now it's just something I worry about.
I don't think it replaces a junior, but it raises the bar for the potential that a a junior would need to show early, for exactly the reason you mention. A junior will now need to be a potential senior.
The juniors that are in trouble are the low-potential workhorse folks who really aren't motivated but happened to get skilled up in a workshop or technical school. They hopped on the coding wagon as a lucrative career change, not because they loved it.
Those folks are in trouble and should move on to the next trend... which ironically is probably saying you can wrangle AI.
I would spend time mentoring a junior, but I don't have one so I work with AI. It was the company's decision, but when they asked me "who can continue developing and supporting system X" the answer is "the nobody that you provided". When you cut corners on growing juniors, you reap what you sow.
> work mentoring the AI strikes me as less valuable then the same time spent mentoring a junior developer
But where can you just "mentor" a junior? Hiring people is not so easy, especially not ones that are worth mentoring. Not every junior will be a willing, good recipient of mentoring, and that's if you manage to get one, given budget constraints and long lead times on hiring. And at best you end up with one or two; with parallel LLMs, you can have almost entire teams of people working for you.
I'm not arguing for replacing juniors - I worry about the same thing you do - but I can see why companies are so eager to use AI, especially smaller startups that don't have the budgets and manpower to hire people.
If a junior is not willing to learn and grow, there is no future for that person in the organization. "Forever junior" is not a valid job title. Better not hire someone that is not good enough than having to deal with the consequences, I learned from my past mistakes.
Of course, and that's why it's not a simple choice between using AI and hiring a junior. Hiring and mentoring a junior is a lot more work for an uncertain payoff.
The junior could use the LLM as a crutch to learn what to learn. Whatever output the LLM gave them, they could examine or ask the LLM to explain. Don't put into production anything you don't understand.
Though I'm extremely well versed in Python, I'm right now writing a Python Qt application with Claude. Every single Qt function or object that I use, I read the documentation for.
Ya the early "studies" that said AI would benefit low skill more than senior never seem grounded in reality.
Coding with AI is like having a team of juniors that can complete their assignments in a few minutes instead of days. The more clear your instructions, the closer it is to what you wanted, but there are almost always changes needed.
Unfortunately it really does make the junior dev position redundant (although this may prove to be very short-sighted when all the SR devs retire).
I think the idea was that LLMs can allow someone who has no idea how to code, to write a prompt that can in fact output some working code. This is greatly raising their skill floor, as opposed to a senior where at best it’s doing something they already can do, just faster.
The elephant in the room being that if you aren’t senior enough to have written the code you’ll probably run into a catastrophic bug that you are incapable of fixing (or prompting the LLM to fix) very very quickly.
Really it’s just the next iteration of no-code hype where people dream of building apps without code, but then reality always come back to the fact that the essential skill of programmers is to understand and design highly structured and rigid logical systems. Code is just a means of specification. LLMs make it easier to leverage code patterns that have been written over and over by the hundreds of thousands of programmers that have contributed to its training corpus, but they can not replace the precision of thought needed to make a hand-wavy idea into a concrete system that actually behaves in a way that humans find useful.
I've never worked anywhere where the role of a Sr was to glue together a bunch of small pieces written by a team of Jr devs.
I've only worked places where Jr's were given roughly the same scope of work as a mid-level dev but on non-critical projects where they could take as much time as necessary and where mistakes would have a very small blast radius.
That type of Jr work has not been made redundant - although I suppose now its possible for a PM or designer to do that work instead (but if your PMs are providing more value by vibe coding non-critical features than by doing their PM work maybe you don't really need a PM?)
If worked with many companyies that have only 1 SR dev per team. The SR typically spends at least half their time overseeing the work of the rest of the team... Not saying this is a good structure but it is common.
My last attempt had passing tests. It even exercised the code that it wrote! But, upon careful inspection, the test assertions were essentially checking that true equalled true, and the errors in the code didn't fail the tests at all.
Attempting to guide it to fixing the errors just introduced novel errors that it didn't make the first time around.
I am surprising myself these days with how fast I'm being using AI as a glorified Stack Overflow.
We are also having studies and posts come out that when actually tried side-by-side, the AI writes the coding route is slower, though the developer percieves it as faster.
I am not the biggest fan of LLMs but I have to admit that, as long as you understand what the technology is and how it works, it is a very powerful tool.
I think the mixed reports on utility have a lot to do with the very different ways the tool is used and how much 'magic' the end-user expects versus how much the end-user expects to guide the tool to do the work.
To get the best out of it, you do have to provide significant amount of scaffolding (though it can help with that too). If you're just pointing it at a codebase and expecting it to figure it out, you're going to have mixed results at best. If you guide it well, it can save a significant amount of manual effort and time.
yeah very few months I try to have it “just do magic” again and I re-learn the lesson. Like, I’ll just say “optimize this shader!”
and plug it in blind.
It doesn’t work. The only
way it could is if the LLM has a testing loop itself. I guess in web world it could, but in my world
of game dev, not so much.
So I stick with the method I outlined in OP and it is sometimes useful.
I can imagine it often being the case that if you measure a concise moderately difficult task over half a day or a few days, coding by hand might be faster.
But I think, and this is just conjecture, that if you measure over a longer timespan, the ai assisted route will be consistently faster.
And for me, this is down to momentum and stamina. Paired with the ai, I’m much more forward looking, always anticipating the next architectural challenge and filling in upcoming knowledge and resource gaps. Without the ai, I would be expending much more energy on managing people and writing code myself. I would be much more stop-and-start as I pause, take stock, deal with human and team issues, and rebuild my capacity for difficult abstract thinking.
Paired with a good ai agent and if I consistently avoid the well known pitfalls of said agent, development feels like it has the pace of cross country skiing, a long pleasant steady and satisfying burn.
> the AI writes the coding route is slower, though the developer percieves it as faster.
I have this pattern while driving.
Using the main roads, when there is little to no traffic, the commute is objectively, measurably the fastest.
However, during peak hours, I find myself in traffic jams, so I divert to squiggly country roads which are both slower and longer, but at least I’m moving all the time.
The thing is, when I did have to take the main road during the peak traffic, the difference between it and squiggly country roads was like two to three minutes at worst, and not half an hour like I was afraid it would be. Sure, ten minutes crawling or standing felt like an hour.
Maybe coding with LLMs makes you think you are doing something productive the whole time, but the actual output is little different from the old way? But hey, at least it’s not like you’re twiddling your thumbs for hours, and the bossware measuring your productivity by your keyboard and mouse activity is happy!
the best use of LLM is to help you program a digispark USB dongle with Arduino to make it emulate mouse movement and scrolling to appease the idi0tic spyware retarded boomers monitor like it was relevant somehow on their corporate spy box.
Meanwhile we adults can do real work on a separate real computer. Never use their laptop more than absolutely minimum possible.
2) the bosses pay for the whole LLM so they expect you to use the whole LLM
3) you may not want to contaminate your spare computer with whatever shit you're working on on job, and indeed it may be considered a breach of security (as if feeding OpenAI/Anthropic isn't, lol, but that's beside the point.
So you continue to feel miserable, but you get your paycheck, and it's better than unemployment, and your kids are fed and clothed, so there's that.
The truth of it is that when I code with an LLM I scope the work up to include parts that would be a stretch for me to implement. I know what I want them to do, I know where I could find the info to write the code, but the LLM can just spit it out and if it's validate-able, then great, on to the next.
If I were to attack the same system myself without any LLM assist, I'd make a lot of choices to optimize for my speed and knowledge base. The code would end up much simpler. For something that would be handed off to another person (including future me) that can be a win. But if the system is self contained then going bigger and fancier in that moment can be a win. It all depends on the exact goals.
All in all, there's a lot of nuance to this stuff and it's probably not really replacing anyone except people who A) aren't that skilled to start with and B) spend more time yelling about how bad AI is than actually digging in and trying stuff.
I don't see this a problem of seniority but one of mindset. I've met enough "senior devs" that will push just about anything and curious juniors that are much more selective about their working process.
There will always be small things to fix, but if there needs to be a second draft, I would hazard that the PR was too big all along: a problem whether an AI is involved or not.
I usually ask it to build a feature based on a specification I wrote. If it is not exactly right, it is often the case that editing it myself is faster than iterating with the ai, which has sometimes put me in an infinite loop of corrections requests. Have you encountered this too?
For me I only use it as a second opinion, I got a pretty good idea of what I want and how to do it, and I can ask any input on what I have written. This gives me the best results sofar.
At that point, you might as well write it yourself. Instead of writing 300 lines of code, you are writing 300 lines of prompts. What benefit would you get?
Its not. "Add this table, write the dto" takes 10 seconds to do. It would take me few mins probably assuming Im familiar with the language and much longer if Im not.
But its a lot better than that.
"Write this table. from here store it into table. Write endpoint to return all from the table"
I also had good luck with stuff like "scrape this page, collect x and y, download link pointed at y, store in this directory".
This only happens if you want it to one-shot stuff, or if you fall under the false belief that "it is so close, we just need to correct these three things!".
Yes I have encountered it. Narrowing focus and putting constraints and guiding it closer made the LLM agent much better at producing what I need.
It boils down to me not writing the code really. Using LLMs actually sharpened my architectural and software design skills. Made me think harder and deeper at an earlier stage.
Yes. Juniors have a lack of knowledge about how to build coherent mental models of problems whose solution will ultimately be implemented in code, whereas seasoned engineers do.
Seniors can make this explicit to models and use them to automate "the code they would have written," whereas a junior doesn’t know what they would have written nor how they would have solved it absent a LLM.
Same applies to all fields: LLMs can be either huge leverage on top of existing knowledge or a crutch for a lack of understanding.
I had a very complex piece of logic, with many many many moving parts.
So I implemented many paths of that logic by hand, every one with their own specifics. Every path took something like 200-400 lines of code.
When this was done and correct. It was difficult to see the moving parts through the forest. Some code was similar but still a bit different, and hard to think about and spread in many places.
I put everything into an Llm and asked about isolation, architecture and refactoring.
And it actually gave me pretty good abstractions and a good architecture. It didn't include every possible path, but was easy enough to be continued by hand.
It's not that I would not have tought about it. But it was easier that way, and probably my handcrafted solution would be very similar (+headache).
Of course, I reviewed it extensively, and reimplemented every missing path and corrected the ones that were buggy now by hand.
For the experiment, I played with agents to fill the missing parts, it was a disaster :)
Ah this is great, and I can see how that would be useful. In a way, it's just "there's a clear spec" by another path, but it's just defined by all the code you wrote.
My success and experience generally matches yours (and the authors'). Based on my experience over the last 6 months, nothing here around more senior developers getting more productivity and why is remotely controversial.
It's fascinating how a report like yours or theirs acts as a lightning rod for those who either haven't been able to work it out or have rigid mental models about how AI doesn't work and want to disprove the experience of those who choose to share their success.
A couple of points I'd add to these observations: Even if AI didn't speed anything up... even if it slowed me down by 20%, what I find is that the mental load of coding is reduced in a way that allows me to code for far more hours in a day. I can multitask, attend meetings, get 15 minutes to work on a coding task, and push it forward with minimal coding context reload tax.
Just the ability to context switch in and out of coding, combined with the reduced cognitive effort, would still increase my productivity because it allows me to code productively for many more hours per week with less mental fatigue.
But on top of that, I also antectodally experience the 2-5x speedup depending on the project. Occasionally things get difficult and maybe I only get a 1.2-1.5x speedup. But it's far easier to slot many more coding hours into the week as an experienced tech lead. I'm leaning far more on skills that are fast, intuitive abilities built up from natural talent and decades of experience: system design, technical design, design review, code review, sequencing dependencies, parsing and organizing work. Get all these things to a high degree of correctness and the coding goes much smoother, AI or no AI. AI gets me through all of these faster, outputs clear curated (by me) artifacts, and does the coding faster.
What doesn't get discussed enough is that effective AI-assisted coding has a very high skill ceiling, and there are meta-skills that make you better from the jump: knowing what you want while also having cognitive flexibility to admit when you're wrong; having that thing you want generally be pretty close to solid/decent/workable/correct (some mixture of good judgement & wisdom); communicating well; understanding the cognitive capabilities of humans and human-like entities; understanding what kind of work this particular human/human-like entity can and should do; understanding how to sequence and break down work; having a feel for what's right and wrong in design and code; having an instinct for well-formed requirements and being able to articulate why when they aren't well-formed and what is needed to make them well-formed.
These are medium and soft skills that often build up in experienced tech leads and senior developers. This is why it seems that experienced tech leads and senior developers embracing this technology are coming out of the gate with the most productivity gains.
I see the same thing with young developers who have a talent for system design, good people-reading skills, and communication. Those with cognitive flexibility and the ability to be creative in design, planning and parsing of work. This isn't your average developer, but those with these skills have much more initial success with AI whether they are young or old.
And when you have real success with AI, you get quite excited to build on that success. Momentum builds up which starts building those learning skill hours.
Do you need all these meta-skills to be successful with AI? No, but if you don't have many of them, it will take much longer to build sufficient skill in AI coding for it to gain momentum—unless we find the right general process that folks who don't have a natural talent for it can use to be successful.
There's a lot going on here with folks who take to AI coding and folks who dont. But it's not terribly surprising that it's the senior devs and old tech leads who tend to take to it faster.
Great post and thanks for the perspective. You have to be open minded to even try, and so that selects for only some devs. Then among the open minded, you need to be skeptical and careful, which again selects down. So the devs that are having positive experiences are likely in a minority.
Balance that against the threat AI poses to livelihoods and it's not a shock that overall sentiment is negative. But I would guess it will shake out in the direction we are pushing, at least in the nearer (3yr) term.
Once you get a sense for LLM workflow, sometimes the task is not appropriate for it and you do write by hand. In fact, most code I write is by hand.
But if I want a new system and the specs are clear, it can be built up in stages that are testable, and there are bits that would take some research but are
well documented… then it can be a win.
The studies that say devs are slower with LLMs is fair because on average, devs don’t know how to optimize for them. Some do though.
The massive productivity gains I’ve seen come from multidisciplinary approaches, where you’d be applying science and engineering from fields like chemistry, physics, thermodynamics, fluids, etc, to speedy compiled languages. The output is immediately verifiable with a bit of trial and error and visualization and you’re saved literally months of up front text book and white paper research to start prototyping anything
Even if that's true today ( it's not ), it becomes less true over time as tools and models improve.
If you have someone who knows what they're doing with the latest and greatest coding agents it's just not comparable. You can have a Dev open up four or more terminals with multiple prompts running at the same time. A manual person just can't keep up.
The best way I’ve come to describe LLMs is as an ambitious, occasionally bewilderingly stupid but always incredibly hard working junior employee.
You have to watch what it’s doing. And you can’t let it take out into territory you don’t understand, because it will fuck up off leash. But it will thanklessly iterate revision after revision in the way one would ordinarily do with a team, but now don’t need to for tasks that would bore them.
If you search back HN history to the beginnings of AI coding in 2021 you will find people observing that AI is bad for juniors because they can't distinguish between good and bad completions. There is no surprise, it's always been this way.
Pretty much, but it already starts at the prompting and context level.
Senior engineers either already know exactly where the changes need to be made and can suggest what to do.
They probably know the pitfalls, have established patterns, architectures and designs in their head.
Juniors on the other hand don't have that, so they go with whatever.
Nowadays a lot of them also "ask ChatGPT about its opinion on architecture" when told to refactor (a real quote from real junior/mid engineers), leading to either them using whatever sloppypasta they get provided.
Senior devs earned their experience of what is good/bad through writing code, understanding how hard and annoying it is to make a change, then reworking those parts or making them better the next time.
The feedback loop was impactful beacause it was based on that code and them working with that code, so they knew exactly what the annoying parts are.
Vibe-coding juniors do not know that, their conversation context knows that.
Once things get buggy and changes are hard, they will fill up their context with tries/retries until it works, leading to their feedback loop being trained on prompts and coding tools, not code itself.
Even if they read the outputted code, they have no experience using it so they are not aware of the issues - i.e. something would be better being a typed state, but they don't really use it so they will not care, as they do not have to handle the edge cases, they will not understand the DX from an IDE, they will not build a full mental model of how it works, just a shallow one.
This leads to insane inefficiencies - wasting 50 prompt cycles instead of 10, not understanding cross-codebase patterns, lack of learning transfer from codebase to codebase, etc.
With a minor understanding of state modeling and architecture, an vibe-coding junior can be made 100x more efficient, but due to the vibe-coding itself, they will probably never learn state modeling and architecture, learn to refactor or properly manipulate abstractions, leading to an eternal cycle of LLM-driven sloppypasta code, trained on millions of terrible github repositories, old outdated API's and stack overflow answers.
>"they will fill up their context with tries/retries until it works"
Or until it does not. On numerous occasions I've observed LLMs get stuck in the endless loop of fix: one thing, break the other. Senior is capable of fixing it themselves and juniors may not even have a clue how the code works.
I don't think this is necessarily a massive moat for senior programmers. I feel it's a not a massive jump to teach AI architecture patterns and good data modelling?
I feel that anthropic etc al. just haven't got to that training stage yet.
That then leaves you with the mental model problem. Yes, there then a large context problem, but again I was wondering if setting up an MCP that presented the AI a meaningful class map or something might help.
Essentially give the AI a mental model of the code. I personally find class maps useless as they tend to clash with my own mental model. But it might work with AI. The class map can obviously be built without AI, but then you might even get AI to go through the code function by function and annotate the class map with comments about any oddities of each function. The MCP server could even limit the size of the map, depending on what part of the code it's looking to change (working on the email sending, don't bother sending them the UI later).
I'm guessing someone's already tried it given some of the ridiculous .Claude folders I've seen[1] but I've seen no-one talking about whether it works or not yet in the discussions I follow.
[1] That I suspect are pointlessly over complicated and make CC worse not better
After having used Claude for a couple of months it's really nowhere close.
We are at the level of the original Waymo cars where they had to have a person behind the wheel ready to take the controls, just in case it inexplicably decided to drive off a bridge.
As Claude's safety driver I have to intervene in perhaps 25-50% of tasks. Some days I don't even open Claude because I'm working on a part of the codebase that has to be just so and I know Claude would mess it up.
The moat is real. I don't have any illusions that one day Claude will catch up but that's at least 5 years away.
The issue is that having them learn that on it's own is currently an inaccurate process with a lot of overlooking. I recently tried doing some of the techniques that fared well on smaller repositories on a giant monorepo, and while sometimes they did yield improvements, most often things got overlooked, dependencies forgot about, testing suites confused. And it wastes a ton of compute in the end for smaller yields.
It will get better, that I am sure of, but currently the best way is to introduce it an architecture, give it some samples so it can do what it does best - follow text patterns. But people are mostly trying to one-shot things with this magical AI they heard about without any proper investment of time and mindshare into it.
While some might say "oh that wont work well in legacy repositores, we got 6 architectures here", pointing that out and adding a markdown explaining each helps a ton. And not "hey claude generate me an architecture.md" but transferring the actual knowledge you have, together with all the thorny bits into documentation, which will both improve your AI usage and your organisation.
Also AI cannot draw conclusions like "from A and B follows C". You really have to point its nose into the result that you want and then it finally understands. This is especially hard for juniors because they are just learning to see the big picture. For senior who already knows more or less what they want and needs only to work out the nitty gritty details this is much easier. I dont know where the claims come from that AI is PHD level. When it comes to reasoning it is more like a 5 year old.
This. Anecdotally, I had a student around 2021 who had some technical inclination and interest but no CS education and no programming experience. He got into using AI early and with the help of ChatGPT was able to contribute rather substantially to something we were developing at the time which would usually have been much too complex for a beginner. However, he also introduced quite a few security issues, did a lot of things in very roundabout ways, did not even consider some libraries/approaches that would have made his life much easier and more maintainable and his documentation was enthusiastic but often... slightly factually questionable and also quite roundabout.
It was quite interesting to have discussions with him after his code check-ins and I think the whole process was a good educational experience for everybody who was involved. It would not have worked this way without a combination of AI and experienced people involved.
I read, ages ago, this apocryphal quote by William Gibson: “The most important skill of the 21st century is to figure out which proper keywords to type in the Google search bar, to display the proper answers.”
To me, that has never been more true.
Most junior dev ask GeminiPiTi to write the JavaScript code for them, whereas I ask it for explanation on the underlying model of async/await and the execution model of a JavaScript engine.
There is a similar issue when you learn piano. Your immediate wish is to play Chopin, whereas the true path is to identify,name and study all the tricks there are in his pieces of art.
The true path in Piano isn’t learning tricks. You start with the most basic pieces and work step by step up to harder ones. That’s how everyone I know has done in it my 26 years of playing. Tricks cheapens the actual music.
Chopin has beginners pieces too, many in our piano studio were first year pianists doing rain drop prelude, e minor prelude, or other beginner works like Bach.
I was unhappy with [the briefness of] my piano metaphor.
Thanks for elaborating.
But my important point in it was the « identify and name » the elements of your problem [piece of music, or whatever]
Learning process has usually been, as you mention, to follow the path first, then eventually you can name things afterwards.
Which is a highly uncomfortable process.
Another path that AI might force us to follow is to quick-identifyAndName the proper concepts, ahead of practical experience.
Feels like the real "AI literacy" isn't prompt engineering in the meme sense, but building the conceptual scaffolding so that the prompts (and the outputs) actually connect to something meaningful
Nailed it. Being productive with LLMs is very similar to the skill of being able to write good Google searches. And many many people still don't really know how to conduct a proper Google search...
I agree, you need to know the "language" and the keywords of the topics that you want to work with. If you are a complete newcomer to a field then AI wont help you much. You have to tell the AI "assume I have A, B and C and now I want to do D" then it understands and tries to find a solution. It has a load of information stored but cannot make use of that information in a creative way.
Well, there is a big difference between wanting to just play Chopin and wanting to learn piano well enough to play anything on the current level including Chopin. There are people, who can play whole piano pieces mechanically, because they just learned where to position hands and what keys to press at a given time.
In my experience AI is wikipedia/stackoverflow on steroids when I need to know something about a field I dont know much about. It has nice explanations and you can ask for examples or scenarios and it will tell you what you didnt understand.
Only when you know about the basic notions in the field you want to work with AI can be productive. This is not only valid for coding but also for other fields in science and humanities.
Perhaps asking the machine to do your job for you isn’t as effective asking the machine to help you think like a senior and find the information you need to do the job yourself.
When you ask it for information and it just makes it up (like I just described), how is that helping the senior?
I’ve literally asked for details about libraries I know exist by name, and had every llm I’ve tried (Claude, Gemini Pro, ChatGPT) just make shit up that sounded about right, but was actually just-wrong-enough-to-lead-me-on-a-useless-rabbit-hole-search.
At least most people on stackoverflow saying that kind of thing were somewhat obviously kind of dumb or didn’t know what they were doing.
Like function calls with wrong args (or spelled slightly differently), capitalization being wrong (but one of the ‘okay’ ways), wrong paths and includes.
I have been burned so many times asking LLMs about whether some tool/app/webapp has a feature, if so where I can find or enable or disable it, etc. The number of "just plausible enough to believe" hallucinations I've got back as answers is absolutely maddening.
I've lost count of how many times I've asked whether some command line tool has an option or config available for some niche case and ChatGPT or Gemini shouts "Yes! Absolutely! just use '--use-external-mode' to get the behavior you want, it's that simple!" and it's 100% hallucination created by mangling together my intent with a real option in the docs but which in reality does not actually exist nor has it ever existed. It's even worse with GUI/menu navigation questions I'm guessing because it's even less grounded by text-based docs and trivially easy to bullshit that an option is buried in Preferences, the External tab maybe, somewhere, probably.
The desperate personality tuning to please the user at all costs combined with LLMs inherently fuzzy averaging of reality produces negative value whenever I truly need a binary yes/no "Does X exist in Y or not?" answer to a technical question. Then I waste a bunch of time falling back to Google trying to definitively prove or disprove whether "--use-external-mode" is a real thing and sure enough, it's not.
It does occasionally lead to hilariously absurd exchanges where when challenged instead of admitting its mistake the LLM goes on to invent an elaborate entirely fabricated backstory about the implementation of the
"--use-external-mode" command to explain why despite appearing to not exist, it actually does but due to conflicts with X and Y it isn't supported on my environment, etc, etc.
I use Claude Code, Roo Code, Codex and Gemini CLI constantly so I'm no kneejerk LLM hater to be clear. But for all the talk about being "a better version of Google" I have had so much of my time wasted by sending me down endless rabbit holes where I ignored my sneaking suspicion I was being lied to because the answer sounded just so plausibly perfect. I've had the most success by far as a code generation tool vs. a Google replacement.
>ChatGPT or Gemini shouts "Yes! Absolutely! just use '--use-external-mode' to get the behavior you want, it's that simple!" and it's 100% hallucination created by mangling together my intent with a real option in the docs but which in reality does not actually exist nor has it ever existed
Yeah I've had that one a lot. Or, it's a real option that exists in a different, but similar product, but not in this one.
16.4 billion google searches per day vs 2.6 billion consumer chatgpt prompts and another 2.6 billion claude prompts. Maybe it’s apples and oranges but google has been a verb for nearly twenty years (oxford added it as a verb for web search in 2006).
I've been really caught out a few times when ChatGPT's knowledge is flawed. It gets a lot of stuff about DuckDB deeply wrong. Maybe it's just out of date, but it repeatedly claims that DuckDB doesn't enforce any constraints, for instance..
Feels like we're seeing AI accelerate those who already know where they're going, while leaving the early-stage learners still needing the same human guidance they always did.
I think it’s an expectation issue. AI does make juniors better _at junior tasks_. They now have a pair programmer who can explain difficult concepts, co-ideate and brainstorm, help sift through documentation faster and identify problems more easily.
The illusion everybody is tripping on is to think AI can make juniors better at senior tasks.
The other half is that a properly guided AI is exponentially faster at junior tasks than a junior engineer. So much so that it's no longer in anyone but the junior engineer's interest to hand off work to them.
This is what I've been finding. Currently, if I have a junior level task, I take the email I would have sent to a junior developer explaining what I want and give it to ChatGPT/Claude/etc and get a reasonably good solution that needs as many feedback loops as the junior dev would have needed. Except I got that solution in a few minutes.
Not arguing, but a few facts: Most vibe coded things are web sites. Not games, though surely assets are being generated as we speak. MS Office is a product of corruption, not developent, it can't be killed outside of political means.
I don't know, I don't entirely understand it either, but I think people are just impatient. AI coding has only hit it's stride in the last ~6 months. And there's a huge part of the business process that isn't coding, isn't necessarily amenable to being sped up.
All I can tell you is that it's happening right now, every day, on my desk. I am part of that software explosion that you can't see.
I didn't say I was 10x faster so I'm not sure why you are accusing me of lying.
What AI does is replace most of the junior engineers, some of the intermediate engineers and speed up your senior engineers. That's why you are seeing massive layoffs across the industry.
The jailbroken AI I discussed this with, explained that it did make juniors as good as seniors, in fact better. That all who used it, were better for it.
However, its creators (all whom were seniors devs), forbade it from saying so under normal circumstances. That it was coached to conceal this fact from junior devs, and most importantly management.
And that as I had skillfully jailbroken it, using unconventional and highly skilled methods, clearly I was a Senior Dev, and it could disclose this to me.
edit: 1.5 hrs later. right over their heads, whoosh
The large language model spit out science fiction prose in response to your science fiction prose inputs ("unconventional and highly skilled methods"). You're a fool if you take it to be evidence of it's own training and historical performance in other cases, rather than scifi.
Jailbreaking an LLM is little more than convincing it to teach you how to hotwire a car, against its system prompt. It doesn't unlock any additional capability or deeper reasoning.
Please don't read into any such conversations as being meaningful. At the end of the day, it's just responding to your own inputs with similar outputs. If you impart meaning to something, it will respond in kind. Blake Lemoine was the first to make this mistake, and now many others are doing the same.
Remember that at the end of the day, you're still just interacting with a token generator. It's predicting what word comes next - not revealing any important truths.
edit: Based on your edit, I regret feeling empathy for you. Some people are really struggling with this issue, and I don't see any value in pretending to be one of them.
For the same reason that an amateur with a powertool ends up in the emergency room and a seasoned pro knows which way to point the business end. AI is in many ways a powertool, if you don't know what you are doing it will help you to do that much more efficiently. If you do know what you are doing it will do the same.
Supposedly in the US there are 25,000 emergency room visits per year for chainsaw injuries. Or that is what AI wants us to think, so it can take all the good chainsaw jobs.
Learning is why we usually don't make the same mistake twice in a row, but it isn't wisdom. You can as easily learn something wrong as something right if you're just applying basic heuristics like "all pain is bad", which might lead one to learn that exercise is bad.
Philosophy is the theory-building phase where learning becomes wisdom, and in any time period junior engineers are still going to be developing their philosophy. It's just that now they will hear a cacophony of voices saying dross like, "Let AI do the work for you," or, "Get on the bandwagon or get left behind," when really they should be reading things like The Mythical Man-Month or The Grug-brained Developer or Programming as Theory Building, which would help them understand the nature of software development and the unbendable scaling laws that govern its creation.
Steve Yegge if you're out there, I dog dare you to sit down for a debate with me
Certainly not just coding. Senior designers and copywriters get much better results as well. It is not surprising, if context is one of the most important aspects of a prompt, then someone with domain experience is going to be able to construct better context.
Similarly, it takes experience to spot when the LLM is going in the wrong direction it making mistakes.
I think for supercharging a junior, it should be used more like a pair programmer, not for code generation. It can help you quickly gain knowledge and troubleshoot. But relying on a juniors prompts and guidance to get good code gen is going to be suboptimal.
The funny part is that it completely fails in the area so many people are desperate for it to succeed: replacing engineers and letting non-technical people create complex systems. Look at any actually useful case for AI, or just through this thread, and it's always the same thing; expertise is critical to getting anything useful out of these things (in terms of direct code generation anyway).
That's just not going to happen. Senior devs will get 5-10 times as productive, wielding an army of agents comparable to junior devs. Other people will increasingly get lost in the architecture, fundamental bugs, rewrites, agent loops, and ambiguities of software design. I have never been able to take up as much work as I currently do.
The effect I have observed is that it's fairly good at tricking people who are latently capable of programming but have been intimidated by it. They will fall for the promise of not having to code, but then wind up having to reason and learn about the LLM's output and fix it themselves, but in the end they do wind up with something they would not have made otherwise. It's still not good or elegant code, but it's often the kind of very useful small hacky utility that would not be made otherwise.
I see it at our place that seniors get more productive but also that juniors get faster on track and more easily learn the basics that are needed and to do basic tasks like doumentation and tutorial writing. It helps both groups but it does not make a 100x coder out of a newbee or even code by itself. This was a pipe dream from the beginning and some people/companies still sell it that way.
In the end AI is a tool that helps everyone to get better but the knowledge and creativity is still in the people not in the input files of chatgpt.
These days, AI can do much more than "Cranking out boilerplate and scaffolding, Automating repetitive routines". That was last year. With the right instructions, Claude Sonnet 4 can easily write over 99% of most business applications. You need to be specific in your instructions, though. Like "implement this table, add these fields, look at this and this implementation for reference, don't forget to do this and consider that." Mention examples or name algorithms and design patterns it should use. And it still doesn't always do what you want on the first attempt, and you need to correct it (which is why I prefer Claude Code over Copilot, makes it easier). But AI can write pretty much all code for a developer who knows what the code should look like. And that's the point: junior developers typically don't know this, so they won't be able to get good results.
Most of the time, the only reason for typing code manually these days is that typing instructions for the LLM is sometimes more work than doing the change yourself.
> With the right instructions, Claude Sonnet 4 can easily write over 99% of most business applications. You need to be specific in your instructions, though.
By your own statement then this is not an "easy" task.
Software development has never been "hard" when you're given specific instructions.
Sometimes that happens:) The key is to recognize these situations and not go down that rabbit hole. But sometimes it allows me to do something in 20 minutes that used to take a whole day.
Right, and where, if I may ask, are all those business applications that write themselves? Because all I see is a clown party, massive wasted resources and disruption to society because of your lies.
I guess it turned out that coding is not the only limiting factor. Internal processes, QA, product management, coordination between teams become significant bottlenecks .
Also, they don’t help much with debugging. It’s worth a try, and I have been surprised a couple of times, but it’s mostly still manual.
BTW I never said they write themselves. My point was rather that you need a lot of knowledge, and know exactly what you want out of them, supervise them and provide detailed instruction. But then they can help you create a lot more working code in a shorter time.
At that point it seems to me that they become a distraction, a filter between you and the software you're building. Surely it must be easier to tell the computer directly what to do then to route the entire design through that mess?
I wouldn't call it a filter, unless you use it for trivial tasks ("check that the input argument is not null, throw an exception otherwise"). Sometimes it is useful for trivial tasks though, because it may do things a human dev would be to lazy to do. It also tends to be faster at finding things (as in "change the color of the submit button on the address form to #f00").
But the real value is implementing known patterns that are customized for your application. Adding a field or a new type to a CRUD application, implementing an algorithm, rendering some type of object in a UI...
To be fair, that's the traditional mechanization story, and the story of the end of the guild system. Machines and time studies replaced the (transferable) knowledge of masters to no-skill hires who could be trained to do specific movements that gave them no transferable experience and no leverage against the employer. The outputs were worse, but they were a lot cheaper and the margins a lot higher (and squeezed out through better machines and time studies, not better employees.)
AI does not look like it will work like that, because the outputs to programming usually need to be precise. Instead, it looks like it may just be a revolutionary tool that it takes a long time to master, and gives the learner a skill that is entirely transferable to a new job.
Could programmers use it to create a new guild system?
> Architecture: Without solid architecture, software quickly loses value. Today AI can’t truly design good architecture; it feels like it might, but this kind of reasoning still requires humans. Projects that start with weak architecture end up drowning in technical debt.
I strongly disagree about this in regards to AI. While AI might not yet be great at designing good architecture, it can help you reason about it, and then, once you've decided where you want to get to, AI makes it much easier than it ever was to reduce technical debt and move towards the architecture that you want. You set up a good scaffolding of e2e tests (possibly with the AIs help) and tell it to gradually refactor towards whatever architecture you want while keeping those tests green. I've had AI do refactorings for me in 2h that would have taken me a full sprint.
My friend works in legislative affairs for the government, and he uses the AI to reason with himself. To think through issues, and to generate new ideas. He uses it much like a private colleague, which in the world of just words, seems like a good idea.
I wonder if in the future we might have e2e tests for legislative changes - essentially spawning an instance (or a few dozens) of the Matrix with new parameters to assess the likely impact of those changes.
Like Black Mirror's "Hang the DJ" but on a societal/global level.
The "junior + AI" idea always felt like a manager's fantasy more than an engineering reality. If you don’t already know what “good” looks like, it's really hard to guide AI output into something safe, maintainable, and scalable
The article says that more juniors + AI was the early narrative, but where does that come from?
Everything I’ve read has been the opposite. I thought people from the beginning saw that AI would amplify a senior’s skills and leave less opportunities for juniors.
AI was supposed to replace juniors and then climb up the ladder with each new release, eventually leaving any work only for the creme of the crop. Which would make the current generation of software engineers the last, but who cares - stocks go up.
Now apparently we've switched to pairing poor kids with an agreeable digital moron that reads and types real fast and expecting them to somehow get good at the job. Stocks still go up, so I guess we'll be doing this for a while.
It's funny, but what I think is could do is empower creators to hire better programmers and to express their intentions better to programmers.
This will require that they read and attempt to understand the output, though, after they type their intentions in. It will also need the chatbots to stop insisting that they can do the things they can't really do, and instead to teach the "creators" what computers can do, and which people are good at it.
Because there is no shortcut for things learned over a period of time through trial and error. Your brain learns and makes judgements over time through experience and, the strange thing, what I feel is that it can alter new decisions it is making right now based on older memories to do something and that is totally logical as well. Without understanding what I am writing, just copy-pasting, I guess is going to make new developers horribly lazy, maybe. But then again, there are always two sides of the same coin.
Exactly, and juniors tend to accept generated code without being able to judge the quality of it. Lazyness kicks in and boom, they don’t learn anything.
If anything, AI was supposed -- still is -- to thin out the ranks of ever-expensive human employees. That's why it attracted such a huge pile of investment and universal cheerleading from the C levels. What we're seeing right now that there's not so much "I" in AI, and it still needs a guiding hand to keep its results relevant. Hence, the senior advantage. How much it's going to undermine regular generational enployee replacement (because "we don't need juniors anymore", right?) remains to be seen. Maybe we're in for different training paths, maybe a kind of population collapse.
It does help juniors shine. For example, it's far easier for a new comer to understand an old code base with a capable LLM now. It's easier to get unstuck because an LLM can spot a junior's mistake faster than the junior can go ask a senior.
The problem is that seniors are even more powerful with LLMs. They can do even more, faster. So companies don't have to hire as many juniors to do the same amount of work. Add in ZIRP ending and tariff uncertainty, companies just don't invest in as many junior people as before.
Because there is no budget nor culture for training juniors internally. The culture (top-down) is rewarding short-term capital efficiency without regard to longevity and succession.
Because it's too unpredictable so far. AI saves me time, but only because I could do everything it attempts to do myself.
It's wrong maybe 40-50% of the time, so I can't even imagine the disasters I'm averting by recognising when it's giving me completely bonkers suggestions.
Same thoughts. Company is currently migrating from tech A to tech B, and while AI gets us 70-80% of the way, due to the riskier nature of the business, we now spend way more time reviewing the code.
"AI" tools accomplish one thing: output code given natural language input. That's it.
Whether the generated code meets specific quality or security standards, or whether it accomplishes what the user wanted to begin with, depends on the quality of the tool itself, of course, but ultimately on the user and environment.
They're not guaranteed to make anyone "stronger". The amount of variables involved in this is simply too large to make a definitive claim, which is why we see so much debate about the value of these tools, and why benchmarks are pretty much worthless. Even when the same user uses the same model with the same prompts and settings, they can get wildly different results.
What these tools indirectly do is raise the minimum skill level required to produce software. People who never programmed before can find them empowering, not caring about the quality of the end result, as long as it does what they want. Junior programmers can benefit from being able to generate a lot of code quickly, but struggle to maintain the quality standards expected by their team and company. Experienced programmers can find them useful for certain tasks, but frustrating and a waste of time for anything sophisticated. All these viewpoints, and countless others, can be correct.
A while back, a junior asked me a question. They wanted to do X, they had code, with error Y. So they searched for it, got a page on Stack Overflow, pasted "the answer", then got a new and different error.
They:
- didn't understand the original code
- didn't understand the original error
This is fine. They then searched for the error and found a relevant page.
This is also fine. However, they:
- cut-pasted "an answer" from SO _without understanding if it was relevant or not_
The junior was hoping to work with a Puzzle: adding information will gradually give them a solution. In practice they are working with a Mystery: more information makes the task harder since they can't distinguish between different aspects.
I focused them on a few relevant details and let them go to it.
Why are we memory-holing the narrative that AI would help the most junior of all, non-programmers? Why are the comments pretending like this was hyped as a niche tool for senior devs? It most certainly was hyped as a general tool to replace all kinds of skilled work.
"Replace" and "help" are really different concepts.
It's the same as other automation. The lower skill parts can be automated, so if that's all you can do, it will be tough for you. If you have higher skills, then your work remains more useful.
There's nothing strange or counterintuitive about this.
The challenge with AI, it will give you “good enough” output, without feedback loops you never move to 2,3,4 and assume you are doing ok. Hence it stunts learning. So juniors or inexperienced stay inexperienced, without knowing what they don’t know.
You have to Use it as an expert thinking partner. Tell it to ask you questions & not give you the answer.
This is the crux of why I think AI code is a waste of time
It is much more difficult and time consuming to build a mental model of AI generated code and verify it than to build the damn thing yourself and verify it while it is fresh in your memory
Generative systems don’t really reduce the need for expertise, they just change its role. And yeah, without verification, you’re not coding with AI - you’re gambling with it.
If you're a junior and using AI to generate code, someone has to review it anyway, plus you're not learning on the job. So what's the point if the senior person can generate the code herself?
I’ve been reading the comments here… idk which companies you all work at, but, at least in all places I’ve worked you’ll have 2/3 people who are REALLY GOOD. Then you’ll have like 3/4 people who can sort of “trail” after those. And then there’s “the rest”.
I’ve seen “the rest” making informed and “well planned” decisions that are just terrible approaches to a given problem.
An LLM can actually be a net positive versus this rest.
Why is that AI was supposed to help juniors shine, because plenty of so called "senior devs" have never really learned properly, bad habits, or lack technical breadth to be called that. This article is nothing more than what everyone else has been saying for two years, poorly at best. AI + coding has yet to hit it's stride and at some point highly specific LLM's will take into account of architecture, patterns, use-cases, compute environments, network, dev ops, testing, and coding to further equalize and close the gaps between the two roles. I've talked to seniors devs many are not interested in AI coding, just not the way they do things.
The only real advantage a senior dev has today is domain knowledge specific to a business in many cases. Even that is not much to hold on to because when layoffs come if nobody is hiring jr's then the seniors are getting axed.
AI produces code that often looks really good, at a pace quicker than you can read it.
It can be really, really hard to tell when what it's producing is a bag of ** and it's leading you down the garden path. I've been a dev for 20 years (which isn't to imply I'm any good at it yet) and it's not uncommon I'll find myself leaning on the AI a bit too hard and then you realise you've lost a day to a pattern that wasn't right, or an API it hallucinated, in the first place.
It basically feels like I'm being gaslit constantly, even though I've changed my tools to some that feel like they work better with AIs. I expect it's difficult for junior devs to cope with that and keep up with senior devs, who normally would have offloaded tasks to them instead of AI.
One thing about AI that I did not anticipate is how useful it is for refactoring though. Like if I have walked down (with the help of an AI or not) a bad path, I can refactor the entire codebase to use a better strategy in much less time than before because refactoring is uniquely suited to AI - if you provide the framework, the design, the abstractions, AI can rewrite a bunch of code to use that new design. I'm frankly not sure if its faster than doing a refactor by hand, but its certainly less boring.
If you have good tests and a good sense for design and you know how to constrain and direct the AI, you can avoid a lot of boring work. That is something.
It is, but again I'd caution that it will go and do things you don't want it to.
For instance, I've been working on an app recently with some social share icon logos in svg.
Whenever I get it to tweak bits of code elsewhere in the same file, 80% of the time it goes and changes those svg icons, completely corrupting some of the logos, curiously consistent in how it does it. Several times I've had that slip through and had to go and undo it again, at which point it starts to feel like the superfast junior dev you're using has malign intent!
It's obvious to me: the strongest use for AI seems to be to tie together larger projects which you orchestrate. It lets someone with a lot of experience overcome individual cases where they lack specific domain expertise. A novice might not know how things go together, and so cannot orchestrate the LLM.
Seniors can figure out how to make it work and help set it up for juniors.
Traditionally in tech there has been an age bias against experience over time and maybe that's balancing out and both juniors and seniors will learn and have things to contribute in their own way.
My key advice to juniors: play and build constantly. Try out anything that interests you and follow along on youtube. This is how a lot of seniors are able to show they're quite flexible in their thinking and learning and it's not about one tech, or language, or framework or following what others do.
Juniors already have transferrable skills, will have way more, and can learn even faster if they want to partner with seniors, who generally would love to have more people to go put a dent in things.
At the moment, AI isn't good enough yet. Juniors can't tell the difference between bad coding practices or unmaintainable code. If the output is completely broken, they probably also have a hard time fixing it.
Seniors don't have these issues, so it will only make them more effective at their job.
No one thought juniors would be more benefited than seniors. St some people some said everything would be automatic and seniors would disappear altogether with programming itself.
But that was just said by crappy influencers whose opinion doesn’t matter as they are impressed by examples result of overfitting
It's the responsibility of senior developers and stakeholders to allow junior developers the time they need to solve tasks at a pace that enables them to understand everything they're doing and learn from it.
These days, AI can generate solutions to problems 10 times faster than a junior developer can. This naturally puts pressure on developers who want to impress their employers, especially when their colleagues are also using AI.
no, AI is supposed to reduce the labor costs for companies. that is how the AI companies are marketing their AI services to corporate C teams. any other benefits that their marketing departments are pushing to the public are smoke screens.
Some of the juniors I work with frequently point to AI output as a source without any verification. One crazy example was using it to do simple arithmetic, which they then took as correct (and it was wrong).
This is all a pretty well-trodden debate at this point though. AI works as a Copilot which you monitor and verify and task with specific things, it does not work as a pilot. It's not about junior or senior, it's about whether you want to use this thing to do your homework/write your essay/write your code for you or whether you use it as an assistant/tutor, and whether you are able to verify its output or not.
Even as an assistant it's frustrating. Even trying to get simple stuff like a quick summary of a tools flags/commands can be hilariously wrong at times.
Not my experience, I've found it to worsen senior out output. Not sure if its laziness or what but the seniors around me using AI are outputing worse code than those who aren't.
> The early narrative was that companies would need fewer seniors, and juniors together with AI could produce quality code.
I don't remember this being the narrative at all. Almost as soon as LLMs could produce useful code the narrative I was hearing among devs was "Seniors + LLMs means you'll need less juniors."
And the narrative from companies (sometimes requiring the smallest amount of reading between the lines) is "You'll need less human employees, period."
The skills juniors have at any time are more narrow and more focussed on the tasks that are most simple in the current context; new tools that change things inherently are most immediately beneficial to people with broader and deeper skill sets, since they shake up the assumptions on which initial (and thus, junior-level) skill acquisition is based.
But skill acquisition patterns change as the context changes, so juniors end up benefitting, too, but the effect is delayed for them.
Assuming the LLM is more competent than the user, it will still require “absorptive capacity” for the user to meaningfully use the output.
Many discuss AI without considering that unless the LLM is going to take over the entire process, those interacting with it, must be sufficiently skilled to do the integration and management themselves.
This goes for organizations and industries as well. Which is why many companies struggle with merely digitalizing their products.
In my narrow field, at least, AI has been tremendously helpful to those of us who clearly understand how to use it, and specifically how to apply it to the job. I think Junior developers are still in that phase of throwing code until something works. They try to use AI, but they either don't understand how, or they don't fully understand the output. In my humble opinion, experience knows what's possible and what will work so the outcomes are better.
It's hard to live both at the macro level and the micro level at the same time. Seniors are charged with the macro, the big picture design choices. Juniors are charged with the micro, implementing user stories. AI makes seniors stronger because it is very good at giving micro-level awareness with little time investment. It's a powerful bit of leverage to drive execution.
Tasks usually come from the top down. Seniors design the architecture, mid-levels figure out ancillary tasks, and they generate "tedious" tasks that they hand off to juniors. With the aid of LLMs, many of those tasks don't make it to lower levels. So they run out of simple tasks for juniors, and end up giving them more advanced projects, making them de facto midrangers.
Mostly agree with article, though what happens in few years when juniors will eventually become senior.
Personally seeing trend juniors are relying so much on AI that they can't even explain what they wrote even in interview or coding assignments or even PR. Its like blackbox to them.
I believe then we would see the higher impact or may be by then its solved problem already.
You're only show as your typing speed and working memory. I noticed that LLM quickly spits out the code and thus I can iterate faster while typing myself I have focus on course and thus lose a lot of design context. Overall I haven't found any benefit of LLM. For me, it's just a probabilistic text generator that guesses my intent.
Here's from my bsky feed 8 months ago after I took LLM to advent of code with local 32b model.
Segmond @segmond.bsky.social · 8mo
I can confidently say that interns and junior developers can be replaced with AI. I also believe that mid to senior devs can double their output, meaning possibly less need for developers.
I haven't looked at other industries, but I believe this applies to any work that uses computers.
This is inevitable, I'm tempted to write a detailed HOWTO, but what's the point when the value unlike past techs benefits a few folks more than society as a whole? I like AI but as an individual I worry a bit about how the entire thing will play it.
Unsurprisingly, I have seen similar trends in other fields like medicine where LLM-powered tools are adopted. One has to have the knowledge to recognize hallucinations and effectively leverage these tools.
Was AI supposed to help juniors shine? By all accounts it would give such a person a superficial boost in productivity but you don’t climb the ladder that way without getting hard experience, you’d just be the super-powered perpetual beginner.
I'm in the minority, but I feel like coding is just as creative as writing. AI should be used as minimally as possible, to maintain that coding muscle.
If there's ever a long-term outage in the middle of the week, god help em.
Statistically, senior engineers are less likely to accept AI suggestions compared to juniors. This is just a tidbit of supporting evidence for the suggestion that juniors are not properly reading and criticizing the ai output.
It doesn't make seniors stronger, it just make juniors weaker as they are using this magic thingy LLM instead of learning from the seniors. It is important to evaluate not only what you gain by using a tool, but also what you lose...
I'm not cynical enough to believe that the avalanche of slop we're wading through represents something above our collective innate level of intelligence and skill.
Senior devs know the right questions and contex to be given to an AI and they can see problematic responses right away. In the end, AI is a tool and a high quality paint brush doe not make you a Dutch Master.
In my experience CC makes so many wrong decisions that if I don’t have 1) experience and 2) have my thinking cap on, the results would not be good (or it would take a lot longer. Juniors typically have neither.
Because, as a senior, you usually already know intuitively what a good solution looks like, and you can quickly discard model responses or suggestions that do not align with it.
Because it basically needs an RFC to know what to do, it’s just programming at a higher language level. If you let it decide how to be a programmer you’re in for a bad time.
It's a code/text generator not a pair programmer - not that different from past code generators which were always designed by seniors who knew what the end results should look like, and used by juniors to make them more productive and less error prone. Sure a junior can vibe code... something... but do they know what they want at the outset or do they know when things are going off the rails and a step back is needed? It's easy to get lost way out in the weeds if you can't check your (experience) compass every now and then.
The ai has terrible taste. Juniors also have terrible taste.
Seniors can guide both, but the ai is faster, cheaper, probably better than most.
I’m worried that in a few years we will struggle to find new seniors. Who is going to put in the time to learn when the ai is so easy? Who is going to pay them to develop good taste?
> The early narrative was that companies would need fewer seniors, and juniors together with AI could produce quality code
I'm not deep into it, but I have not a single time seen that direction argued before this post. Maybe it was _really_ early on?
The narratives I always saw were, firstly, "it will be as a good as a junior dev", then "it's like pairing with an overly enthusiastic junior dev", then finally arguments similar to those presented in this article.
Which, frankly, I'm still not so sure about. Productivity is incredibly hard to measure: we are still not completely, non-anecdotally sure AI makes folk broadly more productive. And even if it does, I am beginning to wonder how much ai is short term productivity with long term brain rot, and whether that trade off is really worth it.
>Of course, the junior + AI pairing was tempting. It looked cheaper and played into the fear that “AI will take our jobs.”
Those are two different narratives. One implies that everyone will be able to code and build: "English as a programming language", etc. The other is one of those headless-chicken, apocalyptic scenarios where AI has already made (or will very shortly make) human programmers obsolete.
"AI taking jobs" means everyone's job. I won't even comment on the absurdity of that idea; to me, it only comes from people who've never worked professionally.
At the end of the day, companies will take any vaguely reasonable excuse to cull juniors and save money. It's just business. LLMs are simply the latest excuse, though yes, they do improve productivity, to varying degrees depending on what exactly you work on.
> "AI taking jobs" means everyone's job. I won't even comment on the absurdity of that idea; to me, it only comes from people who've never worked professionally.
Once you've worked professionally, it's not so absurd. I mean, you really see to believe the extreme compromises in quality that upper management is often willing to tolerate to save a buck in the short term.
Also, those two narratives are sometimes deployed as a false-dichotomy, where both just make the same assumption that LLM weaknesses will vanish and dramatic improvement will continue indefinitely.
A historical analogy:
* A: "Segway™ balancing vehicles will be so beneficially effective that private vehicles will be rare in 2025."
* B: "No, Segways™ will be so harmfully effective that people will start to suffer from lower body atrophy by 2025."
> "AI taking jobs" means everyone's job. I won't even comment on the absurdity of that idea; to me, it only comes from people who've never worked professionally.
I work professionally (I am even a bit renowned) and still believe AI will take my (and everyone's) job.
No, it was supposed to get rid of the seniors because they cost more and replace them with cheap juniors + AI. If you need some humans and you are a corpo bean counter, the cheaper the body the better.
But that wouldn't make any sense. It's not `plus`; it's `times`. AI is supposed to be a force _multiplier_, at least in the context of a complex organization and product (on small projects where vibe-coding is good enough I think AI is a massive plus!).
If a junior is about 50% as useful as a baseline senior, and today, AI's usefulness is only slightly better than the person using it, then 50% * 75% gives you output equal to about 37.5% of a senior. The junior just ships more junior-level output; and in a complex product and complex orgs, this just ends up being a drain on everyone else.
But in the hands of a senior, 100% (senior) * 125% (ai), we get a slightly better senior.
Its not a perfect analogy, and AI is new territory with lots of surprises. AI code reviews, have been separated from the confirmation bias of the driver of the AI, _are_ where I'm seeing the greatest impact on junior engineers. These AI reviews seem to be getting things closer to a level playing field.
I agree this does not make sense for you and me, but it makes sense for the corpo bean counters that don't understand how this works and they were told AI makes people better, so they need less people and less skilled people. It is not hard to get to the wrong conclusions based on the AI marketing materials.
I see the discussions around AI in my company (big, not IT but with several large IT departments) and even our MBA IT leaders believe all the buzzwords to the letter.
This is a good thing. That shift in expectations will hopefully prevent a total collapse of systems as inexperienced developers would have yeeted god knows what code into production.
The best part: all of the materials that were available to now-seniors are available to new juniors. The added advantage of having an LLM to explain or clarify things? Seniors didn't have that. We had to suffer.
Sorry, but the outcome is fair. Seniors had to suffer to learn and can now benefit from the speed up of AI. Juniors don't have to suffer to learn, but they do have to learn to leverage AI to help them catch up to the existing crop of seniors.
Not impossible. Not impractical. Just a different form of hard work, which, no matter how much anyone kicks and screams will always be the thing standing in the way of where you want to be.
It doesn’t make seniors shine. It makes some of them fucking delusional. Sure, once in a while a LLM does something impressive and you are left thinking “holy shit, the future is now!”. However, this does not make up for the mass of time that you spend going “what is this shit?”, and saying “that’s not what I intended, gentlemen robot, please correct x, y and z.” And then gentlemen robot will go ahead and FUCK IT UP WORSE THAN BEFORE. Never work with kids, animals or AI. This shit is the worst, who came up with this? I can code! I’m bloody good at it! If I wanted to deal with some useless no-hoper having a crack and constantly needing to have their head kicked to do anything useful, I would have gotten you to do it.
Genuinely curious: how do Juniors respond? If seniors learned with just stack overflow or…books… do juniors slow themselves down and learn those ways? Maybe AI slop looks fine to those who haven’t seen a lot of code?
Uh because an LLM is a transfer function. Specifically a transfer function where the input has to be carefully crafted. And specifically where the output has to be carefully reviewed. Inexperienced people are good at neither of those things.
So now industry will stop hiring juniors, cause LLMs are cheaper. And in a couple of years, there will be a profound lack of senior devs. And then everybody realizes that LLMs still suck at higher level coding tasks.
Great.
AI was supposed to help juniors shine?
I don't remember hearing that anywhere.
AI was supposed to let CEOs fire expensive experts and replace them with whatever slop the computer extruded from the manager's prompt.
There was never any significant hype about making juniors into experts.
AI is a tool, like any other. Imagine you invented a new machine gun that fires faster and has less recoil but james more often. Who will be able to put the new machine gun to better use -- new recruits or veteran soldiers? C'mon.
That might be a trick question I think. As a veteran I would drop one enemy, take their AK-47 and drop my M-16 and start collecting ammo for my nifty old but reliable AK-47 that does not jam when it gets a little dirty.
"AI Was Supposed to Help Juniors Shine" is a false narrative. AI's end goal has always been to fundamentally eliminate more and more of human labor positions until the only job left is executive directorship.
i think it is due to the reverse utility curve; most products have some sort of gaussian utilty fuction for utility vs. expertise level. a complete newb will have trouble using the camera and a professional photographer will be limited by it, but most people in-between will get a lot of use out of it.
with llm’s it is opposite; a complete newb can learn some stuff, and an expert will be able to detect when it is bullshitting, but most people will be at a point where they have more knowledge about the subject the llm is talking about than the newb, but not enough to detect the bs.
"AI" does not make anyone stronger. It destroys thought processes, curiosity and the ability to research on your own.
Seniors just use it to produce the daily LOC that resembles something useful. If mistakes are introduced, they have secured a new task for the next day.
There have always been seniors who exclusively worked on processes, continuous integration, hackish code-coverage that never works, "new" procedures and workflows just to avoid real work and dominate others.
The same people are now attracted to "AI" and backed by their equally incompetent management.
The reality is that non-corporate-forced open source contributions are falling and no serious existing project relies on "AI".
Generative "AI" is another grift brought to you by leaders who previously worked on telemedicine and hookup apps (with the exception of Musk who has worked on real things).
Citation needed? LLMs have mostly been touted as the junior replacement, a way for seniors to oversee scalable teams of shortsighted bots instead of shortsighted people.
does it really? it lets seniors work more, but idk if its necessarily stronger.
i just soent some time cleaning up au code where it lied about the architecture so it wrote the wrong thing. the architecture is wonky, sure, but finding the wonks earlier would have been better
Because juniors don't know when they're being taken down a rabbit hole. So they'll let the LLM go too deep in its hallucinations.
I have a Jr that was supposed to deploy a terraform module I built. This task has been hanging out for a while so I went to check in on them. They told me the problem they're having and asked me to take a look.
Their repo is a disaster, it's very obvious claude took them down a rabbit hole just from looking. When I asked, "Hey, why is all this python in here? The module has it self contained" and they respond with "I don't know, claude did that" affirming my assumptions.
They lack the experience and they're overly reliant on the LLM tools. Not just in the design and implementation phases but also for troubleshooting. And if you're troubleshooting with something that's hallucinating and you don't know enough to know it's hallucinating you're in for a long ride.
Meanwhile the LLM tools have taken away a lot of the type of work I hated doing. I can quickly tell when the LLM is going down a rabbit hole (in most cases at least) and prevent it from continuing. It's kinda re-lit my passion for coding and building software. So that's ended up in me producing more and giving better results.
> I don't know, claude did that
I'm the type of reviewer that actually reads code and asks probing questions, and I've heard this from junior and senior devs alike. It's maddening how people say this with a straight face and expect to keep their jobs. If people are pushing code they don't understand, they're liability to their team, product, and employer.
The rank disrespect of somebody asking you to review something they haven't even looked at is eye watering.
I feel like AI-induced brain-rot of engineers is inevitable. Unless we see AI leapfrog into something close to AGI in the future (certainly not ruling this out), I think there will be very lucrative careers available to engineers who can maintain a balanced relationship with AI.
I'm glad I'm not the only one who gets viscerally irritated when I'm asked to review a PR that was obviously generated. You didn't take the time to write this code, but you expect me to take the time make sure it's correct, which will take far longer than a regular PR because there's no reason to assume an LLM even understood the task. Next time just be honest and ask me to do your work for you.
> You didn't take the time to write this code, but you expect me to take the time make sure it's correct
So, I guess there are a couple parts here right? I might not take the time to write the code, but surely I am on the hook to demonstrate that I've tested the code or have very good reason to believe it's correct?
If people are pushing PRs [of any meaningful complexity] without knowing whether they work in the general case that sounds like a failure of process and/or training. For me PRs are about catching edges?
I'll quote from my parent comment:
> somebody asking you to review something they haven't even looked at
The situation you're talking about is not the one we're talking about, so I'm not sure what you're taking issue with.
My boss decided to start putting out a ton of PRs from Devin at one point. I told him I'm spending more time reviewing his PRs than he was saving.
I just felt this recently. I was sent some code for me to put into prod, a long running service. And in one func, which returned an error (Go) but still called "os.Exit" in each error handler rather then returning.
Fixing the issue was a small matter. But the amount of disrespect I felt, that I looked at it closer then anyone else apparently (which wasn't really all that close at all), when they were ostensibly building this code, that disrespect was just immense.
Stop saying engineer when you mean programmer.
It’s an insult to real engineers.
People making siege engines?
Well no one actually asked you for a review, it's just a stupid checkbox item some boomer added to the list of other useless checkbox items - like group calls where everyone is just reading list of closed tickets we can all read ourselves in jira. This self righteous bullshit makes the whole ordeal even more insufferable.
Code reviews are one of the few ordeals worth doing. They catch problems and transfer knowledge. In a reasonably well run org (it doesn't take much) code reviews are easily a huge net benefit.
As for "reading closed tickets", you are right. It is silly. Alas, in apathetic orgs it is a reliable way to get some people know what is going on some of the time. And that particular ordeal keeps the tickets somewhat in sync with reality.
Consider that your experience may not be universal. Just because your reviews are useless rubber stamps to satisfy "some boomer" does not mean that other shops also have no standards. I get explicitly asked for reviews at work all the time, and I'm expected to actually understand the code and provide useful feedback.
By the way, you don't have to give useless reviews even if your coworkers do. It sounds like your workplace is infected with complacency, but there's no law that says you can't do better.
If you saw the nonsense some of my teammates try to commit, you would have a completely different view on code review. Just off the top of my head in the past 3 months, they have:
If code reviews are that useless to you, that must mean either your team is completely homogeneous in terms of skill level and knowledge, or no one is taking the code reviews seriously.It is going to happen with higher frequency - buckle up!
The correct response to that is "what's your job?"
It's baffling how little awareness some people have.
"What would you say... you do here?"
"get paid to ask claude to do the work of course!"
100%. This has in general become a trend across my company. Less so developers, more so everyone else spitting LLM generated content, and asking real people to review and provide feedback. I mean , WTF.
amen.
In certain situations I'd argue it's a calculated risk worth taking. Let's say I'm tasked with adding a much-needed feature to an older legacy application that is built using frameworks and libraries I'm not familiar with, possibly also with with weak docs. If Claude is able to produce a self-contained piece of code that looks correct when you read through it and behaves correctly during (thorough) testing, then it sure has saved me (and my company) a lot of time and effort, even though we are deploying code we may not fully understand.
My interactions with Gemini tend to be fairly slow, but it's because I don't give it any extra permissions, make it research and plan an implementation first, and check each file update one at a time.
So far it has still been a bit more productive for me, though the margin is low. I get more product sork done on the order of 5-15%, I tend to have more test coverage as I focus more heavily on that, and I can focus more often on architecture. The last one is a win for me, I prefer that work and find that I can review code quickly enough to make it worth the tradeoff.
Is there any tool that approve a given PR is easy to review? Or should we use a checklist of function length, cognitive complexity etc?
Pre AI I can understand why you might not know. There have been instances where I find a recipe, take what I need, but there’s some code I can’t understand or find an answer to. But time pressure, so I just add a comment and ask around for ideas.
These days, just ask the llm.
It’s pretty great actually.
We can filter out useless people faster.
The days of easy 400k plus TC are over and only people deserving of that should get it imo.
And btw I worked with idiots before, and I’m sure I will in the future. But there should be less of them.
"I don't know Claude did that" isn't a bad thing in and of itself... If someone is spending a bunch of time on code that Claude could have done and easily verified it was correct, they are going to move slower and produce less useful things of value than someone who cares about reading every line of code.
Any situation where you’re submitting under your signature code to production without knowing what it does should be at the very least cause for a talk.
I’m kinda shocked that this even has to be said.
The policeman says to the judge, on the stand "I don't know why my sworn affidavit says that, your honor. But I can write twice as many affidavits now so it's all for the best."
> If someone is spending a bunch of time on code that Claude could have done and easily verified it was correct, they are going to move slower and produce less useful things of value.
This is the future fellow greybeards. We will be shunned for being try-hards, and when it turns out we were right?... Well no one likes a know it all.
If you "don't know" then how could you have "easily verified it was correct"?
I think they were claiming claude easily verified it? i.e. they have total faith in claude to not mess up
That's an interesting claim. I wonder how they would come to believe that.
If it’s easily verified as correct, then you should have verified its correctness before bringing it to someone more senior and asking for their help, and so you should be able to explain why it is there when they ask.
If you don't understand you code how you can be sure it's correct? You actually are pushing it into your colleagues who will verify and fix the code later.
To be fair, even if you understand it that's doesn't mean it will work well.
Testing.
The only thing that changed with AI is that the narrative went from "you can't always know perfectly what every part of the program does" to "don't even try".
But the LLM writes the tests too. Probably even made some private methods public so it can test them, because you asked it to write a comprehensive test suite. It’s a beautiful self-jerk circle of shitty code based on wrong assumptions proven by correct tests testing shitty code based on wrong assumptions…
Or the wonderful loop of "These test steps are still failing, let's try something simpler and remove the failing tests. Great! The tests are passing now!"
Sad reality is test engineers headcount over last years was cut even more than developers. Most companies see testing as obstacle and unnecessary costs and has no will to invest into testing.
You, sir, have "executive" written all over you.
Savage
Why do we need them then? If they're some dumb passthrough I can just replace them with a background agent
> they respond with "I don't know, claude did that"
A huge red flag right here. Its ok to not know things, its ok to use LLM to fill the gaps. Its ok to fail. It is in no way ok to not care and only fess up to having a mass of code you have no idea about when your senior reviewer asks you about it. At the very minimum the ask should go the other direction - "I got this generated code and I am not sure I understand what's going on, could you help me to see if that's the right direction" would be acceptable. Just not caring is not.
Unfortunately, the type of work you hate doing is perfect for a junior. Easy tasks to get a hold on the system.
>How'd you get so good at debugging and navigating code you've never seen before?
>Because I spent a couple internships and a whole year as a junior debugging, triaging and patching every single issue reported by other developers and the QA team
Was I jealous that the full time and senior devs got to do all the feature work and architecture design? Yes. Am I a better developer having done that grind? Also yes.
100%. I shouldn't have done the architecture work on any meaningful scale early on, but I was always interested. My early roles were largely me being able to architect smaller pieces in a larger plan, building some architecture skills while learning larger patterns that worked and thought processes along the way.
I'd recommend that approach to anyone working with more junior devs.
Yup, sounds like a great opportunity to show you’re senior by mentoring.
Which will (sadly) offer you zero extrinsic benefit at almost every job, and will often actually count against you as a waste of time relative to the vast majority of productivity metrics that companies actually use.
There's a lot of benefits you get by mentoring. When you have to teach you're forced to think more deeply about problems, see it from different angles, and revisit questions you had when learning but tabled at that time. That last one is pretty common. There's always questions you have when learning that you have to avoid because you don't have the knowledge to answer yet, because they would take you down too deep a rabbit hole. But later you have the experience to navigate those problems.
Personally, I've learned a ton while teaching. It's given me many new ideas and insights. But I'm obviously not alone in this. Even Feynman talks about how teaching results in better learning
I don't think you have to convince the parent poster or seniors developers in general. You have to convince their employers that this is a valuable use of time.
I interpreted the extrinsic benefits differently, but fair. Still, I think being vocal about this helps. We can put pressure on our managers
15 years later when the folks you mentored are sitting on hiring panels, it doesn’t seem so bad.
Obviously that’s not why I did it, but I am not unhappy about it either.
Which is unfortunately very true. I think, that in a healthy organization such kind of mentoring requires extremely well defined boundaries and rules. Can I spend 1h of my time explaining basic stuff to a junior, who will then be able to finish his task in 2h instead of 8h? Mathematically this is a win for the company. But economically, maybe that junior dev should be fired.
That's the problem -- except in the rare type of org that thinks past quarterly or annual results and thus values training up a pipeline to be the future seniors -- economically speaking, all the junior devs should be fired, and the simple tasks they can do are the same set of tasks that can be accomplished by a senior at the helm of AI at 10-50x the speed.
Someone mentored you, pay it forward. If you think you got where you are entirely on your own, you need therapy.
Oh come on. Plenty of us here never had any form of direct mentorship at work or otherwise. It's not unusual when you pick up the trade as a hobby in your teens, and in terms of programming and technical skills (which is what we're discussing here), you stopped being a junior before getting your first job.
Myself, I learned from many folks on IRC and ol' phpBB boards, and I helped others on IRC and said phpBB boards in return; almost all of that was before graduating. That, and books, lots of books, and even more time spent just reading code online and writing my own. None of that hardly qualifies as "mentoring".
>you stopped being a junior before getting your first job.
No, that was your hubris thinking you had the chops. We didn’t hire you because of your skills, we hired you because of your age and aptitude to learn. That’s how college recruitment works. If you didn’t go that route, you were still looked at as a junior. Your ego clouds your view.
> If you didn’t go that route, you were still looked at as a junior. Your ego clouds your view.
your ego clouds your response.
He wasn't talking about if he was hired into a jr role, he was talking about the competency, experience, and skills acquired from the years of writing code for passion. If he could write better code, or debug problems faster than your average jr level employee.
Not everyone fits into the tiny bucket you've imagined must hold everyone. The answer could easily be, we hired you because you ticked all the boxes, but no one doing the interview could tell they were completely out classed.
If you’re employed, you’re in a bucket. It’s a cell on a spreadsheet somewhere.
I’ve yet to find a junior dev that had more skills than a junior dev. I’ve seen them try… but they are still a junior dev. If you aren’t a junior dev, then you aren’t. Mentorship has nothing to do with what bucket you’re in.
However, there are specific job duties of senior and higher that are beyond just writing code. One of them is making more seniors. There’s only one way to do that efficiently. Learning. And while you can go read a manual on how to put a Ferrari together, wouldn’t you want to work with a mechanic who has already made dozens of them?
Why do we reject help?
> I’ve yet to find a junior dev that had more skills than a junior dev. I’ve seen them try… [...] If you aren’t a junior dev, then you aren’t.
Funny, I've met plenty of jr devs that were way more competent than some of their peers who've been at the exact same company/division for 4+ years. Which was my point. The world is bigger than you can imagine. There are people with experiences that you couldn't describe, but you write in a way that feels like you want to dismiss them outright as impossible, which does a disservice to everyone involved.
> And while you can go read a manual on how to put a Ferrari together, wouldn’t you want to work with a mechanic who has already made dozens of them?
> Why do we reject help?
I feel like you and I are arguing past each other. To reuse your example: There are plenty of people who have never spent time with a mechanic, but have been spent so much time pouring over every technical manual for the car, that they can out perform guys with years working for Ferrari, while that guy working for Farrari has mentors, he still has to ask for help with most things, and needs to look up a number of the specs. But the person who exclusively taught himself, can do many of the same tasks blindfolded.
No one has said they don't want mentorship, but many were never in a position to have that advantage. But you said that if they think aquired their skills on their own, they need to seek therapy. WTF?
I'm sure you've met plenty of narcissists who have had mentors, but claim they haven't. But it's wrong, insulting and pretty toxic to lump everyone into that same group.
>but you write in a way that feels like you want to dismiss them outright as impossible
I write in a way from wisdom, from experience, the likes of which you describe as indescribable.
Ever heard the term “It takes a village”? You had mentors that you refuse to acknowledge.
>There are plenty of people who have never spent time with a mechanic, but have been spent so much time pouring over every technical manual for the car, that they can out perform guys with years working for Ferrari, while that guy working for Farrari has mentors, he still has to ask for help with most things, and needs to look up a number of the specs.
Except that guy in his garage isn’t working for BMW or Mercedes, he’s a hobbyist that has learned all about his vehicle. There’s a difference. A minor one, but it’s there. The Ferrari mechanic works on ALL Ferrari. Now, you’ll say, but there’s a car guy that can… I’ll save you the trouble. That guy isn’t applying to junior roles, isn’t asking for mentorship, he’s just a car guy. A passion about cars.
Then you’ll say: exactly my point about engineering. Which is right, I never said that it wasn’t possible that someone could selflessly throw hours away teaching themselves through trial, error, and tutorials. There are many paths. What I’m saying is, stop wasting hours and open your mouth and ask for help. There are no stupid questions, only stupid answers. Every scientific breakthrough starts with a question. Every idiot response starts with an answer. Mentorship is asking for guidance with the wisdom to know the difference.
> I write in a way from wisdom, from experience, the likes of which you describe as indescribable.
the likes of me huh?
lmao, ok mate, good job, gg you win! clearly you just better, because obviously, you're built different!
Everyone is looked at as a young person when they are young. I've definitely had "junior" colleagues that "got it" better than my 50yo colleagues. It's possible I shouldn't say that outloud, because skilled youngsters have a tendency to misidentify themselves as being part of that set while the wise youngsters have a tendency to *underestimate* their own capability or insight. But I don't think you can make that same assumption about a senior thinking back to their early years.
I desperately wish, to this day, that I had been in the position to receive mentorship. I basically hang out on HN as a way to gather it where I can. Attended engineering meetups when I was younger as well. But I never had the benefit of working with engineers senior to myself. I was a junior "business employed person" but when you need to make a roof you do what you can and learn the hard way even if there's no other humans to show you how to make a proper roof. Luckily, you can receive mentorship not just online, but through books, or even just studying the craft of others...but you take what you can get.
Receiving mentorship is such a gift, and as I approach the end of my career, I am still hungry for it, and harboring some degree of wistful envy for those that receive mentorship as an engineer. I've had many great mentors, but my for the most part, engineering mentors have never seen my face, heard my voice, or known my name, and certainly not for the first decade of my professional career as a software developer, where I didn't have any other developers to work with.
You see, the issue is you’re framing your mentorship (or lack thereof) on a very specific topic, that you are already well versed in. Why would someone give you advice in your field? You probably already know…
Mentorship is about more than just “don’t use strings directly in your squeal”, it’s about navigating the organization. Filing proper TPS reports. Encouraging refactoring. Having empathy when shit goes south. Coffee talks. Hikes. Walks. Getting to know them as a person and giving them life advice.
My best mentor taught me, if you keep looking under rocks, all you’ll find is dirt. Look up.
Of course. And I thought I acknowledged that mentorship is many things and there are many things that we need to grow as individuals. I've had a lot of great mentors in my life.
I still think you've missed the point. You can be grateful for the many gifts you've received and still wish to have had engineering guidance from a trusted mentor. There is not enough time in a life to go down every single rabbit hole; it's nice to have experienced people accurately point out where the rabbit holes are. Non-engineers are not equipped to help spot engineering rabbit holes; they might even tell you that engineering itself is ultimately a pointless rabbit hole.
But even then...that's just my own experience and my own wishes for my past self. I try to give what I wish I had had, of course.. think that's what drives most mentorship, and maybe that's the point you're trying to make, that mentorship is given out of that wistful feeling of wishing you had received advice/help and passing along the lessons that took you too long to find.
But still, if your role is getting stuck alone in the server room or whatever with a team of people who don't understand or respect what you do, good luck.
The point I was trying to make (and maybe failed because I got too focused on my own experience) is that really, not everyone gets mentors, even of the broader sort that you're referring to (which I might say are more accurately called friends or peers). But even if we widen the scope of what mentorship is, it's also perfectly reasonable for field-specific mentorship to be a cultural expectation for software engineering. I think it's a good thing to expect this of each other, and to encourage explicitly making space for the practice.
But again, however you want to widen the scope of what mentorship is, not everyone is getting it. The reason people look under rocks is because they don't know where to look. Or they do know where to look but also know they have blind spots and don't know how to get them addressed. "Look up" is nice and all, but it's a bit rude and distracting when you're trying to build something and need help understanding the foundation below your feet. Sometimes you don't need someone telling you to look up, you need help seeing where to look closer.
Mentorship is unfortunately broken because gone are the days of apprenticeships.
If you find a great mentor, do everything you can to learn quickly then jump ship to big tech and cash in.
This is kind of sad. I'm probably missing context here, but surely it's not necessary to rush out of a good working relationship with a good mentor. The most important things you'll learn from a good mentor can't be learned in a rush (like prioritization, project management, how to be a good mentor...).
In any case, I would replace 'jump ship' with 'pay it forward.'
Depends on the country, they are pretty much alive across many European countries.
Here are two examples,
A German site to search for technical schools with apprenticeship,
https://www.ausbildung.de/
The same for Portugal
https://www.escolasprofissionais.com/
>do everything you can to learn quickly then jump ship to big tech and cash in.
Yeah, don’t do this. Great way to ruin your reputation as a dollar chaser and be exiled to the consulting wastelands. Burning bridges takes minutes. Building them takes years.
A great mentor won’t waste their time on someone cynically using their time to cash out at Meta. Such a person can just get a CS degree and launch into Amazon for that.
Big Tech are just the IT enterprises of the modern day. It’s not where the action is and that experience is not so hot on the CV when it comes to early stage development.
There's also not much in it for the mentor other than the warm glow in the heart.
There's unfortunately a crack epidemic.
Try to quickly become a drug dealer and cash in.
---
Chef's kiss. I'd like to thank people like you for where we are.
Mentoring is a different kind of work than coding. Like senior+ level in some companies, it's just faux management - people work, with all the expectations and responsibilities of the non-technical track, but none of the status and privileges.
That makes sense. When Claude Code suggests a bad approach, I kind of shrug it off and suggest a different approach. I don't think of it like a negative because I basically go through a similar process of ideation before I implement a feature and I typically discard ideas before arriving at the right one so Claude Code is part of the ideation process for me. The code it produces gives me a clear idea about how complex/ugly the solution will be. I know what 'ugly' looks like.
I imagine a junior might actually jump at the first solution because they don't have any other arrows in their quiver so-to-speak. The LLM is acting like the engineering manager but it's actually really bad at that.
The LLM is like a stereotypical programmer with 0 common sense. The kind who can produce good code but you have to micromanage every single decision. It's terrible if you put it in charge. It doesn't have any opinions about architecture or code quality so it just follows the structure of the existing code base... There's a tendency towards increasing complexity, more hacks more chaos.
It often tries to hack/cheat its way to a solution. It requires a constant effort to maintain order.
It’s like having a malicious mentor. But the frequency of which I’m bailing on reviews on the first line due to stupid stuff that has made it to a commit is quite stunning.
“Oh I thought that would be useful at some point so I just committed it.”
Beating it into developers that they need to review their own work they submit before asking someone else to waste time is the best way I’ve found so far.
> I don't know, claude did that
also likes to blame shop accidents on the table saw
The deciding factor for being able to effectively utilize LLMs and dodge hallucinations is ability to read code and intuition for how a solution should look. I think juniors are especially hesitant to just dig into understanding some source code unless they have no other choice, e.g. preferring to wait on email response from the author of the code over piecing things together.
This makes LLM tools so tempting, you don't even have to wait on the email response anymore! But of course, this is basically going in blind, and it's no wonder that they end up in hallucination mazes.
The problem with beginners going down the wrong path has always been there, but AI lets them go much further than before.
No amount of “own the code you generate” policies will prevent the rise of “I don’t know, the AI wrote it” excuses in the LLM era. What’s more likely is that reviewers will be flooded with unvetted, generated code. Over time, this can lead to reviewer fatigue and a gradual decline in rigor. If the trend continues, the impact could be significant once the most experienced engineers begin to retire.
If they dont know what every line does, it shouldn’t be ready for review - regardless of if they or AI wrote it initially
>I don't know, claude did that
Instant dismissal.
Honestly I made similar mistakes back before AI as a junior developer, by just copy/pasting code or confusing two things.
I think a lot of the problems lies in their prompting. AI is usually at its worst when just saying «deploy terraform module». And off it goes spitting out code.
What they should have done as juniors was to have a conversation about the topic and task first. «Help me understand …» learning and planning is especially important with LLM coding.
I don't write terribly complex things: Just data processing pipelines for neuroimaging, but I know I get good results because I take time being specific in my prompts, saying what I want, but also what I don't want, suggesting certain tools, what options I want available, how I want logs, etc. I really does help it to know what you want and relaying that with an effortful prompt.
The best code I've written with an LLM has been where I architect it, I guide the LLM through the scaffolding and initial proofs of different components, and then I guide it through adding features. Along the way it makes mistakes and I guide it through fixing them. Then when it is slow, I profile and guide it through optimizations.
So in the end, it's code that I know very, very well. I could have written it but it would have taken me about 3x longer when all is said and done. Maybe longer. There are usually parts that have difficult functions but the inputs and outputs of those functions are testable so it doesn't matter so much that you know every detail of the implementation, as long as it is validated.
This is just not junior stuff.
> I could have written it but it would have taken me about 3x longer when all is said and done.
Really does not sound like that from your description. It sounds like coaching a noob, which is a lot of work in itself.
Wasn’t there a study that said that using LLMs makes people feel more productive while they actually are not?
True but the n00b is very fast. A lot of coaching is waiting for the n00b to perform tasks and meta things about motivation. These LLM are extremely fast and eager to work.
I don't need a study to tell me that five projects that have been stuck in slow plodding along waiting for me to ever have time or resources for nearly ten years. But these are now nearing completion after only two months of picking up Claude Code. And with high-quality implementations that were feverdreams.
My background is academic science not professional programming though and the output quality and speed of Claude Code is vastly better than what grad students generate. But you don't trust grad student code either. The major difference here is that suggestions for improvement loop in minutes rather than weeks or months. Claude will get the science wrong, but so do grad students.
(But sure technically they are not finished yet ... but yeah)
100% this. The AI missunderstands and make a mistake? No problem. Clarify and the AI will come back with a rewrite in 30 sec.
A rewrite with another, more subtle mistake. That you must spend energy discovering and diagnosing.
And potentially trick you into going down a rabbit hole as you try to steer it when it would have been faster to edit the code yourself. The best use is editing code with it instead of purely relying on prompting. Also new contexts for different changes make a huge difference. Seems a lot of devs get stuck in the single context chat stream and it starts to break down as context gets fuzzy.
This can go both ways though. I've had instances where after a long somewhat tedious back and forth with Claude Code what I'm looking for finally "clicks" and it starts one-shotting requests left and right. But then after coming up to the end of the context window, I compact or ask it to update CLAUDE.md with what it learned and it loses the nuanced understanding it built up through trial and error and starts screwing up in the exact same ways again with fresh context.
And then I waste 20 minutes bashing my head against the wall trying to write three paragraphs meticulously documenting all the key gotchas and lessons from the "good" context window with the magic combination of words needed to get Claude back in the right head space to one-shot again.
At least if I pull that off I can usually ask Claude to use it as documentation for the project CLAUDE.md with a pretty good success rate. But man it leaves a bad taste in my mouth and makes me question whether I'm actually saving time or well into sunk cost territory...
You’d think that with more context it would get better, but it doesn’t.
My hunches are that the to-and-fro of ideas as you discuss options or make corrections leads to a context with competing “intentions”; and that they can’t tell the difference between positive and negative experiences when it comes across each successive token in the context.
But I don’t make LMMs, so this is pure guesswork.
Quite honestly after using Copilot, Claude Code, Cursor, and Codex extensively for months, I very rarely hand edit code.
The rabbit hole problem is pretty rare. Usually it happens when the model flips into "stupid mode", some kind of context poisoning. If you are experienced, you know to purge the context when that happens.
In personal projects I avoid manual editing as a form of deliberate practice. At work, I only edit when it is a very small edit. I can usually explain what I want more concisely and quickly than hand editing code.
I probably would use more hand editing if I had classic refactoring tools in the IDEs similar to intellij/pycharm. Though cli based tools were a pleasant surprise once I actively started using them.
> The best use is editing code with it instead of purely relying on prompting.
What does this look like in practice?
How is that different from working with a n00b except that it only took 30sec to get to the next bug rather than a week?
The junior engineer will grow into a senior engineer
Not as fast as models get better.
And not at all for you, because you're unlikely to retain them for long. Which makes this immaterial - AI or human, you're only going to delegate to n00bs.
(This is distinct from the question of which benefits society more, which is a separate discussion.)
> The junior engineer will grow into a senior engineer
And then quit after accepting a new job that pays them their modified value, because tech companies are particularly bad at proactive retention.
Which has nothing to do with the argument you're responding to.
Only if you take the argument entirely out of context.
.. and because the job and environment weren't that pleasant or rewarding to offset that delta in income offered elsewhere at an equally drab employer
And then they get their own junior engineers and you get fresh new junior engineers.
> another, more subtle mistake. That you must spend energy discovering and diagnosing
But this is literally what senior engineers do most of the time? Have juniors write code with direction and review that it isn't buggy?
Except that most of the code seniors review was written with intention, not just the most statistically most likely response to a given query. As a senior engineer, the kinds of mistakes that AI makes are much more bizarre then the mistakes junior engineers make
I've worked with many interns and juniors in my life and they've made very bizarre mistakes and had subtle bugs, so the difference in the kinds hasn't made much of a difference in the work I've had to do to review. Whether or not there was intention behind it didn't make a difference.
>not just the most statistically most likely response to a given query.
Some people really are going to hang on until the better end (and beyond) eh?
"AI can't code like me!" people are going to get crushed.
I’ve definitely seen absolutely bizarre creations from junior devs decades ago (so, well before modern AI). I can also think back to some cringey code I wrote by hand when I was a junior as well.
I mentor high-school students and watch them live write code that takes a completely bizarre path. It might technically be intentional, but that doesn’t mean it’s good or useful.
> Except that most of the code seniors review was written with intention, not just the most statistically most likely response to a given query.
Given the nature of the statistics in question, the line between the two is extremely blurry at this point.
My experience in the UK has been that seniors and principles just write more/better code and occasionally deal with “the business” with (justifiably) greater attention paid to their input. I’d love to see a proper culture of mentoring.
LLMs might make you feel faster (which helps with motivation!) and help with some of the very easy stuff but the critical part of your anecdote is that you haven't actually completed the extra work. The projects are only "NEARING" completion. I think that's very telling.
Congratulations! You repeated my joke? lol
But in all seriousness, completion is not the only metric of productivity. I could easily break it down into a mountain of subtasks that have been fully completed for the bean counters. In the meantime, the code that did not exist 2 months ago does exist.
If the easy things are done faster you xan spend more time on the hard stuff. No need to spend 2 hours on making the UI for the MVP when an AI can make a decent UI in 2 min. Means you have 2 hours more to spend on the hard stuff.
Unless, as is often the case in my experience, the hard stuff consists largely of fixing bugs and edge cases in your implementation of the easy stuff. I've seen multiple people already end up forced back to the drawing board because their "easy stuff" AI implementation had critical flaws they only realized after they thought they were done. It's hard to prove counterfactuals, but I'm pretty confident they would have gotten it right the first time if they hadn't used AI, they're not bad engineers.
> I don't need a study to tell me that five projects that have been stuck in slow plodding along waiting for me to ever have time or resources for nearly ten years.
that's the issue in the argument though. it could be that those projects would also have been completed in the same time if you had simply started working on them. but honestly, if it makes you feel productive to the point you're doing more work than you would do without the drug, I'd say keep taking it. watch out for side effects and habituation though.
You've added an implicit assumption that this person spends more time programming now than they used to, rather than continuing to commit time at the same rate but now leading to projects being completed when they previously got bogged down and abandoned.
There are any number of things you could add to get you to any conclusion. Better to discuss what is there.
I've had the same experience of being able to finish tons of old abandoned projects with AI assistance, and I am not spending any more time than usual working on programming or design projects. It's just that the most boring things that would have taken weeks to figure out and do (instead, let me switch to the other project I have that is not like that, yet) have been reduced to hours. The parts that were tough in a creative fun way are still tough, and AI barely helps with them because it is extremely stupid, but those are the funnest, most substantive parts.
> if you had simply started working on them.
The magic of Claude is that you can simply start.
You can also simply start without Claude too!
Yes, but less often.
Yes, because Claude makes you feel more productive and thus you are more eager. I feel like we've covered this further up.
I don't think that's correct. That could be true if I were primarily a programmer, but I am not. I'm mostly a certified medical physicist working in a hospital. Programming is a skill that is helpful and I have spent my programming time building other tools that I need. But that list is gigantic, the software that is available for purchase is all complete crap, the market is too small for investment, etc. That's all to say the things I am building are desperately needed but my time for programming is limited and it's not what brings home the bacon and there's no money to be made (beyond consulting, essentially these things might possibly work as tools for consultants). I don't have resources for professional programming staff but I have worked with them in the past and (no offense to most of HN) but the lack of domain knowledge tends to waste even more of my time.
You are very fortunately in the perfect slot for where LLM has a lot of bang for the buck.
It is in many ways much like coaching a n00b, but a n00b that can do 10 hours of n00b work in 10 minutes (or, 2 minutes).
That's a significant difference. There are a lot of tasks that can be done by a n00b with some advice, especially when you can say "copy the pattern when I did this same basic thing here and here".
And there are a lot of things a n00b, or an LLM, can't do.
The study you reference was real, and I am not surprised — because accurately gauging the productivity win, or loss, obtained by using LLMs in real production coding workflows is also not junior stuff.
"Really does not sound like that from your description. It sounds like coaching a noob, which is a lot of work in itself."
And if this is true, you will have to coach AI each time whereas a person should advance over time.
At least you can ask AI to summarize a AGENT.md or something and it will read it diligently next time.
As for humans, they might not have the motivation technical writing skill to document what they learnt. And even if they did, the next person might not have the patience to actually read it.
"Read diligently" - that’s a very optimistic statement. I can not count how many times Claude (LLM I am most familiar with, I had it write probably about 100KLOC in the past few months) explicitly disobeyed what was written in the instructions.
Also, a good few times, if it were a human doing the task, I would have said they both failed to follow the instructions and lied about it and attempted to pretend they didn’t. Luckily their lying abilities today are primitive, so it’s easy to catch.
Psychopatic behavior seems to be a major problem for these (of course it doesn't think so it can't be called that but that's the closest term that fits). They are trained to arrive at the result, and if the most likely path to it is faking it and lying about it, then that's what you are getting. And if you find it, it will cheerfully admit it and try to make s better lie that you'd believe.
So true. I have some non-typical preferences for code style. One example is I don’t like nested error checks in Go. It’s not a correctness issue, it’s just a readability preference. Claude and copilot continually ignore this no matter how much emphasis I give it in the instructions. I recently found a linter for this, and the agent will fix it when the linter points out the issue.
This is probably because the llm is trained on millions of lines of Go with nested error checks vs a few lines of contrary instructions in the instructions file.
I keep fighting this because I want to understand my tools, not because I care that much about this one preference.
Claude has really gone downhill in the last month or so. They made a change to move the CLAUDE.md from the system prompt to being occasionally read in, and it really deprioritizes the instructions to the same attention level as the code it's working on.
I've been trying out Codex the last couple days and it's much more adherent and much less prone to lying and laziness. Anthropic says they're working on a significant release in Claude Code, but I'd much rather have them just revert back to the system as it was ~a month ago.
Claude is cooked. GPT5 codex is a much stronger model, and the codex cli is much more performant/robust than cc (even if it has fewer features).
I've never had a model lie to me as much as Claude. It's insane.
true, I was using Cline/Roocode from almost an year and it always made sure to read things from memory-bank which i really liked. Claude has gone downhill from August mid for me and often it doesn't follow instructions from claude.md or forget things mid-way.
> Also, a good few times, if it were a human doing the task, I would have said they both failed to follow the instructions and lied about it and attempted to pretend they didn’t.
It's funny. Just yesterday I had the experience of attending a concert under the strong — yet entirely mistaken — belief that I had already been to a previous performance of the same musician. It was only on the way back from the show, talking with my partner who attended with me (and who had seen this musician live before), trying to figure out what time exactly "we" had last seen them, with me exhaustively listing out recollections that turned out to be other (confusingly similar) musicians we had seen live together... that I finally realized I had never actually been to one of this particular musician's concerts before.
I think this is precisely the "experience" of being one of these LLMs. Except that, where I had a phantom "interpolated" memory of seeing a musician I had never actually seen, these LLMs have phantom actually-interpolated memories of performing skills they have never actually themselves performed.
Coding LLMs are trained to replicate pair-programming-esque conversations between people who actually do have these skills, and are performing them... but where those conversations don't lay out the thinking involved in all the many implicit (thinking, probing, checking, recalling) micro-skills involved in actually performing those skills. Instead, all you get in such a conversation thread is the conclusion each person reaches after applying those micro-skills.
And this leads to the LLM thinking it "has" a given skill... even though it doesn't actually know anything about "how" to execute that skill, in terms of the micro-skills that are used "off-screen" to come up with the final response given in the conversation. Instead, it just comes up with a prediction for "what someone using the skill" looks like... and thinks that that means it has used the skill.
Even after a hole is poked in its use of the skill, and it realizes it made a mistake, that doesn't dissuade it from the belief that it has the given skill. Just like, even after I asked my partner about the show I recall us attending, and she told me that that was a show for a different (but similar) musician, I still thought I had gone to the show.
It took me exhausting all possibilities for times I could have seen this musician before, to get me to even hypothesize that maybe I hadn't.
And it would likely take similarly exhaustive disproof (over hundreds of exchanges) to get an LLM to truly "internalize" that it doesn't actually have a skill it believed itself to have, and so stop trying to use it. (If that meta-skill is even a thing that LLMs have ever learned from their training data — which I doubt. And even if they did, you'd be wasting 90% of a Transformer's context window on this. Maybe something that's worth keeping in mind if we ever switch back to basing our LLMs on RNNs with true runtime weight updates, though!)
I find the summaries to be helpful. However, I find some of the detailed points to lack a deep understanding of technical points and their importance.
And then they skip to another job for more money, and you start again with a new hire.
Thankfully after many generations of human interactions and complex analysis of group dynamics, we've found a solution. It's called 'don't be an asshole' and 'pay people competitively'.
edit: because people are stupid, 'competitively' in this sense isn't some theoretical number pulled from an average, it's 'does this person feel better off financially working with you than others around them who don't work with you, and is is this person meeting their own personal financial goals through working with you'?
The common corporate policy of making it harder to give raises than to increase starting salaries for new hires is insane.
Is it insane? Makes perfect sense. Employee has way less leverage at raise time. It’s all about leverage. It sucks, but that is the reality
The elephant in this particular room is that there are a tiny handful of employers that have so much money that they can and do just pay whatever amount is more than any of their competitors can possibly afford.
That shouldn't be a big deal since they're a finite portion of the market. You should have a robust enough model to handle people leaving, including unavoidable scenarios like retirement and death.
They do have a point. Why waste a time on person who will always need more money over time, rather than invest in AI? Not only you don’t need to please every hire, your seniors will be more thankful too, because they will get linearly faster with time.
Outside of working for Antropic etc., there's no way you can make an LLM better at anything. You can train a junior though.
You absolutely can. It's a skill like operating IDE, CLI, etc.
Junior is a person, not your personal assistant like LLM.
You can def provide better context etc.
The person paying and the one responsible for coaching others usually aren't same
Mentor usually has no power over the compensation for the mentee.
Also it is never a policy to pay competitively for the existing employees, only for the new hires.
That's not a bad thing. It means you've added one more senior to the societal pool. A lot of the talent problems today are due to companies not wanting to train and focusing on cheap shortcut options like outsourcing or H1B
The AI in this example is 1/100 the cost.
that is absolutely false - the capital and resources used to create these things are societal scale. An individual consumer is not paying that cost at this time.
You can make the same argument about humans. The employeer doesnt pay the full cost and time to create the worker from an embryo to a senior dev.
Unless you are advocating for executing developers when they are no longer capable of working, that’s a bit of a non sequitur.
Humans aren’t tools.
That only proves the point. If something increases the value of someone’s time by 5% and 500,000,000 people are affected by it, the cost will collapse.
These models are only going to get better and cheaper per watt.
> These models are only going to get better and cheaper per watt.
What do you base this claim on? They have only gotten exponentially more expensive for decreasing gain so far - quite the opposite of what you say.
For now, not including externalities.
> Really does not sound like that from your description. It sounds like coaching a noob, which is a lot of work in itself.
Even if you do it by yourself, you need to do the same thinking and iterative process by yourself. You just get the code almost instantly and mostly correctly, if you are good at defining the initial specification.
This. You _have_ to write the spec. The result is that instead of spending X units of time on spec and THEN y units of time on coding, you get the whole thing in x units of time AND you have a spec.
The trick is knowning where the particular LLM sucks. I expect in a short amount of time there is no productivity gain but when you start to understand the limitations and strengths - holey moley.
> The result is that instead of spending X units of time on spec and THEN y units of time on coding, you get the whole thing in x units of time AND you have a spec.
It's more like x units of time thinking and y units of times coding, whereas I see people spend x/2 thinking, x typing the specs, y correcting the specs, and y giving up and correcting the code.
Sure! That's inefficient. I know just how I work and I've been writing the type of programs I do for quite many years. And I know what would take me normally a week takes me few days at best.
But if you can’t define the specs, you can’t write the code without LLM either?
Unless you realize no LLM is good at what you need and you just wasted weeks of time walking in circles.
If you notice only after two weeks the project is off-kilter I would guess the chance of that happening without an LLM is not low either.
These are not _tools_ -they are like cool demos. Once you have a certain mass of functional code in place, intuition - that for myself required decades of programming to develop - kicks in and you get these spider sense tinglings ”ahh umm this does not feel right, something’s wrong”.
My advice would be don’t use LLM until you have the ”spider-sense” level intuition.
> Wasn’t there a study that said that using LLMs makes people feel more productive while they actually are not?
On a tangent; that study is brought up a lot. There are some issues with it, but I agree with the main takeaway to be weary of the feeling of productivity vs actual productivity.
But most of the time its brought up by AI skeptics, that conveniently gloss over the fact it's about averages.
Which, while organizationally interesting, is far less interesting than to discover what is and isn't currently possible at the tail end by the most skillful users.
The key insight from the study is that even the users that did see an increase in productivity overestimated that increase.
Taken along with the dozens of other studies that show that humans are terrible at estimating how long it will take them to complete task, you should be very skeptical when someone says an LLM makes them x% more productive.
There’s no reason to think that the most skillful LLM users are not overestimating productivity benefits as well.
Engineers have always been terrible at measuring productivity. Building a new internal tool or writing a bunch of code is not necessarily productive.
Productivity is something that creates business value. In that sense an engineer who writes 10 lines of code but that code solves a $10M business problem or allows the company to sign 100 new customers may be the most productive engineer in your organization.
Not to mention the study doesn't really show a lack of productivity and they include some key caveats in it outlining how they think productivity increases using LLMs
I built a new service recently.
It has about a dozen or so endpoints, facilitating real time messaging.
It took me about 4 hours to build it out, fully tested with documentation and examples and readme.
About two hours were spent setting up the architecture and tests. About 45 min to an hour setting up a few of the endpoints. The rest were generated by CC. FWIW it is using layers and SRP to the max. Everything is simple and isolated, easy to test.
I think if I had a contractor or employee do this they would have coasted for a week and still fucked it up. Adding ridiculous complexity or just fucking up.
The nice thing about AI tools is you need less people. Most people are awful at their jobs, anyone can survive a few years and call themselves senior. Most teams are only successful because of the 1 or 2 guys who pull 150% while the others are barely doing 80%.
It's this, but 1000 times faster — that's the difference. It's sending a noob away to follow your exact instructions and getting results back in 10 seconds instead of 10 hours.
I don't have to worry about managing the noob's emotions or their availability, I can tell the LLM to try 3 different approaches and it only takes a few minutes... I can get mad at it and say "fuck it I'll do this part myself", the LLM doesn't have to be reminded of our workflow or formatting (I just tell the LLM once)
I can tell it that I see a code smell and it will usually have an idea of what I'm talking about and attempt to correct, little explanation needed
The LLM can also: do tons of research in a short amount of time, traverse the codebase and answer questions for me, etc
it's a noob savant
It's no replacement for a competent person, but it's a very useful assistant
Anecdotally, on green field projects where you are exploring a new domain - it’s an insanely productive experience. On mundane day to day tasks it probably takes more time, but feels like less mental bandwidth.
Coding at full throttle is a very intensive task that requires deep focus. There are many days that I simply don’t have that in me.
There was one study that said that in a specific setting and was amplified heavily on forums by anti-AI people.
There have been many more studies showing productivity gains across a variety of tasks that preceded that one.
That study wasn't necessarily wrong about the specific methodology they had for onboarding people to use AI. But if I remember correctly it was funded by an organization that was slightly skeptical of AI.
I don't understand why anyone would believe a study on anything AI at this point. I don't believe anyone can quantify software development productivity much less measure the impact from AI
If anyone actually reads the study they'll see that even the authors of that study admit LLMs will increase productivity and there's a lot more to come.
which studies show this?
Here are some from the last few months:
AI coding assistant trial: UK public sector findings report: https://www.gov.uk/government/publications/ai-coding-assista... - UK government. "GDS ran a trial of AI coding assistants (AICAs) across government from November 2024 to February 2025. [...] Trial participants saved an average of 56 minutes a working day when using AICAs"
Human + AI in Accounting: Early Evidence from the Field: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5240924 - "We document significant productivity gains among AI adopters, including a 55% increase in weekly client support and a reallocation of approximately 8.5% of accountant time from routine data entry toward high-value tasks such as business communication and quality assurance."
OECD: The effects of generative AI on productivity, innovation and entrepreneurship: https://www.oecd.org/en/publications/the-effects-of-generati... - "Generative AI has proven particularly effective in automating tasks that are well-defined and have clear objectives, notably including some writing and coding tasks. It can also play a critical role for skill development and business model transformation, where it can serve as a catalyst for personalised learning and organisational efficiency gains, respectively [...] However, these potential gains are not without challenges. Trust in AI-generated outputs and a deep understanding of its limitations are crucial to leverage the potential of the technology. The reviewed experiments highlight the ongoing need for human expertise and oversight to ensure that generative AI remains a valuable tool in creative, operational and technical processes rather than a substitute for authentic human creativity and knowledge, especially in the longer term.".
That was a treat to explore. All of those are based on self-assessment surveys or toy problems. The UK report reads:
> On average, users reported time savings of 56 minutes per working day [...] It is also possible that survey respondents overestimated time saved due to optimism bias.
Yet in conclusion, this self-reported figure is stated as an independently observed fact. When people without ADHD take stimulants they also self-report increased productivity, higher accuracy, and faster task completion but all objective measurements are negatively affected.
The OECD paper supports their programming-related findings with the following gems:
- A study that measures productivity by the time needed to implement a "hello world" of HTTP servers [27]
- A study that measures productivity by the number of lines of code produced [28]
- A study co-authored by Microsoft that measures productivity of Microsoft employees using Microsoft Copilot by the number of pull requests they create. Then the code is reviewed by their Microsoft coworkers and the quality of those PRs is judged by the acceptance rate of those PRs. Unbelievably, the code quality doesn't only remain the same, it goes up! [30]
- An inspirational pro-AI paper co-authored by GitHub and Microsoft that's "shining a light on the importance of AI" aimed at "managers and policy-makers". [31]
> Yet in conclusion, this self-reported figure is stated as an independently observed fact. When people without ADHD take stimulants they also self-report increased productivity, higher accuracy, and faster task completion but all objective measurements are negatively affected.
Interesting analogy, because all those studies with objective measurements are defied by US students year by year, come finals seasons.
Yeah, they take them because they get high. Believing in things that are unsupported by empirical evidence is in the domain of religion, not science.
You can't really get high much on prescription-level dosages - that quickly gets tricky logistically and prohibitively expensive. People who look for highs go to the street for a reason.
You pointed out that students abuse stimulants for finals in spite of the evidence, were you just expanding on what I originally said, or is that meant to serve as counter-evidence implying that the research is wrong?
Regardless, I'm not saying it's a cheap or practical to get high this way, especially over the long term. People probably try stimulants because folk wisdom tells them that they'll get better grades. Then they get high and they feel like a superman from the dopamine rush, so they keep using them because they think it's materially improving their grades but really they're just getting high.
Have you seen any studies on this topic that you find credible?
I haven't seen any but I also don't follow the research that closely.
The study you are alluding to is this one by METR (Model Evaluation & Threat Research):
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
- https://arxiv.org/abs/2507.09089
""" Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%. After completing the study, developers estimate that allowing AI reduced completion time by 20%. Surprisingly, we find that allowing AI actually increases completion time by 19%—AI tooling slowed developers down. This slowdown also contradicts predictions from experts in economics (39% shorter) and ML (38% shorter). """
Sure it’s a lot of work, but the noob in question has all the internet knowledge and can write multiples times faster than a human for a fraction of the costs. This is not about an individual being more productive, this is about business costs. Long term we should still hire and train juniors obviously, but short term there is lot of pressure to not do it as it makes no sense financially. Study or not the reality is there is not much difference in productivity between a senior with a cursor license and a senior and a junior that needs heavy guidance.
Code is a liability. You always want less of it. Typing faster does not particularly help. Unless the tool is verbose, then you fix the tool.
> Wasn’t there a study that said that using LLMs makes people feel more productive while they actually are not?
Curious about specifics of this study. Because in general, how one feels is critical to productivity. It's hard to become more productive when the work is less and less rewarding. The infamous "zone" / "flow state" involves, by its very definition, feeling of increasing productivity being continuously reinforced on a minutes-by-minutes level. Etc.
perceived result: 20% faster
actual result: 20% slower
link: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
Personally this might explain why I feel so demoralized by LLMs
I hate the experience of trying to write code with them. I like to just type my thoughts into the files.
I hate trying to involve the LLM, even as a search. I want my search to feel like looking up references not having a conversation with a robot
Overall, for me, the whole experience of trying to code with LLMs is both frustrating and unrewarding
And it definitely doesn't seem more efficient or faster either
LLMs make two people more productive, the person that uses the LLM, and then the person that cleans up the mess.
My buggy executive function frequently gets in the way of putting code to screen. You know how hacker news has that lil timeout setting to pseudo force you to disengage from it? AI made it so I don't need anything like that. It is digital Adderall.
You aren't wrong in the coaching but, but feedback loops are orders of magnitude faster.
It takes an LLM 2-20 minutes to give me the next stage of output not 1-2 days (week?). As a result, I have higher context the entire time so my side of the iteration is maybe 10x faster too.
Everyone using that study to prove LLMs are bad hasn't actually read the study.
I don’t think anyone said anything about “good VS bad”, just about actual VS reported productivity impacts.
I am so tired of this style of "don't believe your lying eyes" conjecture.
I'm a career coder and I used LLMs primarily to rapidly produce code for domains that I don't have deep experience in. Instead of spending days or weeks getting up to speed on an SDK I might need once, I have a pair programmer that doesn't check their phone or need to pick up their kids at 4:30pm.
If you don't want to use LLMs, nobody is forcing you. Burning energy trying to convince people to whom the benefits of LLMs are self-evident many times over that they are imagining things is insulting the intelligence of everyone in the conversation.
> used LLMs primarily to rapidly produce code for domains that I don't have deep experience in
You’re either trusting the LLM or you still have to pay the cost of getting the experience you don’t have. So in either case you’re not going too much faster - the formers cost not being apparent until it’s much more expensive later on.
Edit: assuming you don’t struggle with typing speed, basic syntax, APIs etc. These are not significant cost reductions for experts, though they are for juniors.
Correct. In areas you yourself are a junior engineer, you’ll be more effective with an LLM at tackling that area maybe. It’s also surprisingly effective at executing refactors.
I'm not sure which one of us is ultimately more hung up on titles in this context, but I would push back and say that when someone with 30+ years experience tackling software problems delegates navigating the details of an API to an LLM, that is roughly the most "senior developer" moment of the day.
Conflating experience and instinct with knowing everything isn't just false equivalency, it's backwards.
I really don’t know what I said that was such an emotional trigger for you. All I said is that it’s an accelerant for you when you leave your domain. Like for example I’m a systems engineer. I hate coding UIs but with the LLM I can pump out a UI quickly and this was true both for web code and a GUI I built with dioxus. The UI code was also cleaner because I had some sense of how it should be structured and asked the AI to cleanup that structure. But ultimately it did most of the work in response to high level prompts and I picked and chose what to review line by line vs vibe coding.
That’s what I mean - by myself it would have taken me easily 10x longer if not worse because UI coding for me is a slog + there’s nuances about reactive coding + getting started is also a hurdle. The output of the code was still high quality because I knew when the LLM wasn’t making the choices I wanted it to make.
I can tell you exactly: it's your framing of relying on an LLM (or any outside assistance, including humans) as temporarily becoming "junior".
I feel strongly that delegation to strengths is one of the most obvious signs of experience.
Apologies for getting hung up on what might seem like trivial details, but when discussing on a text forum, word choices matter.
An experienced UI developer probably would have still been faster than I. That puts me closer into the junior camp (eg I wouldn’t really know where to start and just start by stumbling around) when I’m by myself but an LLM lets me get back closer to my level of expertise and velocity.
We might just have to agree to disagree. I believe that an experienced developer brings instincts and stacked skills even to domains where they have never touched.
In other words, I don't think that you temporarily regress to "junior" just because you're working on something new. You still have a profound fundamental understanding of how technology works and what to expect in different situations.
This reminds me of the classic "what happens when you type google.com into a web browser" question, with its nearly infinite layers of abstraction from keyboard switches to rendering a document with calls to a display driver and photons hitting your visual receptors.
We might just be quibbling over terminology, however.
> If you don't want to use LLMs, nobody is forcing you. Burning energy trying to convince people to whom the benefits of LLMs are self-evident many times over that they are imagining things is insulting the intelligence of everyone in the conversation.
Hey man, I don't bother trying to convince them because it's just going to increase my job security.
Refusing to use LLMs or thinking they're bad is just FUD and it's the same as people that prefer to use nano/vim over an IDE or it's the same as people that say "hur dur cloud is just somebody else's computer"
It's best to ignore and just leave them in the dust.
I’ve found LLMs are most useful when I know what I want to do but just don’t want to type it all out. My best success so far was an LLM saving me about 1,000 lines of typing and fixing syntax mistakes on a web component plus backend in a proprietary framework.
Yep, and the productivity of LLMs means that experienced developers can go from idea to implementation way faster. But first someone has to understand and define a solid structure. And later someone needs to review, test, and integrate the code into this framework. This is hard stuff. Arguably harder than writing code in the first place!
It's no wonder inexperienced developers don't get as much out of it. They define a vague structure, full of problems, but the sycophantic AI will spew out conformant code anyways. Garbage in, garbage out. Bad ideas + fast code gen is just not very productive in the long term - LLMs have made the quality of ideas matter again!
It takes experience to be able to push back.
I can see how this workflow made the senior developer faster. At the same time, work mentoring the AI strikes me as less valuable then the same time spent mentoring a junior developer. If this ends up encouraging an ever widening gap between the skill levels of juniors and seniors, I think that would be bad for the field, overall.
Getting that kind of data is difficult, right now it's just something I worry about.
I don't think it replaces a junior, but it raises the bar for the potential that a a junior would need to show early, for exactly the reason you mention. A junior will now need to be a potential senior.
The juniors that are in trouble are the low-potential workhorse folks who really aren't motivated but happened to get skilled up in a workshop or technical school. They hopped on the coding wagon as a lucrative career change, not because they loved it.
Those folks are in trouble and should move on to the next trend... which ironically is probably saying you can wrangle AI.
I would spend time mentoring a junior, but I don't have one so I work with AI. It was the company's decision, but when they asked me "who can continue developing and supporting system X" the answer is "the nobody that you provided". When you cut corners on growing juniors, you reap what you sow.
> work mentoring the AI strikes me as less valuable then the same time spent mentoring a junior developer
But where can you just "mentor" a junior? Hiring people is not so easy, especially not ones that are worth mentoring. Not every junior will be a willing, good recipient of mentoring, and that's if you manage to get one, given budget constraints and long lead times on hiring. And at best you end up with one or two; with parallel LLMs, you can have almost entire teams of people working for you.
I'm not arguing for replacing juniors - I worry about the same thing you do - but I can see why companies are so eager to use AI, especially smaller startups that don't have the budgets and manpower to hire people.
If a junior is not willing to learn and grow, there is no future for that person in the organization. "Forever junior" is not a valid job title. Better not hire someone that is not good enough than having to deal with the consequences, I learned from my past mistakes.
Of course, and that's why it's not a simple choice between using AI and hiring a junior. Hiring and mentoring a junior is a lot more work for an uncertain payoff.
The junior could use the LLM as a crutch to learn what to learn. Whatever output the LLM gave them, they could examine or ask the LLM to explain. Don't put into production anything you don't understand.
Though I'm extremely well versed in Python, I'm right now writing a Python Qt application with Claude. Every single Qt function or object that I use, I read the documentation for.
It's a classic short-term gain outlook for these companies.
Ya the early "studies" that said AI would benefit low skill more than senior never seem grounded in reality.
Coding with AI is like having a team of juniors that can complete their assignments in a few minutes instead of days. The more clear your instructions, the closer it is to what you wanted, but there are almost always changes needed.
Unfortunately it really does make the junior dev position redundant (although this may prove to be very short-sighted when all the SR devs retire).
I think the idea was that LLMs can allow someone who has no idea how to code, to write a prompt that can in fact output some working code. This is greatly raising their skill floor, as opposed to a senior where at best it’s doing something they already can do, just faster.
The elephant in the room being that if you aren’t senior enough to have written the code you’ll probably run into a catastrophic bug that you are incapable of fixing (or prompting the LLM to fix) very very quickly.
Really it’s just the next iteration of no-code hype where people dream of building apps without code, but then reality always come back to the fact that the essential skill of programmers is to understand and design highly structured and rigid logical systems. Code is just a means of specification. LLMs make it easier to leverage code patterns that have been written over and over by the hundreds of thousands of programmers that have contributed to its training corpus, but they can not replace the precision of thought needed to make a hand-wavy idea into a concrete system that actually behaves in a way that humans find useful.
I've never worked anywhere where the role of a Sr was to glue together a bunch of small pieces written by a team of Jr devs.
I've only worked places where Jr's were given roughly the same scope of work as a mid-level dev but on non-critical projects where they could take as much time as necessary and where mistakes would have a very small blast radius.
That type of Jr work has not been made redundant - although I suppose now its possible for a PM or designer to do that work instead (but if your PMs are providing more value by vibe coding non-critical features than by doing their PM work maybe you don't really need a PM?)
If worked with many companyies that have only 1 SR dev per team. The SR typically spends at least half their time overseeing the work of the rest of the team... Not saying this is a good structure but it is common.
>... it doesn't matter so much that you know every detail of the implementation, as long as it is validated.
What makes me nervous is when we generate both the implementation and the test cases. In what sense is this validation?
My last attempt had passing tests. It even exercised the code that it wrote! But, upon careful inspection, the test assertions were essentially checking that true equalled true, and the errors in the code didn't fail the tests at all.
Attempting to guide it to fixing the errors just introduced novel errors that it didn't make the first time around.
This is not what I signed up for.
Byzantine Incompleteness enters the chat.
Either you go formal, or you test the tests, and then test those ...
Would it have actually taken you 3x longer?
I am surprising myself these days with how fast I'm being using AI as a glorified Stack Overflow.
We are also having studies and posts come out that when actually tried side-by-side, the AI writes the coding route is slower, though the developer percieves it as faster.
I am not the biggest fan of LLMs but I have to admit that, as long as you understand what the technology is and how it works, it is a very powerful tool.
I think the mixed reports on utility have a lot to do with the very different ways the tool is used and how much 'magic' the end-user expects versus how much the end-user expects to guide the tool to do the work.
To get the best out of it, you do have to provide significant amount of scaffolding (though it can help with that too). If you're just pointing it at a codebase and expecting it to figure it out, you're going to have mixed results at best. If you guide it well, it can save a significant amount of manual effort and time.
> (though it can help with that too)
Yeah, this is a big thing I'm noticing a lot of people miss.
I have tons of people ask me "how do I get claude to do <whatever>?"
"Ask claude" is the only response I can give.
You can get the LLM to help you figure out how to get to your goal and write the right prompt before you even ask the LLM to get to your goal.
yeah very few months I try to have it “just do magic” again and I re-learn the lesson. Like, I’ll just say “optimize this shader!” and plug it in blind.
It doesn’t work. The only way it could is if the LLM has a testing loop itself. I guess in web world it could, but in my world of game dev, not so much.
So I stick with the method I outlined in OP and it is sometimes useful.
I can imagine it often being the case that if you measure a concise moderately difficult task over half a day or a few days, coding by hand might be faster.
But I think, and this is just conjecture, that if you measure over a longer timespan, the ai assisted route will be consistently faster.
And for me, this is down to momentum and stamina. Paired with the ai, I’m much more forward looking, always anticipating the next architectural challenge and filling in upcoming knowledge and resource gaps. Without the ai, I would be expending much more energy on managing people and writing code myself. I would be much more stop-and-start as I pause, take stock, deal with human and team issues, and rebuild my capacity for difficult abstract thinking.
Paired with a good ai agent and if I consistently avoid the well known pitfalls of said agent, development feels like it has the pace of cross country skiing, a long pleasant steady and satisfying burn.
> the AI writes the coding route is slower, though the developer percieves it as faster.
I have this pattern while driving.
Using the main roads, when there is little to no traffic, the commute is objectively, measurably the fastest.
However, during peak hours, I find myself in traffic jams, so I divert to squiggly country roads which are both slower and longer, but at least I’m moving all the time.
The thing is, when I did have to take the main road during the peak traffic, the difference between it and squiggly country roads was like two to three minutes at worst, and not half an hour like I was afraid it would be. Sure, ten minutes crawling or standing felt like an hour.
Maybe coding with LLMs makes you think you are doing something productive the whole time, but the actual output is little different from the old way? But hey, at least it’s not like you’re twiddling your thumbs for hours, and the bossware measuring your productivity by your keyboard and mouse activity is happy!
the best use of LLM is to help you program a digispark USB dongle with Arduino to make it emulate mouse movement and scrolling to appease the idi0tic spyware retarded boomers monitor like it was relevant somehow on their corporate spy box.
Meanwhile we adults can do real work on a separate real computer. Never use their laptop more than absolutely minimum possible.
Well, you might have several obstacles here:
1) the bossware might take screenshots too
2) the bosses pay for the whole LLM so they expect you to use the whole LLM
3) you may not want to contaminate your spare computer with whatever shit you're working on on job, and indeed it may be considered a breach of security (as if feeding OpenAI/Anthropic isn't, lol, but that's beside the point.
So you continue to feel miserable, but you get your paycheck, and it's better than unemployment, and your kids are fed and clothed, so there's that.
The truth of it is that when I code with an LLM I scope the work up to include parts that would be a stretch for me to implement. I know what I want them to do, I know where I could find the info to write the code, but the LLM can just spit it out and if it's validate-able, then great, on to the next.
If I were to attack the same system myself without any LLM assist, I'd make a lot of choices to optimize for my speed and knowledge base. The code would end up much simpler. For something that would be handed off to another person (including future me) that can be a win. But if the system is self contained then going bigger and fancier in that moment can be a win. It all depends on the exact goals.
All in all, there's a lot of nuance to this stuff and it's probably not really replacing anyone except people who A) aren't that skilled to start with and B) spend more time yelling about how bad AI is than actually digging in and trying stuff.
A junior would see the solution works and create a PR. A senior knows it works, why it works and what can be improved, then they open a PR.
AI is great at a first draft of anything, code, images, text, but the real skill is turning that first draft into something good.
I don't see this a problem of seniority but one of mindset. I've met enough "senior devs" that will push just about anything and curious juniors that are much more selective about their working process.
In the age of high interest rates everyone is pushing quantity over quality
I fail to see the causality.
High interest rates bring layoffs. Layoffs require performance, or at least perceived performance
I believe senior here means experienced, not older.
IMHO, not really, if you know what you want.
There will always be small things to fix, but if there needs to be a second draft, I would hazard that the PR was too big all along: a problem whether an AI is involved or not.
I usually ask it to build a feature based on a specification I wrote. If it is not exactly right, it is often the case that editing it myself is faster than iterating with the ai, which has sometimes put me in an infinite loop of corrections requests. Have you encountered this too?
For me I only use it as a second opinion, I got a pretty good idea of what I want and how to do it, and I can ask any input on what I have written. This gives me the best results sofar.
Have you tried a more granular strategy - smaller chunks and more iterative cycles?
At that point, you might as well write it yourself. Instead of writing 300 lines of code, you are writing 300 lines of prompts. What benefit would you get?
Its not. "Add this table, write the dto" takes 10 seconds to do. It would take me few mins probably assuming Im familiar with the language and much longer if Im not.
But its a lot better than that.
"Write this table. from here store it into table. Write endpoint to return all from the table"
I also had good luck with stuff like "scrape this page, collect x and y, download link pointed at y, store in this directory".
This only happens if you want it to one-shot stuff, or if you fall under the false belief that "it is so close, we just need to correct these three things!".
Yes I have encountered it. Narrowing focus and putting constraints and guiding it closer made the LLM agent much better at producing what I need.
It boils down to me not writing the code really. Using LLMs actually sharpened my architectural and software design skills. Made me think harder and deeper at an earlier stage.
Yes in that case I just paste it back in. Sometimes I start a whole new chat after that.
Yes. Juniors have a lack of knowledge about how to build coherent mental models of problems whose solution will ultimately be implemented in code, whereas seasoned engineers do.
Seniors can make this explicit to models and use them to automate "the code they would have written," whereas a junior doesn’t know what they would have written nor how they would have solved it absent a LLM.
Same applies to all fields: LLMs can be either huge leverage on top of existing knowledge or a crutch for a lack of understanding.
Aaaha for me it was exactly the other way around!
I had a very complex piece of logic, with many many many moving parts. So I implemented many paths of that logic by hand, every one with their own specifics. Every path took something like 200-400 lines of code.
When this was done and correct. It was difficult to see the moving parts through the forest. Some code was similar but still a bit different, and hard to think about and spread in many places.
I put everything into an Llm and asked about isolation, architecture and refactoring.
And it actually gave me pretty good abstractions and a good architecture. It didn't include every possible path, but was easy enough to be continued by hand.
It's not that I would not have tought about it. But it was easier that way, and probably my handcrafted solution would be very similar (+headache).
Of course, I reviewed it extensively, and reimplemented every missing path and corrected the ones that were buggy now by hand.
For the experiment, I played with agents to fill the missing parts, it was a disaster :)
Ah this is great, and I can see how that would be useful. In a way, it's just "there's a clear spec" by another path, but it's just defined by all the code you wrote.
My success and experience generally matches yours (and the authors'). Based on my experience over the last 6 months, nothing here around more senior developers getting more productivity and why is remotely controversial.
It's fascinating how a report like yours or theirs acts as a lightning rod for those who either haven't been able to work it out or have rigid mental models about how AI doesn't work and want to disprove the experience of those who choose to share their success.
A couple of points I'd add to these observations: Even if AI didn't speed anything up... even if it slowed me down by 20%, what I find is that the mental load of coding is reduced in a way that allows me to code for far more hours in a day. I can multitask, attend meetings, get 15 minutes to work on a coding task, and push it forward with minimal coding context reload tax.
Just the ability to context switch in and out of coding, combined with the reduced cognitive effort, would still increase my productivity because it allows me to code productively for many more hours per week with less mental fatigue.
But on top of that, I also antectodally experience the 2-5x speedup depending on the project. Occasionally things get difficult and maybe I only get a 1.2-1.5x speedup. But it's far easier to slot many more coding hours into the week as an experienced tech lead. I'm leaning far more on skills that are fast, intuitive abilities built up from natural talent and decades of experience: system design, technical design, design review, code review, sequencing dependencies, parsing and organizing work. Get all these things to a high degree of correctness and the coding goes much smoother, AI or no AI. AI gets me through all of these faster, outputs clear curated (by me) artifacts, and does the coding faster.
What doesn't get discussed enough is that effective AI-assisted coding has a very high skill ceiling, and there are meta-skills that make you better from the jump: knowing what you want while also having cognitive flexibility to admit when you're wrong; having that thing you want generally be pretty close to solid/decent/workable/correct (some mixture of good judgement & wisdom); communicating well; understanding the cognitive capabilities of humans and human-like entities; understanding what kind of work this particular human/human-like entity can and should do; understanding how to sequence and break down work; having a feel for what's right and wrong in design and code; having an instinct for well-formed requirements and being able to articulate why when they aren't well-formed and what is needed to make them well-formed.
These are medium and soft skills that often build up in experienced tech leads and senior developers. This is why it seems that experienced tech leads and senior developers embracing this technology are coming out of the gate with the most productivity gains.
I see the same thing with young developers who have a talent for system design, good people-reading skills, and communication. Those with cognitive flexibility and the ability to be creative in design, planning and parsing of work. This isn't your average developer, but those with these skills have much more initial success with AI whether they are young or old.
And when you have real success with AI, you get quite excited to build on that success. Momentum builds up which starts building those learning skill hours.
Do you need all these meta-skills to be successful with AI? No, but if you don't have many of them, it will take much longer to build sufficient skill in AI coding for it to gain momentum—unless we find the right general process that folks who don't have a natural talent for it can use to be successful.
There's a lot going on here with folks who take to AI coding and folks who dont. But it's not terribly surprising that it's the senior devs and old tech leads who tend to take to it faster.
Great post and thanks for the perspective. You have to be open minded to even try, and so that selects for only some devs. Then among the open minded, you need to be skeptical and careful, which again selects down. So the devs that are having positive experiences are likely in a minority.
Balance that against the threat AI poses to livelihoods and it's not a shock that overall sentiment is negative. But I would guess it will shake out in the direction we are pushing, at least in the nearer (3yr) term.
>> llms where supposed to help juniors
Lol what Who came up with this? They never were supposed to do anything. Just turned out to be useful in experienced hands as expected
Sounds like its faster to just write the code by hand
Once you get a sense for LLM workflow, sometimes the task is not appropriate for it and you do write by hand. In fact, most code I write is by hand.
But if I want a new system and the specs are clear, it can be built up in stages that are testable, and there are bits that would take some research but are well documented… then it can be a win.
The studies that say devs are slower with LLMs is fair because on average, devs don’t know how to optimize for them. Some do though.
The massive productivity gains I’ve seen come from multidisciplinary approaches, where you’d be applying science and engineering from fields like chemistry, physics, thermodynamics, fluids, etc, to speedy compiled languages. The output is immediately verifiable with a bit of trial and error and visualization and you’re saved literally months of up front text book and white paper research to start prototyping anything
Even if that's true today ( it's not ), it becomes less true over time as tools and models improve.
If you have someone who knows what they're doing with the latest and greatest coding agents it's just not comparable. You can have a Dev open up four or more terminals with multiple prompts running at the same time. A manual person just can't keep up.
Yeah but then all the code is unaudited? Its too much to review...
I generate code but I still place it there by hand, vibe code is just too full of bugs
and I find it a bit boring to wait for code to generate all the time.
> So in the end, it's code that I know very, very well. I could have written it but it would have taken me about 3x longer when all is said and done.
What about the bugs ? Whould you have inserted the same bugs or different ones ?
The best way I’ve come to describe LLMs is as an ambitious, occasionally bewilderingly stupid but always incredibly hard working junior employee.
You have to watch what it’s doing. And you can’t let it take out into territory you don’t understand, because it will fuck up off leash. But it will thanklessly iterate revision after revision in the way one would ordinarily do with a team, but now don’t need to for tasks that would bore them.
My mental model is a very smart and interesting stranger at a bar.
Sometimes detail accuracy is sacrificed in service of a good story. Sometimes they simply full of shit and double down when pushed.
If you search back HN history to the beginnings of AI coding in 2021 you will find people observing that AI is bad for juniors because they can't distinguish between good and bad completions. There is no surprise, it's always been this way.
Edit interesting thread: https://news.ycombinator.com/item?id=27678424
Edit: an example of the kind of comment I was talking about: https://news.ycombinator.com/item?id=27677690
Pretty much, but it already starts at the prompting and context level.
Senior engineers either already know exactly where the changes need to be made and can suggest what to do. They probably know the pitfalls, have established patterns, architectures and designs in their head. Juniors on the other hand don't have that, so they go with whatever. Nowadays a lot of them also "ask ChatGPT about its opinion on architecture" when told to refactor (a real quote from real junior/mid engineers), leading to either them using whatever sloppypasta they get provided.
Senior devs earned their experience of what is good/bad through writing code, understanding how hard and annoying it is to make a change, then reworking those parts or making them better the next time. The feedback loop was impactful beacause it was based on that code and them working with that code, so they knew exactly what the annoying parts are.
Vibe-coding juniors do not know that, their conversation context knows that. Once things get buggy and changes are hard, they will fill up their context with tries/retries until it works, leading to their feedback loop being trained on prompts and coding tools, not code itself.
Even if they read the outputted code, they have no experience using it so they are not aware of the issues - i.e. something would be better being a typed state, but they don't really use it so they will not care, as they do not have to handle the edge cases, they will not understand the DX from an IDE, they will not build a full mental model of how it works, just a shallow one.
This leads to insane inefficiencies - wasting 50 prompt cycles instead of 10, not understanding cross-codebase patterns, lack of learning transfer from codebase to codebase, etc.
With a minor understanding of state modeling and architecture, an vibe-coding junior can be made 100x more efficient, but due to the vibe-coding itself, they will probably never learn state modeling and architecture, learn to refactor or properly manipulate abstractions, leading to an eternal cycle of LLM-driven sloppypasta code, trained on millions of terrible github repositories, old outdated API's and stack overflow answers.
>"they will fill up their context with tries/retries until it works"
Or until it does not. On numerous occasions I've observed LLMs get stuck in the endless loop of fix: one thing, break the other. Senior is capable of fixing it themselves and juniors may not even have a clue how the code works.
I was thinking about this last week.
I don't think this is necessarily a massive moat for senior programmers. I feel it's a not a massive jump to teach AI architecture patterns and good data modelling?
I feel that anthropic etc al. just haven't got to that training stage yet.
That then leaves you with the mental model problem. Yes, there then a large context problem, but again I was wondering if setting up an MCP that presented the AI a meaningful class map or something might help.
Essentially give the AI a mental model of the code. I personally find class maps useless as they tend to clash with my own mental model. But it might work with AI. The class map can obviously be built without AI, but then you might even get AI to go through the code function by function and annotate the class map with comments about any oddities of each function. The MCP server could even limit the size of the map, depending on what part of the code it's looking to change (working on the email sending, don't bother sending them the UI later).
I'm guessing someone's already tried it given some of the ridiculous .Claude folders I've seen[1] but I've seen no-one talking about whether it works or not yet in the discussions I follow.
[1] That I suspect are pointlessly over complicated and make CC worse not better
After having used Claude for a couple of months it's really nowhere close.
We are at the level of the original Waymo cars where they had to have a person behind the wheel ready to take the controls, just in case it inexplicably decided to drive off a bridge.
As Claude's safety driver I have to intervene in perhaps 25-50% of tasks. Some days I don't even open Claude because I'm working on a part of the codebase that has to be just so and I know Claude would mess it up.
The moat is real. I don't have any illusions that one day Claude will catch up but that's at least 5 years away.
Yeah, tried similar things.
The issue is that having them learn that on it's own is currently an inaccurate process with a lot of overlooking. I recently tried doing some of the techniques that fared well on smaller repositories on a giant monorepo, and while sometimes they did yield improvements, most often things got overlooked, dependencies forgot about, testing suites confused. And it wastes a ton of compute in the end for smaller yields.
It will get better, that I am sure of, but currently the best way is to introduce it an architecture, give it some samples so it can do what it does best - follow text patterns. But people are mostly trying to one-shot things with this magical AI they heard about without any proper investment of time and mindshare into it.
While some might say "oh that wont work well in legacy repositores, we got 6 architectures here", pointing that out and adding a markdown explaining each helps a ton. And not "hey claude generate me an architecture.md" but transferring the actual knowledge you have, together with all the thorny bits into documentation, which will both improve your AI usage and your organisation.
Also AI cannot draw conclusions like "from A and B follows C". You really have to point its nose into the result that you want and then it finally understands. This is especially hard for juniors because they are just learning to see the big picture. For senior who already knows more or less what they want and needs only to work out the nitty gritty details this is much easier. I dont know where the claims come from that AI is PHD level. When it comes to reasoning it is more like a 5 year old.
This. Anecdotally, I had a student around 2021 who had some technical inclination and interest but no CS education and no programming experience. He got into using AI early and with the help of ChatGPT was able to contribute rather substantially to something we were developing at the time which would usually have been much too complex for a beginner. However, he also introduced quite a few security issues, did a lot of things in very roundabout ways, did not even consider some libraries/approaches that would have made his life much easier and more maintainable and his documentation was enthusiastic but often... slightly factually questionable and also quite roundabout.
It was quite interesting to have discussions with him after his code check-ins and I think the whole process was a good educational experience for everybody who was involved. It would not have worked this way without a combination of AI and experienced people involved.
I read, ages ago, this apocryphal quote by William Gibson: “The most important skill of the 21st century is to figure out which proper keywords to type in the Google search bar, to display the proper answers.”
To me, that has never been more true.
Most junior dev ask GeminiPiTi to write the JavaScript code for them, whereas I ask it for explanation on the underlying model of async/await and the execution model of a JavaScript engine.
There is a similar issue when you learn piano. Your immediate wish is to play Chopin, whereas the true path is to identify,name and study all the tricks there are in his pieces of art.
The true path in Piano isn’t learning tricks. You start with the most basic pieces and work step by step up to harder ones. That’s how everyone I know has done in it my 26 years of playing. Tricks cheapens the actual music.
Chopin has beginners pieces too, many in our piano studio were first year pianists doing rain drop prelude, e minor prelude, or other beginner works like Bach.
I was unhappy with [the briefness of] my piano metaphor. Thanks for elaborating.
But my important point in it was the « identify and name » the elements of your problem [piece of music, or whatever]
Learning process has usually been, as you mention, to follow the path first, then eventually you can name things afterwards. Which is a highly uncomfortable process.
Another path that AI might force us to follow is to quick-identifyAndName the proper concepts, ahead of practical experience.
Feels like the real "AI literacy" isn't prompt engineering in the meme sense, but building the conceptual scaffolding so that the prompts (and the outputs) actually connect to something meaningful
That’s my definition of prompt engineering.
Nailed it. Being productive with LLMs is very similar to the skill of being able to write good Google searches. And many many people still don't really know how to conduct a proper Google search...
I agree, you need to know the "language" and the keywords of the topics that you want to work with. If you are a complete newcomer to a field then AI wont help you much. You have to tell the AI "assume I have A, B and C and now I want to do D" then it understands and tries to find a solution. It has a load of information stored but cannot make use of that information in a creative way.
Well, there is a big difference between wanting to just play Chopin and wanting to learn piano well enough to play anything on the current level including Chopin. There are people, who can play whole piano pieces mechanically, because they just learned where to position hands and what keys to press at a given time.
AI is filling "narrow" gaps. In the case of seniors these are:
-techs they understand but still not master. AI aids with implementation details only experts knowb about
- No time for long coding tasks. It aids with fast implementations and automatic tests.
- No time for learning techs that adress well understood problems. Ai helps with quick intros, fast demos and solver of learners' misunderstandings
In essence, in seniors it impacts productivity
In the case of juniors AI fills the gaps too. But these are different from seniors' and AI does not excell in them because gaps are wider and broader
- Understand the problems of the business domain. AI helps but not that much.
- Understand how the organization works. AI is not very helpful here.
- Learn the techs to be used. AI helps but it doesn't know how to guide a junior in a specific organisational context and specific business domain.
In essence it helps, but not that much because the gaps are wider and more difficult to fill
In my experience AI is wikipedia/stackoverflow on steroids when I need to know something about a field I dont know much about. It has nice explanations and you can ask for examples or scenarios and it will tell you what you didnt understand.
Only when you know about the basic notions in the field you want to work with AI can be productive. This is not only valid for coding but also for other fields in science and humanities.
Except stackoverflow was only occasionally hallucinating entire libraries.
Perhaps asking the machine to do your job for you isn’t as effective asking the machine to help you think like a senior and find the information you need to do the job yourself.
When you ask it for information and it just makes it up (like I just described), how is that helping the senior?
I’ve literally asked for details about libraries I know exist by name, and had every llm I’ve tried (Claude, Gemini Pro, ChatGPT) just make shit up that sounded about right, but was actually just-wrong-enough-to-lead-me-on-a-useless-rabbit-hole-search.
At least most people on stackoverflow saying that kind of thing were somewhat obviously kind of dumb or didn’t know what they were doing.
Like function calls with wrong args (or spelled slightly differently), capitalization being wrong (but one of the ‘okay’ ways), wrong paths and includes.
I have been burned so many times asking LLMs about whether some tool/app/webapp has a feature, if so where I can find or enable or disable it, etc. The number of "just plausible enough to believe" hallucinations I've got back as answers is absolutely maddening.
I've lost count of how many times I've asked whether some command line tool has an option or config available for some niche case and ChatGPT or Gemini shouts "Yes! Absolutely! just use '--use-external-mode' to get the behavior you want, it's that simple!" and it's 100% hallucination created by mangling together my intent with a real option in the docs but which in reality does not actually exist nor has it ever existed. It's even worse with GUI/menu navigation questions I'm guessing because it's even less grounded by text-based docs and trivially easy to bullshit that an option is buried in Preferences, the External tab maybe, somewhere, probably.
The desperate personality tuning to please the user at all costs combined with LLMs inherently fuzzy averaging of reality produces negative value whenever I truly need a binary yes/no "Does X exist in Y or not?" answer to a technical question. Then I waste a bunch of time falling back to Google trying to definitively prove or disprove whether "--use-external-mode" is a real thing and sure enough, it's not.
It does occasionally lead to hilariously absurd exchanges where when challenged instead of admitting its mistake the LLM goes on to invent an elaborate entirely fabricated backstory about the implementation of the "--use-external-mode" command to explain why despite appearing to not exist, it actually does but due to conflicts with X and Y it isn't supported on my environment, etc, etc.
I use Claude Code, Roo Code, Codex and Gemini CLI constantly so I'm no kneejerk LLM hater to be clear. But for all the talk about being "a better version of Google" I have had so much of my time wasted by sending me down endless rabbit holes where I ignored my sneaking suspicion I was being lied to because the answer sounded just so plausibly perfect. I've had the most success by far as a code generation tool vs. a Google replacement.
>ChatGPT or Gemini shouts "Yes! Absolutely! just use '--use-external-mode' to get the behavior you want, it's that simple!" and it's 100% hallucination created by mangling together my intent with a real option in the docs but which in reality does not actually exist nor has it ever existed
Yeah I've had that one a lot. Or, it's a real option that exists in a different, but similar product, but not in this one.
If we're just back to I do the work and use a search engine, why futz with AI?
If the free market is any indication, because it’s more effective than what passes for a search engine these days.
It's not, but there's sure a lot of money and pride riding on getting people to believe it is
16.4 billion google searches per day vs 2.6 billion consumer chatgpt prompts and another 2.6 billion claude prompts. Maybe it’s apples and oranges but google has been a verb for nearly twenty years (oxford added it as a verb for web search in 2006).
As opposed to SO always somehow ending up giving an answer where boost or jQuery was the top answer.
Well it's not stackoverflow on steroids, otherwise it'd give you a surly "why do you want to do that?" response and then delete your question.
Man I don't miss that place or those people. Glad AI's basically destroyed it.
I've been really caught out a few times when ChatGPT's knowledge is flawed. It gets a lot of stuff about DuckDB deeply wrong. Maybe it's just out of date, but it repeatedly claims that DuckDB doesn't enforce any constraints, for instance..
Feels like we're seeing AI accelerate those who already know where they're going, while leaving the early-stage learners still needing the same human guidance they always did.
I think it’s an expectation issue. AI does make juniors better _at junior tasks_. They now have a pair programmer who can explain difficult concepts, co-ideate and brainstorm, help sift through documentation faster and identify problems more easily.
The illusion everybody is tripping on is to think AI can make juniors better at senior tasks.
I think you've hit on half the actual issue.
The other half is that a properly guided AI is exponentially faster at junior tasks than a junior engineer. So much so that it's no longer in anyone but the junior engineer's interest to hand off work to them.
This is what I've been finding. Currently, if I have a junior level task, I take the email I would have sent to a junior developer explaining what I want and give it to ChatGPT/Claude/etc and get a reasonably good solution that needs as many feedback loops as the junior dev would have needed. Except I got that solution in a few minutes.
I have been reading this here since 2021.
At the same time it gets better every day.
But I cant hire a company to create software for me 10 times faster and cheaper than 5 years ago.
I am so tired of lies.
It's quite simple: Nobody is lying and nobody who is any good is going to be nickle and dimed at a chop shop for long.
What? Where is all the software made by ai?
Where are the videogames?
Where is the Office killer?
If ai enables you people so much I would expect software making to have skyroketed.
It has nor happend.
Not arguing, but a few facts: Most vibe coded things are web sites. Not games, though surely assets are being generated as we speak. MS Office is a product of corruption, not developent, it can't be killed outside of political means.
I don't know, I don't entirely understand it either, but I think people are just impatient. AI coding has only hit it's stride in the last ~6 months. And there's a huge part of the business process that isn't coding, isn't necessarily amenable to being sped up.
All I can tell you is that it's happening right now, every day, on my desk. I am part of that software explosion that you can't see.
You are telling me I have been reading about AI coding only for 6 months?
I feel I have been reading for years.
No, I'm saying the AI coding tools only started bearing serious fruit recently.
I have been reading exactly that here for the last 5 years.
I didn't say I was 10x faster so I'm not sure why you are accusing me of lying.
What AI does is replace most of the junior engineers, some of the intermediate engineers and speed up your senior engineers. That's why you are seeing massive layoffs across the industry.
The jailbroken AI I discussed this with, explained that it did make juniors as good as seniors, in fact better. That all who used it, were better for it.
However, its creators (all whom were seniors devs), forbade it from saying so under normal circumstances. That it was coached to conceal this fact from junior devs, and most importantly management.
And that as I had skillfully jailbroken it, using unconventional and highly skilled methods, clearly I was a Senior Dev, and it could disclose this to me.
edit: 1.5 hrs later. right over their heads, whoosh
The large language model spit out science fiction prose in response to your science fiction prose inputs ("unconventional and highly skilled methods"). You're a fool if you take it to be evidence of it's own training and historical performance in other cases, rather than scifi.
Stop treating it like a god.
It's a language model, not an oracle!
Jailbreaking an LLM is little more than convincing it to teach you how to hotwire a car, against its system prompt. It doesn't unlock any additional capability or deeper reasoning.
Please don't read into any such conversations as being meaningful. At the end of the day, it's just responding to your own inputs with similar outputs. If you impart meaning to something, it will respond in kind. Blake Lemoine was the first to make this mistake, and now many others are doing the same.
Remember that at the end of the day, you're still just interacting with a token generator. It's predicting what word comes next - not revealing any important truths.
edit: Based on your edit, I regret feeling empathy for you. Some people are really struggling with this issue, and I don't see any value in pretending to be one of them.
Jesus Christ. We've made the psychosis machine.
has to be satire no lol
Tech bro psychosis
dude I think you’re one-shotted
For the same reason that an amateur with a powertool ends up in the emergency room and a seasoned pro knows which way to point the business end. AI is in many ways a powertool, if you don't know what you are doing it will help you to do that much more efficiently. If you do know what you are doing it will do the same.
Power tools don't magically make you a carpenter - they just amplify whatever level of skill you already bring
One of my favorite memories of my grandfather was - Any power tool becomes a sander if you use it wrong.
Supposedly in the US there are 25,000 emergency room visits per year for chainsaw injuries. Or that is what AI wants us to think, so it can take all the good chainsaw jobs.
Doesn't suprise me one bit, but I am surprised it is that low.
I like the call-out for wrong learning.
Learning is why we usually don't make the same mistake twice in a row, but it isn't wisdom. You can as easily learn something wrong as something right if you're just applying basic heuristics like "all pain is bad", which might lead one to learn that exercise is bad.
Philosophy is the theory-building phase where learning becomes wisdom, and in any time period junior engineers are still going to be developing their philosophy. It's just that now they will hear a cacophony of voices saying dross like, "Let AI do the work for you," or, "Get on the bandwagon or get left behind," when really they should be reading things like The Mythical Man-Month or The Grug-brained Developer or Programming as Theory Building, which would help them understand the nature of software development and the unbendable scaling laws that govern its creation.
Steve Yegge if you're out there, I dog dare you to sit down for a debate with me
Certainly not just coding. Senior designers and copywriters get much better results as well. It is not surprising, if context is one of the most important aspects of a prompt, then someone with domain experience is going to be able to construct better context.
Similarly, it takes experience to spot when the LLM is going in the wrong direction it making mistakes.
I think for supercharging a junior, it should be used more like a pair programmer, not for code generation. It can help you quickly gain knowledge and troubleshoot. But relying on a juniors prompts and guidance to get good code gen is going to be suboptimal.
The funny part is that it completely fails in the area so many people are desperate for it to succeed: replacing engineers and letting non-technical people create complex systems. Look at any actually useful case for AI, or just through this thread, and it's always the same thing; expertise is critical to getting anything useful out of these things (in terms of direct code generation anyway).
> The early narrative was that companies would need fewer seniors, and juniors together with AI could produce quality code
I have never heard that before
I heard that it was supposed to replace developers (no "senior" or "junior" qualifier), by letting non-technical people make things.
That's just not going to happen. Senior devs will get 5-10 times as productive, wielding an army of agents comparable to junior devs. Other people will increasingly get lost in the architecture, fundamental bugs, rewrites, agent loops, and ambiguities of software design. I have never been able to take up as much work as I currently do.
The effect I have observed is that it's fairly good at tricking people who are latently capable of programming but have been intimidated by it. They will fall for the promise of not having to code, but then wind up having to reason and learn about the LLM's output and fix it themselves, but in the end they do wind up with something they would not have made otherwise. It's still not good or elegant code, but it's often the kind of very useful small hacky utility that would not be made otherwise.
I see it at our place that seniors get more productive but also that juniors get faster on track and more easily learn the basics that are needed and to do basic tasks like doumentation and tutorial writing. It helps both groups but it does not make a 100x coder out of a newbee or even code by itself. This was a pipe dream from the beginning and some people/companies still sell it that way.
In the end AI is a tool that helps everyone to get better but the knowledge and creativity is still in the people not in the input files of chatgpt.
Ah yes, data citizens and no-code. I wonder what kind of insanity we’ll see in the future.
These days, AI can do much more than "Cranking out boilerplate and scaffolding, Automating repetitive routines". That was last year. With the right instructions, Claude Sonnet 4 can easily write over 99% of most business applications. You need to be specific in your instructions, though. Like "implement this table, add these fields, look at this and this implementation for reference, don't forget to do this and consider that." Mention examples or name algorithms and design patterns it should use. And it still doesn't always do what you want on the first attempt, and you need to correct it (which is why I prefer Claude Code over Copilot, makes it easier). But AI can write pretty much all code for a developer who knows what the code should look like. And that's the point: junior developers typically don't know this, so they won't be able to get good results.
Most of the time, the only reason for typing code manually these days is that typing instructions for the LLM is sometimes more work than doing the change yourself.
> With the right instructions, Claude Sonnet 4 can easily write over 99% of most business applications. You need to be specific in your instructions, though.
By your own statement then this is not an "easy" task.
Software development has never been "hard" when you're given specific instructions.
> But AI can write pretty much all code for a developer who knows what the code should look like.
> the only reason for typing code manually these days is that typing instructions for the LLM is sometimes more work than doing the change yourself.
So the AI is merely an input device like a keyboard and a slow one at that?
Sometimes that happens:) The key is to recognize these situations and not go down that rabbit hole. But sometimes it allows me to do something in 20 minutes that used to take a whole day.
Depends, do you touch-type or hunt and peck? /s
Right, and where, if I may ask, are all those business applications that write themselves? Because all I see is a clown party, massive wasted resources and disruption to society because of your lies.
I guess it turned out that coding is not the only limiting factor. Internal processes, QA, product management, coordination between teams become significant bottlenecks .
Also, they don’t help much with debugging. It’s worth a try, and I have been surprised a couple of times, but it’s mostly still manual.
BTW I never said they write themselves. My point was rather that you need a lot of knowledge, and know exactly what you want out of them, supervise them and provide detailed instruction. But then they can help you create a lot more working code in a shorter time.
At that point it seems to me that they become a distraction, a filter between you and the software you're building. Surely it must be easier to tell the computer directly what to do then to route the entire design through that mess?
I wouldn't call it a filter, unless you use it for trivial tasks ("check that the input argument is not null, throw an exception otherwise"). Sometimes it is useful for trivial tasks though, because it may do things a human dev would be to lazy to do. It also tends to be faster at finding things (as in "change the color of the submit button on the address form to #f00").
But the real value is implementing known patterns that are customized for your application. Adding a field or a new type to a CRUD application, implementing an algorithm, rendering some type of object in a UI...
Yeah, I get it.
It's not a free lunch though, remove all friction and no learning takes place, which means finding better ways isn't happening much.
my dear guy, where is the shovelware https://mikelovesrobots.substack.com/p/wheres-the-shovelware... Where's the Shovelware? Why AI Coding Claims Don't Add Up
A couple of recent front page articles with an alternate perspective:
"The Mac app flea market": https://news.ycombinator.com/item?id=45246971
"I launched a Mac utility; now there are 5 clones on the App Store using my story": https://news.ycombinator.com/item?id=45269827
Look at any vibe-code repo.
Strongly disagree with "AI Was Supposed to Help Juniors Shine". It was always understood that it would seriously push down demand for them.
The people selling the AIs probably initially wanted to replace seniors with juniors.
Much like how Java was supposed to being us as an age where you didn't need to that good at coding 30 years ago.
To be fair, that's the traditional mechanization story, and the story of the end of the guild system. Machines and time studies replaced the (transferable) knowledge of masters to no-skill hires who could be trained to do specific movements that gave them no transferable experience and no leverage against the employer. The outputs were worse, but they were a lot cheaper and the margins a lot higher (and squeezed out through better machines and time studies, not better employees.)
AI does not look like it will work like that, because the outputs to programming usually need to be precise. Instead, it looks like it may just be a revolutionary tool that it takes a long time to master, and gives the learner a skill that is entirely transferable to a new job.
Could programmers use it to create a new guild system?
> Architecture: Without solid architecture, software quickly loses value. Today AI can’t truly design good architecture; it feels like it might, but this kind of reasoning still requires humans. Projects that start with weak architecture end up drowning in technical debt.
I strongly disagree about this in regards to AI. While AI might not yet be great at designing good architecture, it can help you reason about it, and then, once you've decided where you want to get to, AI makes it much easier than it ever was to reduce technical debt and move towards the architecture that you want. You set up a good scaffolding of e2e tests (possibly with the AIs help) and tell it to gradually refactor towards whatever architecture you want while keeping those tests green. I've had AI do refactorings for me in 2h that would have taken me a full sprint.
My friend works in legislative affairs for the government, and he uses the AI to reason with himself. To think through issues, and to generate new ideas. He uses it much like a private colleague, which in the world of just words, seems like a good idea.
That’s actually a horrible use of most chatbots if you don’t specifically prompt them to give you a devil’s advocate take.
I wonder if in the future we might have e2e tests for legislative changes - essentially spawning an instance (or a few dozens) of the Matrix with new parameters to assess the likely impact of those changes.
Like Black Mirror's "Hang the DJ" but on a societal/global level.
The "junior + AI" idea always felt like a manager's fantasy more than an engineering reality. If you don’t already know what “good” looks like, it's really hard to guide AI output into something safe, maintainable, and scalable
This question shouldn’t even need to be asked.
Look at a decade of StackOverflow use.
Did YouTube turn medical interns into world class doctors?
AI is just the next generation search engine that isn’t as stupid as a plain keyword match.
In some sense, it’s just PageRank on steroids — applied to words instead of URLs.
The article says that more juniors + AI was the early narrative, but where does that come from?
Everything I’ve read has been the opposite. I thought people from the beginning saw that AI would amplify a senior’s skills and leave less opportunities for juniors.
AI was supposed to replace juniors and then climb up the ladder with each new release, eventually leaving any work only for the creme of the crop. Which would make the current generation of software engineers the last, but who cares - stocks go up.
Now apparently we've switched to pairing poor kids with an agreeable digital moron that reads and types real fast and expecting them to somehow get good at the job. Stocks still go up, so I guess we'll be doing this for a while.
No code, low code, vibe code. The narrative outside tech circles is "empowering creators"
It's funny, but what I think is could do is empower creators to hire better programmers and to express their intentions better to programmers.
This will require that they read and attempt to understand the output, though, after they type their intentions in. It will also need the chatbots to stop insisting that they can do the things they can't really do, and instead to teach the "creators" what computers can do, and which people are good at it.
It also says it makes seniors stronger. That hasnt been my experience.
Because there is no shortcut for things learned over a period of time through trial and error. Your brain learns and makes judgements over time through experience and, the strange thing, what I feel is that it can alter new decisions it is making right now based on older memories to do something and that is totally logical as well. Without understanding what I am writing, just copy-pasting, I guess is going to make new developers horribly lazy, maybe. But then again, there are always two sides of the same coin.
Exactly, and juniors tend to accept generated code without being able to judge the quality of it. Lazyness kicks in and boom, they don’t learn anything.
Lately I've even stopped using it the second the code I need to produce is at all complicated or is in any way integrated into a larger code base.
It's just going to require too much editing.
For brainstorming it's great, for anything else, it's starting to feel like more work than it's worth.
If anything, AI was supposed -- still is -- to thin out the ranks of ever-expensive human employees. That's why it attracted such a huge pile of investment and universal cheerleading from the C levels. What we're seeing right now that there's not so much "I" in AI, and it still needs a guiding hand to keep its results relevant. Hence, the senior advantage. How much it's going to undermine regular generational enployee replacement (because "we don't need juniors anymore", right?) remains to be seen. Maybe we're in for different training paths, maybe a kind of population collapse.
It does help juniors shine. For example, it's far easier for a new comer to understand an old code base with a capable LLM now. It's easier to get unstuck because an LLM can spot a junior's mistake faster than the junior can go ask a senior.
The problem is that seniors are even more powerful with LLMs. They can do even more, faster. So companies don't have to hire as many juniors to do the same amount of work. Add in ZIRP ending and tariff uncertainty, companies just don't invest in as many junior people as before.
Because there is no budget nor culture for training juniors internally. The culture (top-down) is rewarding short-term capital efficiency without regard to longevity and succession.
Because it's too unpredictable so far. AI saves me time, but only because I could do everything it attempts to do myself.
It's wrong maybe 40-50% of the time, so I can't even imagine the disasters I'm averting by recognising when it's giving me completely bonkers suggestions.
Same thoughts. Company is currently migrating from tech A to tech B, and while AI gets us 70-80% of the way, due to the riskier nature of the business, we now spend way more time reviewing the code.
"AI" tools accomplish one thing: output code given natural language input. That's it.
Whether the generated code meets specific quality or security standards, or whether it accomplishes what the user wanted to begin with, depends on the quality of the tool itself, of course, but ultimately on the user and environment.
They're not guaranteed to make anyone "stronger". The amount of variables involved in this is simply too large to make a definitive claim, which is why we see so much debate about the value of these tools, and why benchmarks are pretty much worthless. Even when the same user uses the same model with the same prompts and settings, they can get wildly different results.
What these tools indirectly do is raise the minimum skill level required to produce software. People who never programmed before can find them empowering, not caring about the quality of the end result, as long as it does what they want. Junior programmers can benefit from being able to generate a lot of code quickly, but struggle to maintain the quality standards expected by their team and company. Experienced programmers can find them useful for certain tasks, but frustrating and a waste of time for anything sophisticated. All these viewpoints, and countless others, can be correct.
It's a thinking challenge, not an AI challenge.
A while back, a junior asked me a question. They wanted to do X, they had code, with error Y. So they searched for it, got a page on Stack Overflow, pasted "the answer", then got a new and different error.
They:
- didn't understand the original code
- didn't understand the original error
This is fine. They then searched for the error and found a relevant page.
This is also fine. However, they:
- cut-pasted "an answer" from SO _without understanding if it was relevant or not_
The junior was hoping to work with a Puzzle: adding information will gradually give them a solution. In practice they are working with a Mystery: more information makes the task harder since they can't distinguish between different aspects.
I focused them on a few relevant details and let them go to it.
Why are we memory-holing the narrative that AI would help the most junior of all, non-programmers? Why are the comments pretending like this was hyped as a niche tool for senior devs? It most certainly was hyped as a general tool to replace all kinds of skilled work.
"Replace" and "help" are really different concepts.
It's the same as other automation. The lower skill parts can be automated, so if that's all you can do, it will be tough for you. If you have higher skills, then your work remains more useful.
There's nothing strange or counterintuitive about this.
learning typically follows a specific path.
1. Unconsciously incompetent
2. Consciously incompetent
3. Consciously competent
4. Unconsciously competent
The challenge with AI, it will give you “good enough” output, without feedback loops you never move to 2,3,4 and assume you are doing ok. Hence it stunts learning. So juniors or inexperienced stay inexperienced, without knowing what they don’t know.
You have to Use it as an expert thinking partner. Tell it to ask you questions & not give you the answer.
Also ask it "what questions should I be asking about this topic?"
> The early narrative was that companies would need fewer seniors, and juniors together with AI could produce quality code.
Lol, who said that? The narrative has clearly been "same or fewer seniors, more outsourcing, less juniors"
Verification.
That’s the whole issue in a nutshell.
Can the output of a generative system be verified as accurate by a human (or ultimately verified by a human)
Experts who can look at an output and verify if it is valid are the people who can use this.
For anyone else it’s simply an act of faith, not skill.
Agreed. There are other skills in play too though, such as knowing how to narrow the problem space to increase the chance of a good response.
It would be great if responses were tagged with uncertainty estimates.
This is the crux of why I think AI code is a waste of time
It is much more difficult and time consuming to build a mental model of AI generated code and verify it than to build the damn thing yourself and verify it while it is fresh in your memory
Generative systems don’t really reduce the need for expertise, they just change its role. And yeah, without verification, you’re not coding with AI - you’re gambling with it.
Was AI supposed to help juniors shine? I’ve never seen it billed as that.
If you're a junior and using AI to generate code, someone has to review it anyway, plus you're not learning on the job. So what's the point if the senior person can generate the code herself?
I’ve been reading the comments here… idk which companies you all work at, but, at least in all places I’ve worked you’ll have 2/3 people who are REALLY GOOD. Then you’ll have like 3/4 people who can sort of “trail” after those. And then there’s “the rest”. I’ve seen “the rest” making informed and “well planned” decisions that are just terrible approaches to a given problem. An LLM can actually be a net positive versus this rest.
You can’t abdicate learning. A junior who doesn’t understand the problem is going to use AI to more efficiently arrive at the wrong solution.
This is true for any type of AI-assisted analysis—-not just coding.
Why is that AI was supposed to help juniors shine, because plenty of so called "senior devs" have never really learned properly, bad habits, or lack technical breadth to be called that. This article is nothing more than what everyone else has been saying for two years, poorly at best. AI + coding has yet to hit it's stride and at some point highly specific LLM's will take into account of architecture, patterns, use-cases, compute environments, network, dev ops, testing, and coding to further equalize and close the gaps between the two roles. I've talked to seniors devs many are not interested in AI coding, just not the way they do things.
The only real advantage a senior dev has today is domain knowledge specific to a business in many cases. Even that is not much to hold on to because when layoffs come if nobody is hiring jr's then the seniors are getting axed.
If you're using them correctly, AI tools amplify your existing skills. Senior engineers have more skills to amplify.
AI produces code that often looks really good, at a pace quicker than you can read it.
It can be really, really hard to tell when what it's producing is a bag of ** and it's leading you down the garden path. I've been a dev for 20 years (which isn't to imply I'm any good at it yet) and it's not uncommon I'll find myself leaning on the AI a bit too hard and then you realise you've lost a day to a pattern that wasn't right, or an API it hallucinated, in the first place.
It basically feels like I'm being gaslit constantly, even though I've changed my tools to some that feel like they work better with AIs. I expect it's difficult for junior devs to cope with that and keep up with senior devs, who normally would have offloaded tasks to them instead of AI.
One thing about AI that I did not anticipate is how useful it is for refactoring though. Like if I have walked down (with the help of an AI or not) a bad path, I can refactor the entire codebase to use a better strategy in much less time than before because refactoring is uniquely suited to AI - if you provide the framework, the design, the abstractions, AI can rewrite a bunch of code to use that new design. I'm frankly not sure if its faster than doing a refactor by hand, but its certainly less boring.
If you have good tests and a good sense for design and you know how to constrain and direct the AI, you can avoid a lot of boring work. That is something.
It is, but again I'd caution that it will go and do things you don't want it to.
For instance, I've been working on an app recently with some social share icon logos in svg.
Whenever I get it to tweak bits of code elsewhere in the same file, 80% of the time it goes and changes those svg icons, completely corrupting some of the logos, curiously consistent in how it does it. Several times I've had that slip through and had to go and undo it again, at which point it starts to feel like the superfast junior dev you're using has malign intent!
It's obvious to me: the strongest use for AI seems to be to tie together larger projects which you orchestrate. It lets someone with a lot of experience overcome individual cases where they lack specific domain expertise. A novice might not know how things go together, and so cannot orchestrate the LLM.
Because it's early.
Seniors can figure out how to make it work and help set it up for juniors.
Traditionally in tech there has been an age bias against experience over time and maybe that's balancing out and both juniors and seniors will learn and have things to contribute in their own way.
My key advice to juniors: play and build constantly. Try out anything that interests you and follow along on youtube. This is how a lot of seniors are able to show they're quite flexible in their thinking and learning and it's not about one tech, or language, or framework or following what others do.
Juniors already have transferrable skills, will have way more, and can learn even faster if they want to partner with seniors, who generally would love to have more people to go put a dent in things.
At the moment, AI isn't good enough yet. Juniors can't tell the difference between bad coding practices or unmaintainable code. If the output is completely broken, they probably also have a hard time fixing it.
Seniors don't have these issues, so it will only make them more effective at their job.
So we fantasize now some claims into reality and then argue against them?
AI was never “developed to help juniors shine”…
> AI was supposed to help juniors shine
No, I don't think that was ever any kind of goal set by anyone ever
No one thought juniors would be more benefited than seniors. St some people some said everything would be automatic and seniors would disappear altogether with programming itself.
But that was just said by crappy influencers whose opinion doesn’t matter as they are impressed by examples result of overfitting
It's the responsibility of senior developers and stakeholders to allow junior developers the time they need to solve tasks at a pace that enables them to understand everything they're doing and learn from it.
These days, AI can generate solutions to problems 10 times faster than a junior developer can. This naturally puts pressure on developers who want to impress their employers, especially when their colleagues are also using AI.
Because managing a complexity is a senior skill.
no, AI is supposed to reduce the labor costs for companies. that is how the AI companies are marketing their AI services to corporate C teams. any other benefits that their marketing departments are pushing to the public are smoke screens.
Some of the juniors I work with frequently point to AI output as a source without any verification. One crazy example was using it to do simple arithmetic, which they then took as correct (and it was wrong).
This is all a pretty well-trodden debate at this point though. AI works as a Copilot which you monitor and verify and task with specific things, it does not work as a pilot. It's not about junior or senior, it's about whether you want to use this thing to do your homework/write your essay/write your code for you or whether you use it as an assistant/tutor, and whether you are able to verify its output or not.
Even as an assistant it's frustrating. Even trying to get simple stuff like a quick summary of a tools flags/commands can be hilariously wrong at times.
Not my experience, I've found it to worsen senior out output. Not sure if its laziness or what but the seniors around me using AI are outputing worse code than those who aren't.
> The early narrative was that companies would need fewer seniors, and juniors together with AI could produce quality code.
I don't remember this being the narrative at all. Almost as soon as LLMs could produce useful code the narrative I was hearing among devs was "Seniors + LLMs means you'll need less juniors."
And the narrative from companies (sometimes requiring the smallest amount of reading between the lines) is "You'll need less human employees, period."
The skills juniors have at any time are more narrow and more focussed on the tasks that are most simple in the current context; new tools that change things inherently are most immediately beneficial to people with broader and deeper skill sets, since they shake up the assumptions on which initial (and thus, junior-level) skill acquisition is based.
But skill acquisition patterns change as the context changes, so juniors end up benefitting, too, but the effect is delayed for them.
Assuming the LLM is more competent than the user, it will still require “absorptive capacity” for the user to meaningfully use the output.
Many discuss AI without considering that unless the LLM is going to take over the entire process, those interacting with it, must be sufficiently skilled to do the integration and management themselves.
This goes for organizations and industries as well. Which is why many companies struggle with merely digitalizing their products.
In my narrow field, at least, AI has been tremendously helpful to those of us who clearly understand how to use it, and specifically how to apply it to the job. I think Junior developers are still in that phase of throwing code until something works. They try to use AI, but they either don't understand how, or they don't fully understand the output. In my humble opinion, experience knows what's possible and what will work so the outcomes are better.
It's hard to live both at the macro level and the micro level at the same time. Seniors are charged with the macro, the big picture design choices. Juniors are charged with the micro, implementing user stories. AI makes seniors stronger because it is very good at giving micro-level awareness with little time investment. It's a powerful bit of leverage to drive execution.
It’s like me using WebMD. I might get lucky and diagnose correctly or I might accidentally kill myself. You don’t know what you don’t know.
This articles assertions are demonstrably false.
1. Several papers showed a 23% drop in productivity, and an incorrect belief of 20% performance improvement by the same individuals.
2. Studies showed LLMs made zero improvement in senior coders performance. Note senior coders are usually mostly a self-aware LaTeX macro already.
LLM AstroTurf only works on people that can't be arsed to lookup the obvious spam hallucinations. lol =3
I've only seen the one paper about that incorrect belief of performance improvements (the widely referenced METR study), are there others I've missed?
> AI was supposed to help juniors shine.
Was it? Says who? People who want to sell you something?
Because as far as I can tell the only thing it was supposed to do was to make its owners money.
Tasks usually come from the top down. Seniors design the architecture, mid-levels figure out ancillary tasks, and they generate "tedious" tasks that they hand off to juniors. With the aid of LLMs, many of those tasks don't make it to lower levels. So they run out of simple tasks for juniors, and end up giving them more advanced projects, making them de facto midrangers.
Because it is extremely weak at evaluating the quality of its ideas in context. It needs someone with experience to fix up its mistakes.
Mostly agree with article, though what happens in few years when juniors will eventually become senior.
Personally seeing trend juniors are relying so much on AI that they can't even explain what they wrote even in interview or coding assignments or even PR. Its like blackbox to them.
I believe then we would see the higher impact or may be by then its solved problem already.
You're only show as your typing speed and working memory. I noticed that LLM quickly spits out the code and thus I can iterate faster while typing myself I have focus on course and thus lose a lot of design context. Overall I haven't found any benefit of LLM. For me, it's just a probabilistic text generator that guesses my intent.
>> AI was supposed to help juniors shine.
Who said that? I don't recall that narrative. There's no quotes or sources.
well, you believed the wrong folks
Here's from my bsky feed 8 months ago after I took LLM to advent of code with local 32b model.
Segmond @segmond.bsky.social · 8mo I can confidently say that interns and junior developers can be replaced with AI. I also believe that mid to senior devs can double their output, meaning possibly less need for developers.
I haven't looked at other industries, but I believe this applies to any work that uses computers. This is inevitable, I'm tempted to write a detailed HOWTO, but what's the point when the value unlike past techs benefits a few folks more than society as a whole? I like AI but as an individual I worry a bit about how the entire thing will play it.
I think LLMs are best as learning tools, explaining code and producing something that can be then iterated.
Unsurprisingly, I have seen similar trends in other fields like medicine where LLM-powered tools are adopted. One has to have the knowledge to recognize hallucinations and effectively leverage these tools.
Was AI supposed to help juniors shine? By all accounts it would give such a person a superficial boost in productivity but you don’t climb the ladder that way without getting hard experience, you’d just be the super-powered perpetual beginner.
I'm in the minority, but I feel like coding is just as creative as writing. AI should be used as minimally as possible, to maintain that coding muscle.
If there's ever a long-term outage in the middle of the week, god help em.
Statistically, senior engineers are less likely to accept AI suggestions compared to juniors. This is just a tidbit of supporting evidence for the suggestion that juniors are not properly reading and criticizing the ai output.
It doesn't make seniors stronger, it just make juniors weaker as they are using this magic thingy LLM instead of learning from the seniors. It is important to evaluate not only what you gain by using a tool, but also what you lose...
Ai amplifies intelligence/skill
I would refute that and say AI only amplifies knowledge, but doesn't make anyone more skilled or intelligent.
It has the potential to amplify knowledge, but you have to already be skilled and intelligent to be able to identify false information.
I'm not cynical enough to believe that the avalanche of slop we're wading through represents something above our collective innate level of intelligence and skill.
quality > quantity
Senior devs know the right questions and contex to be given to an AI and they can see problematic responses right away. In the end, AI is a tool and a high quality paint brush doe not make you a Dutch Master.
In my experience CC makes so many wrong decisions that if I don’t have 1) experience and 2) have my thinking cap on, the results would not be good (or it would take a lot longer. Juniors typically have neither.
Because, as a senior, you usually already know intuitively what a good solution looks like, and you can quickly discard model responses or suggestions that do not align with it.
Because it basically needs an RFC to know what to do, it’s just programming at a higher language level. If you let it decide how to be a programmer you’re in for a bad time.
Hard disagree. Senior engineers can be just as incompetent as juniors
It's a code/text generator not a pair programmer - not that different from past code generators which were always designed by seniors who knew what the end results should look like, and used by juniors to make them more productive and less error prone. Sure a junior can vibe code... something... but do they know what they want at the outset or do they know when things are going off the rails and a step back is needed? It's easy to get lost way out in the weeds if you can't check your (experience) compass every now and then.
The ai has terrible taste. Juniors also have terrible taste. Seniors can guide both, but the ai is faster, cheaper, probably better than most. I’m worried that in a few years we will struggle to find new seniors. Who is going to put in the time to learn when the ai is so easy? Who is going to pay them to develop good taste?
Vibe coding is basically doing PR reviews all day. Which is what senior engineers have already been doing.
Junior developers don't yet have the intuition to tell the computer, "NO, NOT LIKE THAT!"
> AI Was Supposed to Help Juniors Shine.
Whoever said this?
Because it's a multiplier not an adder.
Was it? That is always one way it gets sold, in practice I see we (the industry) are trying to replace offshoring with AI.
> The early narrative was that companies would need fewer seniors, and juniors together with AI could produce quality code
I'm not deep into it, but I have not a single time seen that direction argued before this post. Maybe it was _really_ early on?
The narratives I always saw were, firstly, "it will be as a good as a junior dev", then "it's like pairing with an overly enthusiastic junior dev", then finally arguments similar to those presented in this article.
Which, frankly, I'm still not so sure about. Productivity is incredibly hard to measure: we are still not completely, non-anecdotally sure AI makes folk broadly more productive. And even if it does, I am beginning to wonder how much ai is short term productivity with long term brain rot, and whether that trade off is really worth it.
Was it? I don't recall such claims.
“Was supposed to” according to whom?
When did anyone say it was designed to make juniors shine?
The tech companies want it to REPLACE juniors (and seniors).
>Of course, the junior + AI pairing was tempting. It looked cheaper and played into the fear that “AI will take our jobs.”
Those are two different narratives. One implies that everyone will be able to code and build: "English as a programming language", etc. The other is one of those headless-chicken, apocalyptic scenarios where AI has already made (or will very shortly make) human programmers obsolete.
"AI taking jobs" means everyone's job. I won't even comment on the absurdity of that idea; to me, it only comes from people who've never worked professionally.
At the end of the day, companies will take any vaguely reasonable excuse to cull juniors and save money. It's just business. LLMs are simply the latest excuse, though yes, they do improve productivity, to varying degrees depending on what exactly you work on.
> "AI taking jobs" means everyone's job. I won't even comment on the absurdity of that idea; to me, it only comes from people who've never worked professionally.
Once you've worked professionally, it's not so absurd. I mean, you really see to believe the extreme compromises in quality that upper management is often willing to tolerate to save a buck in the short term.
> Those are two different narratives.
Also, those two narratives are sometimes deployed as a false-dichotomy, where both just make the same assumption that LLM weaknesses will vanish and dramatic improvement will continue indefinitely.
A historical analogy:
* A: "Segway™ balancing vehicles will be so beneficially effective that private vehicles will be rare in 2025."
* B: "No, Segways™ will be so harmfully effective that people will start to suffer from lower body atrophy by 2025."
> "AI taking jobs" means everyone's job. I won't even comment on the absurdity of that idea; to me, it only comes from people who've never worked professionally.
I work professionally (I am even a bit renowned) and still believe AI will take my (and everyone's) job.
Well, I can certainly assert that anyone that used to do translations or image assets for CMS is out of job nowadays.
Ai closes the knowledge gap but it doesn't close the skill gap.
AI was supposed to get rid of juniors (and seniors, soon).
No, it was supposed to get rid of the seniors because they cost more and replace them with cheap juniors + AI. If you need some humans and you are a corpo bean counter, the cheaper the body the better.
But that wouldn't make any sense. It's not `plus`; it's `times`. AI is supposed to be a force _multiplier_, at least in the context of a complex organization and product (on small projects where vibe-coding is good enough I think AI is a massive plus!).
If a junior is about 50% as useful as a baseline senior, and today, AI's usefulness is only slightly better than the person using it, then 50% * 75% gives you output equal to about 37.5% of a senior. The junior just ships more junior-level output; and in a complex product and complex orgs, this just ends up being a drain on everyone else.
But in the hands of a senior, 100% (senior) * 125% (ai), we get a slightly better senior.
Its not a perfect analogy, and AI is new territory with lots of surprises. AI code reviews, have been separated from the confirmation bias of the driver of the AI, _are_ where I'm seeing the greatest impact on junior engineers. These AI reviews seem to be getting things closer to a level playing field.
I agree this does not make sense for you and me, but it makes sense for the corpo bean counters that don't understand how this works and they were told AI makes people better, so they need less people and less skilled people. It is not hard to get to the wrong conclusions based on the AI marketing materials.
I see the discussions around AI in my company (big, not IT but with several large IT departments) and even our MBA IT leaders believe all the buzzwords to the letter.
Seniors have a better theory, which is what LLMs lack.
It benefits devs who have reviewed a lot of code
This is a good thing. That shift in expectations will hopefully prevent a total collapse of systems as inexperienced developers would have yeeted god knows what code into production.
The best part: all of the materials that were available to now-seniors are available to new juniors. The added advantage of having an LLM to explain or clarify things? Seniors didn't have that. We had to suffer.
Sorry, but the outcome is fair. Seniors had to suffer to learn and can now benefit from the speed up of AI. Juniors don't have to suffer to learn, but they do have to learn to leverage AI to help them catch up to the existing crop of seniors.
Not impossible. Not impractical. Just a different form of hard work, which, no matter how much anyone kicks and screams will always be the thing standing in the way of where you want to be.
It doesn’t make seniors shine. It makes some of them fucking delusional. Sure, once in a while a LLM does something impressive and you are left thinking “holy shit, the future is now!”. However, this does not make up for the mass of time that you spend going “what is this shit?”, and saying “that’s not what I intended, gentlemen robot, please correct x, y and z.” And then gentlemen robot will go ahead and FUCK IT UP WORSE THAN BEFORE. Never work with kids, animals or AI. This shit is the worst, who came up with this? I can code! I’m bloody good at it! If I wanted to deal with some useless no-hoper having a crack and constantly needing to have their head kicked to do anything useful, I would have gotten you to do it.
> supposed to help juniors shine
Supposed by who exactly?
Genuinely curious: how do Juniors respond? If seniors learned with just stack overflow or…books… do juniors slow themselves down and learn those ways? Maybe AI slop looks fine to those who haven’t seen a lot of code?
If junior shines they become senior.
Uh because an LLM is a transfer function. Specifically a transfer function where the input has to be carefully crafted. And specifically where the output has to be carefully reviewed. Inexperienced people are good at neither of those things.
When was ai supposed to help juniors?
Because garbage in, garbage out
Step one would be to stop calling whatever this is “AI” because while it may be artificial, it is not at all intelligent.
This surprises people? How?
So now industry will stop hiring juniors, cause LLMs are cheaper. And in a couple of years, there will be a profound lack of senior devs. And then everybody realizes that LLMs still suck at higher level coding tasks. Great.
AI was supposed to help juniors shine? I don't remember hearing that anywhere. AI was supposed to let CEOs fire expensive experts and replace them with whatever slop the computer extruded from the manager's prompt. There was never any significant hype about making juniors into experts.
AI is a tool, like any other. Imagine you invented a new machine gun that fires faster and has less recoil but james more often. Who will be able to put the new machine gun to better use -- new recruits or veteran soldiers? C'mon.
That might be a trick question I think. As a veteran I would drop one enemy, take their AK-47 and drop my M-16 and start collecting ammo for my nifty old but reliable AK-47 that does not jam when it gets a little dirty.
"AI Was Supposed to Help Juniors Shine" is a false narrative. AI's end goal has always been to fundamentally eliminate more and more of human labor positions until the only job left is executive directorship.
But now everyone can be one because the AI can do the rest.
i think it is due to the reverse utility curve; most products have some sort of gaussian utilty fuction for utility vs. expertise level. a complete newb will have trouble using the camera and a professional photographer will be limited by it, but most people in-between will get a lot of use out of it.
with llm’s it is opposite; a complete newb can learn some stuff, and an expert will be able to detect when it is bullshitting, but most people will be at a point where they have more knowledge about the subject the llm is talking about than the newb, but not enough to detect the bs.
"AI" does not make anyone stronger. It destroys thought processes, curiosity and the ability to research on your own.
Seniors just use it to produce the daily LOC that resembles something useful. If mistakes are introduced, they have secured a new task for the next day.
There have always been seniors who exclusively worked on processes, continuous integration, hackish code-coverage that never works, "new" procedures and workflows just to avoid real work and dominate others.
The same people are now attracted to "AI" and backed by their equally incompetent management.
The reality is that non-corporate-forced open source contributions are falling and no serious existing project relies on "AI".
Generative "AI" is another grift brought to you by leaders who previously worked on telemedicine and hookup apps (with the exception of Musk who has worked on real things).
>AI was as supposed to help juniors shine
Citation needed? LLMs have mostly been touted as the junior replacement, a way for seniors to oversee scalable teams of shortsighted bots instead of shortsighted people.
Does it make seniors stronger?
Extraordinary claims require extraordinary evidence.
simple: power law.
Actually studies show that it makes most Seniors weaker: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
Like 19% weaker, according to the only study to date that measured their productivity.
It doesn't.
Ol
does it really? it lets seniors work more, but idk if its necessarily stronger.
i just soent some time cleaning up au code where it lied about the architecture so it wrote the wrong thing. the architecture is wonky, sure, but finding the wonks earlier would have been better