A side effect of AI code reviews is that now someone actually checks for implementation changes that alter past decisions in ADRs and TDs. Obsessively, and without mercy.
Which makes those docs even more valuable.
Galo Navarro retweeted
I understand why most of you run out of tokens all the time: overengineering by default.
It's like it read all the blogposts and used every single "good practice".
Down on the factory floor, agents disagree in a code review. "It is a policy call for the team, so I leave this thread open" one snaps, mildly irritated.
Most problems manifesting in software dev today existed well before AI agents.
It's just that once you x10 the speed, their impact becomes too large to ignore.
The interesting part (read: difficult) of building a software factory is that it has to integrate with a pre-existing workflow that was designed for and by humans without disrupting it, or alienating people.
Galo Navarro retweeted
How do I say this...
You don't want to use AI when you can reduce something to a deterministic solution.
What do I mean?
You don't want to use AI to fill in fields in loan documents or operating agreements.
Instead you want to use AI to build the software that does it for you. And then you don't need the AI tool again for that task.
It's a subtle difference, but a really important one.
Galo Navarro retweeted
My background: ~15 years in cybersecurity, including six years active duty Navy cyber and three years as a NASA security engineer.
Here's what that taught me about AI for small businesses:
The risk isn't that AI isn't capable enough.
The risk is that you connect it to everything before you've decided what it's allowed to do.
Your inbox. Your client files. Your calendar. Your payment tools. Your finances.
A lot of owners set up AI the way a lot of companies set up security: fast, then patch later.
Flip it.
Before you connect anything:
1. Name the workflows worth fixing
2. Name the data each one touches
3. Name what needs your yes
That's an AI assessment. Do it first.
I started doing this a few weeks ago with notable improvements
We'll be spending a lot more time trying to understand the outputs of language models. A few thoughts, tips & tricks:
Writing. Something I've had success with: Ask your LLM to explain something in ASD-STE100, it's a controlled language specification originally developed for aerospace maintenance documentation. LLMs well-versed in this language and it comes with heavy constraints on clean writing style that I often find a lot more readable. Sometimes I've tried to soften it a bit e.g. ask for "80% of the way to ASD-STE100" because the spec is quite stringent. But even better:
Diagrams / images. Instead of writing, ask your LLM to create a diagram. These can be a lot easier to process, parse, and understand. But even better:
Web pages. Ask for output "in HTML" to get a beautiful, interactive webpage. LLMs are getting really good at frontend and can create beautiful experiences, animations, etc. But even better:
Explainer videos. The output format I am most bullish on is fully custom / bespoke explainer videos generated on any arbitrary topic. Experiment with things like "Create a 3b1b style video explainer on X. Use my ElevenLabs API key for audio narration". (you'd need an API key for the latter or you can ask your LLM to find you decent free alternatives that use your local compute). This is actually starting to work!
In summary:
- As LLMs get better, they will do more and more of the legwork autonomously, and a lot more of our work will rise up the abstractions into oversight and understanding.
- Luckily, LLMs can help here too because as intelligence and code are increasingly abundant, you can ask for large, custom, discardable software artifacts (e.g. web apps, video explainers) that would have never made sense to create before. Push the boundaries here and you'll be surprised.
Read from the perspective of software development in 2026 (from spectrum.ieee.org/bloomberg-…)
Not new, but awesome to make sense of the fairies
Very nice reading - Transformers explained visually
poloclub.github.io/transform…
Galo Navarro retweeted
The "mixed mode" where humans look at some code reviews, assisted by review tools, is also valuable today. But probably even more transient.
The idea that humans will reliably look through code to find the increasingly rare issues that automated tools miss seems like a fantasy.
Galo Navarro retweeted
The "whiteboard defense:" I should be able to pull you aside at any moment and ask you to explain any customer-facing system you've shipped. You should be able to clearly explain how it works and defend the decisions you made. This is my benchmark for responsible AI usage.
I don't expect line-level familiarity with the code. I don't care if you remember the exact function name or implementation detail. You may not even know it. I don't care.
But if I ask "why did you do X instead of Y?", "what happens if this actor behaves maliciously?", "what data structure did you use here and why?", or "where does this fail?" you should be able to answer confidently.
For PoCs, demos, experiments, whatever: I don't care. Generate 100% of it and understand none of it. Speed over quality every time in those specific scenarios.
But if you're shipping customer-facing work, you can't be shipping things you don't understand at a high level.
Galo Navarro retweeted
Interesting to see Yegge say he never successfully built anything with Gas Town.
In danluu.com/ai-coding/, I mentioned not finding these ultra vibed orchestrators useful b/c reliability (w.r.t. completing tasks). Turns out the author of the most famous one had the same issue.
Galo Navarro retweeted
The contagion of fear
bcantrill.dtrace.org/2026/09…
Galo Navarro retweeted
We ditched code review at @DuckbillHQ (mostly)
About a month ago, we found ourselves with 60 open PRs for a team of five. They had been accumulating for a few weeks and we all had the sudden realization we were looking at two days of just code review.
Galo Navarro retweeted
The revolt of the reader
bcantrill.dtrace.org/2026/09…