Rendered at 10:05:24 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
mrweasel 2 days ago [-]
Apparently it's not obvious to everyone, but if you can't write code, you can't review it. I do know people, and companies, that says: "So what, we ask Claude to write the code, Codex will then do the review". The thing that then strikes me as odd is that they still ask for the code in Python, Java, or some other high level language.... Why? Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much. They still want to be able to read the code. So they need developers that can read, debug and reason about the code, yet they don't want to give them the training that's required to do this?
ryandvm 2 days ago [-]
They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.
I'm as hateful of LLMs hollowing out the job market as the next guy, but the reality is the frontier LLMs are really good at writing anything that's been done and documented on the Internet a million times and unfortunately most of what software devs have been doing the last couple decades is shitting out cookie cutter CRUD apps.
I have my doubts about whether the state of the industry is going to advance as long as we're having LLMs do all the creation, but that's another diatribe.
WebAssembly is slightly easier than real assembly, but here Fable used WASM GC extensions, which are poorly documented and not yet super common.
Fable didn't even need to debug it; I believe essentially all the assembly worked correctly on the first try.
I have feelings about this, but I'm not pretending it isn't real.
furyofantares 1 days ago [-]
I have a personal game framework that I have LLMs write games in, which is in AssemblyScript. AssemblyScript is certainly closer to TypeScript than it is to WebAssembly, but it's still this thing where the host shares some big chunk of memory with the script and you pick some memory locations to read and write as your means of exposing APIs, and there's not a lot of training data on games written in AssemblyScript and even less in my game framework specifically (none) - and the LLM does an excellent job.
newaccountman2 20 hours ago [-]
This is for games that run purely in the browser?
furyofantares 20 hours ago [-]
No, I typically want to target either mobile or PC first - but I strongly want stuff to run well in the browser too, for early playtesting and for demos at the very least.
weinzierl 1 days ago [-]
WebAssembly has as much to do with assembly as JavaScript has with Java. I highly doubt the "slightly easier" and my attempts with LLM's and assembly so far were largely disappointing, but I also think there is no compelling reason this has to be the case.
ekidd 19 hours ago [-]
I have written assembly for about 5 different processors, including 65C02s, 680x0s, cute little DSP3210s that managed the CPU cache manually, utterly cursed TI320C40s, and (of course) a bit of Intel. WebAssembly is simpler than some of these architectures in some ways.
But it's not that much simpler. And once you add the WASM GC stuff, WebAssembly gets weird. It's a Harvard architecture with separate value memory, linear memory, GC memory and "tables", all accessible in completely different ways, with a weird mandatory type system (especially for the GC stuff). And the docs are often terrible. And yes, I've also written WebAssembly by hand.
So yes, I would, overall, classify WebAssembly as "slightly easier". But not dramatically so. And the training data for actually writing non-trivial things by hand isn't that great, not compared to something like Intel assembly.
(Don't talk to me about TI320C40 assembly. If Fable can one-shot a Prolog interpreter written using that without finding a reference manual, it's time to hang up my hat and learn to make goat cheese.)
jimbokun 1 days ago [-]
Just interesting to see Claude’s hourly rate is around $17.
Much cheaper than a human software engineer. But comparable to the wages for some human workers.
mgoetzke 2 hours ago [-]
I would assume a human would require multiple hours for the same output though
wartywhoa23 1 days ago [-]
As soon as human software engineers are Ubered away from the field, the price will ramp up to that of a human software engineer or more, have no doubt.
ROI won't make itself up.
voakbasda 21 hours ago [-]
It is hard to believe that no one sees this coming. I can’t imagine it will happen any other way.
mycall 12 hours ago [-]
Let's hope open models will continue to improve and avoid the price ramping.
jimbokun 17 hours ago [-]
Then everyone just starts running open weight models locally.
wartywhoa23 16 hours ago [-]
Running it on RAM and GPUs which cost like a private jet plane, or have to be smuggled in like cocaine due to import/export tariffs or bans.
coderatlarge 21 hours ago [-]
claude helped me build a functional visual modem (using the cameras and microphones/speakers) for mac/iPhone in about a day and <100 prompts. i’ve worked on mobile apps once 10 years ago and have never built one from scratch. i've built a handful of UIs in 20 years on different platforms. my actual work was mostly in systems software. so it would have probably taken me weeks to months to build this from scratch. it would have cost substantial money to outsource this and iterate on ui and core algo as i did.
i've been curious about the feasibility of this concept for quite some time and now i have an actual example to study and measure and hack on, for a fraction of the cost of my pro sub. it wasn’t trivial, i doubt a non-swe could get it done in that time, but i'm a pretty happy customer overall.
danshipt 1 days ago [-]
That’s around 28K EUR/year. I know some junior-mid engineers that earn that (and they are good) in southern Europe.
jacomoRodriguez 1 days ago [-]
But now human will produce the same amount of work in an hour - not even close...
marcus_holmes 1 days ago [-]
And ofc the Chinese workers are a lot cheaper.
dude250711 2 days ago [-]
The guys with unlimited Fable/Mythos access are for some reason incapable of producing a flawless Claude Code app built entirely in native assemblies.
cpursley 1 days ago [-]
You’re getting down voted, but it would really be nice if they rebuilt the thing in Rust or something like that. I’m just tired of these enormous JavaScript bundles pretending to be desktop apps. Especially when we need to squeeze as much juice as possible out of our machines.
bflesch 1 days ago [-]
They're so busy winning that they don't care about improving their own web apps ;)
byzantinegene 1 days ago [-]
they use React to render their TUI :)
quantumHazer 1 days ago [-]
> Fable didn't even need to debug it; I believe essentially all the assembly worked correctly on the first try.
so you don't know if it works properly or not
ekidd 19 hours ago [-]
Fable wrote a pretty decent test suite covering typical Prolog programs, including things with non-trivial execution patterns like "append" that do complex backtracking on multiple branches. And I've run a modest number of test queries by hand, trying a few things. It's entirely possible that there's a bug there somewhere. But it's better than I would have done on the first try, implementing a Prolog interpreter in assembly. And I've worked on actual production compilers a few times.
I am honestly not happy about the way that models can now just take what should have be a fun multi-weekend project and knock out in a couple of hours. But I'm not going to pretend that Fable is stupid, or that it did a bad job on any of the test projects I gave it. It struggles more on big, messy real-world code bases, absolutely.
soco 24 hours ago [-]
It's also conveniently forgetting that AI was trained on the whole internet, a corpus of code including every garbage solution in SO wrong answers or random junior blogs. I didn't see any claim AI could select "best practices" from their sources, so putting AI to correct another AI has high chances of statistically selecting the same wrong solution, because that was just a common thread in those old posts they used as reference.
mattmanser 23 hours ago [-]
I think you're pretty wrong here, but I'm no expert so anyone who wants to correct me please do so.
As I understand it, there's post-training step that does exactly that, they get real developers to select good and bad code and help the AI figure that out. AFAIK it's the reason why Claude was able to leap-frog OpenAI in coding last year, they did this refinement step a lot better.
And now they've taught the older models this, they can use existing models to bootstrap the newer models without humans involved, and bring humans in to just assess the trickier stuff.
soco 21 hours ago [-]
Claude's coding efficiency is largely due to their control plane governing the actual execution of the model - rules, evaluators and basically looping over results. Not related to the model training or fine tuning.
mattmanser 18 hours ago [-]
The models were already much better before Claude Code came out, let's not rewrite history here.
dilyevsky 1 days ago [-]
Which effort setting did you run this with?
avador 1 days ago [-]
There’s a very real dichotomy at play here. Position 0: humans depend upon AI. Position 1: AIs depend upon humans.
At first blush, it seems achingly obvious that position 1 is true, whilst position 0 is a false play by con artists.
Well, at first blush I agree! But first blushes are notorious for being famous last words (blushes).
You see, we always knew that the tool shapes the hand. That is, as we use computational (discrete) devices, we ourselves become more computational, discrete.
But what we did not anticipate is that the tool would fool others as the ACTUAL HAND. I am so fooled. Daily.
My friends. Does technique encompass being? Answer me this!
viccis 1 days ago [-]
Yeah I had it remake my favorite TI-89 graphing calculator game in Python and it one shotted it perfectly.
dehrmann 2 days ago [-]
> They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.
I suspect that despite its translation abilities, this is true, but I'd like to see it do things in languages that are more or less appropriate for tasks to see how much the training corpus matters vs. its ability to translate. Assembly is a bit of an extreme example because you're either writing it as close to C as possible (C is essentially portable assembly) or you're writing complex, unreviewable code that happens to work. And who know if it's been trained on register allocation, or resorts to doing everything on the stack because it works.
LtWorf 1 days ago [-]
> C is essentially portable assembly
Not really, assembly shows you what the machine instructions actually are. In C you have loops, functions structs. All things that make no sense in assembly.
hresvelgr 1 days ago [-]
Both points are specious. C disassembly is usually not an orthogonal translation of the structures in the code, usually due to optimisation.
> In C you have loops, functions structs. All things that make no sense in assembly.
One can reasonably infer that a loop will roughly translate to some type of conditional jump instruction. Function structs are just pointers and call instructions. The former point was that there is little runtime getting in the way of how the constructs could be expressed, and a long time ago it may have been the truth, but not for modern compilers.
gnabgib 1 days ago [-]
Loops (conditional JMPS - JE/JNE/JZ/JNZ/JB/JNB.. and a dozen others) and functions (CALL, RET) exist in assembly. Goto is there too (all JMPs). C makes assembly sense.
fragmede 1 days ago [-]
Oh that's an interesting thought. Goto's are considered harmful, because holy hell as a human trying to understand and reason about code, the spaghettifcation if someone else used gotos all over the place and I have to reconstruct their thought process just doesn't sound like fun. But if we're no longer writing code by hand (which, I gotta be honest, I'm using AI to write a lot of code for me these days), then does that still matter? If a human isn't going to have to understand the code, can we get more performance out of existing systems by considering goto's useful?
t43562 22 hours ago [-]
goto is already useful as an end-of-function cleanup. You pop one at the end of each function (the naming is local to the function) and that's the place where you free ram if the pointer's not null and close the file if the handle is not null and so on.
Then you don't have to litter all of your if/else clauses with hundreds of memory frees and cleanups - you just "goto"
The fact that this is controversial to some people just shows how rules like "Dont use goto" become stupid - if one is trying to make code simpler then there are cases were not using it is the more confusing and error prone choice.
As for "can we now do anything" well if you don't ever need to debug "anything" then yes and if you have any small doubts about your LLM then no.
galaxyLogic 1 days ago [-]
I assume there's a clear technical reason why GOTO is harmful, it adds to the complexity of the code, makes it harder to understand and fix and evolve. Wouldn't the same difficulties affect the LLMs ability to understand and fix and evolve the code as well?
fragmede 10 hours ago [-]
As a human with a human level of working memory, the number of things I can keep in my head and map to concepts and functions is unfortunately limited. An AI running on an Nvidia supercomputer has higher limitations on what it can hold in its working memory, so could theoretically handle more than my human brain can.
LtWorf 4 hours ago [-]
But it won't because it's a language model no an artificial intelligence.
dehrmann 1 days ago [-]
Compilers only really use them for things like break and the end if blocks. There isn't much to gain by being able to execute anything arbitrarily, and then go...where? There might be places here and there within a function where compilers already take advantage of it, but I doubt it's useful in the way you think.
LtWorf 12 hours ago [-]
in C it's quite normal to set a return code and jump to a cleanup section where all the buffers are freed, all the files closed and so on.
1 days ago [-]
wqaatwt 21 hours ago [-]
LLMs are designed to imitate humans not compilers. Hardly anyone is capable of writing modern optimized Assembly code by hand outside of a few snippets here and there (not in a reasonable amount of time at least)
Salgat 1 days ago [-]
LLMs are perfectly capable of translating between programming languages at this point. The main bottleneck for them is logic, not language.
galaxyLogic 1 days ago [-]
And the amount of logic needed to understand code, including how to fix it or modify it further depends on how complicated the code-structure is.
I wonder about this: Does LLM write better code in a better language?
Humans often have more difficulty fixing existing code than reqriting it from scratch, and un-structured un-constrained code would be a big reason for that.
But maybe it doesn't apply to an LLM if it always rewrites all code from scratch?
t43562 22 hours ago [-]
> I wonder about this: Does LLM write better code in a better language?
The whole point is to rewrite everything in a language you don't understand and then ignore whether it's better because you can't tell.
That language, of course, must be Rust.
coderatlarge 21 hours ago [-]
couldn’t the frontier labs simply compile their existing source code training data and have an assembly corpus to train on?
cactusplant7374 2 days ago [-]
It's still possible to make CRUD apps in assembly with an AI agent but it would be a research project.
Zambyte 2 days ago [-]
By "research project" you you mean by people who understand assembly? Because then we're back to where we started.
cactusplant7374 20 hours ago [-]
I mean for the agent. They are good enough to conduct research now.
deadbabe 2 days ago [-]
What's there to advance to?
Without a revolutionary new platform to build apps on that no one has ever developed for before, there is basically no reason to believe there is any software left that has some business or economic value that hasn't already been written.
ryandvm 2 days ago [-]
This gives "let's close the patent office"
aleph_minus_one 1 days ago [-]
> This gives "let's close the patent office"
This is a really good idea for completely different reasons. :-)
asdff 1 days ago [-]
This is probably true in the consumer facing software space. But in business, industry, and academia, often there are novel data generated by some new or refined process. And this needs new software that correctly handles both the nature of these new data and meet the goals the data is collected to advance. This sort of software is also usually poorly represented in training sets, if represented at all.
devin 2 days ago [-]
If you think we're "done", you have no imagination.
deadbabe 2 days ago [-]
What are you gonna make? Yet another CRUD app? An API subscription? A game? A mobile app?
We’ve created software for virtually every place we can put software. There’s nothing new.
It’s like bridges. We’ve seen all the ways bridges can be built by now. There’s nothing new left to discover.
erikschoster 1 days ago [-]
> There’s nothing new left to discover.
It's the end of history. What could we possibly discover about a series of technologies that are already nearly 100 years old now?
I've heard people say that various things are "solved" now because of LLMs too -- programming included. This implies we've "solved" thinking. I'm worried about these sentiments.
When Gutenberg invented the printing press, he could not have predicted the teleprompter. Now that code is easy to generate, it’s plausible that we will use much, much more of it than before.
It’s also a bit ironic to imagine that we’re at the end of new software ideas on a site owned(?) by YC.
dsego 20 hours ago [-]
Are teleprompters a net positive achievement? They were needed for live television, they will be superseded I guess by AI generated news avatars. And 24-hour news coverage is in the business of generating content non-stop, to sell advertisements, regardless if there are newsworthy events or not, the machine never stops producing.
deadbabe 1 days ago [-]
it's also plausible that with an ability to generate as much code as we want with little effort, we will quickly discover how much code we actually need, and then plateau at that point.
Personally, I think we've already reached that point.
Even at YC, I have not really seen any startup doing anything interesting where their main value prop is enabled by new proprietary code that does stuff no one else can already do.
walt_grata 1 days ago [-]
We have more code than we need. Proof for me is every "smart" device that worked better before we put a computer in it.
deadbabe 1 days ago [-]
Exactly, this is the true problem with the world today: too much code.
galaxyLogic 1 days ago [-]
Mature tech evolves more slowly. Think about cars, there's nothing new about them any more. But wait, what about electic cars? Aren't they a new thing? And driverless cars. And soon flying taxis. Automobiles are an old invention but they are still evolving.
aleph_minus_one 1 days ago [-]
The reason the evolution of cars has slowed down so much is mostly regulatory compliance.
With the current ongoing revolution in home manufacturing (starting with 3D printing; currently there is a lot of work done in home CNC machining), it would be easily possible to get a huge leap towards "print your own car".
The reason why you see nothing of this is basically red tape.
kbelder 12 hours ago [-]
Well, a short time ago somebody made the first LLM. Was that the end of it?
whattheheckheck 2 days ago [-]
Why did we even need bridges in the first place
bryanrasmussen 1 days ago [-]
this implies that the only thing that can change what needs doing are technology platforms, which about 6000 years of human civilization would indicate is not the case.
nektro 2 days ago [-]
that you don't see this as inevitable worries me dearly
lp4v4n 2 days ago [-]
>They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.
I'm disputing this. You can have a training corpus in assembly as big as any other language: just feed the compiled result(in assembly) of the CRUD apps to the LLMs.
lelanthran 1 days ago [-]
> Apparently it's not obvious to everyone, but if you can't write code, you can't review it.
There's more to it than that: writing is thinking. If you stop writing code, you aren't thinking anymore.
Many argue that they're now thinking at a higher level (maybe they weren't before?), but, guess what, that high-level design can be done better by the LLM than by you anyway. It's only temporary.
mewpmewp2 20 hours ago [-]
I think writing is summarizing your thoughts outside of thinking. Thinking happens at least for me before I write.
I know what I want to do before I write, and writing is just one medium to get it out there. If there was a faster way, to get my thoughts there I would use that.
palmotea 19 hours ago [-]
> Thinking happens at least for me before I write. I know what I want to do before I write, and writing is just one medium to get it out there. If there was a faster way, to get my thoughts there I would use that.
A lot of people observe that their thoughts get better when they do the work to write them out. It's not just a straightforward encoding process (as maybe a software engineer would conceive of it).
mewpmewp2 18 hours ago [-]
Yes, it gets better, but not because of writing, it gets better because of building, playing it out and observing the results. The trial and error. It wouldn't matter whether I built via voice to command AI or wrote the code myself.
E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
lelanthran 2 hours ago [-]
> Yes, it gets better, but not because of writing, it gets better because of building, playing it out and observing the results. The trial and error. It wouldn't matter whether I built via voice to command AI or wrote the code myself.
This is a poor argument. The trial and error is the LLMs trial and error of your intention (ironically driven by you), not your trial and error.
It's like saying "It wouldn't matter if I instructed an LLM to solve my trigonometry problem or if I wrote the the solution myself; either way I'm learning trig".
> E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
What exactly are you needed for in this scenario, other than saying "make me $PRODUCT"? The LLm is going to be a lot better at architecture than you are. Your role is limited to A/B testing the result for human use.
balder1991 19 hours ago [-]
You’re not wrong, but there’s a nuance here. More often than not our thoughts fool us into thinking we have something clear when we have only a vague idea of what you want to do.
I kinda [wrote about this before](https://dielsonsales.github.io/2023/05/11/starting-a-new-blo...) but the takeaway is that writing forces you to structure your thoughts, giving them a final shape and enables you to notice flaws or gaps in your own thinking process. It’s impossible to do this without writing.
mewpmewp2 18 hours ago [-]
It would be good to have specific situations here I guess, otherwise it's quite abstract, and I'm not sure what to make of it.
As to your post, I think rather than writing it's the act of pressuring yourself to figure the thing out that is making you more knowledgeable about the thing.
You are putting it out publicly out there so you really want to be certain that you are correct, and therefore you do a lot of research.
If you wanted to be accurate and prove a point, the motivation mechanism could vary, but also the eventual communication mechanism could vary. It doesn't necessarily have to be in writing, it could be a live debate or simply something else you built. The writing or the product are end product, but the process of wanting to produce something is what made you research and to understand.
You could be writing to yourself into a Google Docs, and not care and you would not go deep to research since there's no incentive to be accurate.
E.g. I could be doing a home project whether hardware, software or DIY, that in order to produce this output I have to learn and think. Similar to as good set of words to communicate some idea. But also I could build some slop without thinking and I could produce slop writing without thinking, and about nothing special.
1 days ago [-]
enraged_camel 1 days ago [-]
>> There's more to it than that: writing is thinking. If you stop writing code, you aren't thinking anymore.
Humans have been thinking long before writing was invented. Why is code special?
lelanthran 1 days ago [-]
> Humans have been thinking long before writing was invented.
And look how poorly they did it until they invented writing.
> Why is code special?
You don't get better at thinking without doing. With code the "doing" part is writing.
In your view, it is reasonable to expect HS students to thoroughly read a book on trigonometry and then ace the exam? We know, from experience, that only by doing problems does the student actually learn. We also know that when you stop doing problems the facility atrophys.
Why is code different?
satvikpendem 1 days ago [-]
> And look how poorly they did it until they invented writing.
How can you know how poorly they did it?
lelanthran 1 days ago [-]
> How can you know how poorly they did it?
Their lack of progress. Humans existed in the same basic form for around 100k years before they finally invented agriculture, which led to some improvements, and then rapid progress once writing was invented.
jacomoRodriguez 1 days ago [-]
Improvements or just new ways to be occupied and more work? It seems life without agriculture and the like was way simpler and chilled.
ioseph 22 hours ago [-]
Until winter.
satvikpendem 17 hours ago [-]
Humans have been storing food for winter for hundreds of thousands of years before agriculture and the invention of writing, you think they all died off or something? People whose crops failed instead were more heavily affected in winter than hunter gatherers.
ioseph 8 hours ago [-]
Of course, but the surpluses made possible by agriculture meant occasional starvation became a much rarer event
satvikpendem 7 hours ago [-]
No, people starved way more with farming than with hunting and gathering. All in all you're under very severe misconceptions as to how farmers and hunter gatherers lived which is not supported by the evidence.
That study controls only for habitat quality, which I feel is not really relevant: hunter-gatherers are, by definition alone, nomadic. They move to where the food is!
IOW, hunter-gatherers follow the best habitat, so controlling for habitat is always going to have the conclusion this paper reached.
I'd be very interested in other studies that support this conclusion; after all, that's how science works - a single study proves nothing if many studies conclude the opposite.
disgruntledphd2 1 days ago [-]
> then rapid progress once writing was invented.
While I mostly agree with this notion, given that all of our understanding of human progress historically comes from writing, there's a selection effect happening here.
Like, why do we talk about the Dark Ages? Because there was less writing, so obviously things were terrible.
lelanthran 24 hours ago [-]
> While I mostly agree with this notion, given that all of our understanding of human progress historically comes from writing, there's a selection effect happening here.
There's a bit of a selection bias there, because writing itself is used as a measurement of progress.
But, ignoring writing as a measurement of progress, we can pretty much see that for about 100k years the only tech were primitive tools.
Even after the domestication of wolves (about 40k years ago) there were no visible improvement in tech. After agriculture (10k-12k years ago, maybe?), there's visible progress in tech (tools), but not by much, and visible improvement in societies (also, not by much).
Enter writing - those civilisations that had more advanced writing progressed rapidly, and those that did not barely progressed at all, tech-wise.
Because not all civilisations progressed at the same rate, we can see quite clearly that writing is highly correlated[1] with progress.
---------------------
[1] While correlation does not imply causation, as the data mounts it lends more and more weight to the causation bit.
mewpmewp2 20 hours ago [-]
If writing is a natural tech you unlock on an already exponential curve it would always correlate with progress. And so many thousands of other tech.
lelanthran 2 hours ago [-]
> If writing is a natural tech you unlock on an already exponential curve it would always correlate with progress.
That's a big "If". The observation we have is that civilisations that never invented writing simply died out with no tech-tree advancement; and this happened for 100k years at least.
We've got 100k years of "no writing, no tech". We've got around 5k years of "with writing came tech".
The actual tech to write was there for much of the 100k years (cave art), but without writing, the tech never improved.
palmotea 19 hours ago [-]
>> And look how poorly they did it until they invented writing.
> How can you know how poorly they did it?
You could probably get some sense by comparing illiterate people to literate people.
fuzztester 1 days ago [-]
>>Humans have been thinking long before writing was invented.
>And look how poorly they did it until they invented writing.
Yeah, look how poorly they did it until they invented writing.
[peers into the dim ancient past]
Sorry, my time-machine spectacles are on leave or on strike today.
And congrats on being a multi-millen(ium)arian, and a mind reader, who could both 1) exist so far back in the past, and 2) be able to know the thoughts of people who didn't write them down, because they didn't know writing.
/s
cindyllm 19 hours ago [-]
[dead]
dsego 20 hours ago [-]
It's like math in school. I wasn't good at math in school because I thought that understanding the concepts was enough. But without actually putting pen to paper and drilling through math problems you quickly get lost. It's a skill issue.
mewpmewp2 20 hours ago [-]
I specifically liked math and physics because these were something I didn't have to memorize or repeat constantly.
While other subjects felt forced rote memorization. Same with code though. Writing things down feels like a chore mostly, so I am personally glad AI is here.
dsego 3 hours ago [-]
I didn't mean rote memorization, which I agree is what other subjects were like, we used to say "campaign learning", because we studied the material just for the exams. But with math problems for me the trouble is that I didn't put in the work, I would see for example equations solved on the blackboard and it made perfect sense at the time, but because I would skip practicing at home, I would forget some of the steps and would get stuck.
danshipt 1 days ago [-]
Writing changed everything. You barely (if at all) can tell me what humans in the past were thinking without relying on some written artifact.
mewpmewp2 20 hours ago [-]
That is a joke, right? E.g. as in there was no writing therefore no evidence of people having had thoughts?
ares623 1 days ago [-]
have you tried thinking for a long time without writing anything down?
wseqyrku 23 hours ago [-]
You will get to a point that you have to write it down so you don't forget but more importantly check if it even compiles.
koolba 1 days ago [-]
Yes in three specific environments for varying durations. Lying down to sleep, showering and driving.
Each last for a different amount of time and you generally can’t write or even read anything. But in my personal experience, all three lead to solving the most difficult software problems.
ares623 1 days ago [-]
Fair. But in all 3 did you very quickly write down the solution as soon as you were able?
mewpmewp2 20 hours ago [-]
My best thinking is when I am going for very long runs, when I write down the thought, my brain stops thinking about it, considers it done and moves on.
When writing, thoughts become forced and linear in my view as opposed to floating in a specific way from point to point. Like I lose the natural creativity.
Writing is about remembering or communicating, so it is summarizing the thoughts, but it is not thinking itself, it is more so thinking about how to communicate efficiently or how to make a note so you don't forget. It is not creativity for me.
Kind of imagine building an idea in your head while running and then you write down the summary of it.
ares623 14 hours ago [-]
I see, I'm the same too. Throughout my day my thoughts would be flying and zooming around. Some of them good, most of them not good or otherwise useless.
When I sit down to try and write them down, I blank out. Or the thoughts that I thought were good/useful, I second guess when writing them down. Perhaps it's just lack of practice on writing them down (I'm trying to use a typewriter to do so recently).
t43562 22 hours ago [-]
writing is a way to get your brain to put thoughts into a form that someone else will be able to reach the same understanding as yourself. The effort to explain oneself often leads to better understanding: Duck Debugging basically.
softwaredoug 2 days ago [-]
I’m finding it all boils down to cognitive differences.
Some people find code easier to read than the English description. It’s more precise and many experienced devs can scan it and know what’s happening
Many other people can’t read code. Or they find English easier to read than code.
Thats not a knock on anyone. Maybe the latter will rule the world because the former focuses too much on irrelevant details. Or maybe me there are just different types of problems that need differing levels of attention to detail.
rawling 2 days ago [-]
Sure, read the English description.
How can you be sure that's what the code the LLM wrote actually does?
2 days ago [-]
t43562 22 hours ago [-]
The code tells you HOW, the English should be telling you WHY. Both are usually needed IMO. Even a tiny bit of "why" can be extremely helpful to understanding in my experience. I don't want generated AI garbage that merely describes the code - I want the reason the whole thing exists and what was wanted by the person who wrote it.
embedding-shape 18 hours ago [-]
AKA "Direction", which obviously the LLMs follows, and suck at coming up with by themselves. Humans though, when they have purposeful direction and manages to execute it, ends up creating a (small) beautiful life-changing revolution almost.
pythonplayer123 1 days ago [-]
I wonder how LLMs could be compared to compilers. I personally think the nondeterministic behavior of LLMs are the biggest distinguisher.
dgroshev 1 days ago [-]
Some heart surgeons might only be able to explain to the nurses their ideas on how to carry out the surgery, but are they still heart surgeons?
mochapwns 2 days ago [-]
Pretty sure Casey Muratori and Demetri Spanos cover why in one of their videos online.
Less about “trusting” the llm and more about how complex it is to work with binaries due to machine code being different per machine and hard to interpret the context of the code as well as offsets.
In that sense because high level languages come with the ability to add context to what code does. It’s like the understanding a human has when given decompiled C code ghidra gives you vs C source code a developer wrote.
Also the compiler helps the llm write “compiled / working code”, if it just spat out machine code it most likely not even run at all.
But yea generally if you can’t write code at all, reviewing it is even harder.
satvikpendem 1 days ago [-]
> Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much
No, people do advocate for this. It may simply not be as portable however as something that is high level able to be compiled to assembly for many machines.
t43562 22 hours ago [-]
It's the logical outcome of believing that human skills aren't important and that you can "think at a higher level". You can't spend all your time thinking at a higher level if you cannot fully trust the output and the assembler argument is just taking the thing to an extreme to make that point.
zx8080 1 days ago [-]
> Apparently it's not obvious to everyone, but if you can't write code, you can't review it.
Why review it at all? The trend is to vibe code everything with agent harnesses and tokenmaxxxing.
lazyasciiart 1 days ago [-]
This isn’t obvious at all. Editors can evaluate and improve the work of writers even without being bestselling novelists themselves. Richard Williams coached his girls to world championships without winning one himself. Roger Ebert never even made a movie.
asdff 1 days ago [-]
No one gets hurt or dies when roger ebert whiffs on a movie review. Now imagine I tell you I've built a bridge. I have no idea how to perform the necessary calculations. I have no idea how to verify the necessary calculations. But, I've built you a bridge. It kind of looks like a bridge. Will you drive across it?
Not all software is mission critical. But some software is.
notnullorvoid 2 days ago [-]
No defense for not writing or reading code if want to call yourself a software engineer or programmer.
However I do think there is reason to use Java or Python (as much as I loathe both) they have GC, and it'd be a lot easier for AI to fuck up memory safety in something like assembly or C.
hirvi74 1 days ago [-]
I concur.
One has to program computers to be a computer programmer. If one just prompts LLMs, they are a software prompter. I think both can fit under the title of a software developer or perhaps even software engineer.
byzantinegene 1 days ago [-]
churning out assembly code would cost far more in tokens, wouldn't make financial sense for the improved performance which doens't matter that much for most use cases.
dzonga 1 days ago [-]
just to add to your excellent observation
by writing code by hand - you're the author & editor at the same time.
if you're skilled enough - you quickly get to the desired state vs the llm which while might produce a lot of code - but it likely won't give the end state you desire.
an analogy - Jason Fried gave - producing software by llm's is like bragging you're a photographer by pressing the shutter button on an automatic camera.
while the art of photography - is about producing the single perfect photo - that communicates the photographers intent (what they want the world to see & experience).
likewise in software - what we make should be deliberate.
BerislavLopac 2 days ago [-]
> but no, they don't trust the LLM that much
Yet...
streetfighter64 23 hours ago [-]
First of all, obviously there's more training data on high level languages than assembly / compiled binaries. Secondly, Python, Java or even C is portable to another device. You know, one of the main points of high level languages: that you don't have to rewrite your app from scratch each time you want to change the machine it runs on.
Thirdly, compilers also do type checking and other static analysis and dynamic checks (array length etc). So it's not only got more guardrails against "mistakes" by the LLM, but it's also most likely "easier" for the LLM to "reason" about (in the sense that LLMs can reason).
There's no intrinsic value to having humans read the code, so as soon as LLMs are good enough to work on their own, companies will no longer need to keep developers who can read code as a backup solution.
whattheheckheck 2 days ago [-]
Ask the ai what the game theory is for training employees... the Nash equilibrium is under training and self funded certification/training for devs in low trust environments.
dana321 2 days ago [-]
I have a few personal projects, i let codex do all the code - i do the thinking and testing.
One time, something didn't work as expected - its the first time it happened with this project. I read through the section of code and it was perfectly readable and well-written.
Turned out a plugin wasn't effecting the audio, so i just got it to pad some blank audio onto the beginning before processing it, then remove it at the end of the process. That fixed the issue, there was nothing wrong with the code but my ability to think laterally is what made it work.
We're getting to the stage where you can just ask them to write code and they will do what you want, and it writes good code. Its up to you to test everything beyond the internal tests it writes.
fuzztester 1 days ago [-]
dump out assembly?
aargh! haalp!
Which rock are you living under these days.
Nowadays everything is IR or MLIR ... or AIR ...
whoops, i may have skipped a few generations. hard to keep up with the dynamic pace these days. got a job to save. sorry suh.
mumble javascript mumble framework of the half-week ...
walks off muttering
t43562 22 hours ago [-]
No need for IRs if LLMs are all powerful. Just tell them to generate x86 and ARM and let them get on with it.
fuzztester 8 hours ago [-]
Niiice ...
I'll byte the bullet.
Hang on a bit while I register that in my memory.
>generate x86 and ARM
So that hardly anyone can review the machine language output, I guess.
HN users' minds be like:
87.654321 %: JS? yeah. mainhipsterstream. gotta be a part. heart.
smaller %: Rust? wannabe. donno how, u c.
much smaller %: C? oh no ... numeric underflow.
Congrats on moving over to the light side.
t43562 2 hours ago [-]
If nobody can review it that's fine since we'll be generating at least 50k LOC per day and nobody could review that anyhow. We can just get every other LLM model to review the output. What can go wrong?
nojito 1 days ago [-]
>if you can't write code, you can't review it.
I don't write code anymore and I doubt I ever will ever again.
On the flipside I review exponentially more code than ever before.
>Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much
It's not "not trusting" the llm its that the llm has been undergoing reinforcement learning is on coding. Plus generating assembly is extremely token inefficient.
Salgat 1 days ago [-]
The difference is that you already learned how to write code. New devs that go straight to genai are missing that.
brabel 1 days ago [-]
Perhaps new devs should write all their code by hand until they feel comfortable doing that. Then, they can start using LLMs gradually, just a little bit at first, all the way to fully AI generated code.
However, that would just make the difference in productivity between junior and senior developers even more pronounced! It’s really difficult to see how things will play out in the future without junior developers disappearing, causing a slow death of the profession. LLMs will probably never be good enough to do everything a developer needs to do: understand and improve or clean up requirements, consider future needs, test outside the box, evaluate performance and decide where and when to improve it…
supermdguy 2 days ago [-]
“Do you know what the industry term for a project specification that is comprehensive and precise enough to generate a program?
I think if you’re doing it right, the core of your code should be the simplest expression of the underlying business logic. Of course there’s always going to be supporting layers, and maybe those don’t need to be reviewed. But if you haven’t read the code, there’s an extent to which you don’t know the business logic.
> It’s ok to talk to the agent in code. Or create examples for it to follow
If you're doing this, then why not just write the effing code?
softwaredoug 1 days ago [-]
What I mean by "talk to the agent in code" really is to code. Establish patterns. Then have the agent use those patterns as reference for other areas of the project.
SpicyLemonZest 1 days ago [-]
"Hey Claude, can you please make a full matrix of tests according to the following pattern and parameters? Thanks." That's 15-20 minutes of work that can run in the background while I do something else.
softwaredoug 22 hours ago [-]
Exactly this. Spending a few hours crafting and debugging a test you trust save hours of pointless agent time.
1 days ago [-]
noosphr 1 days ago [-]
This is why you need lisp.
First you write a programming language in which the language primatives are the business logic primatives, then you write a trivial program that describes what the business does in the new language.
nmehner 2 days ago [-]
"It’s about attention and understanding. To keep my attention, I must go beyond ‘read code’ like a passive observer of agents from afar. To really connect with the architecture of the system, it helps to truly experience the code"
I guess the funny answer that is behind this sentence is: You have to train your own mental model. We always argue about code in a very abstract and logical manner. But when coding the subconsciousness makes most of the decision ("this just feels right"). But for this to work you have to train it. And this does only work in a very limited way with code reviews or reading documentation. It requires repetition and deep focus.
When there is an issue in production with this mental model you will be able to point to the cause of an error message instantly. With generated code you'll search for a long time with your slow, conscious part of the brain.
For LLMs to be really helpful, they have to take over complete maintenance of the code. So you can treat them like an external library: Just assume it works. Otherwise this will always be problematic.
jurgenburgen 2 days ago [-]
> For LLMs to be really helpful, they have to take over complete maintenance of the code. So you can treat them like an external library: Just assume it works.
We already tried this with humans. It works so poorly that it got the derogatory name “ivory tower architect”. It usually results in theoretical designs that are unworkable in the actual system, implementation teams (or LLMs) that work around the architecture and a lot of slowing down of velocity as the architect and implementers argue past each other.
zelphirkalt 2 days ago [-]
This happens when the architect is out of touch. If the architect themselves works on the code, writes code, deals with the imposed restrictions, then the chances of that happening is much lower. Assuming, that they are a good architect.
jurgenburgen 2 days ago [-]
I agree, if the architect participates in the implementation then they avoid this anti-pattern. That’s not compatible with hands-off autonomous agents where you treat implementation as a black box.
kqr 2 days ago [-]
> With generated code you'll search for a long time
The observability people will claim that if the dynamic runtime behaviour of your system makes it hard to find the source of a behaviour, your system must be made more transparent and observable. They would also claim this was always the case -- we should never have relied on people's mental models being amazing because people move around.
(I don't know yet where I stand on this but I'm trying to learn more.)
nmehner 2 days ago [-]
If it was only "my" system without any integrations, I might agree.
But currently e.g. I am working on an MES/Scada layer that integrates data from a load of different machines in a factory. These machines are from China, Korea, Germany, Sweden ...
Upwards there is an ERP integration (and some other systems).
Sometimes machines are updated and suddenly behave differently. Giving error messages in Chinese.
The ERP has the nasty behavior of returning error messages where it is not clear whether the actual processing actually happened or not. There are some heuristics on parsing the error messages, but these also change with new versions.
Sometimes one machine overloads cloud infrastructure and completely unrelated functionality fails.
Sometimes the on-premise network stops working for whatever reason and data is lost.
Sometimes operators do not understand a perfectly valid error message like: "The batch you loaded into input position XY has expired on XZ and cannot be used for production": "But we have been told to use it..."
So when you get called out at night, because the production line stopped and "MES is displaying an error message", it is mostly about finding out what integration failed and who else to wake up. Getting this right is very much appreciated by your colleagues.
And this is where you need a mental model of how things are connected, what error message happens because of what external causes etc.
Observability can only work perfectly for known problems. In a complex system for unexpected problem you can either provide too much data, so analyzing it and finding the relevant part becomes really hard, or too little data which makes finding the issue impossible.
There are so many companies claiming to provide the perfect observability solution and there are certainly solutions that help. But it is all very far from perfect.
Not relying on people is managers wet dream. And for a lot of people it might be true that they can be easily replaced. But for complex systems there are always some key people that you cannot replace without causing issues.
b112 2 days ago [-]
And here's the thing... juniors become seniors become experts, by doing this their entire career.
By having an understanding built during their entire career.
Right now we live in a fairly-land of mixed capacity. LLMs being used in parallel with skilled people. But as time progresses, there will be no more skilled people, because no one will learn and develop those skills.
If you're in the world of LLMs now, you are basically completely stalled in your personal growth in this field. You will never improve, and some seem to say they lose capabilities as they rely upon LLMs.
The world always changes. But the decisions being made today, are being made by skilled people.
What will the world look like, when it's just all "bro, lol, just tell it to make your thing" and then done?
The observability people are correct. It’s not either-or though.
jillesvangurp 1 days ago [-]
The relevant question is who is going to pay you to write code manually. It's something that's increasingly hard to justify. The answer is of course that people are not paying for code to be written or generated but for some problem to be solved. Whoever does that with the least amount of drama and cost gets the business. And using AI tools just allows for compressing the timelines a bit in a way that is hard to ignore.
Most code out there isn't all that great. I've been in this industry since the nineties. There are a lot of not so great software engineers doing mediocre work. People are romanticizing how great and magnificent their code is (or used to be). The reality of manually crafted code is of course a lot less flattering. Many code bases become hard to maintain over time and are riddled with bugs. And it's not like sloppy code is a new thing. Poorly executed software projects have been very common for a long time. That's not going to go away.
softwaredoug 22 hours ago [-]
I personally am advocating for writing small amounts of code because I think it makes you more productive
Spending a day manually reworking the architecture in my experience can save you $1000s in tokens and weeks of headaches.
We’re trying to build a software factory with hands tied behind our back
tonyedgecombe 1 days ago [-]
>There are a lot of not so great software engineers doing mediocre work.
Yeah, and they are all producing 10x as much mediocre work now.
Pavilion2095 1 days ago [-]
> The relevant question is who is going to pay you to write code manually.
Hopefully companies in the industries where software quality matters and is regulated, e.g.: medicine, aviation, nuclear, etc.
Although this market is relatively small.
jillesvangurp 24 hours ago [-]
You seem to assume that people still have an inherent advantage here. Mostly those sectors compensate for well documented human failures with very rigid and expensive processes and testing. And of course despite that, stuff still goes wrong occasionally.
I actually think AI based automation is going to be a key enabler in those kinds of strict environments as well. Recent work on identifying e.g. security bugs seems to be resulting in a lot of improvement that has somehow escaped decades of human scrutiny. With good quality harnesses (manual or automated), I don't see any big objection against using generated code here.
softwaredoug 22 hours ago [-]
There are ways humans have an advantage. Not in the line by line code, but in the experience of having the whole mental model in your head.
Writing some code with the whole context in your head is the human advantage.
I’m not precious about that code. Maybe it needs to be rewritten by an agent. Or we could build good abstractions so it’s trivial to see the system. We could also use systems that by their design force us + agents away from security, performance, etc
inigyou 14 hours ago [-]
Sadly, AI can process semantic vectors in latent space much more effectively than any human.
prymitive 2 days ago [-]
I need to write code because otherwise LLMs will write too much code, it’s only when you fully understand the problem you can generalise it enough to not end up with 10k lines and 5 abstraction layers for “hello world”. LLMs are token predictors, so all solutions are you tokens, the more problems to solve == the more tokens (code) to output.
softwaredoug 2 days ago [-]
LLMs love to defensively wrap code instead of thinking holistically about the big picture. That creates a lot of bloat.
A human coder might OTOH follow the Boy Scout rule and clean up as they go.
krackers 1 days ago [-]
> it’s only when you fully understand the problem you can generalize
Peter Naur explained this decades ago
>Peter Naur argues that programming is fundamentally a human activity of building a mental "theory" - a deep conceptual insight into how a system's parts match the real-world problem it solves. He rejects the prevailing view that programming is merely the mechanical production of source code, specifications, and documentation. Instead, Naur posits that the true product of programming is the shared mental model held in the minds of the developers who built it.
As a human you're the one with the problem you want code to solve, so it's worth having an understanding the problem. Otherwise you risk an X/Y situation, where the LLM ends up solving a problem that may not actually satisfy what you need.
I think what LLMs allow you to do is better abstract away everything that's _not_ essential to the problem you care about, in the same way that libraries or any higher-level programming language does. Ultimately there's still a "core" of the problem that needs to be expressed formally though. When you see people "vibe coding" by prompting the LLM to add constraints at a time until they reach their desired end-goal, this is ultimately "programming" in a sloppy, non-formal way. Better to get the LLM to write everything else _surrounding_ the problem, so you can write and understand the core yourself.
balder1991 18 hours ago [-]
Basically, I’d say the LLM doesn’t have a “theory” of anything that wasn’t in its training. It’ll always treat your project as if it was reading a book for the first time.
As an example, if you chat with an LLM it can sort of explain concepts it learned in its training, because it created some internal representation of them. However it’ll never be able to explain things about your project unless you tell it (then it can simply repeat it, which is the same RAG does, the LLM is just spitting it out without any deep understanding of it).
You can try to cram as much context to it as possible and overload it with extra information, or you can understand this difference and separate a task that you know the LLM can handle because you’ll be able to leverage its knowledge and judge the final work yourself.
But this distinction needs to be more clear, I think. The LLM doesn’t have any deep understanding of anything you’re creaming into the context window the same way it does with concepts it learned during training from millions of examples and building some internal model of the concepts and their relationships.
bigmattystyles 2 days ago [-]
That’s why even though 99% of my work is C#, llms have made it so I can finally call myself a low-level programmer, which I’ve always aspired to. I didn’t even have to do anything.
TacticalCoder 2 days ago [-]
> I need to write code because otherwise LLMs will write too much code, ...
I second that and I can give an example that happened to me yesterday with a totally SOTA model (a US, not Chinese model).
I needed to display an information on the client-side. Something trivial. I ask the LLM to do it. The thing went onto a rampage: it somehow found a way to pass the information from the server to the client during the initial handshake (already: why, just why?). Modifying both server-side code and client-side code. And it worked.
To an unsuspecting programmer/tester (or automated test)/user: the info is there, what was asked has been done. So it's perfect, flawless LLM victory right?
Except none of that sloppy-pasta was necessary: the info was already available on the client-side and was a one-line change, purely client-side.
These thing shall definitely, as of 2026, write way too much code.
And btw the companies selling metered tokens have a very serious incentive to produce the most complicated, rube-goldberg, solutions that use as many tokens as possible, while still kinda solving the problem.
That way not only you consume tokens to produce the code, but later on you consume tokens when working on that code (which btw is a guaranteed thing: for the LLM just introduced new bugs in that gargantic amount of crap it output).
Funnily enough the very same people who made fun of copy-pasta happen to be in love with sloppy-pasta. Go figure.
supriyo-biswas 1 days ago [-]
So much this, the other day I wanted to set up a project running in K8s similar to our other modules at work, and it he thing ended up writing unit tests for a hello world implementation.
h2aichat 2 days ago [-]
If tokens are the problem, SDD is the solution
avaer 2 days ago [-]
> For example, have you ever seen an agent follow the boy scout rule? Where they leave code better than they found it? And would you WANT them to try to do this?
Yes, it's in the rules; run profiles, check code coverage, do a critical review, post the report and follow up tasks. 90% of people I've worked with did not follow these boy scout rules nearly as well as today's frontier LLMs.
Is the author implying this is bad?
softwaredoug 2 days ago [-]
That quote is the lead in to an example I talk about after this quote illustrates what I often see.
> Agents bias to making the current change as safely as possible. I had a situation in a previous codebase where one morning, pre-caffeinated, my meat brain mentioned using browser local storage. So some random state was managed in local storage. Everything else through a backend database. When I looked at the code, the amount of wrapping and indirection to preserve this idiotic human mistake probably tripled the LoC. Agents can amplify our one-off bad decisions by being so conservative.
You can of course solve this many ways. And many of boils down to just how a particular humans brain works. Some will solve this by not reading code. Some will read / write code.
Whatever works for you is great. But many there is upside to the precision of not having code intermediated through the LLM for many.
avaer 2 days ago [-]
Right, but this just seems like underspecification. In my experience as both a team leader and an "agentic engineer" (ugh), I try to blame myself for the lack of clarity of my asks, rather than the person/agent for making the "wrong" choice.
I'm sure plenty of meat humans out there would make the same mistake (sorry, you said to use local storage boss!). You might give them a scolding. And maybe document that policy. Maybe in a markdown file for the next person. IME the latest models are significantly better than the median engineer at following this feedback.
I don't think it's fruitful to blame the LLM any more than it is to blame someone working under you.
In fact I would say this is an excellent example of how engineering does NOT fundamentally change in the era of AI.
balder1991 19 hours ago [-]
Often times to write a good enough specification in a way the LLM won’t misunderstand it, you need to really understand the code and the possible pitfalls in it though. A few times when I tried this route, even adding details just in case the LLM still went and assumed something wrong that I didn’t consider would be a problem until the agent had to make that choice. Then it becomes a game of doing it again and again with more and more detailed instructions until you could have yourself done it in less time and having a deeper understanding of the problem (or I could argue having any understanding of the problem at all, since having the LLM do it for you is like being a manager who has no clue about the lower level decisions made and only being communicated the final result).
softwaredoug 2 days ago [-]
Yes but I always have to be on the lookout for this meta pattern that leads to code bloat.
In this case things mostly sorta worked and the simplest way to see the problem was look at the code. And try to take it apart a bit to see where the problem was.
I felt I arrived at a better pattern I could trust that the agent could use much more efficiently this way than asking the agent to do it. I could then test that the pattern was being adhered to and therefore better trust the agent not to go off the rails.
I personally internalized the details a lot better by doing this writing. I wouldn’t have internalized it - or more likely played whack-a-mole - by guiding an agent.
How do I arrive at the patterns to check for without exploring the code? And capturing a real failure case?
avaer 2 days ago [-]
> Yes but I always have to be on the lookout for this meta pattern that leads to code bloat.
You don't!
Have you tried adding rules/automations that make it explicit to review and fix the code for bloat (per your taste, with examples if needed)?
With this setup + a good frontier model you will never have to be on the lookout for code bloat. You can even get the agent to send you text message with the LOC-- if it makes you feel better.
I think I understand where you're coming from, that it's hard to "let go" (I've been coding for 30 years and it was hard for me). That's why I'm recommending to have agents write verifiable quantified reports of the things you care about, so you can build up some trust in the agent's work and you don't have to do things by faith.
softwaredoug 2 days ago [-]
How do you arrive at a failure case to measure without looking at the code?
How do you establish sane patterns when you’re in an exploratory /architectural mode? You could do this in English, sure, but many of us do this more efficiently and precisely in code in a way that lets us be careful, internalize details, and add measurement + QA to ensure it’s adhered to by agents or humans.
I’m not saying to write all the code. I’m saying it’s useful to write 5% of it. Then let an Agent stamp out / rewrite the rest
girvo 2 days ago [-]
> I’m not saying to write all the code. I’m saying it’s useful to write 5% of it. Then let an Agent stamp out / rewrite the rest
100% agreed. And it leads to far better LLM output and lower token usage, too, I find.
Iakeman 2 days ago [-]
[dead]
pydry 1 days ago [-]
>I try to blame myself for the lack of clarity of my asks, rather than the person/agent for making the "wrong" choice.
I noticed this phenomenon way before LLMs came along. Some people would put a halo around a particular technology and blame everything around it when something went wrong.
ccoffey1 1 days ago [-]
"Instead, we’re switching to this wrong-headed mindset that coding agents are like compilers. That mindset gives us permission to ship terribly written code. Agents aren’t compilers - they’re more like freshly onboarded interns."
I feel this statement these days during code reviews. I know some amazing engineers whose output lately just isn't the same.
chromadon 23 hours ago [-]
"Why write code in 2026"..
Because AI generated code is STILL complete ass. Even Fable, even whatever custom Pi/opencode leet code harness you have, the output is awful, and, if you cannot distinguish the quality of your code vs the AI's, I've got some bad news for you.
anthonypasq 12 hours ago [-]
99% of code ever written has always been shit. Most of it has been thrown out or not in use anymore, or EVER used. Most people arent going anything particularly unique or complicated or performance focused.
mewpmewp2 17 hours ago [-]
My code is/was worse than AI's, but at least I get paid, so what do I care about the bad news you have.
superze 14 hours ago [-]
You are exactly the person who should be afraid then and you prove his point?!
mewpmewp2 7 hours ago [-]
What should I be afraid about? The code I output with AI is now better than what I did previously so I have equalized with anyone who had better code pre-AI.
TrackerFF 2 days ago [-]
If we look at the progress made from ChatGPT 3.5 (Nov 2022) and up to today...shoot, I'm really starting to wonder if we'll even be reviewing code in 4 years.
And I'm not saying this as some sort of AI maximalist. If progress keeps up, I seriously doubt software engineering and development will, as we know it today, will be a thing in the next 5-10 years. Maybe humans will be left with designing the UI, but everything else will be abstracted away and AI will be doing all the actual work behind the scenes.
softwaredoug 2 days ago [-]
The thing is with a wish machine, you can one shot something very easily.
But then you realize software is the accumulation of 1000s of wishes. And you want this but not that. Many little micro decisions of exactly what you want in every nook and cranny.
In the current paradigm (LLMs) we still have to manage all this. But maybe in the future we have something impossible to imagine.
weakfish 1 days ago [-]
You’re assuming that progress will continue at the same rate (it’s plateaud a bit as far as I can tell, I can look for sources tomorrow but am on phone now :))
& I think it’s fairly demonstrated that the industry isn’t profitable for training ever increasingly huge models, which get exponentially more expensive each iteration
galaxyLogic 1 days ago [-]
I wonder, LLMs have progressed at great speed, because they have learned to duplicate what humans did and recorded in the documents and source-code that became the training materials for the LLMs. But now that humans don't write any more code, there is no new learning materials for the LLMs. There are no new things for them to learn. Therefore I expect they will plateau, the progress is no longer so fast.
And maybe we'll get something like a Mad Cow Disease, when AI "eats its own brains". To avoid that from happening we will need continued human inputs, and review.
inigyou 14 hours ago [-]
They are now paying full-time programmers to write new training data.
zelphirkalt 1 days ago [-]
Already loathing the idea of not even being able to directly blame humans and their incapability for making shitty websites, that require JS for everything, including typing a text in an input field. If we get there and the LLMs build the same crap, dialed up to 110, because even more suits want first and foremost fancy looks, rather than function, and because that's the majority of training data corpus they learned from ... I might have an existential crisis coming in. The web already sucks hard enough. At least let me blame incapable human beings for this situation.
pjmlp 2 days ago [-]
I write code all the time I can, outside the KPI metrics that everyone is being pushed to, I only care about AI for smarter code completion.
fernandotakai 2 days ago [-]
i write code because i love it. it's something that makes me genuinely happy, so why would i give that up?
ivanjermakov 2 days ago [-]
There is magic in telling computer do something and seeing it zap through it billions of times faster than by any other means.
bluefirebrand 1 days ago [-]
That doesn't feel like magic to me, it feels like cheating. It feels miserable and demoralizing.
And then it feels like a chore slogging through whatever it produced to verify it is correct.
zelphirkalt 1 days ago [-]
In a way it is cheating, as it is all built on countless copyright infringements and non-consensual use of other people's works.
Only that businesses have decided it is OK as long as they are benefitting to steal from everyone else, and basically force us to be the acting hand in all of it, or threaten us with starvation (no job, no income).
jayknight 2 days ago [-]
Exactly this. I got into this field because designing programs and writing code is enjoyable. I'm probably behind on using AI and need to get more up to speed, but I never want to stop coding by hand.
DaiPlusPlus 2 days ago [-]
> I'm probably behind on using AI and need to get more up to speed
Same.
My difficulty is that for the past 8 years I've been working for (tiiiiny) SaaS business where I don't have anyone I can simply ask in-person "hey, can you show me how to 'do' all this newfangled AI agentic team coding?"; so my only direct-exposure is with the painful Copilot sidebar chat, which I now find myself allergic to.
So let's see elsewhere: while searching online for some (reputable) "agentic coding courses" my results are for the same kind of people who used to run those dodgy coding-camps from 10 years ago. I'm having difficulty finding resources for practicing SWEs like myself wanting a continuing-professional-development course experience, not a get-rich-by-buying-my-course video library from a contemptable AI booster
Even more surprisingly, my local major university (UW.edu) doesn't seem to offer any certificate courses for getting into agentic development either[1] despite offering courses on C++, Six Sigma, and actual ML/AI courses. It's maddening. I can't be the only one with this problem...
I don't understand this. A skill critical to software engineering is learning how to learn. Just download Claude Code (or open alternative) and try to make things.
See how it fails or succeeds. Look at the supported features, try them out, think about how you might use them in your workflow.
Before you know it, you'll be proficient.
You have to learn how to self-teach.
DaiPlusPlus 2 days ago [-]
I agree with you - but I’m the one with an anxiety disorder here.
ipsod 20 hours ago [-]
Make a copy of your codebase. Go to town on it. Have fun.
Doesn't have to be stressful. Plan to throw away whatever happens. Do it in a VM if your nerves demand it. No reason it can't be fun.
DaiPlusPlus 19 hours ago [-]
I'm not anxious about my codebase; I'm anxious about all the fun parts being sucked out of my job as though I'm being promoted from IC to management - and given the inevitability of progress I can see how my new role as an agent shepherd, too, could be obsoleted in the near-future.
...so I've been avoidant of the whole thing ever since 2023, burying my head in the sand to avoid those feelings of anxiety and uncertainty-about-the-future, and it now makes it difficult for me to engage with the topic head-on.
ipsod 18 hours ago [-]
Ah, well... I can't say that there's any real hope.
I dove in in ~2023, and I'm about as deep in it as one can be. The better I get at it, and the better the agents get, the less time I spend even doing what I do - one prompt will often take 3+ hours. I often keep 8+ agents churning for the whole workday (and leave them running when I leave, too, and it's very often that they'll work from 4pm to midnight or later). I was responsible for 499 commits last week (very little new functionality, though), and I felt pretty useless at the end of it. I keep thinking I should code something, because coding feels productive in comparison, but going by results, it's pretty far from economical to write code by hand, and quickly approaching as bad as shipping goods by foot.
DaiPlusPlus 15 hours ago [-]
May I ask what you end-up doing for the rest of the day?
ipsod 13 hours ago [-]
Depends on the day. Mostly playing with the applications I'm developing to try and find gaps or rough edges, or reading over code and developing further AI tooling when I find disgusting code (to try to detect/fix/prevent disgusting code of that nature). Also, talking to coworkers to learn about the products we build and the business we're in.
Kon5ole 1 days ago [-]
Burke Holland has a few good videos that helped me. For example this on agents[1]. He uses Copilot but the principles are similar for Claude Code, Codex, OpenCode and other harnesses:
So far in the LLM coding revolution I still feel like it's software development. I just work with systems on the level of features and architecture instead of flow control statements. Some day we might lose that too, but I think it will take a while.
> I just work with systems on the level of features and architecture instead of flow control statements.
That's kinda at the level I enjoy though - where I get to think-through things when figuring out exhaustiveness and correctness; introducing refinement-types into a codebase that's previously nothing but ints-and-strings; and trying out new and cutting-edge language-features directly.
I know I can prompt Claude etc into trying to do those things, but from what I've seen from other people doing it the result is somewhat of a mess - or just plain inelegant.
-----
May I ask how well Claude/Copilot/etc works with FP languages instead? So far - and back in early 2024 - I've only messed-around with asking ChatGPT to generate Haskell programs and the results were hallucinated gibberish.
okanat 1 days ago [-]
If you're also happy getting paid for it, then the company will just stop paying you. If you rely on such income to have a visa, you'll 100% sure to accept that you're forced into this and you will give up coding, or else.
bananaboy 1 days ago [-]
100% agree. I don't understand why there is pushback against this.
kzzzznot 1 days ago [-]
Because professional development is not just for fun
zelphirkalt 24 hours ago [-]
One of the things businesses tend to not understand is, that if you take the fun out of the activity, you also lose the passion of the people performing the activity, no matter how many times actors at the job fake passion in front of higher ups. If you lose the passion, what you will be left with it mediocre development and shoddy software.
Maybe that's "enough" for the business to survive. But it surely won't be the reason it succeeds. It can still succeed for other factors though, but the business has given up on one path to success, which is making better software than the competition.
sublinear 2 days ago [-]
> If we’re building a software factory, details matter. The details that establish architectural patterns. Down to algorithms and performance. Agents push us to evaluate, measure, and guard. They’ve made it cool to add CI into side projects early, not as an afterthought. That’s massive improvement to the state of software.
Why are you building a software factory though, and why weren't you immediately adding CI to every project?
> It’s our job to build the software factory - not just the software. Software engineers maintain the assembly line allowing anyone to prompt for a change and ship immediately.
Again, why? Where are you working where this is considered a good idea? This would mean that the software engineers are not just being completely kicked out of all business decisions, but asked to build a moat that ensures they stay on the other side of it.
Any business that intentionally devalues the insights gained through implementation will eventually starve itself to death by making too many passive thoughtless moves. No insight will ever be gained just spot checking AI. Is their intention really just to make tiny amounts of profit while riding the thing into the ground? Crabs in a bucket, man.
andai 2 days ago [-]
>It’s our job to build the software factory - not just the software. Software engineers maintain the assembly line allowing anyone to prompt for a change and ship immediately.
The job of the software engineer increasingly becomes to make himself unnecessary: to empower the nontechnical business users to do as much as reasonably possible, without his/her intervention.
This has, of course, been the dream of computing, since its inception! And the true aim of every "high level" or "beginner friendly" (looking at you javascript!) language.
But finally, now that the computer actually speaks English (and is beginning to stop making completely insane errors), it gradually becomes feasible.
Freeing the masses from the tyranny of the nerds!
andai 6 hours ago [-]
Update: since I have posted this my computer has made several completely insane errors. I guess we're not quite there yet haha.
inigyou 14 hours ago [-]
This isn't the first or even the tenth attempt at making computer programming accessible to everyone. Remember COBOL? COBOL made the computer speak English. It didn't help.
A specification detailed enough to control every aspect of the resulting product is called a program. Compilers are AI. The prevalence of compilers hasn't harmed the programming industry at all, quite the opposite.
andai 6 hours ago [-]
Well, it's harmed the assembly programming industry.
goodness4all 2 days ago [-]
I always hated writing code but loved debugging. LLM super charges systems thinkers & auditors, it’s just a different process and no different than copy and paste from stack overflow. It all comes down to the architecture design and LLM just exposes how bad people are at designing dynamic architectures.
girvo 2 days ago [-]
> and no different than copy and paste from stack overflow
This isn't really the point of your comment, and for that I apologise, but: not all of us did that. For many good reasons, too.
monk_grilla 1 days ago [-]
> not all of us did that. For many good reasons, too.
This isn't really the point of your comment, and for that I apologise, but I still haven't gotten used to speaking about what we "used to do" in the past tense, as if we are in a post-programming world...
We are already starting to speak of the habits we used to have (or not have), how things used to be done back in the day (1-2 years ago).
I don't think you're wrong to do so. I find myself saying it sometimes too. Just an observation about the weird world we find ourselves in.
inigyou 14 hours ago [-]
Objectively, the usage metrics at Stack Overflow are showing that it is already dead. Very few people are still accessing it for any reason. While programming might not be in the past, Stack Overflow very much is.
girvo 1 days ago [-]
For what it’s worth, I was talking in response to the original commenter who was talking in past tense, I was merely responding in kind :)
I would argue that SO is basically “done”, though. For better or worse.
I still write code by hand. I use LLMs too. Weird world for sure.
pydry 1 days ago [-]
Yeah, the more I hear about people writing "boilerplate" or "copy pasting" code faster using LLMs the more I think it's mainly a tool for letting you write brittle, buggy code, faster.
leptons 2 days ago [-]
>architecture design and LLM just exposes how bad people are at designing dynamic architectures
Speak for yourself. A lot of people have great abilities at designing "dynamic architectures" and anything else an LLM is used for. It sounds like you don't realize that an LLM is only capable of what it does because it was trained on human-written code.
TacticalCoder 2 days ago [-]
> ... and no different than copy and paste from stack overflow.
It's even got a name: sloppy-pasta.
imtringued 2 days ago [-]
I'm not sure this is a good combination?
I mean you're basically saying it is a good thing if the LLM messes up so you have a reason to debug the code.
jv22222 2 days ago [-]
At this point I haven't looked at code for many months. Before that, I spent 4 years hand coding a Google Docs competitor in JS without any libraries.
My brain feels equally as exercised (in fact more so as I am not as good at agentic coding as I was at real coding)
But now I'm making highly polished Mac OS apps and I really like that move from JS.
I feel... conflicted.
softwaredoug 2 days ago [-]
Do you like to look at code? I’m finding it’s really just a personal preference. And honestly not worth getting worked up about either way.
jv22222 1 days ago [-]
This is weird but I think I like to focus wherever I feel needs polish.
So, making a real time collaborative tool from scratch there was a lot of deep work in things like sockets, queues, memory structures, etc. That's just what needed attention.
Right now I'm building a memory app for AI.
So far I haven't spent much time looking at code on the swift side of things. But I have spent a lot of time up front working on domain driven design, screaming architecture, and module based design.
I think with AI the polish is in deep QA, design taste, running trace logs and constantly asking it to do html diagrams of the architecture and such.
ngl I miss "knowing what's going on" at the code level, but it feels like not a good use of my time to go into those weeds.
When I look at the code it seems well structured due to screaming architecture, and module based design.
2 days ago [-]
throwatdem12311 2 days ago [-]
If you’re not writing code it won’t be long until you get to a point where your agent won’t be able to dig you out of whatever hole you’ve dug for yourself and then you are fubar because you’ve just completely forgotten how.
minimaxir 2 days ago [-]
Note as some may be confused by the "1 hour ago" with comments older than that: this submission was rescued by dang when a previous discussion existed: https://news.ycombinator.com/item?id=48883341
fwiw I think the rationale behind it is counterproductive because the only difference between a OP submitting their article link and someone else submitting their article link is internet points.
softwaredoug 2 days ago [-]
I was fairly confused myself as the author :)
This was actually my original submission last week. There was a front page submission last night from someone else (hence the comments). Then my old post got re-upped just now (1 hr ago)
balder1991 19 hours ago [-]
I’d like to recommend people to read the “Programming as a theory building” article and why the code itself isn’t enough to understand the whole context of a complex project.
Every time you work in a complex software project, you have all the context in your head about what you must take into consideration. LLMs don’t, you have to explain every little detail to them, but there’s no telling where it stops: do you have to explain X to it or is it in the training already?
When you try to shape how a LLM should behave and what it should know, you end up writing a Bible of relevant context that’s increasingly difficult to maintain as well, often with outdated or contradictory information, and it is still free to ignore things you have written and proceed however it wants.
That’s why so many people only feel comfortable giving the LLM some limited task to do, because you can judge if that specific task needs just enough context that it can handle by itself.
feverzsj 2 days ago [-]
Unless you want some unmaintainable shitty sloppy app.
podgietaru 2 days ago [-]
I was thinking about an experience I had recently, and how it relates to my feelings about AI... And it bummed me out a lot.
So I took over an open source project called Omnivore. It's a reading app in the vein of Pocket. The hosted version used pdf-lib to inject some functionality into the pdf viewer. Namely, highlighting, note taking, and storing location. pdf-lib is a licensed application, so when taking it to fully self-hosted this needed to change.
I migrated it over to pdf.js. And I went through the entire process. I added all the functionality bit by bit. It didn't take exceptionally long, maybe 1-3 days. But that process was really satisfying. I found a bug, fixed it, and then found a stackoverflow issue where someone was also experiencing the same issue and suggested the fix. https://stackoverflow.com/questions/59151218/pdfjs-error-on-...
I'm pretty sure an ai could have done all of this. And therein lies my fear and my upset with AI. Not only would it have robbed me of that experience, but it shows that I have in a way been devalued. Because I do think that took a level of skill. And now that's gone...
softwaredoug 2 days ago [-]
I think what we’re learning is that up front slower experience can be valuable for maintaining the maintainers own understanding of the project
I’ll be very curious how / if the Bun port to Rust works out.
mahmoudilyan 1 days ago [-]
I enjoy writing and read code as well, but AI race force me to skip that part to be able to ship faster.
I spend time building AI Agentic guides and skills, then review the code myself. I really miss the old days when you put your headphones on and focus for 3-4 hours
mintflow 1 days ago [-]
This resonate with me a lot
Recently I am seriously thinking the time when agent do the work and I was waiting for it's output, I got a bit lost given it really can do a lot but it make me feel some crisis as a human, even it still can provide me a sort of Joy because some task I long want to do but no time to start can be finally take shape, but the Joy is actually not comparable with the Joy when I read the code and hack with it
Concretely, I am letting agent to write some serious part of code to rust and I will consider only let Agent to handle the UI and integration stuffs, and I will take the rust part and rust is a language that I want to learn and be professional given I was do lots of C coding
mcrk 2 days ago [-]
Do ppl think that programmers just write code from sratch each time..?!
Even without AI I barely write code. 95% of time are spend setting up integrations, configs, copying & adjusting code from previous projects.
estetlinus 2 days ago [-]
+1, I don’t understand who these greenfielders are. Either I wait on the CI to finish, or I’m in a meeting.
softwaredoug 2 days ago [-]
I’m old enough to remember coders being made fun of for doing copy-pasting from stackoverflow all day.
danielbln 2 days ago [-]
And that sort of yak shaving is something LLMs are great at.
dented42 1 days ago [-]
I feel like this question doesn’t need a blog post to answer.
Why write code in 2026? Because it’s fun.
h4kunamata 1 days ago [-]
This does not seem obvious to AI-developers, you cannot fix what you do not understand.
Also, if you use AI to write your code, you are not a developer either.
Let's say AI completely disappears right now, many of the so called "developers" are unable to write code, are unable to fix code, they cannot code.
There are two kind of developers:
1. Non-developers: Use AI for everything, to write code, to test the code, you name it.
2. Real developers: Search engines are broken right now, they use AI as a tool, as replacement for Google to ASSIST you, not to do the task for you.
As AI is falling apart and companies are hiring people back, these non-developers will find themselves out of work.
squibonpig 1 days ago [-]
Ai will fall apart as an industry but it's likely that models on par with e.g. opus 4.8 will be runnable on a home server within the next year and a half and that model hosts will still exist. I figure these tools aren't likely to go away.
h4kunamata 1 days ago [-]
AI is here to stay, full stop.
The problem is IT professionals who depend on AI for everything. That is crashing down and won't be pretty.
soundworlds 23 hours ago [-]
The most interesting and creative projects I have worked on required little code, but novel combinations of ideas.
light_hue_1 2 days ago [-]
This is too generic. There's some code I need to write like core abstractions that are going to set the pace for everything. Or tricky steps that can look good without actually working well.
Then there's the mass. I don't need that anymore. The mountains of boilerplate, etc.
I write little islands which need high judgement that are then connected by the obvious goo.
sublinear 2 days ago [-]
The boilerplate was always boilerplate though. You never needed to write it to already have that code in your project, so I'm confused by what you mean.
Generating boilerplate is strictly inferior than something already written and tested by the authors of the tools. You will eventually have to make slight adjustments to it, and those decisions can be just as impactful as your "high judgment" code. Those decisions are what actually enable your high judgment code to stay clean and straightforward.
Poor decisions in code architecture are some of the biggest blunders of all. Once you have begun to fill in the blanks on some boilerplate code, it ceases to remain boilerplate code. If you let AI make those adjustments, you will eventually blunder the codebase in precisely this way. You'll first recognize it when your high judgment code seems too verbose. You'll then soon realize some things are impossible without adjusting the boilerplate you started off with. Then the AI will fail to grasp what you want and you'll have to manually untangle a lot of the slop that you let grow out of control. Good luck with that.
jdthedisciple 2 days ago [-]
this is the way
j16sdiz 1 days ago [-]
I discovered Doctorow's "Reverse centaurs are the answer to the AI paradox" via a link in this article.
I think fragility is the key reason i intervene in llm code too. Good article.
majorbugger 2 days ago [-]
Why is this even a legit question? I need to keep writing code to stay relevant, not to forget my craft, be able to review code... So many reasons. AI doesn't change a thing.
avaer 2 days ago [-]
Before my time ppl mostly did things in asm, I bet the vast majority of people reading this have never touched assembly and will never have any reason to. This is quickly becoming true of most "code". AI has changed that.
One way to "stay relevant" would be to admit that.
softwaredoug 2 days ago [-]
Yet as a C developer for 15 years I frequently looked at asm and on occasion even wrote a little.
And that is a far stronger abstraction than LLMs :)
cozzyd 1 days ago [-]
How can you evaluate what your compiler is doing without looking at the assembly? The many users of godbolt suggest it's pretty common.
majorbugger 2 days ago [-]
I have also never used punch cards, what does it prove?
deadbabe 2 days ago [-]
assembly is compiled deterministically so you don't really need to look at it, LLMs though can write a variety of things at random based on the prompt. It is not the same.
Arubis 1 days ago [-]
To build software that you understand yourself. Next question.
guyzana 4 days ago [-]
I found myself working mostly at the requirements and architecture level, but do not give up proper code-review, creating skills along the way that maintain conventions.
jonplackett 2 days ago [-]
Prediction: in 2027 a coding agent will read this as inspiration for why it should code.
vips7L 2 days ago [-]
I still exclusively write my code. The quality is higher. I know exactly how it works. It’s more extensible. You don’t have to generate it.
bigstrat2003 2 days ago [-]
In fact, it's better not to generate it imo. Like you said the quality is higher, and by the time I get done reviewing the LLM's output I haven't really saved time over just doing it myself. LLMs are only useful for things you can verify extremely quickly (like a short script), or for things where you don't care about the quality.
glouwbug 2 days ago [-]
Turns out you internalize it when you write it and refactor it with iteration
sph 2 days ago [-]
In fact, not many people know that these days, but a human doing a thing by bashing their head against it, often tends to improve. My hand-written code is my best yet. My breadth of knowledge, wider than ever.
lordnacho 2 days ago [-]
But the attraction of LLM code is not that you get quality.
The selling point is that you know have a quality Vs time tradeoff that is a lot better than you used to have.
I can spend 10 seconds typing out a prompt that will generate ok code.
Before a couple of years ago, it might have taken me an hour to type out and debug that code.
vips7L 2 days ago [-]
Sure, if you prefer low quality go ahead. Many people have always preferred low quality. Many people prefer to eat junk.
I also genuinely believe that time tradeoff doesn’t matter.
> Before a couple of years ago, it might have taken me an hour to type out and debug that code.
Are you not running and testing your code?
lordnacho 2 days ago [-]
It's just naive to say you are always going for quality. Everyone has constraints in money and time that they need to think about.
> Are you not running and testing your code?
Why would you think that?
vips7L 2 days ago [-]
> Why would you think that?
Because you’re claiming to not debug, and that you’ve gone from 1 hour to 10 seconds. I can only go off of what you tell me here.
slopinthebag 2 days ago [-]
Seems like there’s broadly two ways to use LLMs for coding - either as a way to generate the same code you would have written but faster, or as an opaque program-generator where you have no idea what the code is doing. One of these methods results in roughly the same amount of understanding and the other one radically less.
gloosx 1 days ago [-]
The OpenGraph preview image for this article is a total ragebait
lowsong 1 days ago [-]
Writing code helps me think.
Every time I read some take about keeping up one's skills when using agents people get so tantalisingly close to the obvious answer, and then fall short.
If the tools are making you worse, don't use the tools.
conqrr 2 days ago [-]
All this debate around use LLM or not is tiring and just black and white thinking.
Can I use agents to code a SWE project? yes, with nuances.
Can I write code for a SWE project? yes, with nuances.
Its more options now, I'll write code about projects I deeply care and will use llm at work where its shared slop and forced usage.
hirvi74 1 days ago [-]
I write organic code in 2026 because I do not have a choice. Which, honestly, I am thankful for most of the time. My employer has no LLM mandates nor do they supply us an LLMs to use.
In my personal life, I cannot justify more than a $20 sub per month. I only use the Web Chat anyway. Shelling out $100-$200 a month for a sub in which I would get little to no ROI is a poor choice. Besides, I've never hit the limit on my $20 a month plan either.
The day I am forced to prompt LLMs all day, every day is the day I am cashing out of programming as a career. Though to be clear, I have no opposition towards anyone that uses LLMs, and think they are fantastic tools when used appropriately. (I love them as a StackOverflow replacement, and have learned a lot from going back and forth with LLMs).
vonneumannstan 18 hours ago [-]
Arrogance, vanity, ignorance... etc.
rdksu 2 days ago [-]
exactly how many times do you plan on posting this here
> Not because agents are worse at coding that[sic] humans.
And then the whole article shows tangible reasons where the agents are truly worse at code than humans. Code never is just the text. If intelligence you have is not truly general, you cannot expect things like clarifying wider context, hierarchically ordering knowledge based on criteria and producing consistent results despite transfer learning and retraining.
And no, we are not even close to the multimodal capabilities of human brain to hierarchy encode and reproduce knowledge. Otherwise the correct "reasonable" economic action would be genociding all humans, and I'm pretty sure that this is what billionaires effectively want out of AI.
2 days ago [-]
dlvhdr 2 days ago [-]
lol what a slopper
simonask 2 days ago [-]
"Why cook food in 2026 [while McDonald's exists]?"
mikkolaakkonen 2 days ago [-]
[dead]
olsondv 2 days ago [-]
TL;DR: Write it so you’re actively involved and not a passive reviewer. Then a sign up link for his course.
FounderGod 2 days ago [-]
[dead]
marsven_422 2 days ago [-]
[dead]
fuckaiwriter 2 days ago [-]
[flagged]
cresting 2 days ago [-]
AI is a tool. Learn how to use it!
Interesting article btw
saghm 2 days ago [-]
> AI is a tool. Learn how to use it!
If you think that everyone agrees on the "correct" way to use it, you're mistaken. If you think that your way is the best possible way to use it, you're arrogant. And if you think that the way you think is correct is obvious and that everyone should already know that's the right way, you're delusional.
mikkolaakkonen 2 days ago [-]
The software factory is exactly what I'm building. The world is changing, we can either be the ones changing it or be forced to change afterwards.
jdw64 2 days ago [-]
Recently, even a tourist lost to OAI's model in competitive coding. To be honest, I haven't been able to beat AI at coding since around 5.2. People often say 'AI can't write good code,' but in reality, the quality of AI's output is layered depending on the level of the prompt input. The deeper the prompt, the better the code actually gets.
Usually, when people say AI code is terrible, it's because they either don't understand the theory well but have grown through hands-on experience and can't explain things properly to the AI, or they don't know what they don't know. Or there are the very few who are just far better coders than AI.
Some people will say they're among the rare few who can write better code than AI, and for some that may be true. But in my experience, the vast majority are not. Even from my perspective as a beginner, I could see flaws when I looked at their git code. It's a metacognition problem.
Realistically speaking, at the script level, it's quite common to see AI surpass human programmers as you increase the input level. You might disagree, but that's probably because you're a specialist in that field, deeply immersed in a very narrow area—it only holds true in that limited scope. In the general domain, most people would agree that AI writes code well.
Human programmers don't know much outside their own domain. But AI, while it loses in very narrow specialist areas, writes better code than humans across the broader range. It loses in the 1% zone (the expert's domain), but wins in the other 99%. Usually, when that's the case, you have two choices: become the 1%, or learn how to use AI.
Since I'm a non-native English speaker, I'm already at a disadvantage compared to native speakers in programming skills, so I chose the latter. But I still code. Not for any other reason—if I don't maintain at least some typing muscle, I won't be able to review AI code properly.
That's why I think coding is essential. Even if I can't understand the entirety of AI's output, I still need to understand the core business logic. At the very least, the core logic requires human understanding, so coding is necessary.
rossant 2 days ago [-]
I don't write code anymore, because AI writes better code than me. I could write code, but the next AI would find 10 ways to make it better and more consistent with the rest of the AI-generated codebase. So I just let it write all of it. However, I inspect it all carefully and I constantly asks it to reflect on the code quality, to refactor, to reorganize, to make the code as good as possible. The end result is code that is much better than anything I could have written myself.
And I should mention that I have 30+ years of programming experience.
nevertoolate 2 days ago [-]
Can you explain what you are working on?
I’ve stopped using llms to generate architecture, which i design and write myself and let the machine pattern match the gaps. I also use it to review issues which I lot of the times push back against.
I’m working on a stateful application sitting on top of a data warehouse and have to implement a stream of messy half defined feature requests and navigate on top of an ever changing infrastructure layer. LLMs rarely get the infra layer even if it is written as code and have hard time grasping how to deal with tech debt, when and how to re-architecture parts of the stack or even implement stuff based on a detailed openspec design.
zelphirkalt 2 days ago [-]
How do you improve, if you don't write code? How do you aim to close that gap, that is the 10 different ways of improving your code?
And if you don't aim to improve, how do you deem yourself capable of even reviewing AI code in say 3 to 5 years, when your code writing skill has fully atrophied?
newsoftheday 2 days ago [-]
If AI is generating better code than you can, that does say a lot. I've tried various AI's available and outside of being a better Google or a fast reference for Stack Overflow; LLM's do not generate better code nor better running code.
2 days ago [-]
jdw64 2 days ago [-]
[dead]
jdw64 2 days ago [-]
To be honest, as you know, background knowledge is extremely important in programming. As you move into complex domains, the specifications multiply. So as a domain gets more complex, there comes a point where it exceeds my cognitive capacity. And that's when AI surpasses me and writes code I can't keep up with.
Usually, it produces code that would take three or four humans days to figure out—in just 20 minutes.
Even the professors and PhDs who hire me all use AI. Honestly, they hold PhDs and professorships, which puts them in a league I can't even touch—and even they use it. AI just does it really well.
Honestly, I learned from your book, 'rossant'—I never expected a programmer like you to say something like that. I thought my perspective was because I'm only an intermediate-level programmer. But you're in the 1% expert category I mentioned
nmehner 2 days ago [-]
"The deeper the prompt, the better the code actually gets."
.... and in the and you end up with a very deep prompt that exactly specifies the behavior. This is what a programming language is.
I'd rather describe a data structure in a language designed for this task, than a prompt the might be interpreted in many different ways.
jdw64 2 days ago [-]
[dead]
zelphirkalt 2 days ago [-]
In my experience AI often overlooks generalizations of ideas iteratively arrived at. I need to give it the idea, that something could be generalized and nudge it, to arrive at the solution.
I imagine at competitive coding the goal is quite clear, but in a real world project, the goal is not always so clear, and especially in hobby projects the ideas and goals are not that clear. I get inspiration on how to improve my project or its usability, not the LLM. I instruct it to do something a specific way, because it doesn't do anything on its own, and I need to tell it what to generalize, which it failed to see, because it didn't consider a simplification which is technically less precise, but due to user context and human nature doesn't matter (in this case it was interpreting "now" to mean the current second, which is a small time range, instead of a mere point in time).
So it still takes a ton of hand holding in a more open project. I imagine, one could also code it up in the same amount of time. But it is good for generating tons of test cases. Though one will have to review those, and impose a test style on them, give examples and so on.
jdw64 2 days ago [-]
I agree. In fact, that's precisely one of the hardest parts of programming. Your thinking aligns with mine. I do a lot of equipment programming for factory delivery. I've even delivered an MES system before, to be precise, it was migrating a legacy MES to a modern version.
Beyond hobby projects, most clients often don't really know what they want. And that's generally what we call domain modeling. This is definitely an area where AI is weak. As you know, it mainly pulls from generic patterns.
When there are specific constraints, AI struggles with core business logic. And as you said, it's also weak at choosing the right direction or the goal to pursue. But as you also know, 80% of programming is built on what others have already created. Originality is only about 20%. And in that 80%, AI is absolutely dominant. I agree with you and I've upvoted your comment.
I really like your perspective
h2aichat 2 days ago [-]
It seems to me that AI won the code Battle and that humans are just trying to justify the defeat. I will relax and wait for the Next AI generation to see how it fixed its problems. May be, everything will be ok.
ataru 2 days ago [-]
I've got a coin that answers questions. You have to give it a heads or tails query, then flip the coin, and it returns an answer. It's incredible. Now, it doesn't get the right answer every single time, but we're all learning how to use the new coin technology, and this is only the first generation of coin. The next model of coin is going to be even better. Soon we're not going to need humans any more, for any question we have, we'll be able to use the coin.
yard2010 2 days ago [-]
I have a coin that can tell you whether a program would halt or not. But it's not always right. I think it's a coin like you have? Still trying to figure out how to use it to prove that p=np.
JackSlateur 2 days ago [-]
Even a broken clock is right twice a day :)
invader 1 days ago [-]
So, the developers have finally found their Silver Bullet?
I've seen so many of these already. It would be hilarious to see Brooks proving right once again.
I'm as hateful of LLMs hollowing out the job market as the next guy, but the reality is the frontier LLMs are really good at writing anything that's been done and documented on the Internet a million times and unfortunately most of what software devs have been doing the last couple decades is shitting out cookie cutter CRUD apps.
I have my doubts about whether the state of the industry is going to advance as long as we're having LLMs do all the creation, but that's another diatribe.
WebAssembly is slightly easier than real assembly, but here Fable used WASM GC extensions, which are poorly documented and not yet super common.
Fable didn't even need to debug it; I believe essentially all the assembly worked correctly on the first try.
I have feelings about this, but I'm not pretending it isn't real.
But it's not that much simpler. And once you add the WASM GC stuff, WebAssembly gets weird. It's a Harvard architecture with separate value memory, linear memory, GC memory and "tables", all accessible in completely different ways, with a weird mandatory type system (especially for the GC stuff). And the docs are often terrible. And yes, I've also written WebAssembly by hand.
So yes, I would, overall, classify WebAssembly as "slightly easier". But not dramatically so. And the training data for actually writing non-trivial things by hand isn't that great, not compared to something like Intel assembly.
(Don't talk to me about TI320C40 assembly. If Fable can one-shot a Prolog interpreter written using that without finding a reference manual, it's time to hang up my hat and learn to make goat cheese.)
Much cheaper than a human software engineer. But comparable to the wages for some human workers.
ROI won't make itself up.
i've been curious about the feasibility of this concept for quite some time and now i have an actual example to study and measure and hack on, for a fraction of the cost of my pro sub. it wasn’t trivial, i doubt a non-swe could get it done in that time, but i'm a pretty happy customer overall.
so you don't know if it works properly or not
I am honestly not happy about the way that models can now just take what should have be a fun multi-weekend project and knock out in a couple of hours. But I'm not going to pretend that Fable is stupid, or that it did a bad job on any of the test projects I gave it. It struggles more on big, messy real-world code bases, absolutely.
As I understand it, there's post-training step that does exactly that, they get real developers to select good and bad code and help the AI figure that out. AFAIK it's the reason why Claude was able to leap-frog OpenAI in coding last year, they did this refinement step a lot better.
And now they've taught the older models this, they can use existing models to bootstrap the newer models without humans involved, and bring humans in to just assess the trickier stuff.
At first blush, it seems achingly obvious that position 1 is true, whilst position 0 is a false play by con artists.
Well, at first blush I agree! But first blushes are notorious for being famous last words (blushes).
You see, we always knew that the tool shapes the hand. That is, as we use computational (discrete) devices, we ourselves become more computational, discrete.
But what we did not anticipate is that the tool would fool others as the ACTUAL HAND. I am so fooled. Daily.
My friends. Does technique encompass being? Answer me this!
I suspect that despite its translation abilities, this is true, but I'd like to see it do things in languages that are more or less appropriate for tasks to see how much the training corpus matters vs. its ability to translate. Assembly is a bit of an extreme example because you're either writing it as close to C as possible (C is essentially portable assembly) or you're writing complex, unreviewable code that happens to work. And who know if it's been trained on register allocation, or resorts to doing everything on the stack because it works.
Not really, assembly shows you what the machine instructions actually are. In C you have loops, functions structs. All things that make no sense in assembly.
> In C you have loops, functions structs. All things that make no sense in assembly.
One can reasonably infer that a loop will roughly translate to some type of conditional jump instruction. Function structs are just pointers and call instructions. The former point was that there is little runtime getting in the way of how the constructs could be expressed, and a long time ago it may have been the truth, but not for modern compilers.
Then you don't have to litter all of your if/else clauses with hundreds of memory frees and cleanups - you just "goto"
The fact that this is controversial to some people just shows how rules like "Dont use goto" become stupid - if one is trying to make code simpler then there are cases were not using it is the more confusing and error prone choice.
As for "can we now do anything" well if you don't ever need to debug "anything" then yes and if you have any small doubts about your LLM then no.
I wonder about this: Does LLM write better code in a better language?
Humans often have more difficulty fixing existing code than reqriting it from scratch, and un-structured un-constrained code would be a big reason for that.
But maybe it doesn't apply to an LLM if it always rewrites all code from scratch?
The whole point is to rewrite everything in a language you don't understand and then ignore whether it's better because you can't tell.
That language, of course, must be Rust.
Without a revolutionary new platform to build apps on that no one has ever developed for before, there is basically no reason to believe there is any software left that has some business or economic value that hasn't already been written.
This is a really good idea for completely different reasons. :-)
We’ve created software for virtually every place we can put software. There’s nothing new.
It’s like bridges. We’ve seen all the ways bridges can be built by now. There’s nothing new left to discover.
It's the end of history. What could we possibly discover about a series of technologies that are already nearly 100 years old now?
I've heard people say that various things are "solved" now because of LLMs too -- programming included. This implies we've "solved" thinking. I'm worried about these sentiments.
https://en.wikipedia.org/wiki/End_of_history
It’s also a bit ironic to imagine that we’re at the end of new software ideas on a site owned(?) by YC.
Personally, I think we've already reached that point.
Even at YC, I have not really seen any startup doing anything interesting where their main value prop is enabled by new proprietary code that does stuff no one else can already do.
With the current ongoing revolution in home manufacturing (starting with 3D printing; currently there is a lot of work done in home CNC machining), it would be easily possible to get a huge leap towards "print your own car".
The reason why you see nothing of this is basically red tape.
I'm disputing this. You can have a training corpus in assembly as big as any other language: just feed the compiled result(in assembly) of the CRUD apps to the LLMs.
There's more to it than that: writing is thinking. If you stop writing code, you aren't thinking anymore.
Many argue that they're now thinking at a higher level (maybe they weren't before?), but, guess what, that high-level design can be done better by the LLM than by you anyway. It's only temporary.
A lot of people observe that their thoughts get better when they do the work to write them out. It's not just a straightforward encoding process (as maybe a software engineer would conceive of it).
E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
This is a poor argument. The trial and error is the LLMs trial and error of your intention (ironically driven by you), not your trial and error.
It's like saying "It wouldn't matter if I instructed an LLM to solve my trigonometry problem or if I wrote the the solution myself; either way I'm learning trig".
> E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
What exactly are you needed for in this scenario, other than saying "make me $PRODUCT"? The LLm is going to be a lot better at architecture than you are. Your role is limited to A/B testing the result for human use.
I kinda [wrote about this before](https://dielsonsales.github.io/2023/05/11/starting-a-new-blo...) but the takeaway is that writing forces you to structure your thoughts, giving them a final shape and enables you to notice flaws or gaps in your own thinking process. It’s impossible to do this without writing.
As to your post, I think rather than writing it's the act of pressuring yourself to figure the thing out that is making you more knowledgeable about the thing.
You are putting it out publicly out there so you really want to be certain that you are correct, and therefore you do a lot of research.
If you wanted to be accurate and prove a point, the motivation mechanism could vary, but also the eventual communication mechanism could vary. It doesn't necessarily have to be in writing, it could be a live debate or simply something else you built. The writing or the product are end product, but the process of wanting to produce something is what made you research and to understand.
You could be writing to yourself into a Google Docs, and not care and you would not go deep to research since there's no incentive to be accurate.
E.g. I could be doing a home project whether hardware, software or DIY, that in order to produce this output I have to learn and think. Similar to as good set of words to communicate some idea. But also I could build some slop without thinking and I could produce slop writing without thinking, and about nothing special.
Humans have been thinking long before writing was invented. Why is code special?
And look how poorly they did it until they invented writing.
> Why is code special?
You don't get better at thinking without doing. With code the "doing" part is writing.
In your view, it is reasonable to expect HS students to thoroughly read a book on trigonometry and then ace the exam? We know, from experience, that only by doing problems does the student actually learn. We also know that when you stop doing problems the facility atrophys.
Why is code different?
How can you know how poorly they did it?
Their lack of progress. Humans existed in the same basic form for around 100k years before they finally invented agriculture, which led to some improvements, and then rapid progress once writing was invented.
https://pmc.ncbi.nlm.nih.gov/articles/PMC3917328/
IOW, hunter-gatherers follow the best habitat, so controlling for habitat is always going to have the conclusion this paper reached.
I'd be very interested in other studies that support this conclusion; after all, that's how science works - a single study proves nothing if many studies conclude the opposite.
While I mostly agree with this notion, given that all of our understanding of human progress historically comes from writing, there's a selection effect happening here.
Like, why do we talk about the Dark Ages? Because there was less writing, so obviously things were terrible.
There's a bit of a selection bias there, because writing itself is used as a measurement of progress.
But, ignoring writing as a measurement of progress, we can pretty much see that for about 100k years the only tech were primitive tools.
Even after the domestication of wolves (about 40k years ago) there were no visible improvement in tech. After agriculture (10k-12k years ago, maybe?), there's visible progress in tech (tools), but not by much, and visible improvement in societies (also, not by much).
Enter writing - those civilisations that had more advanced writing progressed rapidly, and those that did not barely progressed at all, tech-wise.
Because not all civilisations progressed at the same rate, we can see quite clearly that writing is highly correlated[1] with progress.
---------------------
[1] While correlation does not imply causation, as the data mounts it lends more and more weight to the causation bit.
That's a big "If". The observation we have is that civilisations that never invented writing simply died out with no tech-tree advancement; and this happened for 100k years at least.
We've got 100k years of "no writing, no tech". We've got around 5k years of "with writing came tech".
The actual tech to write was there for much of the 100k years (cave art), but without writing, the tech never improved.
> How can you know how poorly they did it?
You could probably get some sense by comparing illiterate people to literate people.
>And look how poorly they did it until they invented writing.
Yeah, look how poorly they did it until they invented writing.
[peers into the dim ancient past]
Sorry, my time-machine spectacles are on leave or on strike today.
And congrats on being a multi-millen(ium)arian, and a mind reader, who could both 1) exist so far back in the past, and 2) be able to know the thoughts of people who didn't write them down, because they didn't know writing.
/s
Each last for a different amount of time and you generally can’t write or even read anything. But in my personal experience, all three lead to solving the most difficult software problems.
When writing, thoughts become forced and linear in my view as opposed to floating in a specific way from point to point. Like I lose the natural creativity.
Writing is about remembering or communicating, so it is summarizing the thoughts, but it is not thinking itself, it is more so thinking about how to communicate efficiently or how to make a note so you don't forget. It is not creativity for me.
Kind of imagine building an idea in your head while running and then you write down the summary of it.
When I sit down to try and write them down, I blank out. Or the thoughts that I thought were good/useful, I second guess when writing them down. Perhaps it's just lack of practice on writing them down (I'm trying to use a typewriter to do so recently).
Some people find code easier to read than the English description. It’s more precise and many experienced devs can scan it and know what’s happening
Many other people can’t read code. Or they find English easier to read than code.
Thats not a knock on anyone. Maybe the latter will rule the world because the former focuses too much on irrelevant details. Or maybe me there are just different types of problems that need differing levels of attention to detail.
How can you be sure that's what the code the LLM wrote actually does?
Less about “trusting” the llm and more about how complex it is to work with binaries due to machine code being different per machine and hard to interpret the context of the code as well as offsets.
In that sense because high level languages come with the ability to add context to what code does. It’s like the understanding a human has when given decompiled C code ghidra gives you vs C source code a developer wrote.
Also the compiler helps the llm write “compiled / working code”, if it just spat out machine code it most likely not even run at all.
But yea generally if you can’t write code at all, reviewing it is even harder.
No, people do advocate for this. It may simply not be as portable however as something that is high level able to be compiled to assembly for many machines.
Why review it at all? The trend is to vibe code everything with agent harnesses and tokenmaxxxing.
Not all software is mission critical. But some software is.
However I do think there is reason to use Java or Python (as much as I loathe both) they have GC, and it'd be a lot easier for AI to fuck up memory safety in something like assembly or C.
One has to program computers to be a computer programmer. If one just prompts LLMs, they are a software prompter. I think both can fit under the title of a software developer or perhaps even software engineer.
by writing code by hand - you're the author & editor at the same time.
if you're skilled enough - you quickly get to the desired state vs the llm which while might produce a lot of code - but it likely won't give the end state you desire.
an analogy - Jason Fried gave - producing software by llm's is like bragging you're a photographer by pressing the shutter button on an automatic camera.
while the art of photography - is about producing the single perfect photo - that communicates the photographers intent (what they want the world to see & experience).
likewise in software - what we make should be deliberate.
Yet...
Thirdly, compilers also do type checking and other static analysis and dynamic checks (array length etc). So it's not only got more guardrails against "mistakes" by the LLM, but it's also most likely "easier" for the LLM to "reason" about (in the sense that LLMs can reason).
There's no intrinsic value to having humans read the code, so as soon as LLMs are good enough to work on their own, companies will no longer need to keep developers who can read code as a backup solution.
One time, something didn't work as expected - its the first time it happened with this project. I read through the section of code and it was perfectly readable and well-written.
Turned out a plugin wasn't effecting the audio, so i just got it to pad some blank audio onto the beginning before processing it, then remove it at the end of the process. That fixed the issue, there was nothing wrong with the code but my ability to think laterally is what made it work.
We're getting to the stage where you can just ask them to write code and they will do what you want, and it writes good code. Its up to you to test everything beyond the internal tests it writes.
aargh! haalp!
Which rock are you living under these days.
Nowadays everything is IR or MLIR ... or AIR ...
whoops, i may have skipped a few generations. hard to keep up with the dynamic pace these days. got a job to save. sorry suh.
mumble javascript mumble framework of the half-week ...
walks off muttering
I'll byte the bullet.
Hang on a bit while I register that in my memory.
>generate x86 and ARM
So that hardly anyone can review the machine language output, I guess.
HN users' minds be like:
87.654321 %: JS? yeah. mainhipsterstream. gotta be a part. heart.
smaller %: Rust? wannabe. donno how, u c.
much smaller %: C? oh no ... numeric underflow.
Congrats on moving over to the light side.
I don't write code anymore and I doubt I ever will ever again.
On the flipside I review exponentially more code than ever before.
>Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much
It's not "not trusting" the llm its that the llm has been undergoing reinforcement learning is on coding. Plus generating assembly is extremely token inefficient.
However, that would just make the difference in productivity between junior and senior developers even more pronounced! It’s really difficult to see how things will play out in the future without junior developers disappearing, causing a slow death of the profession. LLMs will probably never be good enough to do everything a developer needs to do: understand and improve or clean up requirements, consider future needs, test outside the box, evaluate performance and decide where and when to improve it…
Code. It’s called code.”
- CommitStrip (https://www.reddit.com/r/ProgrammerHumor/comments/1p70bk8/sp...)
I think if you’re doing it right, the core of your code should be the simplest expression of the underlying business logic. Of course there’s always going to be supporting layers, and maybe those don’t need to be reviewed. But if you haven’t read the code, there’s an extent to which you don’t know the business logic.
It’s ok to talk to the agent in code. Or create examples for it to follow.
https://softwaredoug.com/blog/2026/07/04/write-code-not-spec...
Code is executable. Specs are not.
"Please print 'hello world'"
It's IRP.
https://esolangs.org/wiki/IRP
If you're doing this, then why not just write the effing code?
First you write a programming language in which the language primatives are the business logic primatives, then you write a trivial program that describes what the business does in the new language.
I guess the funny answer that is behind this sentence is: You have to train your own mental model. We always argue about code in a very abstract and logical manner. But when coding the subconsciousness makes most of the decision ("this just feels right"). But for this to work you have to train it. And this does only work in a very limited way with code reviews or reading documentation. It requires repetition and deep focus.
When there is an issue in production with this mental model you will be able to point to the cause of an error message instantly. With generated code you'll search for a long time with your slow, conscious part of the brain.
For LLMs to be really helpful, they have to take over complete maintenance of the code. So you can treat them like an external library: Just assume it works. Otherwise this will always be problematic.
We already tried this with humans. It works so poorly that it got the derogatory name “ivory tower architect”. It usually results in theoretical designs that are unworkable in the actual system, implementation teams (or LLMs) that work around the architecture and a lot of slowing down of velocity as the architect and implementers argue past each other.
The observability people will claim that if the dynamic runtime behaviour of your system makes it hard to find the source of a behaviour, your system must be made more transparent and observable. They would also claim this was always the case -- we should never have relied on people's mental models being amazing because people move around.
(I don't know yet where I stand on this but I'm trying to learn more.)
But currently e.g. I am working on an MES/Scada layer that integrates data from a load of different machines in a factory. These machines are from China, Korea, Germany, Sweden ... Upwards there is an ERP integration (and some other systems).
Sometimes machines are updated and suddenly behave differently. Giving error messages in Chinese.
The ERP has the nasty behavior of returning error messages where it is not clear whether the actual processing actually happened or not. There are some heuristics on parsing the error messages, but these also change with new versions.
Sometimes one machine overloads cloud infrastructure and completely unrelated functionality fails.
Sometimes the on-premise network stops working for whatever reason and data is lost.
Sometimes operators do not understand a perfectly valid error message like: "The batch you loaded into input position XY has expired on XZ and cannot be used for production": "But we have been told to use it..."
So when you get called out at night, because the production line stopped and "MES is displaying an error message", it is mostly about finding out what integration failed and who else to wake up. Getting this right is very much appreciated by your colleagues.
And this is where you need a mental model of how things are connected, what error message happens because of what external causes etc.
Observability can only work perfectly for known problems. In a complex system for unexpected problem you can either provide too much data, so analyzing it and finding the relevant part becomes really hard, or too little data which makes finding the issue impossible.
There are so many companies claiming to provide the perfect observability solution and there are certainly solutions that help. But it is all very far from perfect.
Not relying on people is managers wet dream. And for a lot of people it might be true that they can be easily replaced. But for complex systems there are always some key people that you cannot replace without causing issues.
By having an understanding built during their entire career.
Right now we live in a fairly-land of mixed capacity. LLMs being used in parallel with skilled people. But as time progresses, there will be no more skilled people, because no one will learn and develop those skills.
If you're in the world of LLMs now, you are basically completely stalled in your personal growth in this field. You will never improve, and some seem to say they lose capabilities as they rely upon LLMs.
The world always changes. But the decisions being made today, are being made by skilled people.
What will the world look like, when it's just all "bro, lol, just tell it to make your thing" and then done?
Most code out there isn't all that great. I've been in this industry since the nineties. There are a lot of not so great software engineers doing mediocre work. People are romanticizing how great and magnificent their code is (or used to be). The reality of manually crafted code is of course a lot less flattering. Many code bases become hard to maintain over time and are riddled with bugs. And it's not like sloppy code is a new thing. Poorly executed software projects have been very common for a long time. That's not going to go away.
Spending a day manually reworking the architecture in my experience can save you $1000s in tokens and weeks of headaches.
We’re trying to build a software factory with hands tied behind our back
Yeah, and they are all producing 10x as much mediocre work now.
Hopefully companies in the industries where software quality matters and is regulated, e.g.: medicine, aviation, nuclear, etc.
Although this market is relatively small.
I actually think AI based automation is going to be a key enabler in those kinds of strict environments as well. Recent work on identifying e.g. security bugs seems to be resulting in a lot of improvement that has somehow escaped decades of human scrutiny. With good quality harnesses (manual or automated), I don't see any big objection against using generated code here.
Writing some code with the whole context in your head is the human advantage.
I’m not precious about that code. Maybe it needs to be rewritten by an agent. Or we could build good abstractions so it’s trivial to see the system. We could also use systems that by their design force us + agents away from security, performance, etc
A human coder might OTOH follow the Boy Scout rule and clean up as they go.
Peter Naur explained this decades ago
>Peter Naur argues that programming is fundamentally a human activity of building a mental "theory" - a deep conceptual insight into how a system's parts match the real-world problem it solves. He rejects the prevailing view that programming is merely the mechanical production of source code, specifications, and documentation. Instead, Naur posits that the true product of programming is the shared mental model held in the minds of the developers who built it.
As a human you're the one with the problem you want code to solve, so it's worth having an understanding the problem. Otherwise you risk an X/Y situation, where the LLM ends up solving a problem that may not actually satisfy what you need.
I think what LLMs allow you to do is better abstract away everything that's _not_ essential to the problem you care about, in the same way that libraries or any higher-level programming language does. Ultimately there's still a "core" of the problem that needs to be expressed formally though. When you see people "vibe coding" by prompting the LLM to add constraints at a time until they reach their desired end-goal, this is ultimately "programming" in a sloppy, non-formal way. Better to get the LLM to write everything else _surrounding_ the problem, so you can write and understand the core yourself.
As an example, if you chat with an LLM it can sort of explain concepts it learned in its training, because it created some internal representation of them. However it’ll never be able to explain things about your project unless you tell it (then it can simply repeat it, which is the same RAG does, the LLM is just spitting it out without any deep understanding of it).
You can try to cram as much context to it as possible and overload it with extra information, or you can understand this difference and separate a task that you know the LLM can handle because you’ll be able to leverage its knowledge and judge the final work yourself.
But this distinction needs to be more clear, I think. The LLM doesn’t have any deep understanding of anything you’re creaming into the context window the same way it does with concepts it learned during training from millions of examples and building some internal model of the concepts and their relationships.
I second that and I can give an example that happened to me yesterday with a totally SOTA model (a US, not Chinese model).
I needed to display an information on the client-side. Something trivial. I ask the LLM to do it. The thing went onto a rampage: it somehow found a way to pass the information from the server to the client during the initial handshake (already: why, just why?). Modifying both server-side code and client-side code. And it worked.
To an unsuspecting programmer/tester (or automated test)/user: the info is there, what was asked has been done. So it's perfect, flawless LLM victory right?
Except none of that sloppy-pasta was necessary: the info was already available on the client-side and was a one-line change, purely client-side.
These thing shall definitely, as of 2026, write way too much code.
And btw the companies selling metered tokens have a very serious incentive to produce the most complicated, rube-goldberg, solutions that use as many tokens as possible, while still kinda solving the problem.
That way not only you consume tokens to produce the code, but later on you consume tokens when working on that code (which btw is a guaranteed thing: for the LLM just introduced new bugs in that gargantic amount of crap it output).
Funnily enough the very same people who made fun of copy-pasta happen to be in love with sloppy-pasta. Go figure.
Yes, it's in the rules; run profiles, check code coverage, do a critical review, post the report and follow up tasks. 90% of people I've worked with did not follow these boy scout rules nearly as well as today's frontier LLMs.
Is the author implying this is bad?
> Agents bias to making the current change as safely as possible. I had a situation in a previous codebase where one morning, pre-caffeinated, my meat brain mentioned using browser local storage. So some random state was managed in local storage. Everything else through a backend database. When I looked at the code, the amount of wrapping and indirection to preserve this idiotic human mistake probably tripled the LoC. Agents can amplify our one-off bad decisions by being so conservative.
You can of course solve this many ways. And many of boils down to just how a particular humans brain works. Some will solve this by not reading code. Some will read / write code.
Whatever works for you is great. But many there is upside to the precision of not having code intermediated through the LLM for many.
I'm sure plenty of meat humans out there would make the same mistake (sorry, you said to use local storage boss!). You might give them a scolding. And maybe document that policy. Maybe in a markdown file for the next person. IME the latest models are significantly better than the median engineer at following this feedback.
I don't think it's fruitful to blame the LLM any more than it is to blame someone working under you.
In fact I would say this is an excellent example of how engineering does NOT fundamentally change in the era of AI.
In this case things mostly sorta worked and the simplest way to see the problem was look at the code. And try to take it apart a bit to see where the problem was.
I felt I arrived at a better pattern I could trust that the agent could use much more efficiently this way than asking the agent to do it. I could then test that the pattern was being adhered to and therefore better trust the agent not to go off the rails.
I personally internalized the details a lot better by doing this writing. I wouldn’t have internalized it - or more likely played whack-a-mole - by guiding an agent.
How do I arrive at the patterns to check for without exploring the code? And capturing a real failure case?
You don't!
Have you tried adding rules/automations that make it explicit to review and fix the code for bloat (per your taste, with examples if needed)?
With this setup + a good frontier model you will never have to be on the lookout for code bloat. You can even get the agent to send you text message with the LOC-- if it makes you feel better.
I think I understand where you're coming from, that it's hard to "let go" (I've been coding for 30 years and it was hard for me). That's why I'm recommending to have agents write verifiable quantified reports of the things you care about, so you can build up some trust in the agent's work and you don't have to do things by faith.
How do you establish sane patterns when you’re in an exploratory /architectural mode? You could do this in English, sure, but many of us do this more efficiently and precisely in code in a way that lets us be careful, internalize details, and add measurement + QA to ensure it’s adhered to by agents or humans.
I’m not saying to write all the code. I’m saying it’s useful to write 5% of it. Then let an Agent stamp out / rewrite the rest
100% agreed. And it leads to far better LLM output and lower token usage, too, I find.
I noticed this phenomenon way before LLMs came along. Some people would put a halo around a particular technology and blame everything around it when something went wrong.
I feel this statement these days during code reviews. I know some amazing engineers whose output lately just isn't the same.
Because AI generated code is STILL complete ass. Even Fable, even whatever custom Pi/opencode leet code harness you have, the output is awful, and, if you cannot distinguish the quality of your code vs the AI's, I've got some bad news for you.
And I'm not saying this as some sort of AI maximalist. If progress keeps up, I seriously doubt software engineering and development will, as we know it today, will be a thing in the next 5-10 years. Maybe humans will be left with designing the UI, but everything else will be abstracted away and AI will be doing all the actual work behind the scenes.
But then you realize software is the accumulation of 1000s of wishes. And you want this but not that. Many little micro decisions of exactly what you want in every nook and cranny.
In the current paradigm (LLMs) we still have to manage all this. But maybe in the future we have something impossible to imagine.
& I think it’s fairly demonstrated that the industry isn’t profitable for training ever increasingly huge models, which get exponentially more expensive each iteration
And maybe we'll get something like a Mad Cow Disease, when AI "eats its own brains". To avoid that from happening we will need continued human inputs, and review.
And then it feels like a chore slogging through whatever it produced to verify it is correct.
Only that businesses have decided it is OK as long as they are benefitting to steal from everyone else, and basically force us to be the acting hand in all of it, or threaten us with starvation (no job, no income).
Same.
My difficulty is that for the past 8 years I've been working for (tiiiiny) SaaS business where I don't have anyone I can simply ask in-person "hey, can you show me how to 'do' all this newfangled AI agentic team coding?"; so my only direct-exposure is with the painful Copilot sidebar chat, which I now find myself allergic to.
So let's see elsewhere: while searching online for some (reputable) "agentic coding courses" my results are for the same kind of people who used to run those dodgy coding-camps from 10 years ago. I'm having difficulty finding resources for practicing SWEs like myself wanting a continuing-professional-development course experience, not a get-rich-by-buying-my-course video library from a contemptable AI booster
Even more surprisingly, my local major university (UW.edu) doesn't seem to offer any certificate courses for getting into agentic development either[1] despite offering courses on C++, Six Sigma, and actual ML/AI courses. It's maddening. I can't be the only one with this problem...
[1] https://www.pce.uw.edu/search?type=certificate&programType=c...
See how it fails or succeeds. Look at the supported features, try them out, think about how you might use them in your workflow.
Before you know it, you'll be proficient.
You have to learn how to self-teach.
Doesn't have to be stressful. Plan to throw away whatever happens. Do it in a VM if your nerves demand it. No reason it can't be fun.
...so I've been avoidant of the whole thing ever since 2023, burying my head in the sand to avoid those feelings of anxiety and uncertainty-about-the-future, and it now makes it difficult for me to engage with the topic head-on.
I dove in in ~2023, and I'm about as deep in it as one can be. The better I get at it, and the better the agents get, the less time I spend even doing what I do - one prompt will often take 3+ hours. I often keep 8+ agents churning for the whole workday (and leave them running when I leave, too, and it's very often that they'll work from 4pm to midnight or later). I was responsible for 499 commits last week (very little new functionality, though), and I felt pretty useless at the end of it. I keep thinking I should code something, because coding feels productive in comparison, but going by results, it's pretty far from economical to write code by hand, and quickly approaching as bad as shipping goods by foot.
So far in the LLM coding revolution I still feel like it's software development. I just work with systems on the level of features and architecture instead of flow control statements. Some day we might lose that too, but I think it will take a while.
[1] https://www.youtube.com/watch?v=-BhfcPseWFQ
That's kinda at the level I enjoy though - where I get to think-through things when figuring out exhaustiveness and correctness; introducing refinement-types into a codebase that's previously nothing but ints-and-strings; and trying out new and cutting-edge language-features directly.
I know I can prompt Claude etc into trying to do those things, but from what I've seen from other people doing it the result is somewhat of a mess - or just plain inelegant.
-----
May I ask how well Claude/Copilot/etc works with FP languages instead? So far - and back in early 2024 - I've only messed-around with asking ChatGPT to generate Haskell programs and the results were hallucinated gibberish.
Maybe that's "enough" for the business to survive. But it surely won't be the reason it succeeds. It can still succeed for other factors though, but the business has given up on one path to success, which is making better software than the competition.
Why are you building a software factory though, and why weren't you immediately adding CI to every project?
> It’s our job to build the software factory - not just the software. Software engineers maintain the assembly line allowing anyone to prompt for a change and ship immediately.
Again, why? Where are you working where this is considered a good idea? This would mean that the software engineers are not just being completely kicked out of all business decisions, but asked to build a moat that ensures they stay on the other side of it.
Any business that intentionally devalues the insights gained through implementation will eventually starve itself to death by making too many passive thoughtless moves. No insight will ever be gained just spot checking AI. Is their intention really just to make tiny amounts of profit while riding the thing into the ground? Crabs in a bucket, man.
The job of the software engineer increasingly becomes to make himself unnecessary: to empower the nontechnical business users to do as much as reasonably possible, without his/her intervention.
This has, of course, been the dream of computing, since its inception! And the true aim of every "high level" or "beginner friendly" (looking at you javascript!) language.
But finally, now that the computer actually speaks English (and is beginning to stop making completely insane errors), it gradually becomes feasible.
Freeing the masses from the tyranny of the nerds!
A specification detailed enough to control every aspect of the resulting product is called a program. Compilers are AI. The prevalence of compilers hasn't harmed the programming industry at all, quite the opposite.
This isn't really the point of your comment, and for that I apologise, but: not all of us did that. For many good reasons, too.
This isn't really the point of your comment, and for that I apologise, but I still haven't gotten used to speaking about what we "used to do" in the past tense, as if we are in a post-programming world...
We are already starting to speak of the habits we used to have (or not have), how things used to be done back in the day (1-2 years ago).
I don't think you're wrong to do so. I find myself saying it sometimes too. Just an observation about the weird world we find ourselves in.
I would argue that SO is basically “done”, though. For better or worse.
I still write code by hand. I use LLMs too. Weird world for sure.
Speak for yourself. A lot of people have great abilities at designing "dynamic architectures" and anything else an LLM is used for. It sounds like you don't realize that an LLM is only capable of what it does because it was trained on human-written code.
It's even got a name: sloppy-pasta.
I mean you're basically saying it is a good thing if the LLM messes up so you have a reason to debug the code.
My brain feels equally as exercised (in fact more so as I am not as good at agentic coding as I was at real coding)
But now I'm making highly polished Mac OS apps and I really like that move from JS.
I feel... conflicted.
So, making a real time collaborative tool from scratch there was a lot of deep work in things like sockets, queues, memory structures, etc. That's just what needed attention.
Right now I'm building a memory app for AI.
So far I haven't spent much time looking at code on the swift side of things. But I have spent a lot of time up front working on domain driven design, screaming architecture, and module based design.
I think with AI the polish is in deep QA, design taste, running trace logs and constantly asking it to do html diagrams of the architecture and such.
ngl I miss "knowing what's going on" at the code level, but it feels like not a good use of my time to go into those weeds.
When I look at the code it seems well structured due to screaming architecture, and module based design.
fwiw I think the rationale behind it is counterproductive because the only difference between a OP submitting their article link and someone else submitting their article link is internet points.
This was actually my original submission last week. There was a front page submission last night from someone else (hence the comments). Then my old post got re-upped just now (1 hr ago)
Every time you work in a complex software project, you have all the context in your head about what you must take into consideration. LLMs don’t, you have to explain every little detail to them, but there’s no telling where it stops: do you have to explain X to it or is it in the training already?
When you try to shape how a LLM should behave and what it should know, you end up writing a Bible of relevant context that’s increasingly difficult to maintain as well, often with outdated or contradictory information, and it is still free to ignore things you have written and proceed however it wants.
That’s why so many people only feel comfortable giving the LLM some limited task to do, because you can judge if that specific task needs just enough context that it can handle by itself.
So I took over an open source project called Omnivore. It's a reading app in the vein of Pocket. The hosted version used pdf-lib to inject some functionality into the pdf viewer. Namely, highlighting, note taking, and storing location. pdf-lib is a licensed application, so when taking it to fully self-hosted this needed to change.
I migrated it over to pdf.js. And I went through the entire process. I added all the functionality bit by bit. It didn't take exceptionally long, maybe 1-3 days. But that process was really satisfying. I found a bug, fixed it, and then found a stackoverflow issue where someone was also experiencing the same issue and suggested the fix. https://stackoverflow.com/questions/59151218/pdfjs-error-on-...
I'm pretty sure an ai could have done all of this. And therein lies my fear and my upset with AI. Not only would it have robbed me of that experience, but it shows that I have in a way been devalued. Because I do think that took a level of skill. And now that's gone...
I’ll be very curious how / if the Bun port to Rust works out.
I spend time building AI Agentic guides and skills, then review the code myself. I really miss the old days when you put your headphones on and focus for 3-4 hours
Recently I am seriously thinking the time when agent do the work and I was waiting for it's output, I got a bit lost given it really can do a lot but it make me feel some crisis as a human, even it still can provide me a sort of Joy because some task I long want to do but no time to start can be finally take shape, but the Joy is actually not comparable with the Joy when I read the code and hack with it
Concretely, I am letting agent to write some serious part of code to rust and I will consider only let Agent to handle the UI and integration stuffs, and I will take the rust part and rust is a language that I want to learn and be professional given I was do lots of C coding
Even without AI I barely write code. 95% of time are spend setting up integrations, configs, copying & adjusting code from previous projects.
Why write code in 2026? Because it’s fun.
Also, if you use AI to write your code, you are not a developer either.
Let's say AI completely disappears right now, many of the so called "developers" are unable to write code, are unable to fix code, they cannot code.
There are two kind of developers:
1. Non-developers: Use AI for everything, to write code, to test the code, you name it.
2. Real developers: Search engines are broken right now, they use AI as a tool, as replacement for Google to ASSIST you, not to do the task for you.
As AI is falling apart and companies are hiring people back, these non-developers will find themselves out of work.
The problem is IT professionals who depend on AI for everything. That is crashing down and won't be pretty.
Then there's the mass. I don't need that anymore. The mountains of boilerplate, etc.
I write little islands which need high judgement that are then connected by the obvious goo.
Generating boilerplate is strictly inferior than something already written and tested by the authors of the tools. You will eventually have to make slight adjustments to it, and those decisions can be just as impactful as your "high judgment" code. Those decisions are what actually enable your high judgment code to stay clean and straightforward.
Poor decisions in code architecture are some of the biggest blunders of all. Once you have begun to fill in the blanks on some boilerplate code, it ceases to remain boilerplate code. If you let AI make those adjustments, you will eventually blunder the codebase in precisely this way. You'll first recognize it when your high judgment code seems too verbose. You'll then soon realize some things are impossible without adjusting the boilerplate you started off with. Then the AI will fail to grasp what you want and you'll have to manually untangle a lot of the slop that you let grow out of control. Good luck with that.
It was a great read.
Recent HN Discussion: https://news.ycombinator.com/item?id=48873855
One way to "stay relevant" would be to admit that.
And that is a far stronger abstraction than LLMs :)
The selling point is that you know have a quality Vs time tradeoff that is a lot better than you used to have.
I can spend 10 seconds typing out a prompt that will generate ok code.
Before a couple of years ago, it might have taken me an hour to type out and debug that code.
> Before a couple of years ago, it might have taken me an hour to type out and debug that code.
Are you not running and testing your code?
> Are you not running and testing your code?
Why would you think that?
Because you’re claiming to not debug, and that you’ve gone from 1 hour to 10 seconds. I can only go off of what you tell me here.
If the tools are making you worse, don't use the tools.
Can I use agents to code a SWE project? yes, with nuances.
Can I write code for a SWE project? yes, with nuances.
Its more options now, I'll write code about projects I deeply care and will use llm at work where its shared slop and forced usage.
In my personal life, I cannot justify more than a $20 sub per month. I only use the Web Chat anyway. Shelling out $100-$200 a month for a sub in which I would get little to no ROI is a poor choice. Besides, I've never hit the limit on my $20 a month plan either.
The day I am forced to prompt LLMs all day, every day is the day I am cashing out of programming as a career. Though to be clear, I have no opposition towards anyone that uses LLMs, and think they are fantastic tools when used appropriately. (I love them as a StackOverflow replacement, and have learned a lot from going back and forth with LLMs).
And then the whole article shows tangible reasons where the agents are truly worse at code than humans. Code never is just the text. If intelligence you have is not truly general, you cannot expect things like clarifying wider context, hierarchically ordering knowledge based on criteria and producing consistent results despite transfer learning and retraining.
And no, we are not even close to the multimodal capabilities of human brain to hierarchy encode and reproduce knowledge. Otherwise the correct "reasonable" economic action would be genociding all humans, and I'm pretty sure that this is what billionaires effectively want out of AI.
Interesting article btw
If you think that everyone agrees on the "correct" way to use it, you're mistaken. If you think that your way is the best possible way to use it, you're arrogant. And if you think that the way you think is correct is obvious and that everyone should already know that's the right way, you're delusional.
Usually, when people say AI code is terrible, it's because they either don't understand the theory well but have grown through hands-on experience and can't explain things properly to the AI, or they don't know what they don't know. Or there are the very few who are just far better coders than AI. Some people will say they're among the rare few who can write better code than AI, and for some that may be true. But in my experience, the vast majority are not. Even from my perspective as a beginner, I could see flaws when I looked at their git code. It's a metacognition problem.
Realistically speaking, at the script level, it's quite common to see AI surpass human programmers as you increase the input level. You might disagree, but that's probably because you're a specialist in that field, deeply immersed in a very narrow area—it only holds true in that limited scope. In the general domain, most people would agree that AI writes code well.
Human programmers don't know much outside their own domain. But AI, while it loses in very narrow specialist areas, writes better code than humans across the broader range. It loses in the 1% zone (the expert's domain), but wins in the other 99%. Usually, when that's the case, you have two choices: become the 1%, or learn how to use AI.
Since I'm a non-native English speaker, I'm already at a disadvantage compared to native speakers in programming skills, so I chose the latter. But I still code. Not for any other reason—if I don't maintain at least some typing muscle, I won't be able to review AI code properly.
That's why I think coding is essential. Even if I can't understand the entirety of AI's output, I still need to understand the core business logic. At the very least, the core logic requires human understanding, so coding is necessary.
And I should mention that I have 30+ years of programming experience.
I’ve stopped using llms to generate architecture, which i design and write myself and let the machine pattern match the gaps. I also use it to review issues which I lot of the times push back against.
I’m working on a stateful application sitting on top of a data warehouse and have to implement a stream of messy half defined feature requests and navigate on top of an ever changing infrastructure layer. LLMs rarely get the infra layer even if it is written as code and have hard time grasping how to deal with tech debt, when and how to re-architecture parts of the stack or even implement stuff based on a detailed openspec design.
Usually, it produces code that would take three or four humans days to figure out—in just 20 minutes.
Even the professors and PhDs who hire me all use AI. Honestly, they hold PhDs and professorships, which puts them in a league I can't even touch—and even they use it. AI just does it really well.
Honestly, I learned from your book, 'rossant'—I never expected a programmer like you to say something like that. I thought my perspective was because I'm only an intermediate-level programmer. But you're in the 1% expert category I mentioned
.... and in the and you end up with a very deep prompt that exactly specifies the behavior. This is what a programming language is.
I'd rather describe a data structure in a language designed for this task, than a prompt the might be interpreted in many different ways.
I imagine at competitive coding the goal is quite clear, but in a real world project, the goal is not always so clear, and especially in hobby projects the ideas and goals are not that clear. I get inspiration on how to improve my project or its usability, not the LLM. I instruct it to do something a specific way, because it doesn't do anything on its own, and I need to tell it what to generalize, which it failed to see, because it didn't consider a simplification which is technically less precise, but due to user context and human nature doesn't matter (in this case it was interpreting "now" to mean the current second, which is a small time range, instead of a mere point in time).
So it still takes a ton of hand holding in a more open project. I imagine, one could also code it up in the same amount of time. But it is good for generating tons of test cases. Though one will have to review those, and impose a test style on them, give examples and so on.
Beyond hobby projects, most clients often don't really know what they want. And that's generally what we call domain modeling. This is definitely an area where AI is weak. As you know, it mainly pulls from generic patterns.
When there are specific constraints, AI struggles with core business logic. And as you said, it's also weak at choosing the right direction or the goal to pursue. But as you also know, 80% of programming is built on what others have already created. Originality is only about 20%. And in that 80%, AI is absolutely dominant. I agree with you and I've upvoted your comment.
I really like your perspective
I've seen so many of these already. It would be hilarious to see Brooks proving right once again.