When Vibe Coding Meets a Real Developer
Three clients built apps with AI tools, got surprisingly far, then called a developer before going live.
Nobody With Delivery Scars Is in the Room
9 min read
The Tool Did Not Remove the Software
05.08.2026, By Stephan Schwab
Digitalization projects rarely fail because nobody bought a tool. They fail because everyone in the room believes the tool has made software judgment optional. Workflow automation platforms, low-code configuration, better documentation, AI-generated screens, vendor demos, tidy process maps: all of it creates the same dangerous impression that the hard part has been simplified away. It has not. We have heard this promise before. COBOL was supposed to make business programming accessible. Visual Basic was supposed to let ordinary business users build applications. Excel plus VBA quietly became the operating system of half the office world. Each wave made software easier to start and easier to misunderstand. AI is the strongest version yet. In 2026, a serious embedded technical person can build a useful internal tool in days, but only if they bring the scars: tests, deployment discipline, failure thinking, domain questioning, and the judgment to know when the happy-path demo is lying to the room. The missing person in most digitalization rooms is not another vendor. It is someone who has actually shipped under pressure and knows where software breaks. Who in your next digitalization meeting has actually shipped under pressure and can challenge the happy-path demo?
The room usually looks responsible. Business owners describe the process. A vendor explains the platform. Someone from IT asks about access rights. A project manager maintains the timeline. A consultant turns disagreement into a workshop exercise. Everyone nods at the diagram.
Then someone says the fatal sentence: “This is mostly configuration.”
That sentence has cost companies absurd amounts of money.
It sounds modest, practical, and non-technical. It tells management the project is not really a software effort. It is a tool rollout, a workflow implementation, a digitalization initiative, an automation program, a documentation cleanup with a little AI around the edges.
Fine words. Wrong risk model.
If the project changes how work gets done, routes decisions, transforms data, triggers actions, stores state, handles exceptions, and becomes something people rely on every day, it is software work. It may be built with a platform. It may be configured through a graphical interface. It may be accelerated with AI. It may not have a traditional development team around it. None of that changes the underlying reality.
Someone is still deciding behavior.
Someone is still encoding assumptions.
Someone is still creating failure modes.
The question is whether anybody in the room knows what those failure modes look like before the business starts depending on them.
The Old Promise Keeps Returning
Every generation gets a new tool that promises software without software consequences.
The current belief that automation tools and AI can let non-technical people build reliable business systems is not new. It is an old promise with better demos.
COBOL was designed to make business programming more readable and accessible. That was not foolish. It was a serious attempt to bring business language closer to computing. But it did not remove the need for software judgment. It created enormous systems that ran payroll, banking, insurance, logistics, and government operations for decades. Many of them still run because business logic, once embedded, becomes infrastructure.
Visual Basic carried a similar promise into the desktop era. Build forms. Connect data. Automate office work. Let people closer to the business create applications without the ceremonial weight of enterprise software development. Again, useful. Again, not magic. A successful VB application stopped being a little helper and became a system people depended on.
Excel plus VBA did the same thing quietly and everywhere. A spreadsheet solved one annoying process. Then another. Then it acquired macros, buttons, hidden sheets, copied formulas, pasted exports, and a person in finance who was “the only one who understands it.” Years later, the company discovers that a business-critical process runs on a file nobody can safely modify.
Modernizing legacy VBA with AI makes the same point. The hard part is not translating old syntax into new syntax. The hard part is discovering what the system actually does, proving the replacement matches the behavior that matters, and creating enough validation layers that “almost right” does not become business failure.
AI is the latest and most powerful version of this pattern. It lowers the cost of creating software-shaped things. That is useful. It also means a weak idea can become a working demo before anyone has asked the questions that a scarred developer would ask in the first hour.
What happens when the provider times out?
Who owns the data after the process changes?
What gets logged?
What can be replayed?
What is the rollback path?
Which rules are policy, which are habit, and which are folklore?
The tool does not ask those questions with enough stubbornness. A serious practitioner does.
Documentation Is Not Judgment
Better documentation helps only after someone has understood the system well enough to document the right thing.
Documentation is the favorite compromise when nobody wants to admit the room lacks software judgment.
Write down the process. Map the workflow. Document requirements. Create the exception table. Produce the operating manual. This feels safe because documentation is visible, reviewable, and politically neutral. Nobody has to say the uncomfortable thing: the process being documented may already be full of contradictions, hidden workarounds, bad incentives, and rules nobody actually follows.
Automating that gives you executable confusion.
That is why pure configuration so often disappoints. Configuration is not neutral. Every dropdown, mapping, trigger, condition, permission, and escalation rule is a design decision. The fact that it sits inside a vendor tool does not make it less architectural. It just makes the architecture harder to see.
The same goes for AI-generated tooling. The first version can look miraculous. A form appears. A database table appears. An approval flow appears. A dashboard appears. Everyone is impressed because the visible part arrived quickly.
But reliable software is mostly the invisible part.
Validation. Tests. Auditability. Data migration. Error recovery. Role boundaries. Deployment discipline. Observability. Change history. Operational ownership. The boring machinery that lets a system survive after the demo glow wears off.
Vibe coding is not software development: a prompt can create code, but it cannot transfer responsibility. The person driving the work still has to know what “good” means when the happy path is no longer enough.
What Delivery Scars Actually Buy
Delivery scars are not nostalgia. They are pattern recognition earned by being responsible when software met reality.
People with delivery scars are not impressive because they know more tools. They are useful because they have seen the same failure wearing different costumes.
They have watched “temporary” spreadsheets become systems of record. They have seen vendor configuration grow into untestable business logic. They have debugged approval workflows whose real purpose was avoiding responsibility. They have inherited code written by someone who thought documentation would be enough. They have shipped under deadline pressure, broken something, fixed it, written the test afterward, and remembered the bruise.
That experience changes the questions they ask.
They do not ask only whether the tool can do it. They ask whether the organization can live with it.
They do not ask only whether the workflow is documented. They ask which rule will be disputed the first time money, compliance, or customer anger is involved.
They do not ask only whether AI generated the code. They ask who can read it, test it, deploy it, roll it back, and explain it when the generated abstraction leaks into operations.
They do not ask only whether the vendor has a feature. They ask what happens when the vendor’s feature does not quite match the company’s real process, because that “not quite” is where the expensive workaround will grow.
That is why the fashionable title “Forward Deployed Software Engineer” is interesting. Palantir uses it for people embedded directly with customers to configure and extend software for hard operational problems. The label is theirs; the need is broader. The valuable part is not the title. It is the posture: someone close enough to the business to understand the real problem and technical enough to build with production consequences in mind.
In 2026, such a person with AI can move very fast. Days, not months, for a useful internal tool in many cases. But the speed only matters because the work is guided by judgment. Without that, the same speed produces a prettier version of the old Excel macro trap.
The Room Has the Wrong People
If nobody in the room has shipped software under pressure, the room will overvalue tools and undervalue consequences.
Digitalization rooms often contain many people with legitimate authority and nobody with the specific authority that matters.
The process owner knows how work is supposed to happen. The vendor knows the product. The consultant knows how to keep the program moving. The project manager knows the timeline. The executive sponsor knows the budget and the political stakes.
All useful.
Still not enough.
The missing person is the one who can say, calmly and early, “You are creating a software system. Here is where it will break. Here is what we need to prove before anyone depends on it. Here is the smallest reliable version we can build first. Here is what should stay manual until we understand the exception. Here is the test that will keep us honest.”
That person is often filtered out because they do not fit the purchasing category. Too technical for the strategy room. Too broad for the staffing requisition. Too practical for the transformation workshop. Too unwilling to pretend that configuration is harmless.
So the organization buys tools, writes documentation, configures workflows, celebrates the pilot, and discovers later that it created software without the habits that keep software alive.
The lesson is not to reject automation tools. Use them. The lesson is to stop confusing tools with capability.
The Management Test
Before starting the next digitalization project, ask one uncomfortable question:
Who in the room has been responsible for software after the demo?
Not who has selected a platform. Not who has managed a vendor. Not who has written requirements. Not who has facilitated a workshop.
Who has lived with the system after users found the edge cases?
Who has watched a small automation become critical infrastructure?
Who has dealt with a failed deployment, a bad migration, a security mistake, a broken integration, a support escalation, or a business rule that turned out to be wrong in production?
If that person is not in the room, the project is flying blind with better stationery.
AI makes this more urgent, not less. It means the first working version can appear before governance has finished scheduling the steering committee. That is an advantage only when someone with delivery scars is close enough to shape it. Otherwise the organization gets the old promise again: software development made easy for people who have not yet learned why it became hard.
The missing person is not another tool expert.
It is not another documentation lead.
It is not another framework consultant.
It is someone who can build, verify, simplify, and say no before the company turns a demo into a dependency.
That is where real value appears.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
Mornings Start Before You Do
Dawn on the finca introduces Sophie to Esteban's discipline, Rosa's kitchen authority, and the measured rhythm of horses and weather. She tries to ...
The AI Extraction
Back inside on temporary access, Ethan Carter goes after the oldest part of Whitaker Payroll: the COBOL itself. With Nathan Cole beside him, he use...
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
- Nobody With Delivery Scars Is in the Room (05.08.2026)
- Software Flow Is Not Process Theater (01.08.2026)
- When Vibe Coding Meets a Real Developer (28.07.2026)
- Crew Resource Management for AI Pairing (24.07.2026)
- Agentic Coding Is Not 'Make Me X' (20.07.2026)