all 9 comments

sorted by: hot top controversial new old
[–] 18 points 9 months ago

From the paper abstract:

[…] Novice workers who rely heavily on AI to complete unfamiliar tasks may compromise their own skill acquisition in the process. We conduct randomized experiments to study how developers gained mastery of a new asynchronous programming library with and without the assistance of AI.

We find that AI use impairs conceptual understanding, code reading, and debugging abilities, without delivering significant efficiency gains on average. Participants who fully delegated coding tasks showed some productivity improvements, but at the cost of learning the library.

We identify six distinct AI interaction patterns, three of which involve cognitive engagement and preserve learning outcomes even when participants receive AI assistance. Our findings suggest that AI-enhanced productivity is not a shortcut to competence and AI assistance should be carefully adopted into workflows to preserve skill formation – particularly in safety-critical domains.

  • source
  • [–] 6 points 9 months ago

    Discussion
    Our main finding is that using AI to complete tasks that require a new skill (i.e., knowledge of a new Python
    library) reduces skill formation.
    ...
    The erosion of conceptual understanding, code reading, and debugging skills that we measured among participants using AI assistance suggests that workers acquiring new skills should be mindful of their reliance on AI during the learning process.
    ...
    Among participants who use AI, we find a stark divide in skill formation outcomes between high-scoring interaction patterns (65%-86% quiz score) vs low-scoring interaction patterns (24%-39% quiz score). The high scorers only asked AI conceptual
    questions instead of code generation or asked for explanations to accompany generated code; these usage
    patterns demonstrate a high level of cognitive engagement.
    Contrary to our initial hypothesis, we did not observe a significant performance boost in task completion
    in our main study.
    ...
    Our qualitative analysis reveals that our finding is largely due to the heterogeneity in how participants decide to use AI during the task.
    ...
    These contrasting patterns of AI usage suggest that accomplishing a task with new knowledge or skills does not necessarily lead to the same productive gains as tasks that require only existing knowledge.
    Together, our results suggest that the aggressive incorporation of AI into the workplace can have negative impacts on the professional development workers if they do not remain cognitatively [ sic ] engaged. Given time constraints and organizational pressures, junior developers or other professionals may rely on AI to complete tasks as fast as possible at the cost of real skill development. Furthermore, we found that the biggest difference in test scores is between the debugging questions. This suggests that as companies transition to more AI code writing with human supervision, humans may not possess the necessary skills to validate and debug AI-written code if their skill formation was inhibited by using AI in the first place.

  • source
  • [–] 5 points 9 months ago (2 children)

    Interesting read and feels intuitively plausible. Also matches my growing personal sense that people are using these things wildly differently and having completely different outcomes as a result. Some other random disconnected thoughts:

    1. I'm surprised they're publishing this, it seems to me like a pretty stark condemnation of the technology. Like what are the benefits they anticipate that made them decide this should be published, vs. quietly kept aside "pending further research"? Obviously people knowing how to use the tools better is good for longevity, but that's just not what our idiotic investment cycles prioritize.

    2. I'm no scientist or expert in experimental design, but this seems like way too few people for the level of detail they're bringing to the conclusions they're drawing. That plus the way it all just feels intuitively plausible has a very "just so" feeling to the interpretation rather than true exploration. I mean, cmon - the behavioral buckets they are talking about range from 2-7 people apiece, most commonly just 4 individuals. "Four junior engineers behaved kinda like this and had that average outcome" MIGHT reflect a broader pattern but it sure doesn't feel compelling or scientific.

    Nonetheless I selfishly enjoyed having my own vague subconscious observations validated lol, would like to see more of this (and anything else that seems to work against the crazy bubble being inflated).

  • source
  • hideshow 2 child comments
  • [–] 6 points 9 months ago (1 child)

    For 1: as a software company, they have a vested interest in ensuring that software engineers are as capable as possible. I don't know if anthropic as a company uses this as a guiding principle, but certainly some companies do (ex Jane Street). So they might see this as more important than investment cycles.

    The quality of software engineers and computer scientists I've seen coming out of undergraduate programs in the last year has been astonishingly poor compared to 2-3 years ago. I think it's almost guaranteed that the larger companies have also noticed this.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 9 months ago* (last edited 9 months ago)

    I completely agree and appreciate sincerely that they released this. It's unfortunate, the way the obviously nonsense claims made by the industry at large - "LLMs are AI and can do everything!" - have polluted a lot of devs' ability or willingness to see the tools for what they are, and maybe official acknowledgements like these can help.

    It also seems likely to me that the major players know a lot of negative truths about all this stuff, you're probably right about hiring observations. I don't follow any of their marketing really so I have to admit I'm even just assuming that releasing this is out of character.

    If I'm being honest, I'm mostly just on the edge of my seat waiting for the hype bubble to burst, lol, and curious about how it'll unfold. Probably just kind of hoping this marks a step toward that.

  • source
  • parent
  • [–] 3 points 9 months ago (2 children)

    In a randomized controlled trial, we examined 1) how quickly software developers picked up a new skill (in this case, a Python library) with and without AI assistance; and 2) whether using AI made them less likely to understand the code they’d just written.

    We found that using AI assistance led to a statistically significant decrease in mastery. On a quiz that covered concepts they’d used just a few minutes before, participants in the AI group scored 17% lower than those who coded by hand, or the equivalent of nearly two letter grades. Using AI sped up the task slightly, but this didn’t reach the threshold of statistical significance.

    Who designed this study? I assume it wasn't a software engineer, because this doesn't reflect real world "coding skills". This is just a programming-flavored memory test. Obviously, the people who coded by hand remembered more about the library in the same way students who take notes by hand as opposed to typing tend to remember more.

    A proper study would need to evaluate critical thinking and problem solving skills using real world software engineering tasks. Maybe find some already-solved, but obscure bug in an open source project and have them try to solve it in a controlled environment (so they don't just find the existing solution already).

  • source
  • hideshow 2 child comments
  • [–] 1 point 9 months ago (1 child)

    The study is about the impact AI use has on learning. Their experiment seems to test just that, unlike what you're describing.

    Besides, remembering what you did an hour ago seems like a real world problem to me. Unless one manages to switch project before the bug reports come in

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 9 months ago

    The study is about the impact AI use has on learning. Their experiment seems to test just that, unlike what you’re describing.

    The title is literally "How AI assistance impacts the formation of coding skills". Memorizing APIs isn't what most people would consiser a "coding skill".

    Debugging, systems design, optimization, research and evaluation, etc are what actually make someone a useful engineer, and are the skills a person develops as they go from junior to senior. Even domain knowledge (like knowing a lot about farming if you're working on farming software) is more useful than memorizing the API of any framework. The only thing memorization does is it saves you a few minutes from having to read some docs, but that's minimal impact, and it's something you pick up normally throughout the course of working on a project anyways. When you finish that project, you might never use that API again, or if you do it might have changed completely when a new version is released.

    remembering what you did an hour ago seems like a real world problem to me.

    Sure, humans have shitty memory, but that has nothing to do with AI code assistance. There are plenty of non-AI coding assistants that help people with this (like Intellisense/LSP auto complete, which has been around for decades)

  • source
  • parent
  • [–] 0 points 9 months ago

    Why are like 70% of the posts in this comm about AI lately?? I'm out of here...

  • source
  • 14 comments in c/technology@lemmy.world view that post
    [–] 30 points 9 months ago (1 child)

    OP, please add a fat disclaimer at the bottom that this is from Anthropic, a major AI company.

  • source
  • hideshow 1 child comment
  • [–] 29 points 9 months ago (1 child)

    Importantly, using AI assistance didn’t guarantee a lower score. How someone used AI influenced how much information they retained. The participants who showed stronger mastery used AI assistance not just to produce code but to build comprehension while doing so—whether by asking follow-up questions, requesting explanations, or posing conceptual questions while coding independently.

    importantly, in our own funded study, we found that those who used our product the most did the best

  • source
  • hideshow 1 child comment
  • [–] 12 points 9 months ago (1 child)

    I would love to read an independent study on this, but this is from Anthropic (the guys that make Claude) so it's definitely biased.

    Speaking for myself, I've been using LLM's to help out with jumps in small gaps of knowledge. Like for example, I know what I need to do, I just don't know/remember the specific functions or libraries that I need to do that in Python. LLM is extremely useful for these moments; and it's faster than searching and asking on forums. And to be transparent, I did learn a few tricks here and there.

    But if someone lets the LLM do most of the work - like vibe coders - I doubt they will learn anything.

  • source
  • hideshow 1 child comment
  • [–] 3 points 9 months ago*

    I do the same. I start with the large task, break it into smaller chunks, and I usually end up writing most of them myself. But occasionally there will be one function that is just so cookie-cutter, insignificant to the overall function of the program, and outside of my normal area of experitise, that I'll offload that one to an LLM.

    They actually do pretty well for tasks like that, when given a targeted task with very specific inputs and outputs, and I can learn a bit by looking at what it ended up generating. I'd say it's only about 5-10% of the code that I write that falls into the category where an LLM could realistically take it on though.

  • source
  • parent
  • [+] 10 points 9 months ago (2 children)
  • [–] 5 points 9 months ago

    My boss make lots of really odd and… just bad requests. Half the time I can’t even understand what he’s asking because he seems to enjoy being super vague. For a few months now I just copy and paste his request to codex and let it rip. It’s usually pretty accurate. At least… the PRs get approved… and that’s all that matters.

  • source
  • parent
  • [–] 3 points 9 months ago

    Familiar but with a difference in my case.

    I've spent my entire career alternating between two experiences.

    One is being grilled why I an delivering what I think should be done instead of what the executives told me to do.

    The other is getting awards and promotions when it turns out that I was right and the customers loved it.

    It happened to work for me to do it my way, though my executives have usually simultaneously rented the implication they don't have good vision, they also know how to leverage my success for themselves. Particularly this most recent promotion has been stalled to reward better drones instead, but it's looking like they have to pivot back to rewarding the folks the paying customers actually like instead of those that feed the executive egos.

  • source
  • parent
  • [–] 7 points 9 months ago (4 children)

    I'm trying out using Claude on a problem at work that has been frustrating; lots of unexpected edge cases that require big changes.

    I definitely know less about my "solution" (it's not done yet, but it's getting close) than if I actually sat down and did it all myself. And it's taken a lot lot of back and forth to get to where I am.

    It'd probably have gone better if, once Claude provided me a result, I went through it completely and made sure I understood every aspect of it, but man when it just spits out a full script, the urge to just run it and see if it works is strong. And if it's close but not quite right, then the feeling is "well, let me just ask about this one part while I'm already here" and then you get a new complete script to try. And that loop continues, and I never get around to really going through and fully understanding the code.

  • source
  • hideshow 4 child comments
  • [–] 5 points 9 months ago (3 children)

    Do you tell Claude to make a plan first?

    That helps me tremendously. Whenever something needs to be modified, I tell it to update the plan first, and to stick to the plan.

    That way, Claude doesn't rewrite code that has already been implemented as part of the plan.

    And understanding the plan helps understanding the code.

    Sometimes if I know there will be a lot of code produced, I'll tell it to add a quick comment on every piece it adds or modifies with a reference to the step in the plan it refers to. Makes code reviewing much more pleasant and easier to follow. And the bugs and hallucinations stick out more too.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 9 months ago (1 child)

    Smart, I'll definitely try that out.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 9 months ago

    You probably know this, but aside from that, Claude has "plan mode". When writing, hit "Shift+Tab" a few times until you select it. Claude won't immediately start coding when you give it instructions.

    Also, ask him about the "superpowers* and "ask questions" skills. Game changers too.

  • source
  • parent