Agentic Engineering: Protect Your Production Environment

This has been really interesting to watch over the last year and a half with the rise of agentic engineering.

For the better part of the last year, we've seen engineers simply refuse to use the technology.

"I'm not going to do that. I'm going to write and manually review code for the rest of my life. I don't care."

Well, obviously, you're not seeing as many of those debates as you were a few months ago because those engineers have probably been told, "Hey, you need to start using AI tools or you need to find another job."

More recently, though, I've started seeing the other extreme.

I'm seeing posts where engineers on engineering teams using agentic processes are bragging that they're no longer using PRs or any type of production release process. They're just committing directly to main and letting the code deploy.

And they're bragging about it like, "Wow, this is amazing. Aren't we cool?"

This is the other extreme, right?

We went from: "I'm not going to use AI at all. Screw AI. It's evil." to: "I'm not going to use any gates or guardrails at all. Screw that. I'm just going to commit directly to main and let it deploy. Look how cool I am."

I don't know if this is purely a case of having a big ego or if it's just stupidity.

But my advice on this topic is simple: Don't do it. Do not do it.

Yes, hallucinations have gotten better with AI. But you still have to check things. You still have to validate your changes before you push them to production.

I recommend having at least two different model sets, or two different agentic validation agents running on at least two different LLMs, to independently validate that your changes are working.

And you need to perform that validation in an environment that is not production. That could be staging. It could be a PR environment. It could be some other isolated environment.

Because here's the thing: your main branch is your gold. It's your source of truth. When you commit directly to main without proper validation, you are corrupting your source of truth. You're tainting it. You're contaminating it.

So stop doing this. Come up with reasonable gates to production. Establish reasonable pathways to production. Build a reasonable release process.

Because if your AI agent wipes your production database clean, introduces new bugs into your production code, and you start experiencing downtime that you're unable to recover from, that's not AI's fault. It's your fault. It's humanity's fault.

If you're not sure how to do this, contact engineers like myself who understand these processes. I can help give you some pointers.

But the bottom line is this: protect your main branches in your production repositories. Protect them at all costs. Make sure that the only thing you commit to main is code that has been properly validated and vetted.

And I'm not saying that validation needs to be done by human eyes. This is agentic engineering. If you're manually writing code or manually reviewing every line of code, you're missing the point of agentic engineering.

Build agents. Build teams of agents. Have those agents perform the work necessary to give you confidence that the quality of your output is up to par. You do this through trial and error. You refine the process over time.

Have a solid production release process. Have a solid merge to main process with the necessary approvals. And if you're just starting out, get as many approvals as you can. Make the process a little more restrictive. Add some extra red tape.

It might slow things down. But it will keep your production environment running. Be smart.