| ▲ | kylecazar 6 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 6 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | Izkata 5 hours ago | parent | next [-] | | > 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 2 hours ago | parent [-] | | 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) | | |
| ▲ | otabdeveloper4 an hour ago | parent [-] | | > 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. |
|
| |
| ▲ | 01100011 4 hours ago | parent | prev | next [-] | | 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. | | | |
| ▲ | sandeepkd 5 hours ago | parent | prev | next [-] | | 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 3 hours ago | parent [-] | | > 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 2 hours ago | parent [-] | | The 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 |
|
| |
| ▲ | simonw 6 hours ago | parent | prev | next [-] | | What kind of shape of evidence would you find convincing? | | |
| ▲ | unknownfuture 6 hours ago | parent | next [-] | | 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. | | |
| ▲ | simonw 5 hours ago | parent [-] | | How's this? 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/llm/graphs/code-frequency https://github.com/simonw/sqlite-utils/graphs/code-frequency | | |
| ▲ | unknownfuture 2 hours ago | parent | next [-] | | The article mentions that coding is only a fraction of dev time and thus accelerating that part of the job can only create incremental gains, and oh PS, lines of code and similar metrics are a bad way if measuring dev productivity, anyway, and we've known that for decades. The OP claims AI accelerates non-coding parts of the job, too, and so the article is misguided. I ask for evidence. In response you give me... code output metrics? | | |
| ▲ | simonw an hour ago | parent [-] | | I don't have anything else to hand that I can think of. I don't keep a time tracking diary. |
| |
| ▲ | qsera 4 hours ago | parent | prev | next [-] | | I don't think volume of code changed was the metric the other commenter was asking for. | | | |
| ▲ | the_af 4 hours ago | parent | prev [-] | | 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. | | |
| ▲ | simonw 2 hours ago | parent [-] | | I'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 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! | | |
| ▲ | otabdeveloper4 an hour ago | parent | next [-] | | > Lines of code are akshually a good metric now, because that's the only metric LLMs can optimize and I really, really, really love LLMs, they're the bee's knees. Really now? | | | |
| ▲ | skydhash 37 minutes ago | parent | prev [-] | | > Saying "lines of code are a bad measurement" is too easy! It's about time someone presented an opposing argument. Maybe because there is none. One of the main quality of good codebase is simplicity. Which is about how easy for someone else to understand the code. It’s hard to define what simplicity looks like, so the best bet is to avoid the other side, making the code too complex. And you can make the code complex by shortening variable name, doing code golfing with quicks of the platforms, so smaller LoC. You can also go the other way and increase the LoC by adding unneeded abstractions, repeating slices of code,… There’s a window where the LoC is perfect to attain simplicity, but that amount is an effect of striving for simplicity, not a cause of it. And it’s variable for every problem. So you got something where the correct value is a different for each case. And trying to manipulate it artificially often results in complex code. And you want to say that is a good metric for productivity? And in the cases of your projects, there are a lot more info could share that are interesting, like the amount of issues (reported or found by you) that are tied to implementation bugs (coding, libraries API breakage,…) or design issues (requirements conflicts,…), documentation improvement,… Anything that is tied to the actual usefulness of the projects, and not fumbling around with code. |
|
|
|
| |
| ▲ | bluefirebrand 6 hours ago | parent | prev [-] | | People working fewer hours :) | | |
| |
| ▲ | therealdrag0 4 hours ago | parent | prev | next [-] | | It certainly helps as a research assistant for design work. But it can’t do it for you. | |
| ▲ | cuttothechase 6 hours ago | parent | prev | next [-] | | [flagged] | |
| ▲ | mountainriver 6 hours ago | parent | prev [-] | | 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 | | |
| ▲ | dgellow 24 minutes ago | parent [-] | | Are 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 |
|
|
|
| ▲ | mkozlows 6 hours ago | parent | prev | next [-] |
| 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 6 hours ago | parent [-] | | > 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 5 hours ago | parent | next [-] | | 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 3 hours ago | parent | next [-] | | 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 | |
| ▲ | 4 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | claytongulick 4 hours ago | parent | prev [-] | | 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. | | |
| ▲ | decimalenough 3 hours ago | parent | next [-] | | > 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. | |
| ▲ | griffiths 2 hours ago | parent | prev [-] | | 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. |
|
| |
| ▲ | mkozlows 5 hours ago | parent | prev [-] | | Your PM can write the ticket, and your QA can test the output. | | |
| ▲ | qsera 4 hours ago | parent | next [-] | | 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 3 hours ago | parent | prev [-] | | >> 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 4 hours ago | parent | prev | next [-] |
| 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 6 hours ago | parent | prev | next [-] |
| 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 5 hours ago | parent | prev [-] |
| 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. |
| |
