Rendered at 05:16:54 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
a_bonobo 4 hours ago [-]
>On my visits to the Bay Area, I would ask AI researchers or interns why they are doing their current research or projects, when in a year or three agentic LLMs could probably do them;
This is such a weird point to make that doesn't become correct just because everyone makes it, all the time. Why clean the ocean if some magic future tech will clean them? Why save the world now if some benevolent AI is 'just around the corner' and will do it for us? And people have been making this point for years now, and it's not like my job got any easier. I just got more AI.
And I say that as someone who uses Claude Code in complex environments almost hourly; I, as the human, still have to do the thinking as Claude still 'can't jump' [1] and I have seen no evidence that they (or similar AI, any time soon) will 'jump' like a human brain does.
Same reason some think preserving the environment is pointless because the believers will ascend to heaven, either way. It’s a religion. It’s dogmatic nihilism.
fhub 4 hours ago [-]
> I, as the human, still have to do the thinking as Claude still 'can't jump'
I still have to do quite a bit of thinking but the amount of of thinking I do per task is trending down. I agree LLMs are not good at abduction but very few humans are either and very few jobs/tasks require it. I can't talk for researchers jobs though. But perhaps fewer researchers would be desired by these labs (not none).
bigfishrunning 3 hours ago [-]
> I still have to do quite a bit of thinking but the amount of of thinking I do per task is trending down
Don't worry, I'm sure you'll hit your goal of zero thinking soon!
xprnio 2 hours ago [-]
Trending towards the Homo Amens Mechanicus: the mechanical thoughtless human. What a goal
champagnepapi 3 hours ago [-]
[dead]
jihadjihad 3 hours ago [-]
> I agree LLMs are not good at abduction but very few humans are either
I, too, am glad that few humans seem good at abduction.
although, if i'm out of tokens and have to wait a full day, i won't bother doing some things manually because the day i'll spend doing something won't take more than 1 hour the next day when tokens are available again.
MikeTheGreat 1 hours ago [-]
That seems like a somewhat orthogonal point? Like, if I'm a carpenter and my batteries all run out / I can't actually power my power tools then the best course of action is to go home and recharge all the batteries instead of trying to hand-cut 100 pieces of lumber today. After all, the power tools can do it a lot faster (and with less effort) than I can.
I say this as someone who's watched a bunch of woodworking videos but hasn't actually done this myself :)
skew-aberration 3 hours ago [-]
AI has made 'jumps' in demanding fields like leading mathematical research and has made advancements in AI research itself. Is now a good time to start a maths career? Is there a field of research (yours?) which is inherently (more) AI proof?
Btw, I think the discussion of Einstein's career in the paper you link is historically wrong in many respects, particularly the argument about 'weak signal'. Einstein was in fact working on some of the most mainstream and widely discussed problems in physics of the day, he is admired for the creativity of his solutions to those problems, and much of his work built incrementally on ideas and breakthroughs that came (long) before (as all research does).
Article suggests that a central motivation of Einstein's work was resolving action-at-a-distance in Newtonian mechanics - yet Maxwell introduced the same Lagrangian field theories for electromagnetism we use today 50 years earlier to solve the same problem for Farraday's laws of electromagnetism. Similar wave equations existed even earlier. Heaviside in 1893 extended this technique to gravity (matching 'weak field' GR) 20 years earlier. So this is perhaps the one aspect of gravity that had actually already been solved before Einstein. Authors might be conflating his work on action-at-a-distance in QM.
Einstein's GR extended the linear 'weak field' understanding of gravity to include the non-linear self-referential case where masses themselves create gravity. This was mathematically incredibly difficult but was necessary precisely because SR's mass energy equivalence created so many strong signals that were unresolved. For example: if finite energy is mass, then mass changes as objects accelerate past a large mass like a start, and hence their propagation in space could not be explained by linear EM style field equations. Many such considerations were causing very 'strong signals' in SR, and there were analogous problems in QM atomic models being developed at the same time.
SR was also a solution to a problem that was actively being worked by many of the leading physicists of the day. SR actually does match Newtonian mechanics for a single observer - it resolves contradictions in the case of separate observers, by allowing them to assign different values to the speeds, masses, etc of objects such that each object appears to follow Newtonian mechanics for each observer. Again, this was necessary because of a lot of contradictions related to the behavior of light that had been well-known for ~20 years at the time.
Personally, I don't consider this kind of reasoning to be beyond the capabilities of future LLMs (even current LLMs if the task was broken into technical rather than philosophical problems). Personally, I doubt that such problems could stand open for 20+ years waiting for a creative genius to solve them in the modern world.
> > Mathematician Richard Hamming used to ask scientists in other fields "What are the most important problems in your field?" partly so he could troll them by asking "Why aren't you working on them?" and partly because getting asked this question is really useful for focusing people's attention on what matters.
> I imagine someone being asked this question, and how they should respond. I think like so - ‘Fuck off Richard’.
> This is partly because I imagine this question being asked in a kind of snarky, gotcha kind of way, with some sort of nerdy superiority. Like ‘ha your behaviour is inconsistent with your implied preferences, you idiot, do you even von Neumann–Morgenstern?’
paul7986 3 hours ago [-]
By trade I'm a UX Researcher/Designer who designs in code (HTML/CSS) and have done so since 2009. Recently I vibe coded an entire python app with a database and each time I didnt know what to do I would just feed screenshots to Gemini or Codex for guidance (i think i could share my screen with Codex and it can guide me via a voice conversation). I know I could follow up and build a companion iPhone and Android app using these tools.
Overall, I'd like to understand those who have a positive outlook on design and software engineering as a career. Where do you see the opportunity where I just see a bleak one where anyone can do this stuff by typing or talking to AI? Myself, after 17 years in the field I am begrudingly back in school for a new medical career. As well, anytime an IT recruiter reaches out I am getting responses back only after under-cutting the hourly rate I use to demand and what others probably are still trying to get. And with it feels even bleaker as it becomes a race to the bottom!
griffiths 58 minutes ago [-]
In my experience, not everyone can really do this stuff by typing. I think you need to be creative, resourceful, inventive, open minded and have ideas how to approach the typing/prompting. I see many people struggle in using AI.
esafak 4 hours ago [-]
Also, if you believe your well-paying job is eventually going to be automated you would be prudent to bank the money while you prepare for the future.
saghm 1 hours ago [-]
It also seems kinda tone deaf. If someone basically told me I was wasting my time and asked what I would do in the future, I would not bother giving them a particularly thoughtful answer because trying to spend effort justifying my life choices to them would be the actual waste of time.
What kind of answers were they expecting to get?
simonw 4 hours ago [-]
> We already know developers don’t actually spend most of their time writing code, with studies at Microsoft and elsewhere showing it’s closer to 14 percent.
Anyone else finding they're spending more time writing code (or at least driving agents to write code) now?
14% used to feel about right for me - I'd spend the rest of the time researching approaches and libraries, planning things out in issues, or sometimes just thinking really hard about problems I ran into.
Now... I still do those things, but I'm doing many of them faster - and I'm often doing them while my coding agents are churning away on code.
There's also this weird effect where the harder a problem is the more I can get done in parallel with it, because an agent might need to spend 20 minutes on it without my involvement.
01100011 2 hours ago [-]
You read my mind. I suspect it is a transient spike while I blow through the backlog and I'll run out of things that AI can vastly accelerate in, say, 6 months. But right now? I'm spending 80-90% of my time blasting through implementing features, finding bugs, fixing old bugs, writing and improving my tools... Code was never the majority of my job. But right now the bar to doing things is so low and the sheer joy of blasting through some previously tedious, low to medium hanging fruit is thrilling.
AdieuToLogic 2 hours ago [-]
>> We already know developers don’t actually spend most of their time writing code, with studies at Microsoft and elsewhere showing it’s closer to 14 percent.
> Anyone else finding they're spending more time writing code (or at least driving agents to write code) now?
Not really, as once it is time to write code, the problem has been defined/understood (to the degree possible with knowledge acquired at the time), and encoding it is largely an exercise in typing along with verifying assumptions via test suites.
Does GenAI quicken some portions of the above workflow? Sure, in the same way IDEs with contextual code snippet suggestions can make encoding faster.
geoduck14 4 hours ago [-]
I used it to write SQL and make dashboards. Back in the day, I would spend a lot of time doing that, then I changed roles. I dipped my toe in it recently and used AI exclusively. I would send a prompt, see the output, decide if that is what I wanted or not. I kept my brain in "what-if mode" and I let the LLM handle the technical specs.
geraneum 50 minutes ago [-]
Does the code get reviewed? How do you deal with increased amount of code that may need to be looked at?
enraged_camel 4 hours ago [-]
Yeah. I spend most of my day driving agents to write code, verifying the results, orchestrating work streams, and so on. The rest of the time, a Fable agent is organizing work in Linear/Jira and making sure coworkers are getting their stuff done in a way that won’t conflict.
cyliu 43 minutes ago [-]
Some experience from my work:
- In biz development, a dev usually spends 30-40% time on coding, and more time on requirement discussion, integration testing (especially when the tests involves mobilephone or car)
- coding time can be reduced to 30%, which means reduce 20%-30% time of the full pipeline
- meanwhile, every phase and role is using LLM now, for example, product manager can produce longer requirement doc easily (we can use LLM to read it anyway:) Meeting sometimes is more than before, because more document output leads to more reading and discussion.
- I hope to find new ways to express biz requirements, in a more efficient and automatic manner.
- Shorten the requirement-dev-test-deploy loop is very important. OUTPUT is not OUTCOME. It is equal when we can see the final result, instead of intermediate metric.
- Agentic infra is extremely useful, or every one will find a way to access the database, report and ops system, in some weird fragile method.
mkozlows 4 hours ago [-]
I feel like all you need to know about how seriously to take this is that they cite that ancient early-2025 METR study, and describe it in the text as "recently one even found..."
katzgrau 3 hours ago [-]
Same thought - 80% through reading it occurred to me to check the citations. A few items from 2025 and most well before that.
So much has changed since late 2025 one can’t really draw any conclusions from this.
In fact, I’m guessing things will continue to move so fast that by the time one were to execute a survey of developers, many of the responses and findings are no longer relevant.
joshuastuden 2 hours ago [-]
Exactly. I saw them using things from 2025... AI sorta sucked then and didn't really "take off" until that Opus drop in December or whatever it was.
greenhat76 2 hours ago [-]
Your point really goes both ways, we really don't know anything about how LLM usage is affecting anything. No one knows, it's the wild wild west, which is whatever. But I think no one can really draw conclusions from what's happening in tech right now.
Reminds me of COVID and how everyone was fighting over early trends during that time.
CompoundEyes 3 hours ago [-]
I felt the same and why didn’t the authors look over METR’s recent material?
The whole point of the 2025 one is that they found the self-reporting to be significantly inflated, which is why self-reported surveys like this one are hard to trust.
mkozlows 43 minutes ago [-]
Yes, but their newer write-up discusses that (and shows that the self-reported numbers have gone up radically, in a way that suggests that even if there is some inflation, the numbers are almost certainly positive if you deflate).
They also have an update -- linked from the original study! -- explaining that it's out of date and no longer reliable, and explaining why they had to cancel a follow-up study because it was understating productivity gains (but also was showing wins for the people who carried over from their previous study): https://metr.org/blog/2026-02-24-uplift-update/
The authors of this paper decided to ignore all of METR's follow-up data and discussion, and to report only the ancient number from early 2025 (a time when Windsurf was state of the art). And then, rather than apologizing for it, and caveating it as a number not to be taken seriously, they described it as a study done "recently."
That's either shockingly dishonest or incredibly out-of-touch.
bwhiting2356 26 minutes ago [-]
> A June 2025 study of Microsoft developers
A year ago feels like forever
kylecazar 4 hours ago [-]
I don't understand Myth 1 (Developers Spend Most of Their Time Writing Code).
They quote a study in which developers report to spend 11-14% of their day coding. The rest is stuff like solution design and meetings. The insinuation is that AI can at most automate 14% of your day.
The problem with this argument is that once you have code, some (not all) of the precursors to code go away.
unknownfuture 4 hours ago [-]
Okay.
Show me the evidence that AI has an impact on productivity when doing design work. Or reducing meeting load.
My own experience is that AI doesn't tighten the design cycle, and in fact might extend it by encouraging gold plating.
01100011 2 hours ago [-]
It helps me. Case in point, I recently had a API refactoring project that was 80% busywork and only a small amount of code. It's crap work, but it has to be done and it's part of my role. I told AI to generate the initial design doc. It took it upon itself to reference the local headers on my system and found some APIs that should be included that I hadn't even considered would also need to be touched for consistency. It saved me hours typing up the doc, requirements, test plan, etc and then saved me embarrassment by preventing me from making a stupid oversight on a tedious and boring task.
thewhitetulip 1 hours ago [-]
AI is helpful in such projects. Less so in other projects where design is heavy
Izkata 2 hours ago [-]
> Or reducing meeting load.
Well, I expect when you've vibed too much and lost track of the code, and can't answer questions in meetings anymore, you'll stop getting invited to them.
griffiths 17 minutes ago [-]
How often do you talk about low code details in the meetings? It is mostly about requirements and goals (IMHO) and "architecture"/design, and now I wouldn't even bother my peers with questions about the code as I can let AI tell me how things work exactly as written in the code, not some thing that someone remembers or thinks how it works (in large codebases, most developers only know in detail the things they are working on currently or from recent history)
sandeepkd 3 hours ago [-]
From the patterns I have seen people would tend to use the time to build demo's using AI instead of design and then have a back and forth on the demo itself. One has to consider the fact that demo's look more convincing/complete and give an impression that the design decision has been made. In some ways, how agile got rid of the need for explicit & detailed documentation, the AI created demo's will cut the requirements of high level designs too.
Exoristos 1 hours ago [-]
> demo's look more convincing/complete ...
In the case of an LLM generated demo, usually deceptively so.
> and give an impression that the design decision has been made.
In the case of a vibed design, this is the opposite of useful for the team.
simonw 4 hours ago [-]
What kind of shape of evidence would you find convincing?
unknownfuture 4 hours ago [-]
Self-reported or observational data capturing time spent for categories of task ala every other similar study in this space?
This isn't exactly novel territory, here, Simon. Let's not pretend I'm asking for something strange, unprecedented, or unreasonable.
Isn't this falling into the "lines of code" trap TFA mentions?
More code written is not a good measure of productivity. It could be garbage, or redundant code, or simply not addressing the real or more pressing needs, it could be building the wrong thing, etc.
Like TFA mentions, it's been known for decades LoC is a misleading metric for productivity. It's one of the lessons of software engineering.
qsera 2 hours ago [-]
I don't think volume of code changed was the metric the other commenter was asking for.
2 hours ago [-]
bluefirebrand 4 hours ago [-]
People working fewer hours :)
kaashif 3 hours ago [-]
Damn, looks like we have lower productivity than cavemen!
keeda 2 hours ago [-]
Sir, this is Capitalism.
therealdrag0 2 hours ago [-]
It certainly helps as a research assistant for design work. But it can’t do it for you.
mountainriver 4 hours ago [-]
It does because you can now just steamroll features out the door and make everyone look bad that’s sitting around in meetings all day
cuttothechase 4 hours ago [-]
[flagged]
mkozlows 4 hours ago [-]
Yeah, this seriously drives me nuts.
That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code. That sync up with the QA engineer you did to hand it off to them? Don't need that meeting if you're not writing the code. That half hour you spent installing vim extensions? Don't need 'em if you don't open vim anymore.
There are engineers whose jobs go well beyond coding, of course. Staff engineers and principal engineers have had their jobs radically change because of AI, but not because it's writing all their code.
But there are also a lot of engineers -- your standard mid-level engineer, or even senior engineers at a lot of orgs with title inflation -- whose job is almost entirely about delivering code, and who spend all day either writing code or engaging in scaffolding around code-writing activities. Let's not pretend that automating away that code writing is a 15% boost.
decimalenough 4 hours ago [-]
> That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code.
How are you going to prompt the LLM or validate its output if you don't understand the requirements?
mikeyouse 3 hours ago [-]
In some number of cases, the business partner who would have passed you the requirements will just generate the code themselves.. I’m shocked shin some engineers don’t see a massive disruption coming..
blharr 33 minutes ago [-]
Sure, but why doesn't said business partner just give a requirement to the AI to do the business partner's own job? Since it is hypothetically superhuman at fulfilling requirements at such a point...
PMs seem pretty easy to replace. In fact, given any single role to fixate on, it's probably replaceable
2 hours ago [-]
claytongulick 2 hours ago [-]
Oh, some of us see a massive disruption coming, just maybe not in the way you think.
Talented, experienced devs leaving the field out of disgust would be pretty disruptive.
Crumbling, faulty technical infrastructure with unmanageable heaps of AI slop that no one understands would definitely disrupt businesses.
Skill atrophy, and an entire generation of "developers" that have never actually written code will be disruptive when something breaks and no one knows how to fix it (this isn't a hypothetical, I'm seeing this phenomenon in a lot of large enterprise groups).
The total elimination of novel solutions, new ideas and new approaches to development and the resulting industry wide stagnation won't be disruptive, but will certainly be a drag.
griffiths 8 minutes ago [-]
You will have artisans or software SWAT teams on one side and code factories on the other.
For most problems code factories will be good enough.
decimalenough 46 minutes ago [-]
> Crumbling, faulty technical infrastructure with unmanageable heaps of AI slop that no one understands
Replace "AI slop" with "legacy code", and you've got basically any large enterprise today.
The timescales are different though: it takes years if not decades to accumulate classic legacy cruft, while LLMs can spew up huge amounts of incomprehensible spaghetti in seconds.
mkozlows 3 hours ago [-]
Your PM can write the ticket, and your QA can test the output.
qsera 2 hours ago [-]
I think we would, at some point realize that the roles of PM and QA are best done by an LLM, while coding is left to humans.
So an 180 from the current coding-automation frenzy..
AdieuToLogic 1 hours ago [-]
>> How are you going to prompt the LLM or validate its output if you don't understand the requirements?
> Your PM can write the ticket, and your QA can test the output.
If your PM can write the ticket and your QA can test the output, why not cut out the middleman by having the PM write the coding agent prompt(s)?
And if your PM can write the coding agent prompt(s), why not cut out the QA group by having the PM write the verification prompt(s)?
And if your PM can write those prompts, why not cut out the PM and have your CSRs write the feature request/verification prompts?
And if your CSRs can write the feature request/verification prompts, why not cut them out and have the organization's customers write the feature request along with acceptance prompts?
And if customers can write those prompts, why would they pay you?
01100011 2 hours ago [-]
Also AI is now drafting design docs, generating PLC work products, entering it all in Jira, characterizing and root causing bugs... It's speeding up the 86% of my job that isn't coding. The article is a bit myopic and frankly contradicts itself.
SpicyLemonZest 4 hours ago [-]
If Claude told you to work on a task that you don't want to work on, or make a design choice that you think is wrong, would you do it? If not, then it can't really replace things like design or meetings. (Note that this is subtly but importantly different than the "vibecoding" model, where you just don't bother to supervise Claude's decisions.)
deadbabe 3 hours ago [-]
I don't know about others, but at work, the reason I only spend like 14% of my day coding is because I'm lazy, not because I'm actually doing other stuff.
hahahaa 2 hours ago [-]
Not lazy it is a taxing task like doing an exam.
Supermancho 5 hours ago [-]
|--------|-------|------|------|-------|------|
|Contract|Product|Design|Coding|Testing|Deploy|
Writing Code Isn't the Bottleneck, until writing code is the bottleneck, until it's not again.
pstuart 4 hours ago [-]
Getting a usable PRD is often the bottleneck.
hahahaa 2 hours ago [-]
The real bottleneck is Omega Star getting their shit together. And I ain't joking.
Exoristos 54 minutes ago [-]
Or SPS Commerce. Evidence is becoming unconvincing that they're even in business anymore.
sublinear 4 hours ago [-]
You forgot to add "coordination" to that pipeline. That is easily far and away the biggest source of delays.
That includes talking to vendors, meetings with every layer of stakeholder when just one person digs their heels, etc.
That is truly the final frontier for "AI", and one that it will likely never cross. That would be when even the execs and upper management feel threatened by "AI". But, since they also delegate so much, you often see someone at the bottom of the totem pole in those meetings. This is why nobody is getting replaced by "AI". We really need to move this discussion away from the scifi stupidity already. There is no singularity or godlike AGI about to take over the world.
I hate to use awful terms like "synergy" and "teamwork", but they do have a lot more substance and truth to them than any perceived threat from "AI".
zkmon 3 hours ago [-]
11-18% of time spent in coding is still very high number I think. For a large org with lots of process and risk aversion, this number could be as low as 5%. Even for 14%, the 10x improvement could mean 86+(14/10) => 87.4/100 => 12.6% overall time saved.
hahahaa 2 hours ago [-]
And time in coding is like time on highways for taxi drivers. A fairly useless metric.
baobeta2907 2 hours ago [-]
This is actually true at my company. They expect employees to be 10× more productive now that we have AI.
jdlshore 1 hours ago [-]
I’ve had people tell me, with a completely straight face, that they expected 10-100x productivity improvements. This is at the executive and VC level. The mania is extreme.
miraculixx 4 minutes ago [-]
So then they should get 10-100x more revenue, now that AI does all the marketing and selling.
mellosouls 56 minutes ago [-]
even an AI assist that makes coding twice as fast would, in theory, improve developers’ overall productivity by less than 15 percent. The other 85 percent of their time remains untouched
I stopped reading after this. AI has massively impacted most aspects of my non-coding work including the mentioned planning, understanding legacy code bases, setting up environments, etc etc.
Either this article is written by people with skill issues or - given the platform - its a biased and protectionist take that will fall quickly under the march of reality.
osigurdson 5 hours ago [-]
It seems that this could have been expanded or contracted to any Fibonacci number of myths.
dasil003 2 hours ago [-]
A lot of this rings true, but I think it's still too narrow. Sure, coding does not equal productivity, that is well debunked already. But I would argue that productivity is a product of engineering delivery + product decision making. Now where is the line between product and engineering? It varies by company, team and individual, but I don't think productivity can be measured for those functions independently, and in fact I see gains from AI on both the coding AND the product management side.
Basically as a senior tech lead in a large company engineering org, I don't have the bandwidth to individually validate every assertion from engineers on other teams OR from every product manager that comes with a half-baked ask. In the past I would be limited by the influence I could get through human relationships to strong SMEs with good judgment, and those folks always thin out as a company grows and calcifies. The number of creative and innovative thinkers dwindles, and the number of people protecting their turf and doing the minimum not to get fired increases. As a result many good ideas can get blocked by random gatekeeprs with poor imagination, poor expertise or both. However with AI I can follow up on gut instincts and fact check a lot more things, and ask incisive questions that can cut through a lot of organizational bullshit.
That's where I think most of the AI gains are today. Of course once AI plateaus and normalizes I think it will be baked into the org structures of tomorrow. But for now it offers real competitive advantage to those with the expertise to ask the right questions.
lovecg 3 hours ago [-]
> studies at Microsoft and elsewhere showing it’s closer to 14 percent
This is a depressing stat. The real productivity gains come from leaving soul sucking big tech companies where nothing gets done with any sort of urgency.
afdbcreid 3 hours ago [-]
In my open source work I believe this is the same. I don't have numbers, but I'm sure the vast majority of my time isn't spent writing code. Of course, it depends on how you define "writing code".
hahahaa 2 hours ago [-]
It is not urgency. Large production systems mean you are doing mostly unsexy operational planning. If I had a dollar each time I hear the word "data migration" I reckon I could do well.
lz400 3 hours ago [-]
Like many others in the comments, I feel there are a lot of assumptions in this piece. Before, coding is only 14% therefore, small slice. I think that's a very superficial assumption. That was because coding was expensive and we needed to be sure we didn't code the wrong thing. If code is as cheap as it is now, we will optimize differently, we will structure around it. Instead of so many meetings we will code 5 different versions of the same thing and choose, etc.
AdieuToLogic 1 hours ago [-]
> That was because coding was expensive and we needed to be sure we didn't code the wrong thing.
Coding has never been expensive as it is nothing more than a reification of a solution to a problem as it is understood at that time.
It is the underlying understanding of the problem which has always been expensive and remains so.
lz400 28 minutes ago [-]
Coding was expensive in the sense that once you decided what to do, it took a few engineers months / years to do moderately complex projects. That's not true anymore. Therefore the risk of "coding the wrong thing" is less.
champagnepapi 3 hours ago [-]
So you're suggesting that coding will take more of the PRD phase?
lz400 9 minutes ago [-]
Basically yes, there will be more coding in that phase, more prototyping, the PRD phases will be shorter too, there will be more pressure to deliver quickly and the PRDs will be under more pressure to move more quickly. This is what I'm already seeing to be honest.
langs 3 hours ago [-]
> Myth 2: Writing Code Is the Bottleneck
Writing code is indeed the bottleneck for same resource constrained companies.
Rapid code development creates more opportunities for trial and error, providing companies with more information for decision making, that previously might have been addressed by meetings.
Of course, this might bring other problems, but it might not right to generally speaking that writing code is not a bottleneck.
armitron 3 hours ago [-]
This reads like a critique of 2023 tooling published in 2026. Their Amdahl-style arithmetic (speed up a 14% slice, cap your gains at 14%) holds only if "AI" means autocomplete. Current frontier models do far more than that: research, code comprehension, review, test authoring, debugging, exploratory prototyping, ideation. That's most of the rest of the working day or "86%".
The only point that still holds is that organizational policies and procedures that automate AI use and lower the barrier to entry are more efficient than leaving it up to each individual. Every other point they make is either stale or was never true to begin with.
physix 3 hours ago [-]
>a “good” workday, engineers spent 18 percent of their time “coding” (not including bug fixing, testing, etc.)
I must be a crap developer, because I probably spend twice as much time bugfixing and testing than "coding". (Both of which actually involve coding stuff, so I really don't like that distinction they make)
This is stuff AI can be really good at, so brushing that part under the table distorts the picture.
Having said that, I do agree with most of the myths they present.
LAC-Tech 3 hours ago [-]
All very sensible points which I think all senior programmers who have used AI would largely to agree with.
For those more junior - keep in mind that a lot of the maximalist rhetoric are from people either selling models, or the cottage industry of people selling you courses or tools to help you use the models. Try and keep in mind software is not a mature industry, it's an immature one, and it's prone to hype and fads.
fenestella 33 minutes ago [-]
[flagged]
abratabia 3 hours ago [-]
[flagged]
outoftheweed 2 hours ago [-]
[flagged]
TrustChain 4 hours ago [-]
The 14% coding time figure is one of those stats that sounds surprising until you actually track your own time. When I started building a coding agent with persistent state, I realized how some days are spent with minimal actual typing, most of it is design, reading code, debugging, problem solving, and context-switching.
But I'd push back on one thing the article implies that AI is automatically a productivity win. It's not. Some days I've shipped two months of work in a few days with AI. Other days, like today, I've burned a whole day and gotten almost nothing done because the proper research was not done by me or multiple agents.
The bottleneck for AI can be the human understanding of how to optimally use the tool. While the bottleneck for the human can be not maximizing multiple agents, or the input the user enters, then the retention of the output. If the user's input is lost, the output falters. If the user doesn't understand what the AI output is, there is going to be a problem eventually.
The article touches on adoption barriers (Myth 7), but it doesn't really get into the ego piece. There's still a wave of experienced devs who either refuse to adopt AI, or use it quietly and don't share what they're doing. That slows the whole team's learning curve. At this point, I think it's pretty much understood that you should be using AI as a dev — not to replace your skills, but to accelerate them. That means still learning new languages, still writing code, still troubleshooting. The tools change, but the craft doesn't.
I think the article is right that the real leverage is organizational, not individual. The teams that succeed with AI aren't the ones giving everyone a license — they're the ones rethinking how they review, test, and maintain code.
What I'm still uncertain about is how to measure whether AI is actually making systems better, not just faster. Lines of code is clearly a bad metric, but I haven't seen a good alternative yet. What metrics are people actually using that feel meaningful?
imrozim 2 hours ago [-]
[dead]
1 hours ago [-]
01100011 2 hours ago [-]
I'm getting tired of these articles telling me what AI will or won't do to my career when every day I see something different first hand. I'm about to stop arguing with people. If you think it's all BS then fine. Good luck.
laichzeit0 1 hours ago [-]
I don’t trust point estimates like 14%. It’s like calculating an average salary and saying it’s $120k. Completely meaningless. What does the actual distribution look like that this was pulled from? No standard deviation. Is it even symmetric? What’s the 10th and 90th percentiles? Just giving a statistic on its own tells me nothing.
This is such a weird point to make that doesn't become correct just because everyone makes it, all the time. Why clean the ocean if some magic future tech will clean them? Why save the world now if some benevolent AI is 'just around the corner' and will do it for us? And people have been making this point for years now, and it's not like my job got any easier. I just got more AI.
https://www.poetryfoundation.org/poems/51294/waiting-for-the...
And I say that as someone who uses Claude Code in complex environments almost hourly; I, as the human, still have to do the thinking as Claude still 'can't jump' [1] and I have seen no evidence that they (or similar AI, any time soon) will 'jump' like a human brain does.
[1] https://www.tomzahavy.com/files/llms-cant-jump.pdf
I still have to do quite a bit of thinking but the amount of of thinking I do per task is trending down. I agree LLMs are not good at abduction but very few humans are either and very few jobs/tasks require it. I can't talk for researchers jobs though. But perhaps fewer researchers would be desired by these labs (not none).
Don't worry, I'm sure you'll hit your goal of zero thinking soon!
I, too, am glad that few humans seem good at abduction.
I say this as someone who's watched a bunch of woodworking videos but hasn't actually done this myself :)
Btw, I think the discussion of Einstein's career in the paper you link is historically wrong in many respects, particularly the argument about 'weak signal'. Einstein was in fact working on some of the most mainstream and widely discussed problems in physics of the day, he is admired for the creativity of his solutions to those problems, and much of his work built incrementally on ideas and breakthroughs that came (long) before (as all research does).
Article suggests that a central motivation of Einstein's work was resolving action-at-a-distance in Newtonian mechanics - yet Maxwell introduced the same Lagrangian field theories for electromagnetism we use today 50 years earlier to solve the same problem for Farraday's laws of electromagnetism. Similar wave equations existed even earlier. Heaviside in 1893 extended this technique to gravity (matching 'weak field' GR) 20 years earlier. So this is perhaps the one aspect of gravity that had actually already been solved before Einstein. Authors might be conflating his work on action-at-a-distance in QM.
Einstein's GR extended the linear 'weak field' understanding of gravity to include the non-linear self-referential case where masses themselves create gravity. This was mathematically incredibly difficult but was necessary precisely because SR's mass energy equivalence created so many strong signals that were unresolved. For example: if finite energy is mass, then mass changes as objects accelerate past a large mass like a start, and hence their propagation in space could not be explained by linear EM style field equations. Many such considerations were causing very 'strong signals' in SR, and there were analogous problems in QM atomic models being developed at the same time.
SR was also a solution to a problem that was actively being worked by many of the leading physicists of the day. SR actually does match Newtonian mechanics for a single observer - it resolves contradictions in the case of separate observers, by allowing them to assign different values to the speeds, masses, etc of objects such that each object appears to follow Newtonian mechanics for each observer. Again, this was necessary because of a lot of contradictions related to the behavior of light that had been well-known for ~20 years at the time.
Personally, I don't consider this kind of reasoning to be beyond the capabilities of future LLMs (even current LLMs if the task was broken into technical rather than philosophical problems). Personally, I doubt that such problems could stand open for 20+ years waiting for a creative genius to solve them in the modern world.
And don't get me started on the philosophy.
> > Mathematician Richard Hamming used to ask scientists in other fields "What are the most important problems in your field?" partly so he could troll them by asking "Why aren't you working on them?" and partly because getting asked this question is really useful for focusing people's attention on what matters.
> I imagine someone being asked this question, and how they should respond. I think like so - ‘Fuck off Richard’.
> This is partly because I imagine this question being asked in a kind of snarky, gotcha kind of way, with some sort of nerdy superiority. Like ‘ha your behaviour is inconsistent with your implied preferences, you idiot, do you even von Neumann–Morgenstern?’
Overall, I'd like to understand those who have a positive outlook on design and software engineering as a career. Where do you see the opportunity where I just see a bleak one where anyone can do this stuff by typing or talking to AI? Myself, after 17 years in the field I am begrudingly back in school for a new medical career. As well, anytime an IT recruiter reaches out I am getting responses back only after under-cutting the hourly rate I use to demand and what others probably are still trying to get. And with it feels even bleaker as it becomes a race to the bottom!
What kind of answers were they expecting to get?
Anyone else finding they're spending more time writing code (or at least driving agents to write code) now?
14% used to feel about right for me - I'd spend the rest of the time researching approaches and libraries, planning things out in issues, or sometimes just thinking really hard about problems I ran into.
Now... I still do those things, but I'm doing many of them faster - and I'm often doing them while my coding agents are churning away on code.
There's also this weird effect where the harder a problem is the more I can get done in parallel with it, because an agent might need to spend 20 minutes on it without my involvement.
> Anyone else finding they're spending more time writing code (or at least driving agents to write code) now?
Not really, as once it is time to write code, the problem has been defined/understood (to the degree possible with knowledge acquired at the time), and encoding it is largely an exercise in typing along with verifying assumptions via test suites.
Does GenAI quicken some portions of the above workflow? Sure, in the same way IDEs with contextual code snippet suggestions can make encoding faster.
- In biz development, a dev usually spends 30-40% time on coding, and more time on requirement discussion, integration testing (especially when the tests involves mobilephone or car)
- coding time can be reduced to 30%, which means reduce 20%-30% time of the full pipeline
- meanwhile, every phase and role is using LLM now, for example, product manager can produce longer requirement doc easily (we can use LLM to read it anyway:) Meeting sometimes is more than before, because more document output leads to more reading and discussion.
- I hope to find new ways to express biz requirements, in a more efficient and automatic manner.
- Shorten the requirement-dev-test-deploy loop is very important. OUTPUT is not OUTCOME. It is equal when we can see the final result, instead of intermediate metric.
- Agentic infra is extremely useful, or every one will find a way to access the database, report and ops system, in some weird fragile method.
So much has changed since late 2025 one can’t really draw any conclusions from this.
In fact, I’m guessing things will continue to move so fast that by the time one were to execute a survey of developers, many of the responses and findings are no longer relevant.
Reminds me of COVID and how everyone was fighting over early trends during that time.
https://metr.org/blog/2026-05-11-ai-usage-survey/
They also have an update -- linked from the original study! -- explaining that it's out of date and no longer reliable, and explaining why they had to cancel a follow-up study because it was understating productivity gains (but also was showing wins for the people who carried over from their previous study): https://metr.org/blog/2026-02-24-uplift-update/
The authors of this paper decided to ignore all of METR's follow-up data and discussion, and to report only the ancient number from early 2025 (a time when Windsurf was state of the art). And then, rather than apologizing for it, and caveating it as a number not to be taken seriously, they described it as a study done "recently."
That's either shockingly dishonest or incredibly out-of-touch.
A year ago feels like forever
They quote a study in which developers report to spend 11-14% of their day coding. The rest is stuff like solution design and meetings. The insinuation is that AI can at most automate 14% of your day.
The problem with this argument is that once you have code, some (not all) of the precursors to code go away.
Show me the evidence that AI has an impact on productivity when doing design work. Or reducing meeting load.
My own experience is that AI doesn't tighten the design cycle, and in fact might extend it by encouraging gold plating.
Well, I expect when you've vibed too much and lost track of the code, and can't answer questions in meetings anymore, you'll stop getting invited to them.
In the case of an LLM generated demo, usually deceptively so.
> and give an impression that the design decision has been made.
In the case of a vibed design, this is the opposite of useful for the team.
This isn't exactly novel territory, here, Simon. Let's not pretend I'm asking for something strange, unprecedented, or unreasonable.
I have similar charts across my three main open source projects:
https://github.com/simonw/datasette/graphs/code-frequency
https://github.com/simonw/llm/graphs/code-frequency
https://github.com/simonw/sqlite-utils/graphs/code-frequency
More code written is not a good measure of productivity. It could be garbage, or redundant code, or simply not addressing the real or more pressing needs, it could be building the wrong thing, etc.
Like TFA mentions, it's been known for decades LoC is a misleading metric for productivity. It's one of the lessons of software engineering.
That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code. That sync up with the QA engineer you did to hand it off to them? Don't need that meeting if you're not writing the code. That half hour you spent installing vim extensions? Don't need 'em if you don't open vim anymore.
There are engineers whose jobs go well beyond coding, of course. Staff engineers and principal engineers have had their jobs radically change because of AI, but not because it's writing all their code.
But there are also a lot of engineers -- your standard mid-level engineer, or even senior engineers at a lot of orgs with title inflation -- whose job is almost entirely about delivering code, and who spend all day either writing code or engaging in scaffolding around code-writing activities. Let's not pretend that automating away that code writing is a 15% boost.
How are you going to prompt the LLM or validate its output if you don't understand the requirements?
PMs seem pretty easy to replace. In fact, given any single role to fixate on, it's probably replaceable
Talented, experienced devs leaving the field out of disgust would be pretty disruptive.
Crumbling, faulty technical infrastructure with unmanageable heaps of AI slop that no one understands would definitely disrupt businesses.
Skill atrophy, and an entire generation of "developers" that have never actually written code will be disruptive when something breaks and no one knows how to fix it (this isn't a hypothetical, I'm seeing this phenomenon in a lot of large enterprise groups).
The total elimination of novel solutions, new ideas and new approaches to development and the resulting industry wide stagnation won't be disruptive, but will certainly be a drag.
Replace "AI slop" with "legacy code", and you've got basically any large enterprise today.
The timescales are different though: it takes years if not decades to accumulate classic legacy cruft, while LLMs can spew up huge amounts of incomprehensible spaghetti in seconds.
So an 180 from the current coding-automation frenzy..
> Your PM can write the ticket, and your QA can test the output.
If your PM can write the ticket and your QA can test the output, why not cut out the middleman by having the PM write the coding agent prompt(s)?
And if your PM can write the coding agent prompt(s), why not cut out the QA group by having the PM write the verification prompt(s)?
And if your PM can write those prompts, why not cut out the PM and have your CSRs write the feature request/verification prompts?
And if your CSRs can write the feature request/verification prompts, why not cut them out and have the organization's customers write the feature request along with acceptance prompts?
And if customers can write those prompts, why would they pay you?
|Contract|Product|Design|Coding|Testing|Deploy|
Writing Code Isn't the Bottleneck, until writing code is the bottleneck, until it's not again.
That includes talking to vendors, meetings with every layer of stakeholder when just one person digs their heels, etc.
That is truly the final frontier for "AI", and one that it will likely never cross. That would be when even the execs and upper management feel threatened by "AI". But, since they also delegate so much, you often see someone at the bottom of the totem pole in those meetings. This is why nobody is getting replaced by "AI". We really need to move this discussion away from the scifi stupidity already. There is no singularity or godlike AGI about to take over the world.
I hate to use awful terms like "synergy" and "teamwork", but they do have a lot more substance and truth to them than any perceived threat from "AI".
I stopped reading after this. AI has massively impacted most aspects of my non-coding work including the mentioned planning, understanding legacy code bases, setting up environments, etc etc.
Either this article is written by people with skill issues or - given the platform - its a biased and protectionist take that will fall quickly under the march of reality.
Basically as a senior tech lead in a large company engineering org, I don't have the bandwidth to individually validate every assertion from engineers on other teams OR from every product manager that comes with a half-baked ask. In the past I would be limited by the influence I could get through human relationships to strong SMEs with good judgment, and those folks always thin out as a company grows and calcifies. The number of creative and innovative thinkers dwindles, and the number of people protecting their turf and doing the minimum not to get fired increases. As a result many good ideas can get blocked by random gatekeeprs with poor imagination, poor expertise or both. However with AI I can follow up on gut instincts and fact check a lot more things, and ask incisive questions that can cut through a lot of organizational bullshit.
That's where I think most of the AI gains are today. Of course once AI plateaus and normalizes I think it will be baked into the org structures of tomorrow. But for now it offers real competitive advantage to those with the expertise to ask the right questions.
This is a depressing stat. The real productivity gains come from leaving soul sucking big tech companies where nothing gets done with any sort of urgency.
Coding has never been expensive as it is nothing more than a reification of a solution to a problem as it is understood at that time.
It is the underlying understanding of the problem which has always been expensive and remains so.
Writing code is indeed the bottleneck for same resource constrained companies.
Rapid code development creates more opportunities for trial and error, providing companies with more information for decision making, that previously might have been addressed by meetings.
Of course, this might bring other problems, but it might not right to generally speaking that writing code is not a bottleneck.
The only point that still holds is that organizational policies and procedures that automate AI use and lower the barrier to entry are more efficient than leaving it up to each individual. Every other point they make is either stale or was never true to begin with.
I must be a crap developer, because I probably spend twice as much time bugfixing and testing than "coding". (Both of which actually involve coding stuff, so I really don't like that distinction they make)
This is stuff AI can be really good at, so brushing that part under the table distorts the picture.
Having said that, I do agree with most of the myths they present.
For those more junior - keep in mind that a lot of the maximalist rhetoric are from people either selling models, or the cottage industry of people selling you courses or tools to help you use the models. Try and keep in mind software is not a mature industry, it's an immature one, and it's prone to hype and fads.
But I'd push back on one thing the article implies that AI is automatically a productivity win. It's not. Some days I've shipped two months of work in a few days with AI. Other days, like today, I've burned a whole day and gotten almost nothing done because the proper research was not done by me or multiple agents.
The bottleneck for AI can be the human understanding of how to optimally use the tool. While the bottleneck for the human can be not maximizing multiple agents, or the input the user enters, then the retention of the output. If the user's input is lost, the output falters. If the user doesn't understand what the AI output is, there is going to be a problem eventually.
The article touches on adoption barriers (Myth 7), but it doesn't really get into the ego piece. There's still a wave of experienced devs who either refuse to adopt AI, or use it quietly and don't share what they're doing. That slows the whole team's learning curve. At this point, I think it's pretty much understood that you should be using AI as a dev — not to replace your skills, but to accelerate them. That means still learning new languages, still writing code, still troubleshooting. The tools change, but the craft doesn't.
I think the article is right that the real leverage is organizational, not individual. The teams that succeed with AI aren't the ones giving everyone a license — they're the ones rethinking how they review, test, and maintain code.
What I'm still uncertain about is how to measure whether AI is actually making systems better, not just faster. Lines of code is clearly a bad metric, but I haven't seen a good alternative yet. What metrics are people actually using that feel meaningful?