I've been talking with Andrew for the past year and learned a lot from those conversations, so I asked him to go deeper on a few of them here. Weave is a long-time partner and sponsor of manager.dev, and we also use it at my full-time EM job.
For the last 20 years, it was clear what ‘good software engineering’ looked like: you are obviously using git, you’re doing small PRs, fast reviews, CI, CD with at least daily deployments.
Today, that playbook is not enough. Even if you are an AI-skeptic, you can’t ignore that software engineering is changing. There are lots of takes on LinkedIn and X on what the best new practices look like, but nobody actually knows (and will probably not know for at least a few years).
The most effective way I found to learn for myself is to dive deeper into what works for other engineering teams, beyond the surface level hype.
Today’s article is a guest post with Andrew Churchill, CTO of Weave. Their goal is to help engineering teams optimize their SDLC.
We are going to cover the 3 things he believes every engineering team must focus on today:
A constantly-improving hiring process
Learning how to do parallelization effectively
Adapting your code review flow
Those are based both on his own experience and on observing the most productive teams using Weave.
Mic to Andrew! 🎤
Constantly improving your hiring process
For me, as a CTO, hiring is the single most important thing. When you hire the right engineers, in addition to the huge benefit to the company, there is also much less management work.
In most companies, the hiring process and interview questions are updated at most every couple of years, which means you ignore many important signals that happen during every interview.
Here’s how we try to solve it:
For every ‘failure’, we try to think about how we could have caught this at an earlier stage. The earlier you catch somebody who’s going to fail, the more efficient your system is. For example, we learned that we have to understand why the candidate wants to work at an early stage startup as early as possible, and make sure they are fully aware of the tradeoffs. There are a lot of things that are worse about working at a startup than working at a cushy big company.
Another takeaway was that we need to get a better understanding of what people can practically accomplish, not just how they can do on ‘simulated’ context or in a conversation, so we started doing work trials (3-5 days, fully paid, including flights and hotels).
When we offer a work trial, we are very very sure about that candidate. It means they passed every bar that a typical hiring process has. Still, we made an offer only to 60% of them. Every time we don’t make an offer, we try to understand what we could have done better in earlier stages.
Learning how to do parallelization effectively
With coding agents, switching your attention between 4-5 different sessions is actually a very viable workflow (and a very different one from how we used to work).
Every one of our early engineers is typically working on one main thread, where they put most of the focus, and 3-4 ‘sub-threads’, which are smaller improvements requiring less attention. For new engineers that join, their biggest unlock is figuring out how to adopt a parallelization strategy that works for them.
What I suggest they do:
Push it to the extreme and then figure out what does and doesn't work and then find the equilibrium. For example, see what happens when you work on 10 tasks at once. It's probably going to be crazy, and it's going to be really hard to maintain the context. But somewhere between 1 and 10 parallel tasks, there's a place that does work for you, where you can still focus on your main task while other things are going on in the background.
When engineers say 1 (or even 2) sessions are their limit, it’s usually either:
Each session requires your attention very frequently, causing too many switches
Or the coding agent goes in wrong directions, requiring a lot of effort and babysitting to steer it
In both cases, it’s about the context. Most ineffective AI usage is just ineffective context management.
Imagine you have a very smart intern join your team today. How would you onboard them so they could start working effectively immediately? You need to somehow distill everything they need to know:
The company direction
The product perspective
Coding standard and style
The things to avoid
The things to follow and why they are important
Most companies choose one of the extremes:
barely any info, letting them figure things out by doing. They give you a messy PR, you comment, and they slowly learn.
A 4-week onboarding, with recorded sessions, onboarding tasks, and so on.
Now imagine every new LLM session is a fresh intern. In the first scenario, you’ll of course get shitty results. But in the second scenario too, you’ll also feed it lots of useless information that will hurt the results. So when the LLM provides bad results, the highest ROI thing you can do is to stop and improve the guardrails and guidance it received, so that it won’t happen again in the future.
We are very lucky in that regard, as one of the main points of our product is to help engineers figure that out - so everyone has the mandate to spend the time reviewing their own AI usage metrics, and check where things are working well, and where they can improve. The next level we are working toward is a system that does it more effectively, self-correcting itself over time. It’s a tough challenge!
Going back to parallelization - now is the time to start figuring that out. It’s difficult, but if you have at least solid context infrastructure, it’s totally possible.
Adapting your code reviews flow
The biggest mistake I see remains requiring human review on every single PR.
The 2022 Andrew would tell you “of course you have to review every single PR, it’s insane to suggest otherwise”. But the 2026 Andrew has realized that as long as you have the right guardrails in place, not reviewing every PR will unlock a whole new level of speed that's just impossible otherwise.
Hear me out.
There are 3 main benefits to a code review:
Coding standards. Is this how we write code in our team?
Validation. Is this doing what it's supposed to do? Are there any bugs here?
Direction. This is the biggest value by far: whether the solution is even on the right path, or could be done completely differently.
#1 and #2 are completely solved by AI code reviewers. We use three different ones: Cursor Bugbot, Cubic and Greptile. Each of them catches some stuff that the other ones don't, and as long as that is true, it is worth it to us to have 3 of them. If there is no meaningful comment from any AI bot, we can be pretty confident there are no obvious bugs in it.
Now to the direction part.
If you think about it, the best way to review it is not after the code is written - but during the planning phase. It’s already common practice to have a plan for every feature an LLM implements, now it’s just about shifting the reviewing part to that earlier stage. If the plan is well written and agreed upon, there is a very low risk the implementation will follow a wrong direction. It’s also much easier to review 300 lines of markdown than it is to review 3,000 lines of code.
Of course, even with everything said above - some PRs should still be reviewed by humans. If you are making some change to the server config, infra, or another sensitive part, you want to get a review from somebody who really understands that area.
So how do we combine it all together:
First off, code reviews are optional. It’s the code author’s responsibility to request a review if they think they need it. Around 5% of PRs get reviewed by another engineer.
Plan reviews are ~10x more common
The rest (around 40%) are not reviewed. They are either done by the person with the most context on them or are simple enough that they don’t require it.
Next, we aim to solve our QA bottleneck. Currently, somebody still needs to test every PR in a non-production environment to see that it actually does what it's supposed to and doesn’t break anything. We hope to automate parts of that too. Reach out if you’re building something in this space!
How companies will adapt
So until now I’ve talked purely about my focus as an engineering leader, and the huge change software engineering is going through. Just as important is the change your company and product are going through.
Anton wrote a couple of months ago that Engineering Managers are going to hate OpenClaw. I see it as an inevitable change, where companies will need to climb the ladder to survive:
Understanding
Suggesting
Doing
Think about a product like Cursor. Before Cursor could ever come along, there needed to be an AI model that could understand code. That was LLMs. Then Cursor as a product started out by suggesting tab completions, and their initial smashing growth came just with good tab completions. And then as AI coding continued to evolve, it's gone from suggesting what to do to actually doing the work.
I believe it’s a natural evolution process. You need to understand work first to even have a shot at making a good suggestion. And you have to be really good at making suggestions before you can start doing some of the work.
Until now, we were focused on understanding how engineering teams work, but we’re slowly climbing that ladder. For example, our prompt router is a foray into that territory. We're not just saying, “Hey, we can tell that this model has been the most effective for your work”, we are actually routing work to that model for you automatically.
Most companies will need to do a similar shift - instead of just thinking how to do the best UI so the users will be able to do things for themselves, also thinking about how you can effectively do relevant things for your customers.
Thanks Andrew!
I’m currently in the early stages of improving each of those areas:
We are rethinking our interview process (which was the same for 5+ years)
Some engineers on my team already figured out how to parallelize work effectively. I still haven't, and neither have most of my engineers, but we are getting there.
We stopped having mandatory code reviews, and I’m never going back to that
It’s definitely not a boring time to be an EM.
What I enjoyed reading this week
Attention credits. Every person you communicate with (or that visits your landing page) starts the interaction with a limited number of attention credits. A useful framework to think through.
Code Yellow, Code Red. What to do during engineering crises. Another great article by James Stanier.
What I'd Tell My Team About Competition. A lot of people simply don’t understand the degree to which competition matters in B2B software, and what competing effectively feels like.
