Had a hard time following the vision here. I actually built comprehensive CI/CD into my personal vibe-coded projects first, before anything else, because it's such a strong feedback loop for agents. Absolutely chews through compute, but building and deploying every change is a huge guardrail against bad code slipping through and it makes validating the end product much easier because every change is already deployed. That sounded like what they were describing.
My setup for CICD with agentic first developing: every pushed commit gets built, so I tell the agent to commit often it gets and check the build logs on the CI side. This also guarantees that the build is correct and the whole codebase, the makefile gets runs and not whatever the agent decided. Every PR gets deployed so I can validate as the human. When you started talking about a queue of stuff the human verifies, I got lost.. isn't that just the commits making up the larger PR basically? And the validation happens on the PR.
The complaint that CI/CD is too slow for agents felt backwards to me. That's a human complaint. My agents have no problem waiting and they actively suggest ways to speed pipelines up when i ask what took so long. They don't get distracted like I do either, I fire off a prompt and immediately context-switch. The pipeline is hooked up to the agent, it validates and surfaces feedback before I even look. I can look at the initial code changes when the PR opens and then validate in the deploy, it's probably done deploying by the time i see the PR open.
The PR deployment also acting as a dev environment for the agent working on that, feature, i give it read access to those services and let it poke around and read logs from services after it changes stuff to validate itself.
When I have a stack of PRs queued up i have the agent that worked on it tell other agents to merge main and what the "intent" was so they can make informed decisions against any conflicts. Maybe my features are too small. Or my personal projects are too small as the lone dev. But I've got 10 things in parallel sometimes.
My setup for CICD with agentic first developing: every pushed commit gets built, so I tell the agent to commit often it gets and check the build logs on the CI side. This also guarantees that the build is correct and the whole codebase, the makefile gets runs and not whatever the agent decided. Every PR gets deployed so I can validate as the human. When you started talking about a queue of stuff the human verifies, I got lost.. isn't that just the commits making up the larger PR basically? And the validation happens on the PR.
The complaint that CI/CD is too slow for agents felt backwards to me. That's a human complaint. My agents have no problem waiting and they actively suggest ways to speed pipelines up when i ask what took so long. They don't get distracted like I do either, I fire off a prompt and immediately context-switch. The pipeline is hooked up to the agent, it validates and surfaces feedback before I even look. I can look at the initial code changes when the PR opens and then validate in the deploy, it's probably done deploying by the time i see the PR open.
The PR deployment also acting as a dev environment for the agent working on that, feature, i give it read access to those services and let it poke around and read logs from services after it changes stuff to validate itself.
When I have a stack of PRs queued up i have the agent that worked on it tell other agents to merge main and what the "intent" was so they can make informed decisions against any conflicts. Maybe my features are too small. Or my personal projects are too small as the lone dev. But I've got 10 things in parallel sometimes.
feel like i'm rambling sry