I use AI agents in development almost daily. They take care of the monotonous boilerplate, speed up navigating cumbersome APIs, and serve as sparring partners to bounce architectural ideas against a wall. Coding agents are useful tools. Dismissing their use out of hand as cheating or the decay of craftsmanship simply ignores reality.
Prompts Instead of Program Understanding
The issue rarely lies in the tool itself. It begins where generating code is mistaken for understanding code.
Under the term Vibe Coding, an attitude has gained traction that declares this exact boundary obsolete: throw in a few prompts, have the AI iteratively churn through compiler errors until a window appears—and consider the result finished software. That yields quick gratification. Within two hours, you see something on screen that previously took days. But a working UI does not prove you know what the application is actually doing in memory, on disk, or across the network. If you assemble software purely by vibe, you stay blind to architecture, edge cases, and security vulnerabilities.
Two Thousand Lines of Main.qml
A working user interface is the worst conceivable benchmark for code quality. Code can be modular hazardous waste and still compile without a complaint. If I tell an AI: "Build me an application with a media player, volume slider, and station list," it outputs precisely that. What matters is how that result comes to life when nobody enforces architectural guardrails.
Frequently, business logic, network calls, state management, and styling end up in a single file. You see this regularly with declarative UIs: two thousand lines in a single Main.qml. Signal handlers are wired directly to UI controls, HTTP requests fire right inside a button's click event, and application state floats implicitly across three nested components. Coding agents rarely catch these structural anti-patterns on their own without explicit rules; the risk is high that they blindly perpetuate bad existing layouts. Each new feature gets tacked onto the existing monolith instead of cleanly separating layers.
As long as the window pops up, nobody notices. The vibe holds.
Things get interesting once reality intervenes: a memory leak, a race condition during asynchronous fetching, or attempting to add a feature without breaking three unrelated modules. If you don't grasp how the construct ticks underneath, you cannot debug systematically. The typical reflex is the next prompt: "There is an error, fix this." The AI slaps a band-aid over the symptom, introduces two new side effects, and the codebase gradually degenerates into a thicket of workarounds.
Rapid Repositories, Abandoned Sites
This rarely stays on local disks; it usually lands unchecked on GitHub.
Because code generation carries minimal friction, projects crop up overnight. A single weekend, thirty prompts, a polished README with colored badges and a demo GIF—and straight into a public repository. The thrill lies in showing it off quickly.
What follows rarely fits into a prompt.
Software ages the second it gets published. APIs change, security vulnerabilities emerge in dependencies, and an upstream release breaks the CI pipeline. This marks the difference between a project that is simply finished and needs no further features, and one that rots away unmaintained.
When the first real issue arrives—a crash under a specific environment or a permission failure—the gap between software engineering and superficial prompting becomes obvious. If you never grasped the inner mechanics of your own project, you cannot maintain it properly. Debugging ceases to be fun because complex defects cannot be resolved with a three-word prompt. Often enough, the predictable happens: after a few weeks, commits stop, issues remain unanswered, and the next project is kicked off in a fresh chat window.
Nobody owes the world lifetime support for a hobby project. But an honest note in the README—"Proof of Concept, not actively maintained"—saves other people valuable time.
Guardrails Instead of Autopilot
You can approach this differently: as a fast assistant subjected to rigorous scrutiny.
That starts well before the first line of code. Anyone building software must first map out the system:
- Where does data reside? Who communicates with whom?
- Where is the line drawn between core logic, state, and presentation?
Once that architecture is defined, the workload can be broken down into manageable pieces. Instead of a sweeping instruction like "Build me the application", the model receives a concrete interface contract, an isolated parser task, and matching unit tests for edge cases and malformed payloads. The more clearly context and boundaries are constrained, the less room remains for unchecked generative sprawl.
Then comes the code review.
You don't need to recite every line of standard code in your sleep. But you must understand the broader picture and possess the technical competence to review the generated code:
- Why did the model choose this particular approach?
- What happens to open sockets or file descriptors on a connection drop?
If I cannot reason through an implementation, it does not stay in the repository—regardless of whether it happened to pass the initial smoke test.
Responsibility in Front of the Terminal
Ultimately, a coding agent acts as a lever: it amplifies disciplined engineering just as readily as sloppy superficiality. Responsibility for architecture, commits, and security risks remains squarely with the human at the keyboard.
Nobody is expected to start as a finished software architect. If someone experiments with language models to get their foot in the door of programming, by all means, go for it. There is currently hardly a faster tool to explain concepts, protocols, or unfamiliar APIs—provided you use it to understand, rather than to outsource critical thinking. Smoothly worded explanations can still be flat-out wrong; verifying them against official documentation and live system behavior remains non-negotiable.
Software development was never about typing syntax. That has always been merely the execution layer. The actual core was and remains comprehending systems, weighing trade-offs, and catching the subtle failures nobody thought to put into the prompt.
The vibe lasts only as long as operating conditions are forgiving. It vanishes at the first deadlock or the first serious security flaw in production. What matters then is neither gut feeling nor a prompt, but the ability to understand and repair the system down to its fundamentals.