<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/old-software-engineering-books-are-suddenly-required-reading-for-ai-agents-oslij0fdw" -->

---
title: Old software engineering books are suddenly required...
description: A debate is unfolding among developers about whether classic software engineering wisdom still matters in an era of AI coding agents. Gergely Orosz points out...
canonical: https://daily.dev/posts/old-software-engineering-books-are-suddenly-required-reading-for-ai-agents-oslij0fdw
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Old software engineering books are suddenly required reading for AI agents | daily.dev
og:description: A debate is unfolding among developers about whether classic software engineering wisdom still matters in an era of AI coding agents. Gergely Orosz points out...
og:url: https://daily.dev/posts/old-software-engineering-books-are-suddenly-required-reading-for-ai-agents-oslij0fdw
og:image: https://api.daily.dev/og/posts/osLIj0fdW.png
og:image:alt: Old software engineering books are suddenly required reading for AI agents
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Old software engineering books are suddenly required reading for AI agents

**[Trends](https://daily.dev/sources/trends)** · 3 min read · 47 upvotes · 8 comments

## Summary

A debate is unfolding among developers about whether classic software engineering wisdom still matters in an era of AI coding agents. Gergely Orosz points out that decades-old ideas like shallow vs deep modules and tracer bullets turn out to be exactly what's needed to structure work for agents. Vikhyat Koduvayur counters that old practices won't scale and new best practices are needed. Addy Osmani frames it as agents picking tradeoffs while engineers supervise which tradeoff fits, and Andrew Ng's AI Engineering Skills Map suggests the engineering role is rotating toward directing and validating rather than writing code line by line.

## Content

The discourse around AI coding tools has fractured into at least three camps, and none of them are fully wrong.

On one side: the productivity maximalists. @svpino says he doesn't read code anymore, just evaluates outputs. A developer built a complete Cloudflare Workers app in under four hours using Claude Code and called it a minor existential crisis. 48% of developers are using vibe coding for new projects.

On the other: the skeptics with receipts. LinkedIn engineers tried AI coding tools on mature codebases and mostly went back to manual coding — the agents hallucinated internal APIs and needed constant babysitting. @SebAaltonen spent time cleaning up Codex-generated examples full of code bloat and GPU barrier calls that made no sense. A WinReg library audit found Claude confidently flagging a crash bug that didn't exist, because it didn't know how RegGetValueW actually behaves.

And then there's the identity crisis camp, which might be the most interesting. A Master's thesis and a study of 442 developers found 77% are writing less code, with burnout hitting hardest among experienced engineers who now spend their days reviewing AI output instead of building things. The invisible labor of catching AI mistakes doesn't show up in sprint velocity. Engineers are grieving a job that still exists on paper.

The practical problems are piling up fast. Reviewing 6,000-line AI-generated PRs is becoming a real thing people have to deal with. "Workslop" — colleagues pasting AI output into Slack and calling it communication — is costing teams roughly two hours a month to clean up and eroding trust in 42% of cases. Artie Shevchenko at Craft Conference called this "cognitive debt": AI is generating code faster than humans can build shared understanding of it.

What's striking is how the serious practitioners are converging on old ideas. @GergelyOrosz noticed that working effectively with agents keeps leading him back to 25-year-old books — shallow vs. deep modules, tracer bullets, the surgeon team. A Thoughtworks experiment with ten engineers in one monorepo accidentally rediscovered the blackboard coordination pattern from the 1970s.

Addy Osmani's framing is probably the most grounded: deep expertise plus applied judgment. An Anthropic study found junior engineers using AI to learn scored 50% on follow-up quizzes versus 67% for those working by hand. The reps still matter. You just have to do them deliberately now instead of accidentally.

@housecor put the accountability question cleanly: "If I don't understand the goal, I shouldn't ask AI to do it." That's not a hot take. It's just true, and a lot of teams haven't figured it out yet.

## Questions this post answers

### What percentage of developers are using vibe coding for new projects?

48% of developers report using vibe coding for new projects, according to survey data referenced in discussions of AI coding adoption trends. This sits alongside contrasting findings, such as a study of 442 developers where 77% said they are writing less code overall, with burnout concentrated among experienced engineers who now mostly review AI output rather than write code themselves.

_Track how vibe coding adoption trends are shifting engineering team practices on daily.dev._

### How much worse do junior engineers learn when using AI compared to working by hand?

Junior engineers who used AI to learn a task scored 50% on follow-up quizzes, compared to 67% for those who completed the task by hand, according to an Anthropic study. This suggests that skipping deliberate practice in favor of AI assistance can weaken the retention and understanding junior developers build during learning.

_Developers weighing how much to lean on AI while learning can follow this debate on daily.dev._

### What is workslop and how much does it cost teams?

Workslop refers to colleagues pasting AI-generated output into chat tools like Slack and presenting it as genuine communication or work product. It costs teams roughly two hours a month to clean up and erodes trust in about 42% of cases, since the underlying content often lacks the understanding a person would normally bring to it.

_Teams navigating AI-driven workplace friction like workslop can follow the conversation on daily.dev._

## Community take

How the wider developer community reacted, aggregated from 1 discussion and 30 comments across lobsters (as of 2026-09-13).

**TL;DR:** Reaction to the essay is mostly negative, with many calling it insulting, poorly argued, and entitled toward a maintainer who used Claude to ship a genuinely useful feature, while a smaller group engages more sympathetically with the underlying anxieties about AI-driven coding.

**Sentiment:** 20% positive · 30% mixed · 50% skeptical

**The case for**

- Some argue expanding software capability and accessibility via AI is worthwhile if it helps real users, like a child who can now use the program on Linux.
- A few say maintainers giving away free work shouldn't be criticized for the tools they choose to use.
- Some relate to the essay's point about wanting more time for life outside work, calling that a reasonable desire rather than an insecurity.

**The pushback**

- Many find the essay's tone insulting and presumptuous toward the Paint.NET author, accusing it of caricaturing his motives.
- Several push back on the 'managerial power fantasy' framing as unrealistic or unsupported by how people actually describe using AI agents.
- Some argue the piece states its psychological claims without evidence or exploration, calling it underdeveloped.
- Concerns raised about environmental/resource externalities of running LLMs, and unresolved questions about whether training data included proprietary sources like Direct2D.
- Others describe frustration with AI-generated software in general, citing verbose UI text, bloated code, and loss of personality/care in projects.
- One commenter calls the essay's expectation that users must abandon the program over its AI-assisted feature more about personal purity than real-world impact.

**By community**

- lobsters (skeptical): Discussion leans critical of the essay itself, with many calling it insulting, poorly reasoned, or entitled, alongside a substantive side debate about AI's externalities and the ethics of using Claude for this specific feature.

**Hottest debate:** Whether the essay's framing of AI-assisted coding as driven by a 'managerial power fantasy' and insecurity is a fair diagnosis or an insulting caricature of the Paint.NET author and developers generally.

**Open questions**

- Could the specific Claude-written Direct2D reimplementation have been influenced by proprietary training data, and would anyone besides Anthropic be able to verify that?
- Is there a way to meaningfully weigh the resource/environmental costs of AI coding assistance against its benefits?
- Would using AI to build the feature actually drive users away from Paint.NET in practice, or is that just a hypothetical?

**Highlights**

> lol, i hope the author of paint.net doesn't read this. incredibly + gratuitously insulting. one of the problems with llms is their poor or missing "theory of mind" for their users, so it's ironic (morissette sense) to see the blogger here similarly incapable of conceptualising the other & hallucinating a stereotype to replace them.
> — [gulbanana on lobsters · 9 points, 1 comments](https://lobste.rs/s/qnffyn/endless_temptation_claude#c_2lbste)

> For what it's worth, I've mostly experienced LLM-assisted software in the form of: uncanny interfaces/interaction models that work, but don't really make sense or feel cohesive at all if you think about it too much; simultaneously verbose and vague UI text; meandering blog posts written in unnecessarily dramatic language and devoid of personality; mountains of complex code to do things which could've been achieved in a much simpler idiomatic way; an explosion of distracting features which have a niche use cases (if any); frequent gratuitous tweaks that don't improve anything to justify the cost of adapting to the change; and piles of project spam posts which have completely drained the enthusiasm I used to have for discovering and hearing about other people's projects; as well as the loss of admiration for more than half of programmers I used to respect for the care they used to put in their projects. The upsides have been... two or three utilities that are still useful and tolerable despite having all those flaws. One feeling that keeps popping up is that it feels like the result of someone on a stimulant binge. Which makes sense to me, without the sense of friction for applying effort, it's easy to do a lot without really considering if it's a good idea in the first place.
> — [yuriks on lobsters · 1 points](https://lobste.rs/s/qnffyn/endless_temptation_claude#c_e4ufmx)

> I've struggled with the decision of using LLMs in my own projects.  Just to be upfront about it, I've made the decision of using them, and I use them very extensively for pretty much everything I build lately. > There's no high score, no reward, for endlessly expanding your software as far and fast as possible. This is true.  I agree that the ability to just more or less will some feature into existence makes scope creep and build stuff that nobody cares about extremely tempting. > Does this program NEED to have these extra features? Does this software NEED to work on everything? For me, my thinking came down to something pretty simple. I spend a LOT of time on my personal software projects, and I care about them very deeply.  This has been the case for over a decade, and I was more than happy to hand-code things.  I truly preferred the process of writing code by hand.  I got very good at it, the fact that this skill was valuable to others and society in general was huge for my self-worth and livelihood. Despite all that, I still can't justify not using AI to myself.  I just picture the scenario where I decided to hand-code my projects, and then I log into Twitter and see a post from someone who built something very similar (or perhaps even better) with AI instead.  Without a doubt, it's going to have more features, it's probably going to be more polished (on the surface at least), and it would have been built in an order of magnitude less time. Even if that particular project was a shitty pile of vibe-coded slop with no soul or care put into it at all, it would still be crushing to witness.  Thinking of seeing some kid with a small fraction of my experience and none of my deep interest and enthusiasm for the tech itself pump out something equivalent in 5% the time makes me sick to my stomach. So that really only leaves me with a few options.  I can despair and quit dumping effort into software projects and pursue my only other goal of getting to Platinum in Valorant.  Or I can double down and use AI to accelerate my efforts and try to go far further and do more than I could without it. To be clear, I've done plenty of despairing as well along the way.  I still feel like the craft that used to define me is quite dead, and when I try to project forward to the logical conclusion of this AI revolution, I find it hard to see anything remotely positive.  However, despite all that, I absolutely refuse to just sit here and watch others surpass me because I refuse to make use of tools at my disposal.
> — [Ameo on lobsters · 1 points, 2 comments](https://lobste.rs/s/qnffyn/endless_temptation_claude#c_ateuxh)

> There is a tinkling of an interesting blog post here, but it falls short by not exploring anything introduced further and just stating things as they are. If you are going to write an post like this I do strongly feel that you should spend more time on things like this  > From where I stand I feel like this sadly comes from certain desires and insecurities: >  > 1. Wanting to spend less time at work, more time outside / with loved ones. > 2. Feeling like you should be able to accomplish so much more than your body and mind allows with limited time on Earth. > 3. When people get older, they feel that they deserve upward mobility where eventually they become a manager who tells junior coders to do all the hard work. "AI Agents" allow for that fantasy, they're the tireless junior coders who you get to tell what to do, as if you've been promoted.   I think the author is somewhat in the neighborhood with these points, but calls destination reached before even have reached the right street.  To the point that you now have caricatures of reasons that fit what the author wants it to be rather than what is really going on. The first on is the most reasonable one, which I wouldn't even qualify as a desire or insecurity. In the context of open source development I can understand it if the sole maintainer of something popular considers the aid of AI to balance the time invested a bit more evenly. If that result will be reached is a valid discussion to have, but the reasoning behind it is not something I would actually dispute.  The second point already starts to glide into the ridiculous, mostly be the addition of the last bit. And also here, I don't the desire to be able to do more is unreasonable in many ways. At least not as a standalone bullet point simplified to this point. Again, the valid discussion here is if LLMs can actually make people accomplish more. Extra points for making the discussion about what accomplishing something means if it is largely written by a LLM and if there is a tipping point somewhere.  The third bullet point is just plain ridiculous to me. Sure, I have seen agents described as "tireless juniors who do what I ask". But, that is always in the context the second bullet point and rarely if ever I have seen it in the context of some sort of "I deserve to be management" type of deal.
> — [creesch on lobsters · 1 points](https://lobste.rs/s/qnffyn/endless_temptation_claude#c_pnn0uq)

> Can someone help me understand why everyone grabs their pitchforks as soon as somebody admits to using AI for code? The [original post by the PAINT.NET author](https://forums.paint.net/topic/134563-%F0%9F%8D%B7-extremely-experimental-winelinux-support-how-to-get-started/) was honest about their AI use. It's clear that without Claude this wine compatibility could've never been written, even if he devoted his life to it. Instead of he spent some time and presumably a lot of money on getting it through AI. This post suggests that "users have to ditch the program and look for a new art program to use", I don't see why that's the case at all. The original 200.000 lines of code the author worked on for 20 years hasn't changed.  If you don't want to use this vibecoded Direct2D layer then just don't use it? Does it hurt to have it?
> — [Levitating on lobsters · 2 comments](https://lobste.rs/s/qnffyn/endless_temptation_claude#c_uen2c0)

**Source threads**

- [lobsters](https://lobste.rs/s/qnffyn/endless_temptation_claude) · 23 points · 30 comments

## Community discussion

Top comments from developers on daily.dev.

**@taiwofrancis** · 6 upvotes

> Old software books are just structured logic. Turns out, LLMs need strict logic boundaries to not lose their minds on large codebases.

**@murakon** · 0 upvotes

> Maybe we all should just stick with manual programming ?? It feels like hell when you review what the AI spew out !!

**@ahmetozel** · 0 upvotes

> The GPU example is the tell. That code was not wrong, it was structurally expensive - a barrier per render pass and a command buffer per pass both read as perfectly reasonable line by line. This is exactly the failure class the old books are good at naming: cost of crossing a boundary, batching, what an invariant buys you. It is also the class that review-by-reading cannot catch, which is why the skill that actually scales here is measuring rather than reading. A per-pass barrier is invisible in a diff and screams in a trace.

**@praveenkumar414** · 0 upvotes

> OSTEP and Data Structure with Applications are something to begin with.

**@mark\_kazakov** · 0 upvotes

> Nobody canceled software engineering principles and best practices. The only thing that has changed is the speed of the code output that we need to deal with.

---

Tags: [#ai-agents](https://daily.dev/tags/ai-agents), [#architecture](https://daily.dev/tags/architecture)

[View this post on daily.dev](https://daily.dev/posts/old-software-engineering-books-are-suddenly-required-reading-for-ai-agents-oslij0fdw)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Old software engineering books are suddenly required reading for AI agents","url":"https://daily.dev/posts/old-software-engineering-books-are-suddenly-required-reading-for-ai-agents-oslij0fdw","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/old-software-engineering-books-are-suddenly-required-reading-for-ai-agents-oslij0fdw"},"datePublished":"2026-08-29T00:39:47.729Z","dateModified":"2026-09-13T19:52:55.116Z","description":"A debate is unfolding among developers about whether classic software engineering wisdom still matters in an era of AI coding agents. Gergely Orosz points out...","isAccessibleForFree":true,"articleSection":"Trends","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Trends","logo":"https://media.daily.dev/image/upload/s--ZfSp3asX--/f_auto,q_auto/v1780996004/logos/trends?_a=BAMAMiWQ0","url":"https://daily.dev/sources/trends"},"commentCount":8,"discussionUrl":"https://daily.dev/posts/old-software-engineering-books-are-suddenly-required-reading-for-ai-agents-oslij0fdw","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":47},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":8}],"keywords":"ai-agents,architecture","timeRequired":"PT3M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Trends","item":"https://daily.dev/sources/trends"},{"@type":"ListItem","position":3,"name":"Old software engineering books are suddenly required reading for AI agents"}]}
{"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/old-software-engineering-books-are-suddenly-required-reading-for-ai-agents-oslij0fdw","comment":[{"@type":"Comment","text":"Old software books are just structured logic. Turns out, LLMs need strict logic boundaries to not lose their minds on large codebases.","datePublished":"2026-08-29T04:28:37.894Z","url":"https://daily.dev/posts/osLIj0fdW#c-hYBv7pNAT","author":{"@type":"Person","name":"Taiwo Francis Oguntade","url":"https://daily.dev/taiwofrancis","image":"https://media.daily.dev/image/upload/s--px3_Pvo4--/f_auto/v1785515368/avatars/avatar_FStpm3ZejUD3qGlEeoOUS?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":6}},{"@type":"Comment","text":"Maybe we all should just stick with manual programming ?? It feels like hell when you review what the AI spew out !!","datePublished":"2026-09-03T09:01:30.738Z","url":"https://daily.dev/posts/osLIj0fdW#c-DXafFySU5","author":{"@type":"Person","name":"MuraKon","url":"https://daily.dev/murakon","image":"https://avatars.githubusercontent.com/u/158759753?v=4"}},{"@type":"Comment","text":"The GPU example is the tell. That code was not wrong, it was structurally expensive - a barrier per render pass and a command buffer per pass both read as perfectly reasonable line by line. This is exactly the failure class the old books are good at naming: cost of crossing a boundary, batching, what an invariant buys you. It is also the class that review-by-reading cannot catch, which is why the skill that actually scales here is measuring rather than reading. A per-pass barrier is invisible in a diff and screams in a trace.","datePublished":"2026-09-04T20:46:54.629Z","url":"https://daily.dev/posts/osLIj0fdW#c-D7DKlu8Pp","author":{"@type":"Person","name":"Ahmet Özel","url":"https://daily.dev/ahmetozel","image":"https://avatars.githubusercontent.com/u/70992231?v=4"}},{"@type":"Comment","text":"OSTEP and Data Structure with Applications are something to begin with.","datePublished":"2026-08-31T11:37:13.556Z","url":"https://daily.dev/posts/osLIj0fdW#c-SpCvwkD9Y","author":{"@type":"Person","name":"praveenkumar414","url":"https://daily.dev/praveenkumar414","image":"https://avatars.githubusercontent.com/u/286906715?v=4"}},{"@type":"Comment","text":"Nobody canceled software engineering principles and best practices. The only thing that has changed is the speed of the code output that we need to deal with.","datePublished":"2026-09-07T18:33:34.551Z","url":"https://daily.dev/posts/osLIj0fdW#c-nsR0cJYLi","author":{"@type":"Person","name":"Mark Kazakov","url":"https://daily.dev/mark_kazakov","image":"https://media.daily.dev/image/upload/s--xbUWQzIM--/f_auto/v1743106084/avatars/avatar_DXWhIjQxKsp3WABroh08k"}}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/old-software-engineering-books-are-suddenly-required-reading-for-ai-agents-oslij0fdw#faq","mainEntity":[{"@type":"Question","name":"What percentage of developers are using vibe coding for new projects?","acceptedAnswer":{"@type":"Answer","text":"48% of developers report using vibe coding for new projects, according to survey data referenced in discussions of AI coding adoption trends. This sits alongside contrasting findings, such as a study of 442 developers where 77% said they are writing less code overall, with burnout concentrated among experienced engineers who now mostly review AI output rather than write code themselves. Track how vibe coding adoption trends are shifting engineering team practices on daily.dev."}},{"@type":"Question","name":"How much worse do junior engineers learn when using AI compared to working by hand?","acceptedAnswer":{"@type":"Answer","text":"Junior engineers who used AI to learn a task scored 50% on follow-up quizzes, compared to 67% for those who completed the task by hand, according to an Anthropic study. This suggests that skipping deliberate practice in favor of AI assistance can weaken the retention and understanding junior developers build during learning. Developers weighing how much to lean on AI while learning can follow this debate on daily.dev."}},{"@type":"Question","name":"What is workslop and how much does it cost teams?","acceptedAnswer":{"@type":"Answer","text":"Workslop refers to colleagues pasting AI-generated output into chat tools like Slack and presenting it as genuine communication or work product. It costs teams roughly two hours a month to clean up and erodes trust in about 42% of cases, since the underlying content often lacks the understanding a person would normally bring to it. Teams navigating AI-driven workplace friction like workslop can follow the conversation on daily.dev."}}]}
```

