"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.

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.

The observability people are correct. It’s not either-or though.

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.

Unless you want some unmaintainable shitty sloppy app.

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 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.

If tokens are the problem, SDD is the solution

I think fragility is the key reason i intervene in llm code too. Good article.

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.

this is the way

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.

+1, I don’t understand who these greenfielders are. Either I wait on the CI to finish, or I’m in a meeting.

I still exclusively write my code. The quality is higher. I know exactly how it works. It’s more extensible. You don’t have to generate it.

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.

Turns out you internalize it when you write it and refactor it with iteration

> 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.

lol what a slopper

TL;DR: Write it so you’re actively involved and not a passive reviewer. Then a sign up link for his course.

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.

Can you explain what you are working on?

I’ve stopped using llms to generate architecture, which i design and write myself and let the machine pattern match the gaps. I also use it to review issues which I lot of the times push back against.

I’m working on a stateful application sitting on top of a data warehouse and have to implement a stream of messy half defined feature requests and navigate on top of an ever changing infrastructure layer. LLMs rarely get the infra layer even if it is written as code and have hard time grasping how to deal with tech debt, when and how to re-architecture parts of the stack or even implement stuff based on a detailed openspec design.

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

"The deeper the prompt, the better the code actually gets."

.... and in the and you end up with a very deep prompt that exactly specifies the behavior. This is what a programming language is.

I'd rather describe a data structure in a language designed for this task, than a prompt the might be interpreted in many different ways.