DevOps and Vibe Coding: A Journey

Source: Dev.to

Things to Do

Map Your Application

• Map your application on paper, in a spreadsheet, or using graphics/flowcharts. This is the first step.
• Understanding the actors (variants of users) and the flows (the paths they can take to interact with data) is paramount for smooth development.

Iterate Over Research

• You have an idea and a vision: which route do you take? Supplement guessing, building, and rebuilding with dedicated research.
• You don’t need to open a textbook, but you should be asking questions in Google or your favorite LLM to help identify the right paths.

Use Example Applications as Guidelines

• You aren’t the first and won’t be the last person to have an idea that’s already been done. Find a competitor, ask for an analysis of their tech stack, and use that as a starting direction.
• You don’t need to reinvent the wheel; it’s already been built. Learn from it and make it cooler—better traction, durability, etc.

It’s the simplicity that makes it feel approachable: map & plan, research, and influence. (Imitation is the sincerest form of flattery. If something’s already been done, it should give you confidence that you can do it too.)

Things to Avoid

Don’t Confuse Jobs/Services with VMs

• GCS Jobs run “in the cloud” like serverless functions. A Docker container is all you need if the goal is to start, process data, and then stop.
• A VM is perfect for “Infrastructure as a Service,” better suited for longer‑running tasks, legacy code, and OS‑level control.

If you confuse the two, you might end up like me:

Don’t use Cloud Run Jobs for long‑running tasks!

MIGs and Spot VMs Are a Double‑Edged Sword

• GPU VMs can be out of stock depending on the region, rendering your VM useless when you need it.
• Managed Instance Groups (MIGs) can deploy spot VMs (ephemeral VMs that can be preempted at any time), giving you a dynamic fleet. The downside is that they may be preempted mid‑job, forcing you to choose between:
  1. An always‑on VM
  2. A fleet of fallback VMs that can be turned off at any time
  3. A dedicated machine you pay a premium for

Decide what you need before you start building—don’t swing your hammer randomly as I did.

Take Notes and Be Deliberate with Testing

• Write down what you’re doing; don’t assume the LLM knows what it just built. In troubleshooting and testing, duplicated code can lead to nightmares when debugging.
• Actively test with a suite of tests: working locally with one user is entirely different from handling hundreds of users at scale.

Conclusion

The DevOps experience is the “other side of the coin” in software development. Tools like Xano, which handle routing as a self‑orchestrated system, let me focus on the pipeline and logic without getting bogged down in additional DevOps overhead. I can fire‑and‑forget on the base application layer and concentrate on routing and scaling for the pipeline and render layers.

There’s deep appreciation for those who started their DevOps journeys before the Agentic Era—imagine building without AI‑assisted development! The AI era doesn’t remove DevOps; it amplifies the importance of good architecture.