Books to read to counter AI-induced brain rot
Posted by LexMeat@reddit | ExperiencedDevs | View on Reddit | 59 comments
This is going to be a long and cynical post. I don't want it to be, but I can't help it.
I'm a Senior Data Scientist. I have about 10 years of experience in Python, Machine Learning, and NLP (now called "AI"). I work for a small (but reasonably profitable) startup. When I started working there (about two years ago), my role was about making use of LLMs to enhance our product. I won't go into the details, but we process a lot of unstructured text in all sorts of ways, so using LLMs makes perfect sense for this use case. In the beginning, I was genuinely excited about the role. I was already making heavy use of LLMs in my prior role and for my personal projects, and being able to lead such efforts was fascinating.
I won't describe the full journey because that will make the post too long, but two years later, and in spite of my objections, the company has adopted the use of LLMs internally for everything in the name of fast shipping. Essentially, the founder has mandated our CTO to do that, despite my warnings that this isn't a good idea. Now, writing and reviewing code is being done using LLMs.
I hate it.
I wouldn't call our codebase rubbish (yet), but it's incredibly verbose, and in my opinion we're accumulating tech debt faster than ever. But I'm the only person who believes that. For everyone else, everything is good. We're shipping faster than ever, and that's what counts, right?
Even more importantly, writing and reviewing code is not fun anymore. Even worse, I've come to the realization that in the past two years I've not grown as an engineer. This is inconceivable to me. Up until I started making heavy use of LLMs, every month I felt like I was becoming a better engineer. Not anymore. I thought that if I used LLMs strategically (actually reading the code, making improvements manually, etc.), this wouldn't happen to me. I was wrong.
In other words, AI-induced brain rot (or at the very least a mild version of it) is real to me. This has made me incredibly sour, and to be honest, I'm going through an existential crisis.
Anyway, I've decided to go against the trend and actually return to hardcore coding. I've picked up Rust, and I'm trying to write 100% of the code by hand (I started a silly personal project to keep me occupied). I'm happy to say it works. I feel like a first-year university student. The excitement is rejuvenating.
So my question to you is: What else is there for me to read/consume software-engineering-wise that will help me produce more brain cells instead of burning them? It can be any topic, doesn't have to be specifically about code. Something in the lines of "The Pragmatic Programmer." I want to be a better engineer overall.
intercaetera@reddit
Zen and the Art of Motorcycle Maintenance is the best book on engineering that I know, but it does require an open mind.
user0015@reddit
You may also incur some emotional damage.
user0015@reddit
After making my own little Rust project, let me tell you one thing you'll probably be happy to hear: LLM's can't write Rust code for shit. As in, Rust's extremely opinionated compiler will absolutely smash any LLM's attempt to write anything at all. So rest easy on that front.
In fact, my biggest issues with Rust are not even borrower related. That was relatively painless, and I'm coming from a privileged GC world where pointers are something my mouse has to do when it hovers on elements. But since this isn't really about Rust, here's a book suggestion for you:
Software Architecture: The Hard Parts. It came recommended from this sub and I strongly agree with the sentiment about it being good, It had excellent takeaways on handling projects (and people), and definitely helped shape how I approach upper management/pointy haired bosses. It's also an excellent primer on general architectural approaches, and ranges from front end, backend, databases/storage, and more.
dauchande@reddit
Designing Data-Intensive Applications by Kleppmann is the current hotness.
polacy_do_pracy@reddit
I wish there was some youtube series that would read it together with me. I've read it but it's hard and I don't know if I'm retaining the right information.
I've tried using AI with it and surprisingly, it knew all the contents of that book, by page.
PhillyThrowaway1908@reddit
There's dozens of playlists on YT of groups going through DDIA.
polacy_do_pracy@reddit
oh! i'll try to find them
__scan__@reddit
This book has to be getting on for 10 years old now, or an I thinking of the wrong one? The linked in guy?
PhillyThrowaway1908@reddit
That's surprising, but I guess good to hear. I just checked Amazon and I bought the book seven years ago.
utihnuli_jaganjac@reddit
How different is 2nd edition to 1st?
forgottenHedgehog@reddit
Very watered down for me.
axl88x@reddit
I'll have to add this to my reading list!
big_chung3413@reddit
Jumped on the bandwagon and reading now. I’m reading it so slow the tech might change by the time I finish 😂
Ok-Hospital-5076@reddit
DDIA covers topics which are very tech agnostic. I read it time to time for 3 yrs now. It’s still very much relevant. Can’t say that about most tech books on my shelf.
big_chung3413@reddit
I’m a data engineer and just so happen to have started working with a lot of the distributed technologies they mention. Also, the isolation levels have been causing us locking issues and I had just finished the chapter on it.
I started reading the book in March of this year and I’m halfway through but the more I’ve read the more and more I see it at work. It’s really well done.
failsafe-author@reddit
Reading it right now. Definitely leveling me up.
gruesse98604@reddit
Douglas Hofstadter ( https://en.wikipedia.org/wiki/Douglas_Hofstadter ) https://www.amazon.com/Gödel-Escher-Bach-Eternal-Golden/dp/0465026567 followed by https://www.amazon.com/Am-Strange-Loop-Douglas-Hofstadter/dp/0465030793
intercaetera@reddit
Also Surfaces and Essences is a surprisingly good read for programmers, since it deals with how we structure information.
Quick-Benjamin@reddit
If found since leaning heavily into LLMs, I've started reading a lot more books on the "philosophy" of stuff rather than deep diving on specific techs.
Everything from clean architecture, design philosophy, Lean manufacturing, DevOps, Systems thinking, etc.
Is be lying if I said I didn't also feel some AI brainrot, but I feel far more confident around thinking about and designing systems than I did before.
My perhaps forlorn hope is that as these LLMs quickly improve, it'll become important to have the broad knowledge and systems expertise than deep skills on a particular tech.
But who knows. I'm maybe bullshitting myself.
Anyway. Some recommendations.
Clean Architecture: A Craftsman's Guide to Software Structure and Design: A Craftsman's Guide to Software Structure and Design
The DevOps Handbook, Second Edition: How to Create World-Class Agility, Reliability, & Security in Technology Organizations
Lean Thinking: Banish Waste And Create Wealth In Your Corporation
The Machine That Changed the World
Black Box Thinking: Marginal Gains and the Secrets of High Performance
The Fifth Discipline: The art and practice of the learning organization: Second edition
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
The Goal: A Process of Ongoing Improvement
Donella Meadows; Thinking in Systems
CopyOnWriteCom@reddit
Shout out for 'Donella Meadows; Thinking in Systems'. Should IMHO be mandatory reading in school!
rashnull@reddit
I feel the same as you. But You know what’s great about LLMs?! They are able to fill in the blanks and complete sentences and ideas well. I’m using this new “vibe coding” to generate what I envision as the architecture of software solutions. Effectively, it helps make real the UML skeleton I have in my mind, whilst leveraging everything else that’s been baked into it to produce some interesting and comprehensive code. I know my code patterns, but do I need to keep writing them?
xmBQWugdxjaA@reddit
The Nand2Tetris course / The Elements of Computing Systems.
FWIW I don't think LLM coding is so bad as long as you ask it to explain stuff to you and review the code alongside it carefully.
WhiskyStandard@reddit
I came here to say go physical and as low level as possible. Last time I looked, LLMs couldn’t handle embedded as well because so much of the training code assumes an OS and so many resources that it doesn’t matter if the code sucks.
It may not always be like that, but at the very least you can feel useful when the AGI tells you to solder something. /s
If you’ve never worked with hardware, “Building Embedded Systems” by Elicia White is an excellent place to start.
Merrick’s “Getting Started with FPGAs” is pretty interesting as well. I’ve been fascinated by those, but was too intimidated to pick one up until I read that.
arkvesper@reddit
!RemindMe 1 month
RemindMeBot@reddit
I will be messaging you in 1 month on 2025-10-15 01:39:26 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
^(Parent commenter can ) ^(delete this message to hide from others.)
PhillyThrowaway1908@reddit
Not directly related to software, but I like The Art of Doing Science and Engineering which was originally published in the 90s. A pre-AI hype machine book around value and rewards of doing hard things.
https://www.amazon.com/Art-Doing-Science-Engineering-Learning/dp/1732265178
Firm-Wrangler-2600@reddit
I don't know about books, but I enjoyed Casey's Muratori videos, they always give me this "old school" vibe. I wanted to buy his course on performance at some point, but didn't get to it yet.
Otherwise pretty much the same. I code by hand in my spare time, I disable LSP, I use Neovim (again) after spending years with VSCode. I used to use Vim in 2010-2015 and it brings me back to my olden days as well.
met0xff@reddit
It's really interesting to see how other people end up in similar places..someone else here suggested Daniel Fabians DOD book and I've also been digging it out again just last week. Similarly I've been again watching Mike Acton and Casey Muratori .
And yeah also been thinking about Computer Enhance ;). But pretty sure I wouldn't find enough time.
I also sometimes miss the times where it was just me and my C or C++ compiler, perhaps a book and a manual and that's it. At best a handful of dependencies.
Nowadays 90% of the job feels like evaluating 50 competing libraries, wrestling with AWS and YAML configs and JSON payloads. And there's never enough time or money to do something well and take time but rather stitch together 30 AWS services or external APIs for everything. Had a couple years where I trained hundreds of ML models but that's also over as rarely there's the scale worth building your own models instead of using something from the big ones. Even for LLMs we don't have the scale that running our own would be worth it vs calling external APIs
Firm-Wrangler-2600@reddit
Tell me about it. In the beginning of my career I wanted to do low-level system development, but due to the lack of any jobs ended up with webdev, to the point of essentially just being an API jockey.
But I guess everyone has to do whatever pays.
met0xff@reddit
Yeah I was able to avoid web dev by getting into ML early, 10ish years ago. But as said, at some point it became at the same time massively saturated by people wanting to get into the field as well as jobs being reduced to calling APIs of a handful providers. Last 2 years I've been doing RAG/Agents so back to getting stuff from DB APIs and shoving it into LLM APIs and then shoving it to frontend APIs ;)
Firm-Wrangler-2600@reddit
> as well as jobs being reduced to calling APIs of a handful providers
I must've tried to switch to from webdev ML exactly at the time when it became the default ;)
"Hey we need this ML stuff done, do you have experience with it?"
"Not commercial, but I worked on some personal projects and took a couple of courses"
"Great, here's the API key"
GorgieGoergie@reddit
Das Capital
LexMeat@reddit (OP)
Everyone should read that no matter the context ;)
Teh_Original@reddit
I enjoyed "Data-Oriented Design" by Richard Fabien. Really different way of thinking about software than the OOP world many of us are in.
met0xff@reddit
Came to suggest this as I'm also reading it to not become too lazy brainrotty and going back to the good old times a little bit ;)
OwlProfessional1185@reddit
Like someone else said Structure and Interpretation of Computer Programs (SICP). The second edition - in Lisp. It takes you from the very basics, a programming language that does very little, to writing "meta-circular evaluators". I've been programming for a decade and I get my mind blown at each chapter. E.g the chapter where you go through a generic arithmetic package that works with complex numbers, rational numbers, polynomials, etc, and coerce between them.
axl88x@reddit
One of the best pieces of advice I ever got from a senior was to try to read at least one whitepaper a month. Really forces you to engage with technical details in a way that simpler tech articles frequently don't. I also think browsing r/SoftwareEngineering is a decent idea - There are plenty of interesting articles and discussions about code in areas I don't engage with personally, and it's always a plus to know a little bit of everything.
Revisional_Sin@reddit
What's a good way to to find papers?
axl88x@reddit
I like using arxiv.org, mostly. https://www.amazon.science/publications and https://research.google/pubs/ also have interesting papers.
anonyuser415@reddit
A New Moon is extremely cool, it's a tutorial with a plot where you are a suddenly promoted rocket scientist: https://sales.bigmachine.io/curious-moon
Nature of Code, a really high quality book on simulating nature and randomness https://natureofcode.com/
thephotoman@reddit
Hear me out: read a novel.
I get that you're used to reading a lot of technical manuals, not fiction. You're used to seeing reading as utilitarian, just as you see code: something you do to achieve an end. I want you to break out of that frame and connect with something human.
There are lessons in fiction. If you want to see a radical rejection of AI, Dune is beginners' material. I might also suggest the short stories of Philip K. Dick and maybe some Asimov.
Kept_@reddit
Maybe it'll not help you in particular but as a challenge I'm reading each one of these in my free time
https://nick-black.com/dankwiki/index.php/Book_list_for_streetfighting_computer_scientists
micseydel@reddit
Probably not what you're looking for but related to brain rot https://www.nejm.org/doi/full/10.1056/NEJMe2400189
MonochromeDinosaur@reddit
I believe this I could never concentrate the same after long covid. Back in 2020 been chasing that flow state I used to get into so easily 🤷🏻♂️ but it’s impossible.
micseydel@reddit
I've wondered if one of the reasons for the LLM hype is because of what you're talking about, even if it's impolite to bring up.
MonochromeDinosaur@reddit
I could see that.
I don’t really like them though it’s jarring to my workflow, I’ve really had a hard time integrating them in a way I can trust the code they write.
I find myself pausing to check which is equally as bad/or worse as not being into the flow, except now I have to stop and do code review mid “flow” lol which IMO is probably worse.
micseydel@reddit
Yeah, it pains me that literally no one (myself included) seems to have figured out good measurements for this stuff. Like, I want a formal process to measure somehow whether they're a net benefit or not, ideally with a way to factor in cost and expected future increases. You'd need to take samples over time to detect brainrot, which would have to be defined objectively... it would be really cool if someone figured this out.
halting_problems@reddit
Maybe activate so new areas of the brain.
Threat Modeling by Adam Shostack is such a great book for developers. A skill set that can be applied to any area of engineering.
It will deffinitly help address technical debt way before it’s even created.
NachoCheeseMonger@reddit
SICP.
St0xTr4d3r@reddit
Embrace the overly verbose code, ship as fast as possible with as many lines as possible. As a side project completely separate from work, develop an LLM to combat verbosity. Start your own consultancy in 1-2 years when companies worldwide are awash in tech debt that is indecipherable to humans.
taher66@reddit
TCP ip Illustrator
VoltairBear@reddit
Operating Systems - Three Easy Pieces Computer Architecture - Inside the Machine Networking - TCP/IP Illustrated
sisyphus@reddit
Code by Charles Petzold; The Psychology of Computer Programming by Gerald Weinberg; anything by Chip Huyen or Sebastian Raschka; Crafting Interpreters by Bob Nystrom are all incredible books. I guess a common theme of a lot of these is how something works from the ground up, Code computer code itself; Raschka's book on how to build your own LLM from scratch; Nystrom to build your own language. I guess I have a type.
angrynoah@reddit
Shorter than a book, start with the most important paper in software engineering: https://pages.cs.wisc.edu/~remzi/Naur.pdf
Idea-Aggressive@reddit
As sad and unbelievable this might sound, all it matters is to solve leetcode. It shouldn’t but thats all it matters. You join those companies and that’s it. Meeting after meeting. Colleague’s exaggerating achievements.
mauriciocap@reddit
Some Chaitin work? He jas even cool videos (coolest guy in information theory/computer science ever)
You may also enjoy the story of Dr Ingenia in the paper van Rooij, Guest, Reclaiming AI as a theoretical tool for cognitive science.
snorktacular@reddit
You might enjoy The Programmer's Brain by Felienne Hermans
opened_just_a_crack@reddit
What are some of the projects you are doing with Rust. I have a similar sentiment as you. LLMs at my job have made me feel stuck like I am not progressing. Or even if I am. I don’t particularly enjoy it like I did before.
StupidIncarnate@reddit
Ive found introducing garbage-resistant guard rails with ai stimulating. If you see it as a problem, try to solve it with AI. Its giving me a lot of granular understanding of how it reacts to certain things, which then forces me to rebalance or add different guardrails.
AI takes away what we want most as engineers: solving problems. If AI is the problem, we can solve it there, and then it can produce code without us worrying.
Ive split guardrails between lint and ai code review to figure out how many llm analysis rounds i need for it to find most of the important stuff.
AI isnt going away, its just gonna change where we divert our problem solving itch to.