--- title: "Process-based quality control" date: "2026-07" category: "Working with AI" tags: ["Working with AI"] description: "More and more I think Agent-take development has to rely on a good enough quality control process to hold it up. It's like QA in manufacturing, sampling the critical parts, or controlling the whole process flow..." source: "https://enriquemark.com/en/posts/%E5%9F%BA%E4%BA%8E%E8%BF%87%E7%A8%8B%E7%9A%84%E8%B4%A8%E9%87%8F%E6%8E%A7%E5%88%B6" --- More and more I think Agent-take development has to rely on a good enough quality control process to hold it up. It's like QA in manufacturing, sampling the critical parts, or controlling the whole process flow, to watch whether your own output line is holding a reasonably good quality. Once a production line like that is set up, quality becomes a product you can reproduce. Because as AI code keeps swelling, humans vetting the code becomes less and less possible. Take something I wrote: design plus code output, the whole thing took 28 hours and came to almost ten thousand lines. And what came out was nearly all production-grade design. That's three working days. Normally that would take half a month, maybe a month. But now it compresses down to close to a week. This code, even if you gave me a week and let me review it every day, I'm not sure I could get through it. Going by something like 500 lines per 90 minutes, even the core code alone would take two or three days of review. So in the era of Agent-take development, Review gets less and less important. I'm not saying it can be absent, but it gets less and less important, because you don't have the energy to Review most of the code. The QA quality control process gets more and more important. So although I still micromanage, the granularity of that micromanaging is no longer at the code level, it's at the level of architecture and boundaries. Boundaries especially. I think boundaries are extremely important. A boundary is itself like a chunk, which also fits what learning science says about human working memory. We take big things, ah, I should say we take small scattered things and condense them into big things, abstract the fragmentary ones into chunks. Only that way is our working memory able to bear it. So for a large amount of complex, fragmentary stuff, the best method is to treat it as chunks. Then what should the chunk be for good code development? To my mind it's the boundary. Different code boundaries make up a small module, different small modules make up a big module, different big modules make up the whole architecture. That's a chunk made of one boundary after another. And the fragmentary code below the smallest boundary can be handed entirely to the QA process to control, as long as the boundary tests pass overall. Then on top of that it's still process, and note that shipping to production is a process too. Not all at once but step by step, module by module, a bit at a time, which likewise guarantees that even if something goes wrong, the damage stays within a workable range. Another aspect is clear design. I used to think microservices might cost a bit too much, but looking at it now the advantage of microservices comes out instead, which is that the modules are separated from each other. I noticed it myself while developing. Separation, and especially an architectural design that answers to contracts, lets Agents take development in parallel. As long as each part has agreed on the interfaces and contracts, it can go straight to developing its own without getting blocked. That's a big advantage. The other side is keeping AI's problems strictly inside the boundary of the contract, which guarantees that even if one AI goes wrong, its problem won't spread outside. It only happens inside one module. Microservices are the same. Even if this repo really does go down, only one place goes down, it doesn't spread to the whole. So the amount of highly decoupled code the AI era asks for is bound to grow. Things that in the past might have looked like over-design have turned into a hard part of quality assurance today. Take microservices: we used to say, oh, the development cost, the maintenance cost, they're high. But what's the key point now? The code can all be handed to AI to write, so architecture is what matters most. Sure, a few more repos is a bit of a hassle to write, but interfaces, just hand them to AI, no? It used to be hand-written, and that really was a huge hassle, but it isn't like that now. So what this era shows in the end is that the architecture that can guarantee quality is the good architecture, and especially the architecture that can guarantee quality under AI development is the good architecture. Of course I'm speaking from a quality angle here; in each specific case there'll be its own considerations. But right now, no organization can sit and watch AI's efficiency go unused. Compressing a month of work into a week, say, is a huge temptation to them, or you could even say it's formed a kind of reverse selection pressure, where companies that don't actively use this mode of production get eliminated, because their development cycles take too long, and their quality isn't necessarily much better than AI's either. Anyway, process gets more and more important, and although a good process design does need to be designed for the situation, once it's designed it stays effective for a long time, and the whole output environment benefits from it. --- **Translation note.** I wrote this in Chinese. This English version is an LLM translation, so the wording is not mine even though the thinking is. Original: [基于过程的质量控制]().