Comment by kylecazar

3 months 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.

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.

  • > 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.

    • 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)

      1 reply →

  • 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.

  • 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.

    • > 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.

      1 reply →

  • Anecdotally 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

  • 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

    • 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

      1 reply →

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.)

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.

  • > 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?

  •    You don't need that meeting if you're not writing the code.
    

    I am responsible for a software that carries a multi billions company.

    My mates are not, their code editor are not either : I am.

    Yes, I could be a clown and be accountable for something I know nothing about. I choose not to.

    Not everybody is a cruft-engineer .

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.

  • I pity the poor souls who need to read that.

    • Nobody 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!

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.