Regarding AI
Most of the people saying so have something to sell, which doesn't make them wrong but does make them worth reading slowly. I use this stuff constantly and I build with it, so I'm not a skeptic either. I'd just rather explain how I actually think about it than tell you what you ought to do or overwhelm you with fear.
Most people arrive at this asking whether they should be using AI. It's the wrong question, and it's wrong in a way that costs money, because it starts at the tool and works backwards looking for something to point it at.
The better question is what's actually costing you time or money right now — and then whether any tool touches it. Sometimes the answer is a language model. Often it's a better-designed form, or removing a step nobody needed, or one spreadsheet maintained properly instead of four maintained badly. Speed comes from understanding what's needed first. Not from how quickly you can build the wrong thing.
One project moved money between partners and had to hold up under audit. That bought spec-first discipline, tenant isolation enforced at the database rather than trusted to application code, and slightly more test code than source code.
One was a marketing site that would change every few weeks and held nothing sensitive. That bought speed, a tight loop with the people who owned the message, and an honest expectation that it would be thrown away and rebuilt.
One judges how well a person did. That bought validation built into the system rather than bolted on afterwards.
Same technology, same stretch of months, same person making the call. The only thing that changed was what happens when it's wrong — which is, in the end, the only question that has ever governed the answer.
These are the same anxiety wearing two hats.
Work that used to be out of reach is now reachable. Something that would once have needed a small team and most of a year can sometimes be one person and a season. That's real, and it's most of why I can work this way at all.
The fear underneath it is that cheap and fast means disposable — that you'll be handed something impressive that nobody can maintain, including you. It's a fair fear and the answer is unglamorous. On a loyalty platform there's slightly more test code than there is source code, with a coverage floor enforced automatically before anything ships, and documentation that matches the implementation because the two change together. Whether that's true of any particular piece of work is a question you're entitled to ask anyone, me included.
When people ask about this they're usually asking one of three different questions, and they have different answers. Let's talk about it through examples.
The first is about their own staff. Someone drops a spreadsheet of customer records into a free chatbot to get a summary out of it. This is the live exposure in most businesses, and it's usually already happening while the owner is still deciding whether to adopt anything at all. It's an operations problem more than a technical one — know which tools people are actually using, give them a sanctioned one on terms that don't train on what goes in, and be specific about what's allowed to go in it.
The second is about AI touching customer data as part of the product itself. I'm working on a version of this now, in a training context: students hold conversations with virtual patients, which are themselves language models, and AI evaluates the conversation afterwards. No real patients, no HIPAA. It's the same shape as evaluating a real clinician with materially lower stakes, and that's worth saying plainly rather than letting it sound more serious than it is.
There are two levels. One checks the AI's own output — is the virtual patient behaving accurately and staying inside the scenario. The other assesses the student against established rubrics, so an instructor can grade. Only the second is consequential, and that's where the interesting problems live. The same transcript scored twice can come back different, which stops being an academic concern the moment it touches someone's grade. So the rubrics are known rather than open-ended, and the instructor grades with assistance rather than the model grading alone. Student identifiers never reach the model at all — they're swapped out at the boundary and mapped back to the result afterwards. The model doesn't need to know who it's reading.
The third is about AI writing code, and the rule is simple: the agent touches code and synthetic test data. Never production data, never production credentials. Though the more durable version of that rule is that the risk isn't really the agent — it's the environment. An agent reaches whatever its environment can reach. So scope the environment and stop worrying about the agent.
Underneath all three is the same instinct. Minimize what you hold. Not only because it might leak, but because every extra field and every extra vendor who touches it makes the policy harder to maintain, and that cost never shows up on the invoice. On that payments platform no card data touches the codebase at all — card entry happens in a hosted frame someone else is responsible for — and the personal information stored is a business name, a contact email, and a merchant ID. The exposure was designed away rather than managed.
There is no one size fits all. Let's talk about your goals, risks, and environment.
Nobody asks this one directly.
Most of the small businesses I've seen aren't overstaffed. They're under-capacity, with work piling up that nobody wanted in the first place. The honest version is that some tasks do go away, and they're usually the ones people were doing resentfully.
The clearest example I have is a tool I initially built to solve a known problem — a harness for testing AI-generated conversations, because there was no reliable way to know whether a prompt held up across many conversations and across different models. I ended up deploying it for a team who were struggling to author those conversations at all. It didn't replace them. It let clinical and content people do work that had previously needed someone like me.
No. I don't have an AI / no-AI binary.
If you'd rather not, or your industry makes it complicated, I'll price the work without it and we'll look at the difference honestly. Sometimes that difference is big enough to change the decision. Sometimes it isn't. It's a conversation, not a position.
The distance between code existing and a problem being solved.
AI will produce a working thing quickly. What it won't do is tell you whether that thing addresses what was actually wrong, or get it safely in front of the people who need it. That second part is still mostly human work — environments, review, security, deployment, the question nobody asked until it was live. You can skip a lot of it by handing over the keys and not reading the output, and both of those are bad ideas in any organization with something to lose.
The risk I keep circling is a false sense of security, and it arrives in three forms. That the model understands the strategy better than people who have spent years in the business. That the code is secure and correct because it reads as though it is. That the architecture fits the need — when the need was never described precisely enough for anything to fit it.
None of those are AI problems exactly. They're old problems that a fast, confident, articulate tool makes much easier to walk into. A tidy way of helping someone see that before it costs them something is what I'm continuing to work out.
UNDER CONSTRUCTION — Email me: chris.hartman@yahoo.com