4 ms·
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
by kylecazar 2mo 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 2mo agoOkay. 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.
- simonw 2mo agoWhat kind of shape of evidence would you find convincing?
- bluefirebrand 2mo agoPeople working fewer hours :)
- unknownfuture 2mo agoSelf-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.
- simonw 2mo agoHow's this? https://simonwillison.net/2026/Jul/13/datasette-code-frequency/ https://simonwillison.net/2026/Jul/13/datasette-code-frequen... I have similar charts across my three main open source projects: https://github.com/simonw/datasette/graphs/code-frequency https://github.com/simonw/datasette/graphs/code-frequency https://github.com/simonw/llm/graphs/code-frequency https://github.com/simonw/llm/graphs/code-frequency https://github.com/simonw/sqlite-utils/graphs/code-frequency https://github.com/simonw/sqlite-utils/graphs/code-frequency
- qsera 2mo agoI don't think volume of code changed was the metric the other commenter was asking for.
- deleted 2mo ago[deleted]
- the_af 2mo agoIsn'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.
- simonw 2mo agoI'm planning an article at the moment in defense of lines of code. Saying "lines of code are a bad measurement" is too easy! It's about time someone presented an opposing argument. In my specific case, lines of code for my published open source projects is a metric that I trust, because I have high standards for those. I have plenty of other projects where I'll accept poor quality, unreviewed code (almost all of https://github.com/simonw/tools https://github.com/simonw/tools for example), but Datasette, sqlite-utils and LLM are not that. Of course, that's only useful for me personally and for people who trust me to stick to my own self-declared high standards!
- cuttothechase 2mo ago[flagged]
- mountainriver 2mo agoIt does because you can now just steamroll features out the door and make everyone look bad that’s sitting around in meetings all day
- dgellow 2mo agoAre you aware literally everyone else also has access to AI stuff? You’re not special for using an agent. You’re part of the crowd
- mountainriver 2mo agoDepends on where you work... where I happen to work people sit in Jira meetings all day and in the time they talk about it my team implements it. So yes "literally everyone has access to it" (what a revelation) but you still need to be smart in how you use it
- sandeepkd 2mo agoFrom 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 2mo 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.
- sandeepkd 2mo agoThe concept of MVP has been there for a while, it felt deceptive too and incurred lot of tech debt. However one would feel the deception only if they understand the missing details. For a lot of roles making decisions it benefits them to ignore the details unless it really bites them
- Izkata 2mo 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 2mo agoHow 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)
- otabdeveloper4 2mo ago> It is mostly about requirements and goals and architecture/design People vibe code because they have no clue about any of that. Not because they're slow typers.
- therealdrag0 2mo agoIt certainly helps as a research assistant for design work. But it can’t do it for you.
- 01100011 2mo agoIt 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 2mo agoAI is helpful in such projects. Less so in other projects where design is heavy
- lilbigdoot 2mo agoAnecdotally I find them helpful for design and I don't find them nearly as helpful for coding (strange, given others experiences reported online) I am working on a compiler for an OCaml inspired language (I am on a sabbatical) and used them a lot in the early phases to check my ideas and search for prior work. I use them less now (mostly debugging at this point), but have made use of LLMs to write some pieces like source map generation, a couple of small and well known algorithms that were new to me, and an analyzer to dump a schema from a typescript module. Other times I've tried to use it for other things, I have ended up regretting it because of subtle bugs I don't think it made the design phase any shorter but it definitely helped save me energy in researching and made that period feel less like a fever dream. Design phases can be draining for me so that was welcome
- SpicyLemonZest 2mo agoIf 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.)
- mkozlows 2mo agoYeah, 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 2mo 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?
- mkozlows 2mo agoYour PM can write the ticket, and your QA can test the output.
- qsera 2mo agoI 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 2mo 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?
- deadbabe 2mo agoI 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 2mo agoNot lazy it is a taxing task like doing an exam.
- 01100011 2mo agoAlso 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.
- anon-torment 2mo agoI pity the poor souls who need to read that.
- sensanaty 2mo agoNobody reads it, silly. At most they'll just run it through their own AI and copy-paste the output if a response is needed. It's like all those AI meeting tools. Full transcripts of entire meetings and no human ever takes a 2nd look at them for literally any reason, ever. My favorite is the meeting summaries that nobody reads, and then 2 weeks later a miracle happens and it does get read, only for the AI to summarize nothing useful, or what happens even more often, for the summary to just be blatantly wrong and it implies the opposite of what was said during the meeting!