Writing for the week of March 15, 2026

I’ve been thinking a lot this week about agentic development from the angle of QA. Everyone is excited about the productivity increase engineers are seeing but not thinking about the impact of that increase on the rest of the organization, especially downstream.

Most organizations I have been a part of have had more engineers than QA people. That already can lead to a queue in getting things through the QA process. Say you have 10 engineers and only 2 people performing QA. It’s easy to see how the QA people can get overloaded. Now let’s say agentic increases that 2x. It’s like having 20 engineers finishing work and queuing it up for 2 QA people to process. That seems lopsided. So what are the options?

First option, increase the size of your QA team. Whatever the ratio is, hire more QA people. This makes some assumptions about how QA is done in the organization. Manual smoke testing, etc….

Second option, retool the QA process. I’m using the word retool hear to mean rethink the process and possibly automate parts of it. If more code is being output by agents, maybe more of the product can be QA’d by agents?

Third option, enable QA with additional tools to make the process faster so they can process the queue faster. This is different than option 2. Option 2 was about supplementing QA by handing some of the load off to an agent, and having to trust it. This option is about identifying the granular bits of QA that require time. Things like data access, clear requirements, maybe even screenshots of what the QA process should specifically be looking for. Some of this means, upstream work. Clear requirements, for example, should exist before the engineering work is started but a lot of times, I’ve seen it come together as the feature is being developed.

I don’t know that there is a clear winner in those options, and some of it may vary from organization to organization. But I am going to spend some more time thinking about and writing about this subject. I’m not an AI hater, nor a cheerleader. I see it as a tool, but the old parallel approach was a fallacy. If you wanted to speed up, you hired more engineers. But you can’t make a baby in 1 month with 9 women. Teams and the work just don’t scale that way. So what does supplementing the team with agents really mean? It may mean more output, but that has upstream and downstream impact. Without addressing that impact, it may result in a wash. Organizations may not actually ship more, faster.

I’m going to explore this some more as the organization I am in experiments with these options.

▧ ▧ ▧

Links

• Will My Job Exist In Ten Years - I’ve had similar thoughts but I’m maybe a little more optimistic.
• Slow Gods - great book, creative writing, kinda depressing, but I’ve really enjoyed this sci-fi piece, and the cover art is simply amazing.
• Outcome Engineering - I’ve read through this once and I think I’m mostly in agreement, but think it has a parallel to Simon’s link about “your job is to deliver code that is proven to work”
• Exponential Organizations - I’m a noob with this stuff right now, but am spending time learning it more over the next few weeks

▧ ▧ ▧

Music

• https://ant-zen.bandcamp.com/album/domination-refix-by-architect - really digging this Converter remix
• https://notyetremembered.bandcamp.com/album/teichopsia - been listening to this a lot while I work, it’s gloomy gothic atmospheric techno

▧ ▧ ▧

A couple of promotions each week. First, use my invite link to try Warp as your terminal. It’s fast and has some great features. I’m not affiliated with them at all, just really like it. I’m writing a book about learning Rust if you are familiar with Ruby. Stay tuned. As always, you can connect with me more at https://mikekrisher.com.