Vibe Coding Isn't Software Development
Vibe coding feels magical in demos, then breaks on contact with real systems.
Designing Systems in Dialogue With AI
9 min read
The Agent Is Not Your Night Shift
01.05.2026, By Stephan Schwab
The most expensive sentence in AI-assisted coding is: "I'll write a really detailed specification, let the agent work overnight, and review it in the morning." It sounds efficient right up until you inherit a mountain of plausible code built on three wrong assumptions. By March 2026 the tools are real, useful, and fast. The fantasy is still nonsense. The skills did not disappear. They got more important.
Tooling Matured. The Fantasy Didn’t.
"The tools got better at generating code. They did not become accountable for design decisions."
By March 2026, AI-assisted coding had clearly split into a few families.
There were IDE copilots that stayed close to the file, terminal agents that could inspect a repository and run commands, and longer-running agents that could work across branches, tickets, and pull requests. GitHub Copilot, Cursor, Windsurf, Claude Code, Aider, Cline, OpenHands and their cousins all pushed in roughly the same direction: less typing, faster feedback, broader context, more autonomy.
That part is real. These tools can read more code than most people want to read, sketch a feature quickly, propose migrations, write tests, explain old modules, and grind through the kind of repetitive changes that used to drain an afternoon.
But the popular story around them stayed childish. People kept acting as if the right prompt plus a long enough specification would turn an agent into a trustworthy night shift. It won’t. You are not delegating a closed task to a reliable specialist. You are entering a design conversation with a system that is fast, helpful, probabilistic, and dangerously willing to continue past a bad assumption.
The Skills Didn’t Go Away
"AI reduces typing. It does not remove the need for systems design, software development fundamentals, or experience."
This is the misconception doing the most damage right now. People see code appear faster and conclude that the underlying skills are obsolete. They aren’t. The tools removed some manual work. They did not remove the need to understand what makes a system hold together.
Someone still has to reason about boundaries, state, transactions, failure handling, observability, security, performance, testability, and change over time. Someone still has to know why a clean demo can hide a rotten design. Someone still has to notice when the generated code solved the local prompt while quietly damaging the larger system.
That is why experienced developers keep getting more leverage out of AI than inexperienced users. Experience is not just the ability to write syntax from memory. It is pattern recognition built from incidents, regressions, broken deployments, ugly migrations, race conditions, and design decisions that looked clever until reality got a vote.
The agent can generate ten options in a minute. Experience is what tells you that eight of them are traps.
Designing in Dialogue Is the Point
"The conversation is not overhead. The conversation is where the system design happens."
The good use of AI-assisted coding is not “tell it what to build.” The good use is “use the dialogue to force the design into the open.”
A productive conversation with an agent leaves behind artifacts. Not vibes. Not confidence. Artifacts.
- A glossary of business terms that stops everyone from using the same word for five different things.
- A state model that makes valid and invalid transitions explicit.
- Interface contracts and example payloads.
- Tests that lock down behavior before implementation drifts.
- A migration plan, rollback plan, and monitoring checks.
- A short list of decisions that still need a human owner.
That is the part people miss when they talk about prompting. Prompting is the least interesting part. The real gain is that you can interrogate the design from multiple angles without paying the old transcription tax.
You can ask the agent to model the workflow as states. Then ask where the states leak. Then ask which transitions need transactions. Then ask what happens when the external provider times out after side effects have already started. Then ask for tests that would prove the invariant holds. Then ask which parts are still underspecified. That is not typing assistance. That is accelerated system design.
What a Good Dialogue Sounds Like
"Useful conversations with agents revolve around constraints, failures, and evidence. Bad ones revolve around optimism."
If you want better output, stop asking for polished features first. Ask for structure.
- Model this workflow as states and transitions before writing code.
- List the invariants. What must never happen, even under retry or concurrency?
- Show the failure modes before you show the happy path.
- Which assumptions in this design are business decisions rather than technical ones?
- Propose tests that would catch a broken implementation.
- Generate the thinnest vertical slice that proves the design is viable.
- Tell me what you still cannot know from the repository and current prompt.
That last question matters more than the others. Good developers know that unknowns are usually where the damage hides. A model that answers fluently is still missing context about politics, hidden dependencies, compliance rules, customer behavior, operational pain, and the small ugly scars every real system accumulates over time.
This is why dialogue beats delegation. A dialogue can surface uncertainty. Delegation hides it until production does the reveal.
And this is exactly where foundational practice still matters. If you don’t understand testing, modular design, data integrity, versioning, deployment risk, or how distributed failures behave, the agent will not save you. It will simply let you make bigger mistakes at higher speed.
The Specification-Overnight Myth
"A specification is necessary. A prose specification without executable checks is just better organized hope."
The overnight-agent fantasy usually starts with a respectable instinct. People finally realize that vague prompting is useless, so they decide to write a proper specification. Good. They should.
Then they make the fatal leap: once the specification is detailed enough, the agent can work alone.
No. That is where the logic breaks.
Specifications written in prose are full of traps:
- Business terms that look settled until two stakeholders define them differently.
- Flows that sound linear until retries, cancellations, and partial failures show up.
- Security and compliance requirements that were never written down because “everyone knows that.”
- Legacy constraints that live in one senior developer’s memory and nowhere else.
- Operational realities such as rate limits, broken data, and support workarounds that no product brief ever captures.
The spec is not useless. The spec is the opening move.
The next moves are the ones that matter: challenge the language, turn claims into tests, turn flows into explicit states, turn interfaces into examples, turn failure handling into observable behavior, and keep asking where the design still depends on guesswork. If the agent helps you do that faster, good. If you hand it the document and disappear, you are not automating development. You are automating denial.
What the Agent Can Actually Do Overnight
"Let the agent expand options overnight, not own the decision overnight."
There is useful autonomous work. Just not the magical version.
An agent can spend hours generating alternatives, mapping a codebase, summarizing dependencies, drafting tests, building throwaway spikes, comparing schemas, or preparing refactoring plans for review. That is excellent background work. It widens the option space before the next design conversation.
What it cannot do responsibly is decide which tradeoff your business should live with.
It cannot own whether eventual consistency is acceptable for refunds. It cannot decide whether your support team can survive a manual fallback. It cannot infer which customer segment matters more when two workflows conflict. It cannot be blamed when the migration window is too small and the rollback is fake. Those are not coding problems. Those are decision problems.
The tool can help frame them. It cannot inherit them.
The Practical Workflow That Works in 2026
"Short dialogue loops beat heroic prompts. Always."
A sane workflow for AI-assisted coding in 2026 looks boring. That is why it works.
- Start with the smallest business outcome that matters.
- Use the dialogue to define terms, states, invariants, and failure modes.
- Ask the agent for tests, examples, and a thin implementation slice.
- Run the checks. Read the diffs. Challenge the assumptions.
- Tighten the design through another short round instead of writing a grander prompt.
- Keep the resulting artifacts: tests, diagrams, notes, scripts, and decision logs.
This loop fits the actual tool landscape of March 2026. The models are good enough to be useful in every round. They are not good enough to skip the rounds.
That is why tests beat instructions for AI coding agents and vibe coding is not software development both matter. The better the models get, the more expensive sloppy thinking becomes, because the machine can now turn sloppy thinking into a lot of code very quickly.
The Misconception Behind the Hype
"People think the agent replaces the builder. What it really replaces is the dead time between decisions."
That is the actual shift.
The old workflow had long gaps between intent and feedback. You described the change, wrote the scaffolding, searched the codebase, checked the docs, ran the tests, fixed the obvious mistakes, and only then got back to the real design question. AI-assisted coding compresses those gaps.
That compression is valuable. It is also easy to misread. Faster iteration feels like finished thinking. It isn’t.
The people getting the most out of these tools are not the ones trying to escape system design. They are the ones using the dialogue to do more of it, earlier, with less friction. They treat the agent like an aggressively fast collaborator who needs supervision, not like a substitute for judgment.
The people getting burned are usually chasing the opposite fantasy. They want the output without the craft. They want system quality without design discipline. They want maintainability without testing. They want reliable change without understanding what can break. AI-assisted coding does not grant any of that. It mostly exposes whether it was there in the first place.
The Hard Part Still Has an Owner
"AI is very good at continuing the work. Someone still has to decide what work is worth continuing."
You still need a human who can smell a fake simplification, spot missing constraints, and ask the question nobody wanted to ask.
That is not a temporary limitation that vanishes with the next model release. It is the nature of building systems in organizations. Systems live inside budgets, habits, incentives, grudges, production incidents, and half-kept promises. The code is only one layer.
So yes, use the tools that existed in March 2026. Use them aggressively. Let them read the repo, sketch the module, draft the test, explain the legacy mess, and propose three ways through the swamp.
Just do not confuse dialogue with delegation.
If the conversation produces better constraints, better tests, and better decisions, AI-assisted coding is a serious advantage. If the conversation is replaced by a handoff and a wish, it is just expensive theater.
Contact
Let's talk about your real situation. Want to accelerate delivery, remove technical blockers, or validate whether an idea deserves more investment? I listen to your context and give 1-2 practical recommendations. No pitch, no obligation. Confidential and direct.
Need help? Practical advice, no pitch.
Let's Work Together🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
Amor y Pérdida
As Valentina races to the hospital, her mother clings to life just long enough to share one final truth — and give her blessing. Diego kneels in th...
The Outsider
Stefan Richter arrives at Pixel Spree on a Monday morning in late April. No kickoff meeting. No transformation roadmap. He walks the development fl...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- Designing Systems in Dialogue With AI (01.05.2026)
- What AI Changed About Software IP (24.04.2026)
- Pull Requests Were Never Meant for Your Team (20.04.2026)
- Tests Beat Instructions for AI Coding Agents (17.04.2026)
- Vibe Coding Isn't Software Development (13.04.2026)