How I Ship Production Features with AI Agents (Not Just LinkedIn post or Promotion PoC Demos) | Tech Oriented Chroniclesđź”® of Petros
AuthorsNamePetros SavvakisTwitter@PetrosSavvakis<br>How I Ship Production Features with AI Agents (Not Just LinkedIn post or Promotion PoC Demos)<br>Agentic coding, harness, vibe coding, AI teammates... and more. Those are only some of the "cool" keywords that come up in 2026's engineering space. All that is cool and it means new things to try, experiment, and tinker with... but what does it really work like, at least from what I have tried in my case, across personal projects and independent collaborations?<br>Let's first do a step back and tell you that for the last few months I am just an orchestrator and mostly a code reviewer. I rarely write a full script of code as I did in the past. The most common time that I need to write code is going into CAVEMAN MODE = ON (I first heard this term from Charlie Holtz - Conductor CEO via Conductor's manual mode) and we adopted it. It's the time when we must do manual typing for quick file edits (like config or .env files) when an AI model struggles to complete the task or you don't want to expose .env values to agents.<br>With all that in mind, let's stop the jargon and deep dive into what seems to get real results. For the last months, across personal projects and independent collaborations, we've been shipping features like crazy (that are truly working and are fully tested—not just vibe-coded running in localhost, but in production serving real users). In order to do that, you have to make a legit pipeline that acts like PID Adaptive Control (for those of you that are electrical engineers, you know what I mean)—a system that is self-calibrated and can generate stable and real production results. Enough said, let's move to the architecture of it.<br>The Workflow: One Human Orchestrator, Three Terminals, One Controlled Loop<br>Here is the system that has been working for me.<br>I do not open one agent, throw a vague prompt at it, and hope that something useful comes out at the end. That is the fastest way to get a very convincing demo, a large diff, and a future production incident.<br>For every meaningful feature, I start by making the problem extremely concrete.<br>What are we building? Who is using it? What can break? Which API contracts, database models, conventions, security rules, performance constraints, deployment requirements, and existing architectural decisions must remain intact? (Basically acting like product owner and tech lead.)<br>The more ambiguous the task is, the more work happens before any code is generated—and this is the most crucial part. If something is not clear, then Garbage In, Garbage Out...<br>The plan is not "add feature XYZ". The plan is closer to:<br>Which modules will change and how<br>Which data models and endpoints are affected<br>Which existing flows could regress<br>Which migrations, feature flags, permissions, tests, or telemetry are required<br>What the acceptance criteria look like before implementation starts<br>Which repository rules and conventions the agents must obey<br>This is where repository specific rulesets become extremely important. An agent should not have to rediscover your project architecture every time it starts. It should know the conventions of the repo: how we structure services, how we validate inputs, how we access databases, how errors are handled, how tests are written, how containers are built, and what "done" actually means. For my case, I save all that under the .claude folder, then I separate it into rules folder and context folder.<br>Once the task is really clear, the actual pipeline starts.<br>1. Planning: Turn Business Requirements into an Implementation Contract<br>The first agent is the planning agent , which I found out that Opus 4.8 does a good job for, in contrast to GPT 5.5 (but this is case specific).<br>Its job is not to write code yet. Its job is to decompose the feature into an implementation plan that another engineer can execute without guessing.<br>I usually ask it to inspect the relevant areas of the repository, identify dependencies, describe the files likely to change, highlight risks, and define the tests that must exist once the work is complete.<br>This is also the moment where I challenge the plan heavily, and sometimes if it is complex enough, I take time to draw the graph in Mermaid to get a more clear understanding before doing anything.<br>Does it touch a shared model? Does it change a critical endpoint? Could it affect historical data in the database? Does it need a migration? Are we introducing a race condition, a security risk, an N+1 query that slows the whole app, or an operational issue that will only appear under load?<br>The goal is simple: reduce ambiguity before the development agent starts spending tokens and changing files.<br>A bad plan produces bad code way faster, and you end up fixing in a recursive loop.<br>2. Development: Give the Builder Context, Tools, and Clear Boundaries<br>The development agent is...