Let me be clear. I do not like the term “vibe coding.” The label is sloppy and the concept it pushes is even sloppier. It lumps together two very different practices and turns a serious profession into a trend.
On one side, experienced developers use AI to speed up real work. They ask pointed questions, draft scaffolding, and translate patterns, then verify the result. On the other side, people try to chat their way through an entire build with little grasp of the system they are changing.
The question worth asking is simple. Does AI, used well by capable engineers, actually move the needle on developer productivity, or are we just shifting the bottlenecks to later stages of delivery? In this article, I highlight where AI assistance provides the most value and where it can create drag.
There are real gains when developers use AI as a tool instead of a crutch. Some of the value I have seen AI provide includes:
Targeted troubleshooting: When you hit a weird error, copying it and asking an AI to explain it in plain language saves time. It is not doing the fix for you. It just gets you to the next useful step faster.
Boilerplate and scaffolding: Starting a greenfield app is slow and repetitive. You set up the project structure, pick build tools, wire a router, add a basic test, create env files, add a Dockerfile, and sketch a simple CI step. An LLM can draft those first passes so you can get to coding sooner.
Shortening learning curves: When using a new framework, tool, or API, asking an LLM for assistance reduces the time to implement it. You still need to read the docs to verify behavior, but you spend less time searching.
AI shines when tasks are well bounded, written in popular languages, and live in greenfield or lightly coupled areas. The value drops as complexity rises, especially in large brownfield systems with hidden constraints, custom SDKs, or tight non-functional requirements. Treat it as a collaborative tool that boosts capable engineers. Keep expertise, design choices, and verification in human hands.
The value rarely shows up in DevOps metrics, but it stacks up across a day. This is the productive middle ground. Use AI to remove friction and amplify judgment. Keep the system understanding, trade-offs, and accountability with the developer.
When attempting to use LLMs to code a full application, unless it is a very simple greenfield application that has been written before in a popular language, you will simply move time from the beginning of the development cycle to the end in debugging. There is a joke that goes, “Writing code yourself means six hours of writing code and two hours of debugging. Using LLM-generated code means five minutes of writing code and twelve hours of debugging.”
Some of the errors that can surface when “vibe coding” include:
Invented APIs: Models confidently call methods that do not exist in real SDKs. You chase a mirage and discover it late.
Hidden constraints: A suggestion compiles but breaks idempotency, retry logic, or permission boundaries. The issue appears under load or during rollout.
Prompt drift: Each fix leads to a new prompt. Naming, error handling, and patterns diverge across the codebase.
Shallow understanding: The model does not hold the full picture of your system. It cannot reason about product intent, non-functional requirements, or the trade-offs you already accepted.
Early signals are easy to spot. Answers that cannot cite exact versions and function names. Code that passes type checks yet fails obvious domain tests. A stack of “quick” pull requests that need several back and forth review cycles.
I do not believe teams need a new ceremony or elaborate guardrails for vibe coding. They need to train developers on how to use AI well and keep humans in the loop for anything that matters. Treat the model like a power tool, not an autonomous junior engineer.
Some practical AI habits that work:
Ask specific questions: Narrow prompts produce outputs that are easier to verify.
Ground the model: Provide the relevant docs, interfaces, and examples so it works against your actual surface area.
Keep changes small: Prefer small diffs with tests over large generated patches. Review is faster and safer.
Verify before you trust: Run the code, write or run tests, and check behavior in a realistic environment.
All developers should understand what an LLM is and is not. Model providers have published guidance on how to use these tools effectively. Before companies allow developers to leverage AI, they should enable them to understand what they are using and what it should and should not be used for.
The bottom line is that AI will continue to augment developer work, and developers will use it regardless of whether they are allowed to or not. It can generate code, translate patterns, and speed up repetitive tasks. It does not understand product vision, user needs, or the constraints that shape good engineering. Teams that keep experienced developers in control, ground the model in real context, and invest in training will see benefits. Teams that try to chat their way to complete systems will inherit a mess they cannot explain.
That is the real impact on productivity. The tool saves time for people who already know what they are doing, and it magnifies confusion for those who do not. Train for the first case, avoid the second, and focus on the fundamentals that make software delivery fast and reliable.
