DEV Community

Sergey Shkuratov
Sergey Shkuratov

Posted on

LLM-Assisted Deploy: You Save Typing, Not Thinking

TL;DR

An LLM helped me put together a deploy in about an hour, but only because I did not hand the deploy itself over to it.

What happened

I know how to write deploy scripts. Not in theory — I’ve done it many times, and usually I just sit down and write one.

This time the problem was not how to write it. The problem was time. And I had absolutely no desire to break anything along the way.

So I did not play the game of “the LLM will neatly put this together for me.” In semi-automated deployment, that is an unusually bad idea. Instead of a beautiful result, you get a beautifully broken site lying on the floor.

I did something else.

I defined the script structure myself, based on my previous experience. I spelled out what exactly the deploy had to do, where the boundaries were, what control points existed, what counted as success, and what was a reason not to proceed. Then I fed that text to the LLM and had it write the bash script.

In other words, the model helped where the cost of error was relatively cheap: typing code.

Everything that actually had a price stayed manual: decisions, review, checking the logic, and running it in a safe environment.

In the end I got two scripts: deploy-preprod.sh and deploy-production.sh.

That separation mattered to me. Production should not “just go” directly. First the preprod gate, then production. And I also kept a standard trick of mine for production deploy confirmation — a kind of textual captcha: the script prints a random code to the console, and nothing moves until you type it in by hand. It is not protection from a malicious hacker. It is protection from an overly easy, overly mechanical “fine, let’s just ship it already.”

It took four iterations. Honestly, that is not a sign that the approach was bad. Quite the opposite.

Across those passes, exactly the usual crap surfaced — the kind that makes deployment dangerous: typos, wrong variables, bad log parsing. Nothing conceptually interesting. The code itself looked fairly brisk. The irony was that the code had been written by the LLM — perhaps it was in a hurry too and did not want to get distracted from taking over the world.

My verification was not in the “well, looks reasonable enough” genre either. A more reliable approach after the containers start is to automatically scan the docker-compose logs for obvious signs of errors. Then do a manual smoke check — log in and walk through the key flows. I did think about e2e, but for this task I decided it would be overkill. What I needed at that moment was not a perfect automation contour, but a reproducible deploy with explicit control points and predictable failure behavior.

If you ground this in the actual scripts, the line between “accelerate” and “hand over control” becomes pretty clear:

  • preprod reproduces an exact copy of the production site before the deploy itself, which is feasible because the site is small;
  • production refuses to run with latest;
  • production refuses to do a no-op deploy on the same tags;
  • before production, the preprod gate runs and fails if preprod is unhappy about anything;
  • there is an explicit failure if Postgres does not come up;
  • there is a log check for error, exception, traceback, panic, and fatal;
  • there is manual confirmation before production.

So the LLM did not “do the deploy.” It helped me assemble the code around a structure and a set of constraints that I had already defined.

All in all, it took about an hour.

Takeaways

The LLM saved me time, but not where many people dream it will. Not on responsibility. Not on the engineering decision. Not on verification. It compressed the draft phase — the keyboard pounding. Everything critical was still manual engineering work.

For tasks like this, that is what a sane LLM-assisted mode looks like: do not delegate risk to the model; use it to strip away the mechanical part so more attention remains for architecture and for the control points where mistakes are actually expensive.

A minute of thought increases uptime by an hour.

Top comments (0)