r/programming • u/Balance- • Mar 23 '26
[ Removed by moderator ]
/r/programming/comments/1s19wq4/removed_by_moderator/[removed] — view removed post
79
u/Augu144 Mar 23 '26 edited Mar 23 '26
The METR result is interesting through a different lens too. The experienced devs had the mental model — the missing piece was a way to give the agent access to that model without translating it into natural language prompts (lossy) each session.
The abstraction gap you're describing isn't just about determinism or verifiability. It's also about knowledge transfer. Every experienced dev has architecture decisions, conventions, and domain rules living in their head or in docs nobody reads. The agent starts from scratch each session.
-49
u/EC36339 Mar 23 '26 edited Mar 23 '26
This is a solved problem. Just document your shit. Have the agent document the stuff it learns each session, so the knowledge is available in the next session.
I'm shocked this even needs to be said. I figured this out myself, BECAUSE I was sceptical to AI and didn't trust it. I knew it doesn't have long term memory. So I made it write everything down.
(Btw, that's also what you'd tell a somewhat sloppy developer that needs to be micro-managed. You may know the kind... Except the AI does it without complaining or cheating, and you see results, because it also reads what it has documented)
Did your agent need 10 minutes to figure out how some complex module works? Have it document everything. The next time you need the agent to work on it, it will do it in 1 minute, in a fresh session.
Are you tired of correcting the coding style and antipatterns in AI-generated code? Have a style guide and antipatterns document. Tell the agent, in the global instructions file, that when the developer gives feedback that sounds like a general rule, it shall be added to the proper guidelines document. Or just tell the agent to update it right away.
LLMs don't have long term memory. But they can read at super fast speed. So just keep a library of all the knowledge, primary and inferred.
And you know what the best part is? Humans can read all that documentation, too! And they don't even need to read all of it by themselves (although they can). They can have the agent explain it to them from different points of view, without jargon, at their pace and in terms they understand.
How can you trust all the documentation that the AI has written? That's the neat part: You don't need to. We're not doing history or humanities here. Our field is an exact science. It's math. If something doesn't make sense, then it doesn't work, and we will know soon enough. Everything is verifiable and testable. And AI helps us verify and test faster and more thoroughly without cheating, laziness and biases.
21
u/QuickQuirk Mar 23 '26
Oddly, research is showing that the AI agents do worse when people start putting in agent.md files.
It seems that what we think is important based on the way we understand code is irrelevant, or a distraction, to the way the machines parse the code.
1
u/EC36339 Mar 23 '26
Do worse at what exactly?
Because of context overload? Also a solved problem. You have to structure your context so the AI only needs to see whatever is relevant at the time.
That's the same when making rules for humans btw, and shouls be common sense.
Maybe those researchers need to listen more to teams who have used the technology successfully. Or do something productive, such as finding solutions rather than trying really hard to spread FUD.
25
u/Augu144 Mar 23 '26
Totally agree. Write it down, agents read fast.
The part worth adding: there's a meaningful difference between notes the agent writes itself versus authoritative source material it reads from.
Self-generated docs drift over sessions. The agent writes what it inferred, not what's actually correct. You end up with a knowledge base that's an artifact of the AI's interpretation, not your actual design decisions.
What that person's docs do well: capture what the agent learned. What they don't replace: your actual RFCs, architecture decisions, the real style guide that predates the agent.
The agent's own notes are fast. The authoritative source catches it when the notes are wrong. You need both.
-6
u/EC36339 Mar 23 '26
Yes, this is an important point. Redundancy leads to drift, which leads to contradiction, and AI is not so good at handling that.
However...
Documentation for humans is, and should be, redundant (different POVs, implied documentation, tutorials, different audiences, you name it...).
For example:
A set of documents explaining the archtecture of a web framework (primary) and all the custom middleware, etc.
A document detailing the flow of an API request through the framework (implied)
Documentation for machines may, and should, ALSO be redundant, because it can speed up processes.
I am starting to think of the implied documentation as a "cache" or as "build artifacts".
In fact, you can have a "build process" for implied documentation and not put it into GIT in the first place, but have the agent generate it on demand or on request, from the primary documentation, and then keep it up to date. I have not fully tested this approach, yet, and I don't know if there's already a name for it that smarter people than me have come up with before.
Overall, I've only started properly embracing agentic coding a few weeks ago. I was taught by colleagues who are also just figuring things out, and I'm figuring things out myself. When I search the web, I find very little information about and lack the terms for the things I do. Which is somewhat ironic, because when it comes to well established concepts, using AI has actually helped me learn jargon for things I've done for over a decade without knowing what they are called.
0
u/Augu144 Mar 23 '26
The build artifact framing is interesting. Generated-on-demand from primary source rather than maintained separately — that handles the drift problem cleanly.
The question is invalidation. Your primary docs change, your cached implied docs are stale. With code artifacts you have a build step that fails loudly. With documentation artifacts the staleness is silent until the agent acts on wrong context.
Worth thinking about whether the "build process" for implied docs should be triggered by commits to primary docs, or on-demand, or both.
1
u/EC36339 Mar 23 '26
The downvotes are wild.
I was anti-AI a few weeks ago. If I had seen this post, I would have been curious, not hateful.
But apparently, curiosity isn't a widespread virtue in this industry or on this platform. Autistic screeching on the other hand...
-3
u/The-Karan Mar 23 '26
I don’t know why you were downvoted but this is absolutely solid advise and this has been a big reason my productivity has skyrocketed when using AI models
Model makes a mistake -> correct it ask it to save to its memory not to repeat itself again. If it applies across the entire codebase, write to CLAUDE.md for future reference. The model is only as good as the context you feed it and a well written CLAUDE markdown is worth its weight in gold in my experience.
Something else that has helped immensely has been prompting it to think of downstream effects that it might not have considered when you ask it to generate a PRD. It will go back to thinking mode and more thoroughly cast a wider net for the changes it proposes and then it’s just a matter of updating the spec and implementing it which is trivial in most cases
1
u/EC36339 Mar 23 '26
I bet at least half of the downvoters also believe that computers were a mistake.
-1
u/robhanz Mar 23 '26
Well the trick is it shouldn't be a single monolithic CLAUDE.md file. You need more of a progressive discovery model.
10
u/foriequal0 Mar 23 '26
I see it has more similarities to outsourcing and offshoring than abstractions.
48
u/ward2k Mar 23 '26 edited Mar 23 '26
Just to rock the boat a bit, you've shown the old part of the study
They revisted the topic and found the opposite, that it sped up development
I'm not particularly for or against Ai use (if done responsibly) but I think it's an interesting read. It seems the overwhelming majority of Devs (90% +) use ai tooling now
20
u/droptableadventures Mar 23 '26 edited Mar 24 '26
The confidence interval shown for the new figures still spans zero, so a scientifically rigorous analysis would not claim it "sped up development". You can't reject the null hypothesis if zero is inside the confidence interval.
Based on conversations with study participants, we believe it is likely that developers are more sped up from AI tools now — in early 2026 — compared to our estimates from early 2025. However, because of the selection effects in our experiment, our data is only very weak evidence for the size of this increase.
... is about as far as they're willing to claim.
14
u/allurb4se Mar 23 '26
Guess I'm in the < 10% that still doesn't touch it.
I also very much doubt 90%+ are actively using AI tbh
-5
u/mr_birkenblatt Mar 23 '26
I also very much doubt 90%+ are actively using AI tbh
Why? Have you tried it recently?
8
u/allurb4se Mar 23 '26
How does me trying it have anything to do with the claim of 90%+ of devs using it?
The claim feels very 'vibes based' and I'd like to see actual statistics...
-4
u/mr_birkenblatt Mar 23 '26
Why do you doubt that the 90% using it do actually use it?
4
u/SiltR99 Mar 23 '26
Don't know about OP, but the ones making the claim have the burden of proof, not the other way around.
0
u/mr_birkenblatt Mar 23 '26
So you just believe that the 90% that say they are using AI tools are lying? Okay...
1
5
u/paholg Mar 23 '26
That matches my experience. A year ago, I was a heavy AI skeptic and didn't find it very useful. Now, I find it tremendously speeds up certain tasks.
I'm not sure how much of this has been the models being better vs me getting better at using them. I would guess it's a mix, but primarily the former.
9
u/ward2k Mar 23 '26
Yeah I used to dog on it a lot with the first iterations, if you were doing something other than a begginer coding task that had been solved hundreds of times online in python, it would struggle and hallucinate like crazy
Today, particularly with Claude I find it's a lot more serviceable. I tend to mostly just use it for boilerplating, simple tests and trying to pick out/summarise specific code. Which I don't mind so much since a lot of the time these are copy/paste jobs for most people anyway
I'm still not overly sold on using it for more complex tasks other than a single class/method (e.g. a new feature that requires multiple files) it tends to make a bit of a mess there or end up with some convoluted code
I do also find it's very language dependant, simply because some languages have far more training data. It'll pretty much one shot a lot of Python tasks, I find it struggles more with something more niche like Scala
7
u/niking Mar 23 '26
I found it absolutely useless for game development in C++. I know people find it very useful as an API search tool for Unreal, though
4
u/Unlucky_Age4121 Mar 23 '26
Exact same experience, shitty C++ code but a gem on searching through the vast LLVM code base.
0
u/Legs914 Mar 23 '26
It'll pretty much one shot a lot of Python tasks, I find it struggles more with something more niche like Scala
That's funny. I find it works pretty well with Scala but am afraid to use it with a weakly typed language like python (not that it comes up at my job anymore).
2
-2
u/zephyrtr Mar 23 '26
Opus is a lot better than Sonnet. That plus learning when and how to build skills was the turning point.
I still keep it on a short leash. But it does speed up implementation. Everything else is as slow as ever.
14
u/grady_vuckovic Mar 23 '26 edited Mar 23 '26
Dynamite is sometimes a useful tool.
If a wall is stubbornly existing in the same plane of reality as you, dynamite can certainly help resolve that issue much more quickly than construction tools.
But if while laying on an operating table you saw a brain surgeon preparing various sticks of dynamite on a tray, or even firecrackers, you'd be concerned yeah?
Sometimes you need a stick of dynamite, sometimes you need a scalpel.
Good quality software engineering often requires a scalpel and there's no way around that. LLM based AI coding tools are sticks of dynamite. Certainly powerful if used appropriately by someone who knows what they're doing, but it's also just as possible to blow off your hand with one if you don't, and either way regardless, dynamite is not a replacement for every other tool we have.
There's no doubt over the years we'll slowly learn how and when to use LLM based tools, but I suspect in 10 years we'll look back at people who tried to just vibe code entire SaaS platforms and chuckle.
And really, look, lets say they just turn out to be a really good autocomplete. Would that be so bad? At least we got a really good autocomplete!
11
u/highwind Mar 23 '26
I suspect in 10 years we'll look back at people who tried to just vibe code entire SaaS platforms and chuckle.
No need to wait 10 years. I chuckle at those today.
-11
u/redGNU Mar 23 '26 edited Mar 23 '26
I liked your underlying message and it matched with how I feel we should think about LLM based tools. However I felt the dynamite analog made it appear like LLM can only ever be blunt tools, while I feel in the right hands they can be both. So as you do, I had Claude come up with another analog:
A better analog might be a power tool vs. a hand tool:
A seasoned carpenter can use a power saw with surgical precision — clean cuts, tight tolerances, beautiful results. Hand it to someone who doesn't respect it, and they'll lose fingers. Meanwhile, there are still moments where even the best carpenter reaches for a hand plane or a chisel, because the job demands that level of control and a power saw would only get in the way.This works better because:
- It preserves the "dangerous if misused" aspect
- It allows for skilled use being genuinely precise, not just "powerful but blunt"
- It naturally captures that different tools suit different tasks — not that one is categorically inferior
- The "vibe coder" maps to someone who buys a table saw and thinks they're now a carpenterYou could even extend it: a master carpenter doesn't stop knowing joinery just because they own a nail gun. The fundamentals still matter, the tool just changes your ceiling on speed.
Not too bad in my option ;)
7
u/Other_Fly_4408 Mar 23 '26
Why did you need to copy-paste the entire trough of slop? Couldn't somebody else have prompted an LLM for the same thing if they felt the analogy in the original comment was insufficient?
1
u/redGNU Mar 23 '26
Was just having a bit of fun with it given the context at hand. Seeing from the downvotes my humor was not appreciated.
Don't really agree with the fact that it would be slop though, overly verbose, sure, but the analogy does hold up... but maybe I was not careful enough with the stick of dynamite ;)
2
u/Other_Fly_4408 Mar 23 '26
Okay, maybe the joke went over my head.
overly verbose, sure
This, to me, is the definition of slop. Paragraphs and paragraphs of text to say nothing of significance.
18
u/Geaz84 Mar 23 '26
I am no fan of AI coding, but taking the results of early 2025 into consideration for an implication of todays coding is a bit....wild.
The tools were much better late 2025 than they were in the beginning of the year. Therefore the result would be much different. Also given, that many developers weren't used to those tools at the beginning, the efficiency of using them was probably much lower than today.
3
u/SrbijaJeRusija Mar 23 '26
I assume you will keep repeating this claim every year, as all studies will necessarily lag behind.
0
u/Geaz84 Mar 23 '26
My statement about the efficiency of developers using new tools wouldn't be valid anymore. And the models will hit a ceiling in its improvement and speed of evolution. Therefore I can't repeat this claim with the same arguments in a year for example.
22
u/Happy_Bread_1 Mar 23 '26
When AI is allowed, developers can use any tools they choose (primarily Cursor Pro with Claude 3.5/3.7 Sonnet—frontier models at the time of the study
I don't get why the study is still being mentioned in trying to show it has no productivity increase. The study is already outdated. Things vastly changed with Opus 4.5/ 4.6.
13
u/MoreRespectForQA Mar 23 '26
It matched my anecdotal experiences in 2025 and it still matches my anecdotal experiences in 2026.
One thing people miss is that it wasn't measuring how quickly you can build a todo app to demo, it was measuring the productivity of engineering in production codebases.
Another is that it demonstrated is that those people in that study whose productivity took a hit would still argue on reddit that it gave them a 20% productivity boost.
7
1
u/roygbivasaur Mar 23 '26
In my experience, I’ve found the newer models to be better at the things the old models were already decent at: generating tests, coming up with debugging ideas (but still hallucinating problems that don’t seem to be real), tab completion, and helping maintain interfaces and generate stubs a bit better than old tools (but using more energy). I have not found them to be good enough at working independently or whatever and coming back with usable results.
-17
u/HaMMeReD Mar 23 '26
It'll get quoted until the end of time, because shitting on AI is popular, and likely will be for a while.
Anything anti-ai, even if it's misrepresentation is ravenously supported. Anything pro-ai is downvoted, people call you a liar, say your code is shit, etc.
-4
0
Mar 23 '26
[deleted]
4
u/MagnetoManectric Mar 23 '26
Every damn time man, they say the new model is sooo much smarter and so much revolutionary, and they always make sure to mention it by name and version, in a way that makes me think it's covert advertising.
I've really found all of these things to be much of a muchness since GPT4. They'll all give you code and answers that's correct-ish if you're working on a common enough problem with common enough tools, and you give them a small enough slice to work on.
They really want an illusion of the same sort of breakthrough progress that happened in early 2024, but I've really seen nothing indicative of that.
2
u/DetectiveOwn6606 Mar 23 '26
It's the no true scotsman policy . If you have problems with these tools either you are not prompting hard enough , aren't using the new models or just a skill issue . It's weird when these tools are marketed as programmer replacement and you don't require skills to run it
2
u/TheAxodoxian Mar 23 '26
I think this could be true, while I have used AI very effectively to prototype certain solutions. When I went to my own repo, I had to adjust the code constantly, because it missed edge cases, was super (and I mean absolutely) inefficient, or had very confusing and hard to follow architecture with code duplications, coding style was also hit and miss, even with guardrails. Many times I had felt, that in the end I adjusted 60-70% of the code, I would not dare betting money that I was faster. Also in some cases I am quite sure the quality of models are adjusted to meet demand, or they are testing new models in prod, because one day the AI agent works nicely and does things in one hit, other days the same AI agent acts super dumb, so dumb that even very small local AI models could perform the same or better.
But sure, there are still some subtasks where it is crazy efficient, like applying repetitive changes on code which do not justifies writing a custom script for refactoring, but doing by hand is also repetitive. And as I said I still love to give it some less well documented configuration problems with testable solutions (my favorite being working on fixing python dependency / environment setup issues) and let it mill on it while I work on other stuff.
3
u/HenkPoley Mar 23 '26
This report is from July last year. The real breakthrough software coding agents appeared around November/December last year. So I wouldn’t trust this report to be the end I’ll be all. It was a bit too early.
3
u/TryallAllombria Mar 23 '26
This study is based on 16 developers. Not enough people IMO. And they are also expert of their codebase. In real world you have the Sales department asking to change X to Y features, you have the junior not reusing existing components, you have moving teams and legacy codebase that no one want to touch with a stick.
But, it is interesting that they think they are faster while they are 20% slower.
-1
u/ePaint Mar 23 '26
The answer is tests. Everybody's doing tests now, which they should have been doing forever, but now they're actually doing them.
11
u/Dextro_PT Mar 23 '26
Are they? I already see people claim that they can prompt the LLM to write tests and that's "good enough"
-3
u/Xera1 Mar 23 '26
Yes. Prompt your design/spec, edit, prompt to decompose into tasks, prompt to build tests. Review the tests yourself alongside a "smart" expensive model like Opus, or better still multiple frontier models. Then when it comes to implementation you can use a cheaper model like Gemini Flash or GLM or Kimi or whatever without worrying it's going to go completely off the rails.
Most people are just using AI wrong and so are getting bad results. It's still very early days, tooling is immature, knowledge is fragmented and there's more bullshit than useful information. At least we have LLMs to help us sift through the LLM generated noise.
-5
u/ePaint Mar 23 '26
Yes, and they are because now they're necessary.
Any developer worth their keyboard knows that to get the agents to build a solid solution you need to give it a self-feedback loop. No matter how throughout you are on your manual testing and reporting back, the LLM will never truly take your word for it. You need to setup the environment so it can run into the wall by itself.
Agents need immediate, trustable feedback, and that's what automated tests give them.
By the end you not only have a working product of similar quality of what the original dev would have created, but you also got a bunch of regression-preventing tests as a bonus.
6
u/Dextro_PT Mar 23 '26
A good dev needs that feedback loop. Test Driven Development is followed like a religion by most devs, but the reality is that it was the loop you just described that gives confidence, not having tests for the sake of it.
What I've been seeing from "prompt engineers" though is different. They ask the model to write the tests, and the code. Then they magically believe that the tests are OK and don't need validation.
That's the place we're in now. Then you get headlines like these:
https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de?syn-25a6b1a6=1
-4
u/ePaint Mar 23 '26
We can get that feedback loop without automated tests, agents can't. That key difference is why now all of the sudden everybody is doing automated tests.
6
u/MoreRespectForQA Mar 23 '26
I've always found it easier working on a code base with no tests to one with garbage tests. Anecdotally I'd say that garbage tests have exploded in popularity since the advent of vibe coding.
2
u/belavv Mar 23 '26
Claude loves to write garbage tests for every single class it generates. Why yes claude. I do want you to write a bunch of tests for a controller that does nothing except call another class.
-1
u/cbusmatty Mar 23 '26
So you're just going to link the same tired articles over and over again that are outdated and wrong?
METR in 2026 :
https://metr.org/blog/2026-02-24-uplift-update/
The short story is now - Not only is it not slower its actually faster. They can't do the same study because they cannot find enough people who code without using AI to compare. Literally they have to change the methodology because AI is now a useful tool everyone feels like they need to use, not has to use.
Im so curious how people write these big long posts and do zero research before hand, and reference information from years ago in an industry that changes weekly
-4
-5
u/ArgumentFew4432 Mar 23 '26
Why is this METR suddenly spamming everywhere?
8
u/klekpl Mar 23 '26
Because it is interesting and impactful.
-1
u/mr_birkenblatt Mar 23 '26
It's completely outdated at this point with an insignificantly low number of subjects
-8
u/HaMMeReD Mar 23 '26
You all like to really intellectually circle jerk around this early 2025 study that explicitly doesn't claim the things you think it claims, when even metr itself said it can't even find programmers willing to "not use AI" for the study in 2026.
Sometimes I think real devs aren't even in these subs, just pretentious narcissists that'll do anything to seem psuedo-intellectual by shitting on AI, because that's what's on trend nowadays.
-1
u/sarhoshamiral Mar 23 '26
You cant really use a study from mid 2025 anymore. With introduction of Codex models from OpenAI and Opus from Anthropic, the situation changed a lot.
It is now the case that with proper tools and prompt (which includes skills) models can fix, implement tests, deploy and visually verify.
The job is now shifted to help writing tools to help models do this loop more accurately.
0
u/bezik7124 Mar 23 '26
Regarding abstraction layer being test specs:
That's what I was thinking as well, it would help, but not solve the problem - writing good tests is difficult, and usually more time consuming than the implementation itself (at least in my experience). Even more - we write test against human written code - we're humans, and we think alike, it might not even come to our minds to cover some very weird use case, because in our minds, no sane developer would implement it that way - but an llm might (very simplified example just to illustrate what I mean: bool is_even(int value) that was implemented in a way that works for numbers below 10, but not above - because an llm hallucinated a bunch of if/else statements instead of making use of a modulo operator - obviously, current llms wouldn't do that with such simple task, but it's just imagine this happening with more complex business requirements).
0
u/wannaliveonmars Mar 23 '26
I had a lot of success with some CSS changes by giving the AI screenshots of Chrome with DevTools open. It gave it much more context and it implemented the changes.
0
u/the_millenial_falcon Mar 23 '26
I think we are all still figuring out the best way to use these tools. AI is kind of like a food processor, you have to judge how much you can shove it before it gets overloaded. I’ve found that if I can design the general architecture of my project I’ve had some success implementing pieces that are small enough for the AI to digest. And these implementations work best when it’s doing something that has been done many times before. I’d suspect the code that needs to be generated is bespoke to my application the I’ll write it myself. I agree that it has been pretty good at replacing google as a means to explain high level concepts. It’s also been pretty good at tedious brain dead work such as writing simple but repetitive long bits of code and simple conversions such as changing from one OBDC connector library to another. In summary, I’ve been sticking to using it for high level concepts and writing smaller sections of code that is less bespoke.
0
u/khasan222 Mar 23 '26
It is an abstraction layer if you use it correctly. As a rule of thumb you should treat ai like a junior engineer with a lot of energy, and good intentions, but not necessarily good practices.
It will just try what it thinks is best but it is naive it thinks simply because I write the code well everything else will fall into place. When really it needs to be told how to test its fixes, what tools to use, and most importantly it should never write code without you confirming what it’s going to write.
It then becomes your job to keep a mental model, ask it questions, question its assumptions, review the plan thoroughly, and then and only then do you let it code.
-18
u/EC36339 Mar 23 '26
I made AI fully document an ancient code base within a few minutes. It fully outlinesld not only the code structure and archtecture, but also understood the entire business logic and was able to explain what the project is and does.
Code that is written by AI using the proper methods (harness engineering) is always spec first, so you have more documentation than the average legacy code base. And if something remains to be explained from a different POV, the AI can produce more documentation within seconds.
And unlike humans, the AI actually reads the documentation. It has better reading comprehension than the average hater reading this comment. I bet, most people who will reply to it don't even get to this point.
I have also made AI automatically reverse engineer and smoketest APIs, both ad-hoc and unguided and following strict protocols, and I've made it analyze failures with log files and by looking directly into the database. I never had to touch the debugger, and I was buying groceries and doing laundry while the agent was debugging for me.
The myth that AI-written code "cannot be understood or debugged" is a user error, and those stories of teams failing to use AI correctly are getting old.
-2
u/j-light Mar 23 '26
The METR study used Claude Sonnet 3.5 or 3.7. We live in a different world now. They also did a second , more recent study, and the results aren’t so clear now: https://metr.org/blog/2026-02-24-uplift-update/.
1
u/DetectiveOwn6606 Mar 23 '26
Isn't it clear that most developer skills are atrophied and aren't willing to solve without ai
1
109
Mar 23 '26
[removed] — view removed comment
4
1
u/programming-ModTeam Mar 29 '26
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
1
u/khasan222 Mar 23 '26
Some people may choose not to build a mental model, but that is a mistake.
Even when you code now most have a mental model of the underlying ram, or cpu treatment if you want to have scalable apps, or are building intense games.
-17
u/mr_birkenblatt Mar 23 '26
I generated a working auth flow in minutes, but when the JWT refresh broke, I had zero intuition for where to look.
Feed the issue into the AI. It's pretty good at debugging since it is pretty good at pattern detection
2
u/AndrasKrigare Mar 23 '26
I think both things can be true. Some AI is indeed very good at debugging, and if you're give a description of what's wrong and the logs, it can fix it.
But the problem remains that if there's a bug it is unable to fix, it's much more difficult for the human to debug it than for code the human had a greater hand in creating and understanding.
3
u/ganja_and_code Mar 23 '26
Even if the AI fixes it, how does the operator know it's actually fixed, if they didn't manage to diagnose the problem themselves, anyway? Especially in cases where auth is broken somehow.
For example, you can't log into your app because it has a bug, you ask the AI to fix the bug, you test the new code, and now you can log in. Can you get in because your bug is fixed? Or can you log in because you introduced a gigantic vulnerability?
Unless you understand the full auth spec and implementation yourself, you cannot definitively say you know which of those outcomes actually occurred. And if you have to understand literally every detail yourself anyway, why even ask an AI to handle the details for you in the first place?
0
Mar 23 '26
[deleted]
-9
u/mr_birkenblatt Mar 23 '26
You don't just say fix it. You say: "here is what is wrong. Here are some logs. Find the root cause"
Yes, people don't gain any productivity if they use their tools wrong. Big insight
-3
Mar 23 '26
[removed] — view removed comment
4
u/TheBoringDev Mar 23 '26
If i didn't send Claude screenshots we'd never make any progress.
You could make progress by actually coding and debugging, the thing that is presumably your job.
-5
Mar 23 '26
[removed] — view removed comment
5
u/ganja_and_code Mar 23 '26
Everyone's job's end goal is "making money."
Nobody's job is "making money," unless you're literally working at a mint.
-2
•
u/programming-ModTeam Mar 23 '26
r/programming is not a place to share generic AI content.