The writing about AI and engineering is loud, and most of it is either hype or doom. What you actually want is people who ship, who read the papers, and who tell you plainly what is working and what is not. Here are ten of them.
We kept this list to people who are active right now, who write for engineers, and who show their reasoning instead of selling a conclusion. Follow two or three, not all ten. Reading everyone is its own kind of noise.
What makes a source worth your time
A useful writer on this topic does three things. They test claims on real code instead of repeating a demo. They tell you when something did not work, not just when it did. And they date their opinions, because a take about coding models from a year ago may already be wrong. The people below all pass that bar, though they disagree with each other plenty, which is a feature.
One more filter: we left off pure news accounts that only relay model releases. Releases are easy to find. Judgment about what a release means for your day-to-day work is the rare part, and it is what these writers give you.
1. Simon Willison
Willison, a co-creator of Django, now writes an almost daily blog about large language models and how to build with them. He tests tools in public, posts what breaks, and keeps a running record of what these models can and cannot do. It reads like a lab notebook, which is exactly why engineers trust it. Start at simonwillison.net.
2. Gergely Orosz
Orosz writes The Pragmatic Engineer, one of the most read software engineering newsletters anywhere. His pieces on how AI-assisted coding actually changes the job are careful and honest: what speeds up, what does not, and where teams fool themselves. He talks to working engineers instead of guessing. Read it at newsletter.pragmaticengineer.com.
3. Sebastian Raschka
If you want to understand how these models work under the hood, Raschka is the clearest teacher writing today. His Ahead of AI newsletter breaks down model architectures and training methods with real code, and he wrote the book Build a Large Language Model (From Scratch). Deep, but never showy. Find it at magazine.sebastianraschka.com.
4. Birgitta Boeckeler
Boeckeler is a Distinguished Engineer at Thoughtworks whose full-time job is figuring out how AI fits into real software delivery. Her field notes on coding assistants, published in the Exploring Generative AI series, are grounded in production work: what the tools miss, how review changes, why a coding assistant is not a pair. Read them at martinfowler.com.
5. Addy Osmani
Osmani spent years leading developer experience on Google Chrome, and he writes about AI-assisted engineering from inside daily practice. His piece on the 70 percent problem, that models get you most of the way and the last stretch is where the work lives, is a fair, useful read. His blog and newsletter are at addyosmani.com.
6. Kent Beck
Beck created Extreme Programming and helped popularize test-driven development, and now, decades in, he is experimenting in the open with what he calls augmented coding. He is precise about the difference between shaping AI output toward tested code and just chasing fixes in a loop. His newsletter, Tidy First?, is at tidyfirst.substack.com.
7. Chip Huyen
Huyen wrote Designing Machine Learning Systems and AI Engineering, and she thinks in systems: how models fit into products, where they fail, what it takes to run them. Her writing treats AI as an engineering problem with tradeoffs, not magic. Her essays and book resources live at huyenchip.com.
8. Shawn Wang (swyx)
Wang helped name the AI engineer as a distinct role, and his Latent Space newsletter and podcast are where a lot of that community talks shop. He interviews the people building foundation models and the tools around them, and pulls out the parts that matter for builders. Read and listen at latent.space.
9. Ethan Mollick
Mollick teaches at Wharton and writes One Useful Thing, which is the clearest ongoing account of how AI changes the way work actually gets done. He is not an engineer, but engineers read him because he tests claims, cites research, and stays calm. Find it at oneusefulthing.org.
10. Will Larson
Larson writes Irrational Exuberance and the books Staff Engineer and The Engineering Executive's Primer. His recent work covers how an engineering organization should adopt LLMs without betting the company on a moving target. He writes about strategy as a set of tradeoffs you can reason through, which is a calmer frame than most. Good reading if you set direction, not just write code. It is at lethain.com.
A few honorable mentions
The intersection of AI and engineering is wider than ten names. Chip Huyen's book resources sit alongside a growing shelf of practitioners writing well, and there are strong voices on engineering management and team practice who deserve their own list. If you lead people, our post on engineering managers worth following covers that angle. This one stays on the AI and engineering craft.
How to actually use a list like this
Pick two people whose problems match yours. Read them for a month. Notice which claims hold up in your own work and which do not. The point of following good writers is not to keep up with everything, it is to borrow judgment you can test against reality.
That gap, between reading about the work and being able to answer a real question about it, is the one we think about at StandIn. StandIn answers your teammates' questions while you are away, from the short brief you wrote at the end of your day, in your words, with a source under each answer. When the answer is not in what you wrote down, it says so instead of guessing. Good writers make you sharper. A clear record makes sure the sharp thinking is still there when a teammate needs it and you are offline.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.