We entered the second phase of AI coding 👀
The first was in November/December 2025, when many devs gradually stopped writing the code, leaving that to the AI.
And now the second phase: devs are not even reading the code anymore 🙌
There are a few reasons why this makes sense, and better/worst ways of doing it.
Here is how I am navigating this 👇
AI writes faster, and reads faster
The promise of AI is to make you faster in producing (quality) code.
Part of that is the AI itself: it's obviously faster than you in writing and reading 🙌
You can take advantage of this speed by doing parallel/larger implementations. But then you hit the bottleneck: you 🫵
No matter how fast the AI gets, if you read all of it (or even part of it), you are slower. You become the slowest step 💁🏼♂️
As the AI gets smarter and faster, your presence becomes more and more the main factor slowing speed down.
So, the logic goes as follows:
As AI gets faster and smarter, instead of reading the code yourself, take that time to prompt other AIs to add all sort of automatic checks and reviews on top 🤔
That's the origin of "no reading".
What checks I am using
Now your role shifts from code writing/reading, to full end to end architecture and verification maintenance.
Building software by prompting agents without ever reading or editing the code directly isn't actually a new thing. It's just called being an engineering *manager*. We have decades of experience about how to be effective as engineering managers. It is a different skill, though.
This means knowing your stack, understanding all the possible holes, and fix each with a new automated check.
Strict typechecking
Statically typed languages are a must (they always have been so, but now more than ever I guess).
Types are the bones of your project. Enable the most strict configuration possible 🔒
If you language allows, go a step further:
- Pattern matching enforced
- Branded types
- Schema validation
Custom linting rules
Linting rules are the primary extra component.
Types verify the correct use of the language, linting rules check the proper way of writing the code 🏗️
Skim periodically the AI implementation to catch bad patterns, and promptly ask another agent to create a new linting rule to prevent that.
Over time you built more and more static guardrails 👀
Component libraries and style checks
Turns out UI and frontend can be checked as well 🪄
Anyone doing this reliably on frontend and UI? Enforcing styles, proper components usage, spacing etc. Any worthwhile tool or strategy?
I’m significantly older than you. I started coding in the late 60s. My current strategy is to not read any of the code written by my agents. That’s the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints. Unit
My example: Tailwind CSS.
Open access to all the tailwind styles makes the UI inconsistent and likely broken. Instead:
- Disable all default styles
- Define your own set of styling (the minimum possible to fit your design)
- Define a set of re-usable components
You can then add a bunch of automated checks to prevent your styles from ever being breached:
eslint-plugin-better-tailwindcss: rules that flag every class that is not part of your design system- Add linting rules to prevent any native components outside of the component library (e.g. prevent using
<button>) - Add a linting rule that requires using
className(no other way of styling) - Add scripts that generate the tailwind
.cssfile and let the agent verify that all the times
Suddenly the AI can only use a small subset of styles and components. If the components are good, the result will be at least consistent, then refine.
Tests, all sort of them
Clearly instruct agents to add tests for anything meaningful.
Like a lot. Like all types: unit, e2e, integration.
The AI is fast, it can just add, fix, refactor, remove tests at any time. Just let it run 🚀
Agent documentation and skills
For everything that cannot be statically checked, add skills.
I have a single "implementation" skill for things that are not black or white:
Patterns that are not hard rules always to be applied, but more like "preferences" and "it depends" 👀
Keep this up to date, and look for any opportunity to automate parts when possible.
Give the AI more access
Another critical rule: the AI should be able to verify end to end.
Doing this requires some form of local setup that the AI can own (ideally) 🏗️
Docker, local database, webhook tunnel, browser automation, computer use, github access, backend API access, access to analytics, crash reports, telemetry.
Anything that lets the AI verify beyond the lines of code.
Tools to catch critical changes
Your time reviewing the code should be spent only on the most critical changes.
But also that can be automated and made faster.
I added a script that flags changes to critical files (e.g. database schema), and flags usage of risky APIs (e.g.
useEffectand friends) 👀
The script takes the git diff, checks for patterns, and reports to me only the files that are worth a double check.
Software engineering is about being creative now: how do I make my software more robust end to end?
It's now the time to start laying the bricks for your AI automation. And, soon, stop reading the code 💁🏼♂️
See you next 👋