AI-Built Software, Part 1 of 7: why the series skipped “vibe coding,” what the next six parts cover, and where things stand today

Why I haven’t written about it

Over the past year, I’ve written a wide-ranging series of articles about where AI fits (and doesn’t) in your business. But you may have noticed that I never mentioned one major area: using AI to write code (often referred to as “vibe coding”).

I stayed away from this topic for a couple of different reasons. First, it really didn’t fit a series talking about AI-enabling your processes, and second, it felt like a topic aimed at developers, not people who spend all their time managing and operating a business.

But now, increasingly I’m hearing from managers and business executives who tell me they have internal staff members creating apps to fill in gaps in their workflows or bring new capabilities to the business. I want those executives to understand what they’re really getting, the risks they need to be aware of, and what this looks like in the long term.

I had my first paid programming job in 1985, when I was fifteen, writing code on an Apple IIe. I then spent thirty-two years building and being accountable for a manufacturing company’s internal systems. I was an early adopter of AI coding tools, starting with cutting and pasting code into ChatGPT when it was released in 2022, and I’m now building products using AI tools that write much of the code.

What the series will cover

I first expected to cover this in a couple of posts, but it’s a broad topic. I’m planning seven parts for now, but that may change as I dig in and the series evolves. In each article, I’ll start with what an approach does well, with a real example, before getting to where it goes wrong.

Part 2 is aimed at what I expect is the most common case: businesses that don’t have their own development staff. I’ll look at the most popular platforms aimed at letting non-technical people build and host applications and identify the pros and cons of going in this direction.

Part 3 will look at the less common case where a business has an internal development staff who may or may not already be using AI coding tools. I’ll look at how they can use these tools, where they are and aren’t appropriate, and the benefits and risks of using these tools.

Parts 4 and 5 cover what often gets missed when staff without a development background start creating apps, because the tools will happily build something without mentioning the gaps. Part 4 is infrastructure and security: where the app runs, how it’s backed up, and who can get in. Part 5 is the law, because an app that sends email without proper consent, or collects personal information it shouldn’t can put a Canadian business offside of CASL or PIPEDA, and nothing in the tool will tell you that.

Part 6 is about what is probably already running in your company: how to find the apps people have built, and the one-page policy that keeps that from becoming a problem. Part 7 is the decision: how to decide whether, and how, to use AI coding tools in your business.

Where things stand today

I think it’s helpful to start by understanding how AI is being used for app development today. To simplify things, I’m breaking things down into four methodologies: chat help, prompt-to-app, editor assist, and agentic coding. I’ll use these labels throughout this series.

The first is chat help: simply using one of the chatbots (e.g., ChatGPT, Claude, Gemini) to ask for assistance, perhaps pasting in existing code, and taking the results and integrating it back into the codebase. When chatbots were first released, this methodology was extremely common, but it’s inefficient, and in my experience, it’s now used mostly for small bits of standalone code like command-line scripts.

The second is prompt-to-app: one of the platforms that purport to offer an end-to-end experience. These platforms allow you to ask the AI to create an app based on your description of how it should look and function. They write the code and then offer a hosting platform to deploy the app to users. This market is evolving very quickly, but the big players in this area today are Base44, Lovable, Replit, and Bolt.

The third is editor assist: AI assistants within a developer’s existing editor (e.g., GitHub Copilot or Cursor). Most development environments (the “IDE”) include this now. I view this as a tool to assist developers rather than AI coding; rather than writing all the code it just helps the developer be more efficient.

The fourth is agentic coding, where an AI tool like Claude Code or Codex is given full access to an existing codebase and is prompted to write code. This will often have a developer (or at least a fairly technical person) driving the work, but most of the code is written by the AI, and how carefully it’s reviewed varies.

Looking at these four, I see two distinctions. The first is who writes the code. Chat help and editor assist are assisted: a person writes it and AI helps. Prompt-to-app and agentic coding are delegated: the AI writes most of it. The second is the question I’ll keep returning to throughout this series: can the person responsible read what was written, and do they? With chat help and editor assist, a developer is looking at every line. With prompt-to-app, the person creating the app often never sees the code, nor could they understand it if they did.

This is what people usually mean by “vibe coding,” and I’m going to set the term aside in favour of these labels. It isn’t a criticism of the people using these platforms; making the code invisible is what the products are designed to do, and they do it well. Agentic coding is the interesting middle case: someone technical who can read the code but may choose not to. In a company with developers, that is where I see most of the risk.

The honest frame, and what comes next

Here’s where I stand. Most of what gets built with these tools should be built with them: internal utilities, prototypes, the thing someone needed by Friday. I work this way every week. This series isn’t against the tools, it’s about the smaller set of apps that end up running part of the business - and telling the two apart before the build rather than after. If nobody on staff can read code and the app touches customers, money, or personal information, you’ll find out what you didn’t know later, usually at the worst time.

I’ll also be upfront about my bias. I come into this series with a lot of experience in developing and operating large software projects, and that gives me strong views on how things should be done. Also, I’m talking to more and more companies who have started using AI to create apps with very little understanding of the risks they’re introducing. That gives me a bias towards recommending that, for anything your business depends on, you have someone with strong technical expertise involved in helping you build and deploy apps correctly.

That likely comes across as self-serving, because that’s exactly what my company does - we provide expertise to ensure that companies create and deploy apps that are operationally sound and don’t introduce risks. But honestly, my company exists precisely because these problems exist. So I’ll show my reasoning in each part, and where the honest answer is that you don’t need any help, I’ll say so.

In the next part, we’ll look at the prompt-to-app platforms.