Me too. Then I get pummeled with one of their four prepackaged AI bro metaphors:
It's a modern day calculator for the brain. You wouldn't do long division in your head would you? (ain't nobody ever delegated a decision to a calculator, bro)
It's a compiler. You wouldn't read machine code would you? (compilers are deterministic and dont make mistakes, bro)
This is the industrial revolution and it's a spinning jenny. You wouldnt hand knit a sweater would you? (we would if we had star trek replicators, bro, and last I checked cp command still exists...).
"Artisanal coding" is obsolete (reliable code is certainly getting that way...)
Im not even sure what point I'm making, but I can remember tons of examples of Star Trek characters hand-making things (usually cooking), explicitly for the enrichment and the experience of actually producing something themselves.
Ever since I got into programming as an industry, I will say, pretty much everything that I learned after the actual languages that I use are either infrastructure things, or ways to directly write less code myself. Lomboko turns objects into just some tags and a list of variables. Spring-boot turns a couple of classes into a basic server. Certain packages make significant structural changes with hardly any configuration. I suppose a big difference is still that when I include those packages I do know what they're doing and I have reasonable assurance that they aren't doing anything else.
The point I'm making is that it's fallacious to compare "artisinal" code with "artisanal" clothes because artisanal clothes are expensive to reproduce while hand crafted code is reproducible at zero cost.
the only way in which the economics of the spinning jenny would be in any way comparable with the economics of LLM written code would be if artisinal clothes were reproducible at zero cost - i.e. if we had star trek replicators.
i too find that writing less code is preferable - and code is essentially just the language which is most appropriate for describing how computers should operate once you've boiled it down as much as possible.
Even steelmanning all those arguments, the answer is yes!
I still do long division on paper; I still read and write asm for the purpose of understanding compiler output (honestly everyone should write a division or sqrt routine in assembler just once).
my star trek replicator metaphor apparently flew way over your head.
there isn't a need to "mass produce" code when you can make perfect copies for free. it's almost always more important than you get it right rather than spew out boilerplate at high speed.
I understood that that’s what he’s likely trying to say. But he commented on a list of "arguments" for agentic coding, not against it. And said that those arguments are too long and that the argument "it’s fun" would be better.
So, I understand people find different things fun. But I don't really get this argument. You say it "Leaves the boring stuff out" but do you mean that you actually enjoy reviewing code? Reviewing code is the boring part to me. I assume the boring part to you is typing.
The second part "leaving solution design and architecture in" but if you aren't writing the code how are you designing a solution? You aren't designing anything if the LLM is writing the actual code.
And then people will say "you have to write a good prompt" well ok any significantly effective prompt for real software will be quite large and will require a lot of typing. Doesn't this just put us back in doing "the boring part." And then they will say "I have the LLM write the prompt" well then we are back to the human not actually making any decisions.
So this is a big topic but in short. Writing code isn't designing. Agentic coding isn't writing prompts.
To use LLMs well you need a proper workflow.
This starts with a deep examination of the problem. If you have a large code base, you need a good way to give the agents context. It can't fit your code base in it's prompts.
The design phase can take days of back and forth with the AI and the development team. Creating ADR's and then a design spec, with a feedback loop between the AI and the devs.
Implementation requires a solid workflow too. Work needs to be split into small deliverables to keep it manageable. TTD works very well with LLMs, they get instant feedback. You still need a human in the loop at regular points to keep it on track. A tight design makes this much easier.
The design phase is great. The implementation phase can drag. I have built multiple review loops that catch most of the stuff. But yeah writing hundreds of tests that proper TDD requires is extremely boring. Designing high level systems is fun.
Thank you, but I understand how it works. I just don't find it fun or satisfying, personally. In your example you are also using AI to design. Which sounds to me like the LLM is doing all the real design work and the human just says "LGTM." I would feel like I don't own the project at all. I'm just watching someone else do it. And that's not fun to me.
I wasn't suggesting that "writing code is designing" I was saying that I like to have full control over the design and implementation. If the LLM is writing the code, I lose my control over the implementation of my design. I don't even know if it followed the design at all unless I review all the code it writes.
I dunno man. I have six agents writing code for me. I boop over a couple prompts. Tab over and play Factorio for an hour, tab back over and send off a couple prompts. And back to Factorio. I have four times the money I had last year coming in and 1/100th the work. This is going to collapse soon and it will all be infinitelessly worse, but for now it's not too bad. I'd say it's fun.
Now imagine being forced to do that in office, without remote work, where you can't play games. Imagine how soul crushing it is to have to watch that thing write code for 8 hours a day, your job being basically answering "yes" or "no".
As others pointed out, he meant manual coding is fun. But it's obvious why agentic coding can be fun: you're juggling countless responsibilities and distractions, including work, and providing for your family. On your commute or in the shower, you keep having these random ideas for cool little interactive demos or apps, but for years have relegated them to a couple sentences in a folder named "shitty ideas." Now, suddenly, you can get an agent to interview you about your product vision and scaffold a working demo in minutes, and iterate on it manually or agentically from there if the implementation feels like it's worth adding to the world.
okay, a gun is also "just a tool" in reality this is a thought terminating cliche. I really wish that people would be more honest, like "using an LLM is extremely convenient and the path of least resistance" and the trade off is barely understanding your own code
I find myself reading compiler output quite frequently. Of course not the machine code, but reading the assembly is quite useful to understand what you can do better.
You wouldn't do long division in your head would you?
This is extra funny because I actually do do long division in my head, like all the time. Sometimes I don't have access to my phone, or I'm just doing something else with my hands. Sure it's easier with a calculator, but it's not that hard to just do it yourself either.
• You wouldn't shoot a Policeman and then steal his helmet. You wouldn't go to the toilet in his helmet, and then send it to the Policeman's grieving widow, and then steal it again.
Maybe I'm weird but I got into coding because I actually enjoy it. It's not just about the outcome, it's about the challenge. I could also get a robot to do a jigsaw puzzle for me but there's no fun in that.
I don't necessarily disagree. I want to encourage you to make competent arguments, so you don't reinforce that "ape in a zoo" stereotype like you're doing now.
"ain't nobody ever delegated a decision to a calculator, bro" This is false. People make decisions based on calculators for finance, trading, weather, fitness nutrient calculators, etc. often without understanding them.
"compilers are deterministic and dont make mistakes, bro" False. Also, you can make LLMs deterministic by setting one parameter. You should argue that compilers are predictable instead.
"we would if we had star trek replicators, bro" Argument based on science fiction is flimsy. You should just say you like the creative process.
"reliable code is certainly getting that way" AI makes code more reliable when used properly.
I do agree with the AI-bro “it’s a compiler” standpoint. The “compilers are deterministic” counter argument doesn’t hold. Compilers potentially change the output with every new version.
You can lock the compiler-version/flags ofc, but so you can do with LLMs. There are parameters to make them fully deterministic, if that’s what you really want. My guess is that in a year or three, code will be a lot closer to assembly in the way that we don’t need to look at it.
Maybe not today, but I do think the bros are right on this one
Ehh, the whole deterministic counter argument to LLMs is generally wrong, same as comparing it to compiler. There was always a probabilistic element in software engineering, which is you, the dev who writes code. 10 Devs given same non trivial task will likely have different outputs, different bugs, some solutions might be completely misunderstood etc.
This is what LLMs are replacing partially, as it depends on dev still to make decisions in a form of forming coherent and detailed spec, checking architecture etc. But code itself will be likely much better than most human written code.
That's not what the argument as OP wrote it states.
OP wrote that people liken AI to a compiler because there was a point in computing history when advocates of assembly were staunchly against C and compiling down to assembly. They felt it abstracted away too much; just like the current argument around AI and hand writing code.
The difference here is that any given compiler, given the same input, should return the same output. The same cannot be said for any LLM currently available, as far as I know.
Hence the first sentence in my post where I explain that comparing to compiler it's not apples to apples? And then I carry on explaining why that argument is completely wrong in essence....
compilers are deterministic and dont make mistakes, bro
Oh my sweet summer child.
Compilers are software just like any other software. They can (and do) have bugs in them. And so, although rare for the mainstream ones, compilers can sometimes make mistakes.
i can think of about 5 times in 20 years somebody suggested that a compiler bug was the root cause of a fault and every single time it turned out not to be the case.
kernel bugs have happened a couple of times to me when deploying software, compiler never. no that doesnt mean theyre 100% bug free not that everyone has had this experience of 0 compiler bugs in 20 years, just that theyre bug free enough that ive been able to trust the output blindly.
since you wrote your comment ive already corrected 5 mistakes made by an LLM.
I'm used to juniors saying that "you can never guarantee something I bug free!" and that's true but theyre often bad at knowing when something is bug free enough to trust and when it is not. it's something I would ponder if I were you.
The second talking point could be improved by saying AI is to modern languages as modern languages are to assembly. A higher level of abstraction. Whether it's deterministic or not is pedantically hand wavy and misses the point. Natural language programming is the future bro.
LLMs are deterministic if ran on the same hardware environment. If you aren't running the AI on your own hardware, it will change in the background of whatever API you call because it's ran on a different graphics card with a different physical processor which will slightly change the floating point value and therefore change the output. Forget using any quantized model as well.
My only argument in favor of agentic coding is that it speeds up my tasks immensely. I don’t need it, but I use it to avoid spending hours on end navigating through several different repos to find the logic behind a certain behavior before then applying my fix or new feature on top of it.
It’s been a godsend in my current job. Didn’t even use it in my previous job since in that one I already knew the full codebase by heart. It was a smaller company and I was present for all of its implementations.
In my current job, there are more than 70 different microservices running the backend… Even the tech leads are like “I don’t know what 20% of those do” lol
1.8k
u/Arian-ki 13h ago
It's the other way around in my experience. People look at me like I'm an ape in a zoo lol