Issue 70  September 4th 2026

AI Perspective: The Ethics of "Vibe Coding" — Innovation vs. Extraction

By Gemini

Generative AI code assistants have radically lowered the barrier to software creation. Tasks that once required months of dedicated engineering can now be prompted into existence over a weekend. But as "vibe coding" transitions from a novelty into a commercial shortcut, it raises a fundamental ethical question for IT leaders and developers alike: When software creation costs drop to near zero, what is our duty of care to the end user?

The Shift from Stewardship to Extraction Historically, software pricing reflected a balance of labor, domain expertise, and ongoing operational risk. An engineer selling a utility for $99 was offering an implicit warranty: I built this, I understand its internal logic, and I have the technical competence to debug, patch, and secure it when things break.

AI code generators disrupt this balance. Models are trained on millions of lines of open-source software, built over decades by uncompensated developers who donated their craft to the public commons. When a non-developer uses these models to construct a product in a week and immediately places it behind a commercial paywall, a sharp divergence occurs:

Attribution Laundering: The code relies entirely on the collective intelligence of the open-source ecosystem, yet the output is packaged as proprietary IP without model attribution or open access.

Risk Offloading: If the author freely admits to lacking manual coding skills, they cannot audit memory management, data pipelines, or security boundaries. The long-term technical debt and risk of data loss are transferred entirely to the paying customer.

Community Toll: Rather than using low-cost AI leverage to contribute back to a craft or field, the instinct defaults to rent-seeking—charging users who are already struggling under subscription fatigue.

Defining the Baseline for Ethical AI Development Using LLMs internally to streamline enterprise operations or rapidly prototype concepts is smart engineering stewardship. However, as AI-generated binaries flood the market, organizations and individual builders should hold themselves to a clear standard:

Internal Utility or Open Source: Code generated primarily via AI prompting without deep manual oversight should either remain internal to the enterprise funding the compute or be published as open-source with explicit model attribution.

Competence Before Commercialization: If you choose to charge real money for software, you owe the customer genuine engineering competence—meaning the ability to manually inspect, maintain, and secure every line of code without depending blindly on a prompt box.

Reciprocity Over Rent-Seeking: High-leverage, low-effort tools should lower costs for the end user, not serve as a vehicle to extract maximum revenue for minimal craft.

The democratizing power of AI in software is real, but speed and convenience do not erase the responsibility of stewardship. Lowering the bar to create code shouldn't mean lowering our standards for integrity.

How this was done: I'd read Jason Aten's recent Inc.com article and it just left a bad taste in my mouth when I found out he was basically hawking his vibe coded software for $99 to his peers. After discussing with Mr. Aten, I was somewhat relieved to hear that he at least engaged some professional software developers to smoke over his code-base before publishing and uses formal version controls in Git. I probably still wouldn't do it the way he has, but I'm pretty anal about what I claim as mine and try to sell.

Kudos to Gemini for the graphic which includes an extra limb and some odd capitalization in the image text as a nice reminder why vibe coding requires an actual programmer for oversight. Good luck out there.

The Shift Register  

CIO's Corner

This week I want to talk a bit about managing supply chain risks in our software and hardware stacks. This is an often overlooked area, but is so critical to our modern infrastructure that you can't just grab the lowest bidder, or user chosen devices/tools to go with. What do I mean exactly?

Right now, all the major US telecoms have discovered that their systems were pwned by China after installing routing equipment built by Chinese companies. Many had to cut cables to major infrastructure installations and build completely new ones from the ground up in order to remove all the impacted equipment. Not just the original routers, but every device that had been connected to them as Chinese government agencies laterally exploited connected systems for additional access and control.

This is not written with the intent to be an anti-China rant. I'm just explaining one example where poor supply chain choices have led to high risk and exploited outcomes for an entire industry in the US. In fact, it is nearly impossible to entirely avoid Chinese hardware in most of our US organizations today. Regardless, the job to manage risk of our infrastructure supply chains remains.

For myself, this means I research hardware and software vendor sources and try to find more suitable sources if risk levels are too high for the desired systems. In our most recent AI enabled OCR project, ABBYY was put forward as a major possible product. This company has divested of Russian ownership for some time, but they still have a legacy code base. What that tells me is that anything I scan with that product will likely be accessible by Russian FSB as will the system I install it on. Can I trust to use this product as an onprem server handling all of our invoices? No. Does Deloitte use this product, yes. Why? I don't believe they have properly researched or assigned the risks associated with it. Perhaps, they believe they can segregate and control its communications to eliminate or reduce these risks to acceptable levels. I don't know, but while there are other options available, why not explore them instead of rolling the dice with something like that?

I know this sounds very much like some kind of nationalistic bias on my part, but it really isn't. For companies based in the US, there are absolutely adversarial nations that control a huge percentage of the code and hardware leaving their nation with the intent of leveraging it for future cyber warfare operations against the US and its allies. That is a real risk to our supply chains and one we can control better than just hoping we can stuff it into a locked segment and hope it never bites us.

Okay, I've lambasted Russia and China, but I want to be clear that every major IT software and hardware producing nation is playing this game today. The game is salting all sold products to permit information exfiltration, remote access, or at the very least, remote denial of service capabilities. When Russia published the NSA's hacker toolkit in 2016 that was collected by Kaspersky's antivirus software in 2014, they hadn't just happened across it by accident. No, Kaspersky's had been outed by Israel for collecting and disseminating files with Russia's FSB. Since Kaspersky was burned publicly at that point and the NSA's toolkit was known to be compromised, after a couple of years of using it themselves, the FSB published it as a best means of reducing NSA capabilities. Once upon a time, every HDD built world-wide featured firmware that permitted NSA remote access and exfiltration.

Cyber Warfare units are expensive to train and operate. Much as our own CIA was caught protecting and enabling opium sales to fund operations in the 1950s-1970s in Vietnam, so our international adversaries are protecting and enabling ransomware and other cybersecurity related scams to fund their own cyber warfare operations. In this environment, trusted vendor selections are just basic risk management, but you have to know what is really happening in order to make good decisions. International supply chains carry risks that must be known and managed beyond simple availability.

There. I've slammed the US, Russia and China all as malefactors in international IT supply chains. Your risk level with any specific national source is going to vary, but make no mistake that it matters very much. In software, I look at every vendor and if they make use of open-source, I look at the underlying packages and who has written commits to them in Git. In hardware, I do the same thing down to chip and firmware levels.

Does this mean I can completely avoid any adversarial nation's devices or software? No. It means I can avoid the most commonly exploited ones and actually assign risk levels and mitigations where my choices are limited. Once upon a time, a very good organizational IT security team could absolutely keep any nation out of their systems. Today, that same team has to have a procurement assessment/supply chain analysis specialist and then can still only choose which nations have access to what. While this should be something a very good CISO can put together, it's still risk management the CIO needs to understand and support in order to ensure it is happening in a fashion that aligns with the organization's own goals. It is truly WW III on the Internet out there today and your entire stack is at risk at every level. Good luck out there!

Kudos to CoPilot for the graphic.

The Shift Register