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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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 →
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 →
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.
%20(1).png)
4 min read
Josh Peterson : Dec 16, 2025 12:00:00 AM
In this episode of From the Trenches on the BMK Vision Podcast, Josh Peterson sits down with Milton Bartley (ImageQuest) for a grounded leadership...
-1.png)
4 min read
Josh Peterson : Dec 22, 2025 11:59:59 PM
In this episode of From the Trenches on the BMK Vision Podcast, Josh Peterson sits down with Luis Alvarez of Alvarez Technology Group for a grounded...
.png)
3 min read
Josh Peterson : Feb 16, 2026 12:00:00 AM
Most MSPs don’t stall at $2M because the owners stop working. They stall because the business outgrows its evidence. “We don’t track time” is...
Gary Boyle