The classic pipeline
Most of the pipelines I see focus on increasing throughput. They take humans out of the loop and break important connections and interactions between stakeholders.
I think the key to pipelines that create better products is what I call isolated, quality-enhancing pipelines, as opposed to full-process, quantity-focused pipelines.
Agentic pipelines should improve the interactions between stakeholders at crucial points in the development process. They should deliver quality for users, product owners, developers and customers, while keeping all that important domain knowledge and expertise in human brains.
The observations
Software applications often have built-in tools that let users report errors. Pipelines are often built to convert these poor error reports into internal tickets, with an automated fix as the end goal. Instead, write a circular pipeline that guides the user to create a high-quality bug report with all the important information. One that a developer or product owner can read and prioritise, and that tackles the real issue the user is facing.
Some pipelines that are centred around delivering new features take a vague requirement, create tickets and start implementing. Instead, grill the feature and its requirements and make sure all stakeholders get a clear understanding of the problem and the solution space. Use the double diamond process to create a circular, self-steering and self-improving pipeline.
Boring pull requests are a sign of quality. The ones that when you open them, read the description, check the code and think: was it really that simple? You can't get there with a pipeline that goes from user input to release. It only works with almost deterministic rules and guidelines on the consistency and quality of the code, starting from the refined ticket that came out of one of the previous loops. Fun fact: in Clean Code, Robert C. Martin (Uncle Bob) writes that we spend well over ten times more time reading code than writing it. Usually that's bad legacy code. Now developers finally get to read good code.
Releasing can also benefit from this new approach. Don't release for velocity. Release with confidence. To do so, create an isolated, quality-enhancing pipeline for your deployment and release process. One that writes end-to-end tests that can be visualised and shared with all stakeholders. Developers can use these end-to-end tests for troubleshooting and for preparing meaningful test fixtures. Customers get insight into new features. It's the new way to give demos.
Technical debt is the perfect candidate for an isolated, quality-enhancing pipeline, because it benefits greatly from small and boring pull requests guarded by meaningful tests. Refactoring in this deterministic context is where every coding LLM will shine.
Why isolated
The isolated nature of these pipelines deserves some more explanation. They are allowed to read all the knowledge gathered about the software system: coding guidelines, compulsory standards, feature passports, roadmaps, product visions. But they should never leak their output into another vertical layer of the process. Otherwise they leave no room for the human interaction and the knowledge building that was and still is inherent to software development.
Pipelines that cover the full process are focused on quantity and only fight symptoms. They duct-tape the real issues, give a false sense of improvement, and will stay around forever, becoming more costly over time as quality keeps deteriorating.
Human-centred
I'm a passionate advocate of keeping people in the loop, so they stay mentally attached to the product and grow together with the product. They should become the experts of your domain. Not an LLM with an empty memory, zero passion, endlessly waiting for the next prompt. I want developers who are motivated to deliver clever solutions in elegant, easy-to-maintain code. Product owners who know the system inside out and bridge the gap with the customer. Customers who trust your company as knowledgeable and reliable. And a user base that feels the value of the money they spend on a quality product that does the job and helps them.
So stop building a single start-to-end pipeline focused on throughput and speed. Build several isolated, quality-enhancing pipelines at the boundaries of the human interaction points.
