The two worlds of programming: why developers who make the same observations about LLMs come to opposite conclusions: https://www.baldurbjarnason.com/2026/the-two-worlds-of-programming/
-
@baldur the thing that scares me is there's no end in sight. You know the saying, "the market can remain irrational longer than you can remain solvent"? I think about that a lot in this new context
@autonomousapps Yeah. This is likely to last longer than it should
-
The two worlds of programming: why developers who make the same observations about LLMs come to opposite conclusions: https://www.baldurbjarnason.com/2026/the-two-worlds-of-programming/
@baldur as someone who preaches ux, accessibility and simple native „close to the platform“ solutions win over bloatware and frameworks thrown around like free candy for the last ten years I can only say: it’s good to have more people seeing this and speaking up!
Great article.
-
The two worlds of programming: why developers who make the same observations about LLMs come to opposite conclusions: https://www.baldurbjarnason.com/2026/the-two-worlds-of-programming/
@baldur excellent post!
-
@baldur excellent post!
@jdp23 Thanks!
-
@baldur as someone who preaches ux, accessibility and simple native „close to the platform“ solutions win over bloatware and frameworks thrown around like free candy for the last ten years I can only say: it’s good to have more people seeing this and speaking up!
Great article. -
The two worlds of programming: why developers who make the same observations about LLMs come to opposite conclusions: https://www.baldurbjarnason.com/2026/the-two-worlds-of-programming/
@baldur Great essay! I largely agree with it.
It's a throw-away line, but you say that "code review is the norm even though it’s largely useless as practised".
Why do you think it's useless/how could it be practiced better?
For my two cents:
I feel like code review is a bad way to catch bugs (yet another reason that "humans check all the AI output" is doomed to failure).
But I do think of it as a good way to keep a codebase consistent and to share knowledge between team members.
-
@baldur Great essay! I largely agree with it.
It's a throw-away line, but you say that "code review is the norm even though it’s largely useless as practised".
Why do you think it's useless/how could it be practiced better?
For my two cents:
I feel like code review is a bad way to catch bugs (yet another reason that "humans check all the AI output" is doomed to failure).
But I do think of it as a good way to keep a codebase consistent and to share knowledge between team members.
@ragman @baldur The domination of code review in the industry largely comes from the powerful mythology of the open source model (central maintainers/gatekeepers, distributed async contributors). Async individual work that fits in a Gantt chart is also the way most managers think, and modern era individualism means we are more inclined to play the blame game behind the comfort of our respective screens than really cooperate. In a lot of contexts though, synchronous collaboration through pair/mob programming ensures higher-fidelity shared knowledge, better focus and involvement during coding, creates a more immediate feedback loop on the quality of produced code and reduces the integration time of features.
-
The two worlds of programming: why developers who make the same observations about LLMs come to opposite conclusions: https://www.baldurbjarnason.com/2026/the-two-worlds-of-programming/
@baldur This really does summarise where I am. I was already exhausted from fighting what tech was turning into before AI, now it's still that but we can fall faster. Great!
-
@ragman @baldur The domination of code review in the industry largely comes from the powerful mythology of the open source model (central maintainers/gatekeepers, distributed async contributors). Async individual work that fits in a Gantt chart is also the way most managers think, and modern era individualism means we are more inclined to play the blame game behind the comfort of our respective screens than really cooperate. In a lot of contexts though, synchronous collaboration through pair/mob programming ensures higher-fidelity shared knowledge, better focus and involvement during coding, creates a more immediate feedback loop on the quality of produced code and reduces the integration time of features.
@GuillaumeL @baldur Interesting! The blame game bit rings true, at least in the more toxic environments I've been in. Though I'd say I've more often seen indifference than blame -- code review as a tedious chore, not as a part of a collaboration between you and the other developer.
Re pair programming, my first dev job was at a place that did mandatory pair programming, and I don't think it was good for me.
It worked when it was two people with similar skills/context, but...
(1/2)
-
@GuillaumeL @baldur Interesting! The blame game bit rings true, at least in the more toxic environments I've been in. Though I'd say I've more often seen indifference than blame -- code review as a tedious chore, not as a part of a collaboration between you and the other developer.
Re pair programming, my first dev job was at a place that did mandatory pair programming, and I don't think it was good for me.
It worked when it was two people with similar skills/context, but...
(1/2)
@GuillaumeL @baldur it fell apart when it was two people with a big power/knowledge differential.
If the more experienced person was really deliberate it could become a learning experience for me as the junior, but that was rare.
When it works, it works, but I do think there's something for banging your head against the code individually too.
(2/2)
-
@GuillaumeL @baldur it fell apart when it was two people with a big power/knowledge differential.
If the more experienced person was really deliberate it could become a learning experience for me as the junior, but that was rare.
When it works, it works, but I do think there's something for banging your head against the code individually too.
(2/2)
@ragman I think @GuillaumeL covers it pretty well in their answer. It's not a good approach for catching bugs or defects, which seems to be its primary purpose as practised by the industry today. Code review that was primarily for sharing knowledge between team members would require a different approach and style, I think.
-
The two worlds of programming: why developers who make the same observations about LLMs come to opposite conclusions: https://www.baldurbjarnason.com/2026/the-two-worlds-of-programming/
The two worlds you describe are utterly alien to me.
This article made me realize that i’ve always been in a third world of software development, one which depends on software quality, with colleagues who actively explore and evaluate new techniques, adopt the ones that work, and know how to explore and adopt best practices.
Perhaps it helps that most of my colleagues have worked in software for decades — and are the kinds of senior people who studies show do see productivity gains from adopting AI tools.
-
@ragman @baldur The domination of code review in the industry largely comes from the powerful mythology of the open source model (central maintainers/gatekeepers, distributed async contributors). Async individual work that fits in a Gantt chart is also the way most managers think, and modern era individualism means we are more inclined to play the blame game behind the comfort of our respective screens than really cooperate. In a lot of contexts though, synchronous collaboration through pair/mob programming ensures higher-fidelity shared knowledge, better focus and involvement during coding, creates a more immediate feedback loop on the quality of produced code and reduces the integration time of features.
I don’t think this is true. It comes from software engineering studies done in the eighties, particularly at IBM. Admittedly few places do rigorous reviews the way IBM documented.
-
@ragman I think @GuillaumeL covers it pretty well in their answer. It's not a good approach for catching bugs or defects, which seems to be its primary purpose as practised by the industry today. Code review that was primarily for sharing knowledge between team members would require a different approach and style, I think.
-
I don’t think this is true. It comes from software engineering studies done in the eighties, particularly at IBM. Admittedly few places do rigorous reviews the way IBM documented.
@lain_7 So, me and @GuillaumeL are specifically talking about the pull request style of code review, the one that was popularised by GitHub and is quite popular these days in tech and software dev, especially web.
Quite a few modern software dev practices have diverged considerably from the original methods while still keeping the names. TDD doesn't look like original TDD. Code review doesn't look like original code review. Agile isn't agile. Etc.
-
@GuillaumeL @baldur it fell apart when it was two people with a big power/knowledge differential.
If the more experienced person was really deliberate it could become a learning experience for me as the junior, but that was rare.
When it works, it works, but I do think there's something for banging your head against the code individually too.
(2/2)
@ragman @baldur Yeah I know the feeling. Pair programming can be a hit or miss kind of thing. How does the async code review version of that look, though? Do you think PR review comments can encapsulate the same learning experience? What would the PR comments of these senior devs who were “not deliberate” about teaching look like? How to make sure it’s a two-way street between reviewer and reviewee and not just top down?
-
R relay@relay.infosec.exchange shared this topic
