People say something like this is an example of “AI is replacing engineers,” but that’s ridiculous. What’s actually happening is that one engineer with AI now does the work of ten engineers, which will simply lead to more exciting opportunities for the other nine to “focus on higher-level problems” such as updating their resumes.
That is a pretty good setup and delivery I must say
I think really things will just start shifting as things really do start to get better and step changes of capabilities where “I’m not even going to try to get opus to do X because I know it’s going to suck” moves to “oh wow it’s actually helpful” to “I don’t really even need to be that involved”.
Places where engineering labor is the bottleneck to better output will be where talent migrates towards and places where output is capped regardless of engineering labor are going to be where talent migrates from. I don’t really see this apocalyptic view really accurate at all, I think it’s really going to be cost / output will reduce. It’ll make new markets pop up where it wouldn’t be really possible to justify engineering expense today.
I love Claude Code, but this feels a bit like the perennial "our team spent a year on project X and then some intern built the same thing in a hackathon" claims. The hard part isn't writing the code, it's investigating, testing, integrating, etc. A rule of thumb I've seen in some places (Google certainly seems applicable) is the project will take a month for every day it takes to make the prototype.
Which is no shade on Claude Code, but given everything CC has already done, this seems pretty normal.
The code it produces (svelte, typescript, python) is usually riddled with small errors , deprecated usage, reimplementation, and terrible segmentation. This is opus 4.5. Literally every single time if I did not review it carefully and edit it thoroughly it would be a mountain of extremely hard to debug tech debt. It’s a toss up if it’s actual faster to be honest. I think the phenomenon of people expressing their hopes of the technology as if they were the current reality is an extremely interesting phenomenon.
Your experience mirrors mine as well. I will say since I’ve got both data science and engineering workflows, data science is where I’ve been accelerated the most because opus can do ad hoc scripts and e.g. streamlit websites and data munging very well so all of the things that take time before decisioning are much faster.
For engineering, its extremely easy to not only acquire tech debt but to basically run yourself into the ground when opus cannot do a task but doesn’t know it cannot do a task.
BUT: what I will say is to me and to others the trajectory has been really impressive over the last 1.5 years, so I don’t view the optimism of “we’re nearly there!” As being kind of wishful or magical thinking. I can definitely believe by the end of 2026 we’ll have agents that break through the walls that it still can’t climb over as of today just based on the rate of improvements we’ve seen so far and the knowledge that we still have a lot of headroom just with current stack.
"I'm not joking and this isn't funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned... I gave Claude Code a description of the problem, it generated what we built last year in an hour."
The real question is "could she have written that problem statement a year ago, or is a year's learning by the team baked into that prompt?"
There are lots of distributed agent orchestators out there. Rarely is any of them going to do exactly what you want. The hard part is commonly defining the problem to be solved.
There’s definitely a strong Clyde-the-counting-horse effect. language models perform vastly better on questions to which the question writer knew the answer.
The funny thing is: the abilities that people thought of as clever at the time (doing maths) can be done with a $1 component these days. The thing Clever Hans actually did (reading the audience) is something we spend billions on, and in some circles it's still up for debate whether anything can do it.
We often hear claims like "do this and you'll make so much money" or "this is so good it's unbelievable." Occasionally, they turn out to be true. I've experienced a couple myself and feel fairly positive about the current one. The initial resistance comes from not wanting them to be true because then I know I either have to take action or risk missing out. It's a weird psychological thing that I now try hard to avoid.
I find Claude (and specifically Opus 4.5) insanely impressive and frankly scary, but I think there is some Pareto principle that people ignore when discussing it. Specifically I find it is great at the first 80%, but I struggle getting the last 20% over the line with it. I think this colours people’s judgement, because influencers/casual/beginner users only experience that first 80%
Nevertheless, regardless whether these are real results or just hypes, I do see a bigger existence of AI tools in all processes from planning to coding to wrapping up to even sending an email out. The writing is on the wall.
I'd love that too. We do use AI to summarize meetings, but sometimes people want to hear others talk, so AI is still not ready for that. It doesn't have the context.
I think the key is integration. It is a lot of nitty-gritty to clean the corporate data, train AI with the data, and tweak it to suit different "roles". But if someone can make it work, it's a lot of $$$.
we tried that a little while ago to summarize a few meetings into a timeline of events; turns out the thing invented several milestones and events that don't exist and meeting summaries for meetings that never happened... sigh
> so AI is still not ready for that
it really isnt, at least for the tools we are using...
Every time someone says “AI built in an hour what took us a year,” what they really mean is that humans spent a year doing the hard thinking and the AI merely regurgitated it at silicon speed. Which is, of course, completely different from productivity.
Also, if it truly took your team a year, that probably says more about your process than about AI. But not in a way that threatens my worldview. In a different way. A safer way.
Let’s be clear: writing the code is the easy part. The real work is the meetings, the alignment, the architectural debates, the Jira grooming, the moral struggle of choosing snake_case vs camelCase. Claude didn’t do any of that. Therefore it didn’t actually do anything.
I, personally, have spent years cultivating intuition, judgment, and taste. These are things that cannot be automated, except apparently by a probabilistic text model that keeps outperforming me in domains I insist are “subtle.”
Sure, the output works. Sure, it passes tests. Sure, it replaces months of effort. But it doesn’t understand what it’s doing. Unlike me, who definitely understands everything I copy from Stack Overflow.
Also, I tried AI last year and it hallucinated once, so I’ve concluded the entire field has plateaued permanently. Technology famously never improves after an early bad demo.
Anyway, I remain unconcerned. If AI really were that powerful, it would have already made me irrelevant, and since I still have a job, this must all be hype. QED.
Now if you’ll excuse me, I need to spend the afternoon explaining why a tool that just invalidated a year of human labor is “just autocomplete.”
>I, personally, have spent years cultivating intuition, judgment, and taste.
exactly. I am using AI to make tons of good code and I love it. but the AI makes silly oversight or has gaps in logic that to someone with 'hands on' experience thinks of right away.
im debugging some web server stuff for hours and ai never ask me for the logs or --verbose output, which is insane. instead the ai comes up with hypothetical causes for the problem then confidently states the solution.
I would assume there are open source solutions to the problem it could have trained on, if so it would be interesting yo see how they had influenced what Claude produced here.
I hear over and over from the staff engineers where i work that ai churns nothing but slop. When they know its ai they refuse to approve PRs even when it works cause its not the way they would do it.
Prime example was a quick set of scripts to run some tasks that were commonly performed. The ai version took a couple days to get the patterns right but worked and i was ready to not have to think of it anymore. A solid POC i thought. Well along comes the old hat saying its not the way he wouldve done it. Says he’s going to take a crack at it over the weekend. A month later and he still wont approve my pr, still not done with his better version and the code he has checked in is wayyyy more complicated using self-coded routines rather than preexisting libraries or even forked versions of them cause they are “security risks”. Then theres the things he straight up replicated what i produced with new file and variable names. Im still using what i put together aince his is still not done but in the mean time talking with powers that be about how we balance time, cost and quality.
Where is the prompt? Are they going to hide behind "prompts are IP" now?
AI boosters are heralding this as a new age of programming, but they conveniently ignore that the prompt in these hyperbolic articles (or GASP the source code!) is never shared, because then we would be able to try and replicate it and call out this bullshit. There would be no more hiding behind "oh you are not using the correct model".
Shame on all these "reporters" as well who never ask "Okay can we see the code? Can we see the prompt, since it's just 3 paragraphs?"
i don't know if its just a bubble i'm in, but it seems like most of my day as an engineer is meetings/endless scrum events and tracking problems yet we sound more energy on automating code with llms than on automating all that other overhead...
i wonder, is coding really the bottleneck in most cases?
I routinely spend more time tweaking a prompt than Claude Code spends creating something. The better the prompt, the faster it seems to work (with better results). So I can totally relate to your comment.
It's awesome to be amazed by some cool new technology but let's not be naive.
Yes. Obviously no one is claiming that Claude Code literally made a year pass in an hour as if it were Superman spinning the Earth faster. Can we just keep the goalpost put for a second?
P.S. EDIT:
The big question will soon become - how technical do you need to be to build a system, because most of those learnings, concepts and associations are surely at the domain level. Or phrased differently: to what extent will future software development shift from hands-on engineering to hands-off technical guidance? Perhaps the future developer role would be much more similar to today's TPM (Technical Program Manager)?
how long would it take someone to reimplement DynamoDB's APIs? they're trivial. that was never the hard part....
I'll be impressed when a big service like Google Photos can run 100% with LLM Oncall without paging anyone or any human intervention. FWIW this was always my benchmark.
We've all used Claude, how much can it really do in one hour? Maybe 1-3kloc of quality bug free code that does what you want it to do? Ok, so are we to believe that a team of Google engineers write greenfield code at a rate of 10 lines per day? 1 line per person per day? Or did her team spent a year on some combination of iterating, learning, discarding versions, being blocked by other teams, being blocked by corporate processes etc?
Of course it's the latter, this article is silly clickbait. AI won't help you convince a peer to go with your design, won't clear your work with legal, yada yada.
This is not an interesting result. Coding has never been the bottleneck in software development. How many of us have spent months on simple projects where requirements changed, stakeholders were indecisive, and the project dragged on and on? Oftentimes to be cancelled or otherwise deprioritized? It happens a lot!
Indeed... I've had many projects where initial implementation took a few days but getting to the finished product took months, mostly because... human interaction between clients and developers. Now what if the client can interact directly with the LLM ? I don't know.
> There are various options, not everyone is aligned... I gave Claude Code a description of the problem, it generated what we built last year in an hour.
This is silly, they didn't spend a year trying to crank out the right code, they spent a year not being aligned, disagreeing on approach, getting people to commit, support from other teams providing necessary integrations or platform etc. - Claude didn't help with any of that, it just did the code part, which wasn't the problem in the first place.
We're a small B2B company, been 5 devs for a long time, recently expanded to 10.
This mirrors our experience with our big customers. Minor changes requires countless meetings with a dozen people and nobody takes charge, everything has to be repeated at least three times because people rotate while this circus goes on and so on.
In the end we finally get the people who know what's up involved and it results in a brief meeting and like an hour of writing code and testing.
One of our strengths is that we've all been here so long. We know these large customers way better than they do, because we still have the dev and the project manager that worked on the last thing, even if that was 6-7 years ago. We've literally had a large Fortune 500 customer call us and as how their systems worked, systems we don't even integrate directly with. And we could inform them, since we had retained that knowledge from a project some years ago.
My reading is precisely the opposite, ie that she fed it the problem without the solution and it independently came to the solution they spent months arguing over.
Unless that was a complex constraint-satisfying compromisation problem I don't think that's different though? My point is that it didn't take so long to produce the code of this solution, it took the time to agree that it was the solution. Unless you just get everyone to agree 'whatever Claude says is the solution', having Claude produce it doesn't help!
It is different. You suggested that rakyll told Claude to simply implement a solution that her team already put the legwork into designing. I'm saying that it sounds like Claude produced the solution independently based on a description of the problem. Those two are completely different and if you can't see that, I'm not sure what to say.
> having Claude produce it doesn't help!
Sure. Also, it could be a coincidence that it came to the correct solution, we can't discount that possibility.
I assume at least some of it was technical disagreement, so PMs sure but also TPMs and what have been called SWEs even if hypothetically we don't call them that any more because in the brave new AI world they don't need to directly create software any more.
(I've personally never applied to somewhere that advertised that it would call me a 'developer', because that just sounds like a very boring factory-line 'churn out the code as described in this work ticket' role to me, that I don't want and didn't get a professional degree for, even before all this LLM/'agentic' possibility.)
This is how I viewed it, they spent a year, figuring out exactly what they wanted, then they gave it to the system. I think it might have been different if they had started with AI in the first place.
Scoffing is unfair and uncharitable, but I’d guess it says more about the environment the managers of those developers have created. Big companies build hurdles, not express lanes.
Let’s actually say things that are realistic instead of coming up with shallow delusional dismissals. The engineer is pretty high ranking and he’s talking about a team of engineers at a company with a famously high bar that many engineers on HN wouldn’t be able to get in.
You may disagree. But disagree realistically. Have a valid reason why you disagree instead of attacking their competence.
Or if after you thought about it and can’t find adequate reasoning other than google engineers are total shit…. Then maybe consider that your opinion is incorrect.
There is no code, there isn't even a prompt to try and replicate it, the dismissal is just as realistic as the article.
The article says the prompt was 3 paragraphs, so why is it not shared? Without that it's just a talking head presenting a nothingburger. Put up or shut up.
That there are teams that are basically paralysed by the amount of management, politics, meetings and other various hurdles and distractions put in their way. Enter someone smart and free from all these constraints and the job gets done in no time.
Frankly, as an AI enthusiast, this was my take as well. A team of Google developers can design, implement and iterate in a year much more than Claude Code can in one hour. If it's been so quick it's because it evidently cut with the politics and the analysis-paralysis and jumped straight to the implementation.
You realize they are speaking in favor of their competitors? This isn’t corporate shilling. It’s an engineer speaking against the interests of his own company because the on the ground reality of AI is making us all look in the mirror.
reply