I spent 30min with Opus 5 generating some CSS and components for my Phoenix LiveView template project (which I use for starting new projects). Then I spent around 5 hours parsing and cleaning up the output. I could of course not have done that, but since it's my spare time project I can care about the code and quality.

I did get wins for sure (and I did save time), and I'm sure most people wouldn't even spend five minutes cleaning up, but this is definitely one place where people talk about different things regarding whatever x speedup they get.

I've found a variant of the Gell-Mann Amnesia effect with regards to LLM coding. They're really magical if you're not familiar with the language, domain, or frameworks you are trying to use. But if you're familiar with those things then you'll often catch them lying to your face and producing a lot of plausible nonsense.

... the official return of pair programming! The best part: LLM's save you from having to argue with a human. Added bonus: now you get to master two tools instead of one.

>As such, I use LLMs mainly to produce a rough draft of the code which I then iterate on heavily, at least until I like the general structure

Tell me you just started with agentic programming without telling me you just started using agentic programming.

Look, don't get me wrong: new folks learning tech should absolutely write articles about it! But their claims might very well change once they learn more .. and I strongly suspect that will be the case here.

This is a dated take to me. I think the next stage in unlocking productivity is so called "loop engineering"; figuring out how to effectively not read all the code while ensuring quality. To me that means implementing statistical quality control and formal methods.

Before I get there I have to figure out how to reliably audit plan adherence. The problem is that when the specs are in natural language, as they are, you need a fallible LLM to verify it.

Personally i'm only using local LLMs that i can run on my 7 year old PC (that also has a GPU with 24GB VRAM because reasons :-P) so i'm not sure how much that experience matches what others are doing (though roughly speaking what i see people complain about Claude doing doesn't feel that different from what i see the local stuff doing, so i guess the drawbacks aren't scaled down as model sizes increase).

I'm not sure about 1x, 2x or 10x increase as these metrics are about code written but that isn't a productivity metric (something pretty much every half-decent programmer would agree with before LLMs - remember stories about Bill Gates saying that more LoCs being good for software is like more weight is good for airplanes or Bill Atkinson's story about adding -2000 LoCs to improve QuickDraw?).

But they can certainly help "get you going" faster in that if you're stuck on something (for whatever reason - including "that feels too much drudgery") or have issues starting something, you can have an LLM take a stab at it and it'll produce "something". Sometimes it is enough by itself, but more often than not it'll need tweaks (either directly or having the LLM do it). I got to make a bunch of things i couldn't convince myself to do - e.g. an image viewer that doesn't suck (based on my arbitrary judgement), a game database, a script to convert a git repository into static html pages that kinda look like GitHub, etc.

They can also help find (and sometimes fix) bugs or other "code smell" issues. They're not that great for exact results (without tool calling -and knowledge on how to use them effectively- at least) but when it comes to fuzzy / vague stuff like "check out this code <code dump here> can you spot any issues?" they always tend to find some stuff (even if it is hallucinations :-P but sometimes they find actual issues too or whatever hallucination they come up with reveals some actual issues with the code that you didn't spot by yourself). I've been dabbling with Rust recently and asked Qwen 3.6 35B-A3B to judge my code and it wrote "6.5/10, will compile but looks like C in Rust" :-P.

The article says:

> Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.

And sure, LLMs aren't that great about those (i do let them leave whatever comments they want though and remove them later myself - i think those comments help during the generation/prediction - basically how they "think", kinda like the reasoning phase), but they can be very good at things like "here is the code, here is the documentation for it, spot discrepancies" (i had Devstral Small 2 do this and it hallucinated a few discrepancies but also found real stuff i missed in the docs).

I've tried to use Devstral Small 2 for some API docs but found it'd sometimes make assumptions about what function do or how. One approach that might work, but i haven't tried yet, is to write the "guide" myself, then have the LLM write the function docs using both the guide and the code as reference. The reason i think this will work is because it got things 95% correct just having access to the function code alone (and without the rest of the codebase), so the "guide" would help it reach 99%. I do not expect it to get to 100% so a manual edit pass will need to be done anyway (and i have an idea for a tool to assist in the manual edit pass for that - a tool that i'll probably get an LLM to write - BTW good luck coming up if all that stuff would increase or decrease productivity for an actual product and not some random stuff i'm toying with :-P).

One other thing i've also found LLMs useful recently is to have them use the stuff you make and see how they try to use it. I have an old project, a GUI toolkit i've been hacking on every now and then since 2011 or so, though it was never a priority. Yesterday i decided to dump all the header files to Qwen 35B-A3B (i use 4bit quantization that gives me a 256k context - it isn't particularly smart but it is neat to not have to micromanage context size like i have to do with Devstral Small 2 or Qwen 27B where both of them aren't very usable speedwise at anything above 32k context sizes).

Then i asked it to just make a few small programs and it did[0] (the shot shows a paint app, a calendar, a todo list and a unit converter). Pretty much every program found bugs in the library :-P and gave me ideas on how to improve things.

In general i get the impression that LLMs aren't great at architecting things but if you do the architecture yourself and write them a framework to use, they should do a fine job at it.

[0] http://runtimeterror.com/pages/iv/images/d50c436990db203a07f...

My observation is that AI tools generally make people /less/ productive. They are more productive in that they produce more stuff, but they are less productive in that the stuff they are producing has lower inherent value delivery. The primary place where I see this in software teams as a Product person is in document creation. If you are using an AI tool to produce internal documents, this is likely a net-negative value activity that actually reduces the overall productivity of the team. Why? Because writing is thinking. By handing off document creation to an LLM for a document that's supposed to communicate important details between teams (e.g. technical design docs, requirements docs, strategy docs) you are actually handing off thinking, or rather handing off not-thinking as AI tools cannot "think". The outcome of is poorly "thought out" slop that generates more work for everyone involved to resolve /or/ everyone simply ignores the document and the previous processes stop being useful.

If anything, I'd say AI tools in /most/ enterprises as people are trying to use them now are at least a -30% of productivity. If used correctly for taking a human-written/thought requirements doc, converting it into an interactive prototype that can be critiqued and ultimately included as part of the solution alignment within the requirements doc, and then is handed to an engineering team that is effective at using humans and AI to produce code, then it's probably a benefit. But most businesses lack the internal rigor, quality culture, and data governance to support properly applying AI tools in a high context manner internal to their business.

More than 2x for me. The models are accelerators, but the biggest gains came from building workflows around them. I spend most of my time documenting what I want, while implementation and much of the surrounding work become relatively cheap. I've found that AI amplifies engineering experience more than it replaces it. The better you are at framing problems and evaluating solutions, the more productive it becomes.

[dead]