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?
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.
> 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.
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.
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.
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.
>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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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 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.
> 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.
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.
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.
> 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.)
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.
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?
> 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.
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.
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.
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?
> 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.
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
>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.
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.
> 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.
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.
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.
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.
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)
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.
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.
> 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.
>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.
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.
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.
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.
>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.
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...
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.
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).
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
Yet...
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.
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...
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?
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.
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.
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.
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)
A human coder might OTOH follow the Boy Scout rule and clean up as they go.
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.
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!
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.
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.
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.
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.
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).
One way to "stay relevant" would be to admit that.
And that is a far stronger abstraction than LLMs :)
Even without AI I barely write code. 95% of time are spend setting up integrations, configs, copying & adjusting code from previous projects.
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.
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 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.
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.
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
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.
I've seen so many of these already. It would be hilarious to see Brooks proving right once again.