For what it’s worth, back in August I wrote a post that basically said “use AI, stop complaining.” I still stand by it. But telling someone to use AI is like telling someone to use a hammer. Ok, on what? So here’s the longer version, the one I actually gave my team as we were all figuring this out together. Fair warning, the first part is going to annoy some people.
Code is dead
A team has to accept that code is dead. Not dying. Dead. They absolutely 100% have to accept that. If they’re sitting there looking at code, they are not actually adapting to AI, they’re just typing slower with a fancier autocomplete. I know how that sounds coming from somebody who spent most of his career looking at code. I don’t say it to be edgy, I say it because I watched and to a degree still watch us struggle with this. I find teams still trying to read code, and the lines are coming in faster than any human can read.
What is not dead is everything around the code. Your architecture and systems design experience, your understanding of how the pieces fit, how data flows, where the failure points are, that is absolutely still very important. More important, actually. It’s the part the team falls back on. The engineers who are doing well right now are the ones who stopped reading code and started reading the system.
Stop “Prompting”, Start Talking
So, here’s another one i think people aren’t going to like because it was cool to call yourself a prompt engineer for like 6 months. Well, yeah that’s dead to. I mean, probably less dead than code, but if you’re spending more than 30 seconds to try and tell your session how they should be behaving, for example: “You are a project manager who specializes in managing large projects…” or “You’re a quality assurance engineering specializing in frontend test suites…” Yeah, stop that.
Instead, just say, I need an agent that specializes in QA, or , I need a project managing agent, or something like that. Guess what, the LLMs are better than us at code, and they’re better than us at making prompts for themselves. There’s no reason to bother with doing something it can do in miliseconds.
Specs in, tests out
If a team is building new functionality, new features, the two things they need to be really good at now are writing the right specification and testing the results when it’s done. That’s it. That’s the job. What goes in is a spec that says what the thing has to do, and what comes out gets checked against that spec. Everything in the middle is somebody else’s problem, and the somebody else is a model.
I’m not the only one saying this, and I’m not the first. Plenty of serious people have been saying it for a while now. None of this is new. What’s new, and honestly what surprises me, is how many teams are still ignoring it. Teams that haven’t adapted to AI yet mostly don’t realize that this is just how high-performing teams operate now. Not as an experiment, as the job. Spec-driven development is a real thing with a real name. GitHub has its own open source toolkit for it, Spec Kit, which walks you spec, plan, tasks, implement, and hands each step to whatever coding agent you use. There’s the BMAD Method, also open source, which puts an analyst, a product manager and an architect agent in front of the developer agent so the plan exists before anybody builds. There are a handful of others. Pick one. It almost doesn’t matter which, what matters is that your team is working from a spec and not from a vibe. And if you want a sign of how far this has gotten, Sean Brandt, a Technical Fellow at GEICO, wrote on their tech blog this year that the spec is now “the primary engineering artifact” and that senior people’s time “moves from code review and implementation oversight to specification authorship.” That’s an insurance company. If GEICO has moved, the two-person startup down the street moved a year ago.
Make the AI follow your design principles
Here’s the one most teams miss. You still have architectural patterns and principles. You spent years arguing about them. They don’t go away just because a model is writing the code. The team’s job now is to make sure those principles are being followed by the thing that’s building the software. So if you’re using Claude, you need to be writing down your system design principles where Claude can see them, and you need to be checking that it’s following them. Same with whatever else you’re using. If your team believes in small services, or one database per domain, or no business logic in the controller, that has to be in the context the agent works from, not in some senior engineer’s head.
A model that doesn’t know your principles will happily build you something that works and that you’ll hate in six months. I mean, Claude, Astra, etc, they all do a damn good job of understanding your patterns / architecture just from the codebase it self. But if you are explicit about how things should be followed, it’s a lot easier to check outputs againts those principles in your CI.
And if you’re in a compliance heavy industry (banking, healthcare, etc), you’re definitely going to want to include those compliance requirements in there. Never share PHI, banking info, etc.
Small PRs, fast CI, because they will stack up
Pull requests need to be small and they need to not be overly dependent on each other. Each one should be able to go in on its own, in a timely manner. This was good advice before AI. Now it’s survival. Because here’s what happens, the PRs will absolutely stack up. CI will absolutely slow down. You will go from a handful of PRs a week to a pile, and every one of them runs your whole pipeline.
Faros AI put numbers to this in their Q2 2026 engineering report, “The Acceleration Whiplash,” looking at telemetry from about 22,000 developers. Teams with heavy AI use had PRs 51% bigger, median review time five times longer, 28% more bugs per PR, and, this is the part that gets me, fewer deployments per week, not more. Faster typing, slower shipping. Their advice was to fix quality “at the authoring stage, not downstream,” which is a fancy way of saying write the spec right and keep the PR small.
And the CI bill is real. Eddie Wang at Tenki wrote up the math back in April (he’s updated it since). Every push runs your full pipeline, and in his example a 20-engineer team’s monthly CI cost went from about $640 to about $2,880 once agents were opening the PRs. So whatever your CI speed is today, it needs to be faster. Not a little faster. Cancel the superseded runs, kill the slow jobs, parallelize the suite, whatever it takes. If your pipeline takes 40 minutes you are going to be sitting on a mountain of green-but-waiting PRs by Wednesday.
Build the automation, keep the human parts
Teams of course need to be building automation, so they can focus on the human parts of delivering software in the AI age. Which means first you have to know what the human parts are. For my money there are three gates where a person has to be in the loop:
- The spec. Somebody writes down what the thing has to do, and somebody agrees it’s right.
- The plan. Before anything gets built, a person looks at how it’s going to be built and says yes or no.
- The review. Not reading the code. Checking the result against the spec and the principles.
Everything else should be heading toward automation, and I mean aggressively. Instead of fixing bugs, build the thing that fixes bugs for you. Build the automation that handles all your dependency bumps and all your vulnerability issues. Build the automation that tells you when something is going wrong in the system so you’re aware and can act. And then, and this is the part people stop short of, build the next layer so that when an alert fires, some automation is already taking care of it and all you get is a note saying what it did. The notification shouldn’t be a to-do. It should be a receipt.
Yannick De Pauw at madewithlove has a guide on bringing agents into a team, last updated this month, and the line I keep coming back to is “match agent output to review capacity, not the other way around.” He figures a senior engineer goes from maybe 30% of their time reviewing to 50 or 60%. I’d put it differently. If your seniors are spending 60% of their time reviewing, you haven’t automated enough, and they’re reviewing the wrong things. Reviewing a diff line by line is the old job. Reviewing whether the system did what the spec said, that’s the new one.
I’m gonna write something about building software factories soon, and how engineers should move out or away from the application layers into the factory layer, so stay tuned for that.
From individual contributor to the whole thing
So what is teaching a team to use AI well, really? It’s teaching a team to move from being individual contributors to being their own full suite. And I don’t mean full stack like front end and back end. I mean they are now the product owners, because they are writing the plans for how the functionality needs to work. They are then building out the signals they need to watch. They are watching those signals and acting on them, changing things, and making sure the stuff they built is actually having the impact they expected and works the way they expected.
Product owner, engineer, infrastructure, all of it. One person should be able to take a new feature or a change from beginning to end into the application using AI, without ever really having to think about, or even look at, the code itself. Looking at the code is a waste of time. Yep, I said it again.
I’m not gonna pretend this is comfortable. It’s a bigger job than the old one, not a smaller one, and it’s a different job than the one most of us signed up for. But it’s the job. And the teams that are going hardest at it, the small ones with no legacy process to protect, have already made the switch and aren’t looking back.
If you’re doing this at your place and it’s going better or worse than what I described, I’d like to hear about it. I like talking about this stuff more than is probably healthy.