Development in the Age of AI: When Vibe Coding Hits Production

Q: What does "vibe coding" actually mean?

The term has drifted. As originally coined, it described AI-guided code generation via natural language. In practice today it covers everything from professional engineers using AI as a force-multiplier inside disciplined architecture to non-technical builders generating small applications without any architectural framing. The two are radically different activities with different risk profiles. The distinction that matters is not the tool — it is whether anyone is actively making the architectural decisions that determine whether the artifact can survive contact with a production environment.

Q: What does documentation-first architecture mean and why is it suddenly important?

Documentation-first means writing the architectural plan, feature scope, testing strategy, and integration points before writing the implementation. It has always been a recommended practice; it is now load-bearing because AI generates code based on the context it is given. Thin context produces thin code. A thorough specification of the system, existing patterns, failure modes, and required tests dramatically improves AI output. The documentation is no longer just for human readers — it is the primary input that determines the quality of every AI-generated line.

Q: Should our SMB build custom software with AI or stick with SaaS?

It depends on operational maturity, what percentage of features the business actually uses in current SaaS spend, and the availability of someone who can maintain whatever gets built. For a small organization using a packaged tool well, the answer is almost always to keep buying. For a mid-market firm paying hundreds of thousands per year for a platform whose features they use 20% of, the build-or-wrap conversation is now real. The right answer is rarely the most dramatic. Most organizations are better served by wrapping AI around their existing data and tools than by replacing platforms wholesale.

Q: How should an MSP actually monetize AI services in 2026?

The losing strategy is reselling licenses — that race ends at the vendor's direct channel or the client's procurement department. The winning strategy is selling the wraparound work that determines whether AI delivers a margin or a lawsuit: risk policy, vendor governance, data-leakage controls, audit trails, and the internal automation playbook the client cannot build alone. These services look like the security and backup advisory work MSPs already sell, applied to a new surface area. The clients who will pay are the ones whose general counsel has started asking AI questions and whose owner does not yet have an answer.

The most consequential fact about AI in the workplace right now is not a model release or a benchmark. It is a productivity gap. Senior developers are reporting roughly 81% productivity gains from AI tooling. Junior developers are reporting 15 to 25%. The headline is comfortable; the implication is not. AI does not lift everyone by the same multiple. It rewards judgment, and it punishes its absence. Inside the managed services industry — where the hardest decisions are about who to hire, how to deploy them, and what work is worth keeping in-house — that asymmetry is not a curiosity. It is the next two years of operating strategy compressed into a single statistic. For the long version of that argument from a different operator's chair, the conversations on enterprise roots and MSP AI strategy and on automation, AI, and the next MSP leap are the right companion reading. What follows here is the architect's view from the other side of the build.

Bryan Reynolds has been writing software for thirty years and running Baytech Consulting for seventeen of them. He is also the architect actually building the Vision app for Bering McKinley — which makes him exactly the wrong person to play AI cheerleader and exactly the right person to talk about what holds up when the demo ends and the production system has to keep running. The conversation that follows is not about which model is best this month. It is about what survives a year. It is about the discipline that lets a leadership team ship faster without inheriting a codebase no one can confidently touch. It is about the build-versus-buy-versus-wrap decision every SMB owner now has to make whether they realize it or not. And it is about the strategic prize sitting in plain sight for any MSP willing to stop reselling AI licenses and start selling the wraparound work — the policy, the audit trail, the governance — that determines whether AI delivers a margin or a lawsuit. The hype layer is full. The discipline layer is wide open. This is the architect's argument for why the second layer is where the money will be.

Listen on Your Favorite Platform

The Productivity Gap Is the Real Story

The headline statistics about AI productivity are doing real damage because they average across populations that should never have been averaged. Senior developers — the ten-, twenty-, thirty-year veterans with breadth across multiple systems — are reporting somewhere around 81% productivity gains from AI tooling. Junior developers are reporting 15 to 25%. The aggregate sounds great until you sit inside it. The aggregate is the average of two completely different trajectories. The senior knows what to ask. The senior recognizes when the answer is wrong. The senior carries a mental library of patterns that AI can refresh in seconds but cannot install. The junior is being handed a tool that ships code faster than they can evaluate it, and most of them have neither the mentor nor the time to learn the difference. The MSP and SMB implication is identical to the engineering implication: the operational floor under your business does not rise with AI. The ceiling rises for people who already had judgment. The gap between them widens. Treating that as a benefit means investing in the people, the systems, and the mentorship that let an organization actually capture the upside — not just licensing more seats and waiting.

AI is a leverage instrument; leverage applied to weak judgment compounds error faster, not slower.
The senior-junior productivity gap is the strongest argument anyone has made for mentorship, peer teams, and structured technical apprenticeship in a decade.
The first AI investment most companies should make is not a tool. It is the deliberate cultivation of the judgment that uses the tool well.

"Vibe Coding" Is Fine — Until It Hits Production

The trouble with the term "vibe coding" is that it collapses two completely different activities into one phrase. Generating a prototype on a Saturday morning to test an idea is one thing; that work is supposed to be disposable. Shipping the output of that same generation pattern into a production system that handles customer data, payments, or compliance evidence is something else entirely. The distinction is invisible from the outside, which is precisely why business owners get fooled by their own demos. The application that took ten days to build looks identical to the application that will keep running for ten years. They are not the same artifact. Production code requires gated environments, deployable migrations, isolated services, observable failure modes, and a recovery story for the day something goes wrong. None of those things are emergent properties of a model that has been asked to "make it work." They are deliberate architectural decisions that someone has to make on purpose. When that decision-maker is missing, the cost does not show up on the day the code ships. It shows up six months later, when no one on the team can confidently change a single line of it.

Prototyping and production are two different jobs; AI shrinks the cost of prototyping faster than it shrinks the cost of production discipline.
The "10x faster" headline numbers almost always describe prototype velocity — not maintainable, deployable, recoverable software.
If a vibe-coded artifact crosses into production without architectural review, the team is renting time from a clock no one is reading.

The Discipline That Suddenly Matters Again

The most counterintuitive finding from working with AI at production scale is that the disciplines old-school architects spent twenty years arguing about — documentation, unit testing, integration testing, isolation, reusable components — are not getting less important. They are getting more important, because AI is now the primary consumer of that documentation. The pattern at Baytech now is documentation-first: a feature is described before it is built, the architecture is named, the tests are scaffolded, and only then is AI given the assignment. The plan gets reviewed and revised — sometimes three or four times — before a single line of code generation runs. The output gets verified against the tests. None of that is an AI safety theater. All of it is the same engineering hygiene that has always separated a system that lasts from a system that limps. The difference now is that the cost of skipping it has gone up. AI generates more code in less time, which means more code with less context per line. The only thing that prevents that math from compounding into an unmaintainable mess is the architectural blueprint sitting behind it.

Documentation-first is not a slowdown — it is the only way AI gets to ship more code without the team losing track of what was shipped.
Unit and integration tests are the last line of defense; the value is not theoretical when the AI just generated 800 lines you did not read.
Isolating AI-generated work into bounded modules limits blast radius — the blast does not become a question of if, but of where.

Build, Buy, or Wrap — The SMB AI Decision

Most small and mid-sized businesses do not have an AI strategy. They have a ChatGPT license, a hopeful directive from leadership, and a quietly growing list of departmental subscriptions no one has audited. The next two years will force the same business owners to make a much harder decision than which model to license. The cost of building custom software is collapsing fast enough that "force-fit the business into off-the-shelf SaaS" is no longer the default answer. Whether an organization should build the thing itself, buy a packaged solution, or wrap a model around its own data is now a real choice with real economics — and most owners have neither the framework nor the technical counsel to make it well. The right answer is rarely the most aggressive one. A tiny shop with twenty employees still benefits more from a clean wrap of an existing tool than from a custom build. A mid-market firm spending half a million a year on a SaaS platform whose features it uses 20% of has a different conversation to have. The decision turns on operational maturity, financial leverage, and the ability to maintain whatever gets built — which is exactly where most owners discover they need a partner, not a license.

"We need an AI strategy" almost always means "we have not yet decided what problem AI is going to solve for us."
The build-buy-wrap decision is now a real one for every SMB; the SaaS apocalypse is real, but the right answer is rarely the most dramatic.
The deciding variable is operational maturity — can the business actually maintain what gets built or wrapped, or is the owner buying a problem dressed as a solution?

Where the MSP Margin Actually Lives

The MSP positioning challenge is sharper than the industry has acknowledged. Forty-eight percent of MSPs identify AI as the number one client need for 2026. Only thirteen percent generate meaningful revenue from AI services. That gap is not a competitive problem. It is a positioning problem. The MSPs trying to monetize AI by reselling licenses are in a race to the bottom against the vendor's direct channel and their own client's procurement department. The MSPs that will close the gap are doing something else: they are selling the wraparound work that determines whether AI delivers a margin or a lawsuit. Risk policy. Vendor governance. Data-leakage controls. Audit trails. The internal automation playbook that the owner cannot build alone. None of those services compete on price with a license fee, because none of them are licenses. They are advisory and execution work that requires exactly the kind of operational rigor MSPs already sell on the security and backup side. The strategic move is to apply that same playbook to the AI surface area, and to do it before the client's general counsel forces the conversation in a much less favorable context. The conversation on mentor-driven MSP growth and practical AI automation traces the same pattern in a different chair — the providers who get there first will not be the loudest. They will be the ones who turned discipline into a product.

The 48/13 gap is a positioning gap, not a demand gap; MSPs cannot resell their way into a margin AI clients will respect.
AI governance, risk policy, and audit-trail work look exactly like the security and backup advisory MSPs already sell — same muscle, new surface area.
The MSP that turns AI discipline into a productized service will compound; the one that resells licenses will get squeezed from both sides.

Frequently Asked Questions

What does "vibe coding" actually mean?

The term has drifted. As originally coined, it described a way of working with AI where the developer guides a code-generation tool through natural language rather than writing the code themselves. In practice today it has come to mean almost any AI-assisted software work — from professional engineers using AI as a force-multiplier inside disciplined architecture, to non-technical builders generating small applications without any architectural framing at all. The two are radically different activities with radically different risk profiles. The distinction that matters is not the tool. It is whether anyone is actively making the architectural decisions that determine whether the artifact can survive contact with a production environment.

Why are senior developers seeing 81% productivity gains while juniors see only 15-25%?

Senior developers carry a mental library of architectural patterns, anti-patterns, and trade-offs accumulated over years of seeing systems succeed and fail. AI accelerates the application of that library by removing the friction of looking things up, scaffolding boilerplate, and writing repetitive code. The senior already knows what to ask, what a good answer looks like, and when the answer is wrong. The junior is being handed a tool that produces output faster than they can evaluate it, often without a mentor who can compress the years of pattern recognition into something teachable. The fix is not less AI for the junior. It is more deliberate mentorship, more structured exposure to architectural decisions, and more time spent reading and reviewing code rather than only generating it.

What is the "6-month wall" in AI-built software?

It is the point at which the accumulated cost of architectural shortcuts, undocumented decisions, and AI-generated code with no clear ownership starts to make the system unmaintainable. The symptoms are recognizable: changes start taking longer than they should, new features break things they should not touch, the team can no longer confidently predict the consequences of a deploy, and the AI assistant itself starts producing increasingly poor suggestions because the context has degraded. The wall is not a model failure. It is the accumulated absence of human architectural decisions catching up with the project on a delay.

What does documentation-first architecture mean and why is it suddenly important?

Documentation-first means writing the architectural plan, the feature scope, the testing strategy, and the integration points before writing the implementation. It has always been a recommended practice; it is now load-bearing. AI assistants generate code based on the context they are given. If the context is a few sentences of natural language, the code that gets generated reflects that thinness. If the context is a thorough specification of the system, the existing patterns, the failure modes to avoid, and the tests the code must pass, the generated code is dramatically better. The documentation is no longer just for human readers. It is the primary input that determines the quality of every AI-generated line.

Should our SMB build custom software with AI or stick with SaaS?

It depends on operational maturity, the percentage of features actually used in the current SaaS spend, and the availability of someone who can maintain whatever gets built. For a small organization using a packaged tool well, the answer is almost always to keep buying. For a mid-market firm paying hundreds of thousands of dollars per year for a platform whose features they use 20% of, the build-or-wrap conversation is now real in a way it was not 18 months ago. The right answer is rarely the most dramatic. Most organizations are better served by wrapping AI around their existing data and tools than by replacing platforms wholesale.

How should an MSP actually monetize AI services in 2026?

The losing strategy is reselling licenses. That race ends at the vendor's direct channel or the client's procurement department. The winning strategy is selling the wraparound work that determines whether AI delivers a margin or a lawsuit — risk policy, vendor governance, data-leakage controls, audit trails, and the internal automation playbook the client cannot build alone. These services look like the security and backup advisory work MSPs already sell, applied to a new surface area. The clients who will pay are the ones whose general counsel has started asking AI questions and whose owner does not yet have an answer.

Episode Highlights

04:30 — The senior-junior AI productivity gap (81% vs. 15-25%) and what it means for hiring, mentoring, and the operational floor of every services business.
11:00 — How a disciplined team protects a production system from AI shortcuts: gated environments, CI/CD, isolation, and unit tests as the last line of defense.
14:00 — Why documentation-first architecture suddenly matters more than ever — and how Baytech feeds full system blueprints to AI before generating a line of code.
18:30 — The "6-month wall": the quiet point at which accumulated AI shortcuts compound into an unmaintainable codebase nobody on the team can confidently change.
29:00 — Why "we have a ChatGPT license" is not an SMB AI strategy, and the build-versus-buy-versus-wrap framework owners actually need.
33:00 — The 48/13 monetization gap and why MSPs that resell AI licenses will lose to MSPs that productize AI governance.
44:00 — The 10-day internal estimation tool Baytech could not have built before AI — and the bar it sets for every operator's "we should automate that someday" backlog.
59:00 — The closing thesis: AI accelerates everything, including bad work. The right team and common sense are still the load-bearing assets.

About the Guest: Bryan Reynolds

Bryan Reynolds is the founder and CEO of Baytech Consulting, a custom software development and application managed services firm headquartered in Irvine, California. With 30+ years as a software architect and 17+ years running Baytech, Bryan has led the design and delivery of enterprise-grade applications across healthcare, finance, manufacturing, legal, and education — including the Vision app for Bering McKinley. Baytech is recognized with a perfect 5-star Clutch rating and is a Microsoft Partner, AWS Partner, and Goodfirms-accredited firm. Bryan's perspective on AI-accelerated development is grounded in what actually ships and keeps running — not in what demos well on a Tuesday.

Connect with Bryan on LinkedIn →

About the Host: Gary Boyle

Gary Boyle is a Partner for Strategy & Business Development at Bering McKinley. With a background spanning network engineering, entrepreneurship, and strategic consulting, Gary brings real-world operator experience to helping MSP owners build stronger, more profitable businesses. Gary is guest hosting this episode of The BMK Vision Podcast while Josh Peterson is with clients. He also leads the BMK side of the Vision app build with Bryan Reynolds and the Baytech Consulting team, which makes him a credible interlocutor on what AI-assisted development actually looks like inside an active leadership platform.

Connect with Gary on LinkedIn →

Related Resources from Bering McKinley

Want to Continue the Conversation?

If you are an MSP owner or SMB CEO trying to decide what to do with AI before another quarter passes, the Vision Operating System exists for the exact decisions this episode is about — the disciplined ones, made out loud, with the financial and operational consequences named in advance. AI is not the leadership question. AI is the lever. The question is what you are pulling it for.

Apply to be a Guest Learn More About Vision