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.
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.
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.
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.
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.
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
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.
Then I'm curious: what kind of code did it generate, and in what areas did you find it not better? That's the part I'm most curious about.
'Good' and 'bad' are subjective anyway, and the domain where you use it differs depending on whether it's low-level or high-level. Performance is just assembling libraries anyway.
When I input this, the quality came out very well:
'The situation is this.
There are multiple sensors in a greenhouse or livestock barn. Examples: temperature, humidity, CO2, soil moisture, illuminance, pH, EC, water level, equipment status.
There are also control devices. Examples: ventilation fans, nutrient solution dispensers, pumps, valves, window openers/closers, heaters, coolers, lights, alarms.
What I want is not simply how to use RabbitMQ. I want to design it in a practical way, including sensor data collection, equipment control commands, notifications, failure recovery, retries, DLQ, and idempotency.
First, classify the messages by type.
1.Sensor measurement events
2.Equipment control commands
3.Equipment control results
4.Abnormal condition notifications
5.Periodic status reports
6.Manual admin commands
7.Commands generated by automatic control policies
Distinguish whether each message is an event, command, job, or notification.
Then design the following based on RabbitMQ:
Exchange structure
Routing key design
Queue design
Consumer design
Ack/nack policy
Retry queue
Dead letter exchange / dead letter queue
Message TTL
Prefetch configuration direction
Durable queue / persistent message usage
Preventing duplicate execution of control commands
Allowable loss range for sensor data
Whether equipment command loss is allowed
How to handle equipment being offline
Recovery method in case of broker failure
Transaction boundary between DB storage and message publishing
Whether the outbox pattern is needed'
When I give a detailed prompt like this, the output comes out well-organized, and the resulting design runs much better than what I wrote. So what kind of prompt are you inputting, and how are you using it, that you find it not good?
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.
"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.
> 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 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.
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.
> 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.
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.
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.
> 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.
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.
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.
> 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.
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.
>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.
> 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.
I always think about reading a proof in a book vs. doing the proof yourself. No
one learns mathematics by reading. You must spend the attention cycles and
struggle cycles and do it yourself---even though there's a perfectly good proof
in the book right there! A lot of comments in this post talk about code quality; the quality of the proof in the book is also probably better than the proof you
wrote but it is only so because its author wrote a whole lot of shittier proofs
before that. The content of that book is the result of many, many years and
many, many years of deep attention and development & refinement of expertise.
I have this pernicious tendency to be extremely task focused: I need to get this
done via any means. The objective becomes the artifact at the end. A lot
of this stems from issues I have revolving around self-perception, inadequacy,
and feelings of obligations to others. (For context, I work as a researcher in
academia.) Working like this is very unenjoyable. You feel guilt and shame and
humiliation and a lot of pressure and there's this big (self-imposed) push for
speed and results. [1]
Worse still is that it produces worse outcomes. Maybe in a very local window it
is indeed the fastest way to produce something that works. But, long term, by
not enjoying and engaging with the process and being completely fixated on the
result means that you are not cultivating deeper understanding and expertise, which,
of course, would be really helpful for future tasks!
You can imagine that (the promises of) AI is (are) very seductive for someone who works
like this. What a quick way to get things done and absolve my inner turmoil!
(Although it has limited efficacy in my domain---compilers (what I work on) are
complex beasts with many open problems.)
I didn't really engage with AI until this year and doing so (and also
re-evaluating other aspects of my life) has surfaced a lot of issues with my
approach to work and life. I realized that I was working for the sake of the
result and would kill myself to (try to) satisfy others. But that's no way to
live (let alone enjoy) life.
There of course are the pragmatics that I pointed out---that actual expertise
(as a person and of the codebase) is only developed by spending actual attention
(the linked blog post gets at this) which is really only effectively spent
through active creation (whether that's programming or whiteboarding or
scribbling or whatever). But more important to me now is that I enjoy the
process and the puddle-deep engagement that AI encourages (at least for
me)---seductive as it may be---is not the way to do that.
So, I'm shifting. Rather than ask how I can get this task done quickly, I ask what I can get out of doing the task. Self-cultivation like this is what produces experts and that an overreliance on
AI will result in personal stagnation and decay. And it's just way more
enjoyable. I want to create, not have some stochastic thing create for me.
[1] It's extra stupid because I actually really enjoy deep, focused
work. Historically, when I've had longer breaks from university/research and
have time to let some of my burnout dissipate, I find that I'll pick up a math
book or something else and just start going through it for fun. I really enjoy
the slowness and the puzzles and not having the (partly imagined) pressure of
others to get something done.
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.
73 comments
[ 4.8 ms ] story [ 55.0 ms ] threadThe 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.
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.
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 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.
And I should mention that I have 30+ years of programming experience.
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
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.
'Good' and 'bad' are subjective anyway, and the domain where you use it differs depending on whether it's low-level or high-level. Performance is just assembling libraries anyway.
When I input this, the quality came out very well:
'The situation is this.
There are multiple sensors in a greenhouse or livestock barn. Examples: temperature, humidity, CO2, soil moisture, illuminance, pH, EC, water level, equipment status.
There are also control devices. Examples: ventilation fans, nutrient solution dispensers, pumps, valves, window openers/closers, heaters, coolers, lights, alarms.
What I want is not simply how to use RabbitMQ. I want to design it in a practical way, including sensor data collection, equipment control commands, notifications, failure recovery, retries, DLQ, and idempotency.
First, classify the messages by type.
1.Sensor measurement events
2.Equipment control commands
3.Equipment control results
4.Abnormal condition notifications
5.Periodic status reports
6.Manual admin commands
7.Commands generated by automatic control policies
Distinguish whether each message is an event, command, job, or notification.
Then design the following based on RabbitMQ:
Exchange structure
Routing key design
Queue design
Consumer design
Ack/nack policy
Retry queue
Dead letter exchange / dead letter queue
Message TTL
Prefetch configuration direction
Durable queue / persistent message usage
Preventing duplicate execution of control commands
Allowable loss range for sensor data
Whether equipment command loss is allowed
How to handle equipment being offline
Recovery method in case of broker failure
Transaction boundary between DB storage and message publishing
Whether the outbox pattern is needed'
When I give a detailed prompt like this, the output comes out well-organized, and the resulting design runs much better than what I wrote. So what kind of prompt are you inputting, and how are you using it, that you find it not good?
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
Even without AI I barely write code. 95% of time are spend setting up integrations, configs, copying & adjusting code from previous projects.
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.
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?
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.
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.
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.
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.
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.
It's even got a name: sloppy-pasta.
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.
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.
I have this pernicious tendency to be extremely task focused: I need to get this done via any means. The objective becomes the artifact at the end. A lot of this stems from issues I have revolving around self-perception, inadequacy, and feelings of obligations to others. (For context, I work as a researcher in academia.) Working like this is very unenjoyable. You feel guilt and shame and humiliation and a lot of pressure and there's this big (self-imposed) push for speed and results. [1]
Worse still is that it produces worse outcomes. Maybe in a very local window it is indeed the fastest way to produce something that works. But, long term, by not enjoying and engaging with the process and being completely fixated on the result means that you are not cultivating deeper understanding and expertise, which, of course, would be really helpful for future tasks!
You can imagine that (the promises of) AI is (are) very seductive for someone who works like this. What a quick way to get things done and absolve my inner turmoil! (Although it has limited efficacy in my domain---compilers (what I work on) are complex beasts with many open problems.)
I didn't really engage with AI until this year and doing so (and also re-evaluating other aspects of my life) has surfaced a lot of issues with my approach to work and life. I realized that I was working for the sake of the result and would kill myself to (try to) satisfy others. But that's no way to live (let alone enjoy) life.
There of course are the pragmatics that I pointed out---that actual expertise (as a person and of the codebase) is only developed by spending actual attention (the linked blog post gets at this) which is really only effectively spent through active creation (whether that's programming or whiteboarding or scribbling or whatever). But more important to me now is that I enjoy the process and the puddle-deep engagement that AI encourages (at least for me)---seductive as it may be---is not the way to do that.
So, I'm shifting. Rather than ask how I can get this task done quickly, I ask what I can get out of doing the task. Self-cultivation like this is what produces experts and that an overreliance on AI will result in personal stagnation and decay. And it's just way more enjoyable. I want to create, not have some stochastic thing create for me.
[1] It's extra stupid because I actually really enjoy deep, focused work. Historically, when I've had longer breaks from university/research and have time to let some of my burnout dissipate, I find that I'll pick up a math book or something else and just start going through it for fun. I really enjoy the slowness and the puzzles and not having the (partly imagined) pressure of others to get something done.
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.
(and while I'm at it: thanks for submitting so many great links to HN - we greatly appreciate it)