I run a handful of small AI programs that do parts of my work for me: drafting blog posts, filing ideas I dictate into my phone, that kind of thing. They used to fetch their own instructions by cloning my code repository (a repository, or repo, is just the folder where a project’s code lives, tracked so every past version is kept). That repo was public. Anyone could read it.
While checking whether it was safe to finally make the repo private, I found a live API token sitting in it, in plain text, in two places. An API token is a password-shaped string of characters that lets one piece of software talk to another without a human typing a login every time. This one had been there since I added it, and because a repo keeps every past version forever unless you go out of your way to scrub it, deleting the file from today’s copy would not have removed it from yesterday’s.
The damage was small. The token could only submit one kind of form entry. It couldn’t read anything, and it had no path to anything sensitive. I made the repo private the same day and the routines that used to read from it now hit a private database endpoint instead, so there’s no repo left to clone at all.
I’m not going to pretend this was a clever catch. It was a question I should have asked when I first wrote the token down, not a month later while doing something else.
**A job said “fine” and lied to me twenty times a day**
Twenty. That’s how many of my client automations were being touched by a scheduled job (code that runs itself on a timer, no human involved) that reported “all good” every single day while doing nothing at all on any of them. Not “worked on some, skipped others.” Nothing, on all twenty, silently, for an unknown stretch of weeks.
The job wasn’t broken in a way that throws an error. It was missing one specific permission on the account it used, so it ran, touched nothing, and reported success anyway, because “did it crash” was the only question anyone had ever asked it.
I fixed the actual permission in about five minutes once I found it. The bigger fix took longer: I built a system that now records, for every scheduled job, what it was supposed to do versus what it actually did, every single time it runs, whether those two numbers match or not. A job that’s supposed to touch sixteen sites and touches three now gets flagged as unhealthy even if it never technically errors.
It paid for itself immediately. The first real run of that new coverage-tracker found the missing-permission bug above on day one, and separately corrected a second wrong guess I’d made a few days earlier: I’d assumed a different weekly job was dead, because the data it produced looked thin. It wasn’t dead. It ran every week, on schedule, four weeks running. Twelve of sixteen sites it touched were quietly throwing errors the whole time, because a reporting account had never actually been given access to them. The other four worked fine and always had. A job that’s mostly broken and a job that’s completely dead look exactly the same from a distance.
A monitor that reports in every morning gets ignored by the third day, whether the news is good or not, and then it has failed at the one job it had. Mine only speaks up now when something’s actually wrong. All this runs for Ascend Systems, the automation and IT work I do for other small businesses, and the same blind spot was almost certainly costing real client sites real visibility the whole time nobody was watching for it.
**Two web addresses, one store, and Google noticed before I did**
Forty-three. That’s how many errors Google Search Console (the free tool Google gives site owners to show how their pages are actually performing in search) was reporting on Record Store Directory, a site I run listing independent record stores. My first two guesses at the cause were both wrong, and both wrong with real confidence.
The actual bug: one particular store’s page was reachable at two different web addresses, and both of them loaded, both returned success, and both claimed to be the “real,” official version of the page (the technical term is canonical, meaning the one address a page should be known by, so search engines don’t get confused about which copy is the real one). Two pages, each insisting it was the original, with nothing on either page able to settle the argument.
The fix folds the extra address into a permanent redirect (the web’s way of saying “that page moved, use this address now”) pointing at the one Google had already indexed, rather than the other way around. Verified live, with a fresh request rather than a cached one, since the first check I ran came back stale and nearly reported a working fix as still broken.
The bigger number underneath it: only 65 of about 600 known pages on the site were actually indexed, meaning showing up in Google’s results at all. The duplicate-address bug probably wasted some crawl budget, but 43 duplicate pages doesn’t explain an 11% indexation rate on its own. That’s next week’s problem, not this week’s.
**The bugs my own kitchen and closet apps taught me**
I build small apps for my own household the same way I build them for clients, which means they get the same bugs.
An outfit generator I wrote kept returning the same two outfits over and over. The cause: I’d told the underlying AI model I wanted several outfit options, as a number in a plain-language instruction. A number in a prompt, it turns out, is a request, not a guarantee, the same way asking a contractor for “about six” cabinets doesn’t legally bind them to six. I now ask for more than I need and show a note on screen if fewer come back.
A meal-photo upload feature quietly broke on every browser except Safari. The cause: modern iPhones save photos in a format called HEIC by default, which most non-Apple software, including most web browsers, can’t display. The photo would upload fine and store fine, then render as a broken image icon everywhere except the one browser built by the same company that makes the phone. It now gets rejected with a clear message before it’s ever saved, instead of being stored somewhere it can never be seen.
And a planning screen was silently failing to save anything at all. The picker was sending the date in a shape the save endpoint didn’t expect, the save call was failing every time, and the failure was happening inside a piece of code that catches errors and throws them away instead of showing them. Weeks of planning, zero rows actually saved, and no error ever surfaced to say so.
A calendar date is not an instant, on the client any more than on the server. That one line cost me two separate bugs this month, in two different apps, both involving evening entries landing on the wrong day because a date got treated as a precise moment in time rather than as a whole day.
**I built a fake HVAC company to test somebody else’s platform**
Cloudflare, the infrastructure company, put out an early version of a new platform for running AI agents against real business systems. I wanted to see what it could actually do, so I built a demo company to test it on: a fictional Charlotte HVAC contractor, complete with a marketing site and a small database, wired so that filling out the site’s contact form writes a real lead into the database and an AI agent can read it back out through a standard connector (a small, uniform plug that lets an AI agent talk to a piece of software without custom code being written for that one connection, the same idea as one wall outlet working for any lamp).
It genuinely worked end to end. I gave the fake company a Star Wars theme at first, prices in credits, a founding date measured in years before a fictional battle, purely because it amused me for about an hour, then killed all of it. A demo built to convince real prospects should not also read like a joke only I would get, and it should say plainly that it’s a demo, which the finished version now does with a visible banner.
**Should you bother with llms.txt?**
A reader asked me about llms.txt, a proposed standard where a site publishes a plain text file listing its important pages, meant to help AI tools navigate the site instead of reading raw web pages. Short answer: it’s not the AI-visibility magic bullet a lot of blog posts make it sound like.
Adoption is still low. Roughly 8.7% of the top 1,000 sites on the web have published one, and about 15.8% across a broader sample. More to the point: the AI crawlers behind ChatGPT, Perplexity, and Google’s AI search mostly ignore it entirely and just read the regular HTML like they always have. Publishing one will not get a site cited in AI search results.
Where it does help: coding assistants and IDE tools, the kind developers point at a documentation site while they work, fetch it routinely when it exists. If a site’s audience includes developers or technical prospects reading its docs, it’s a cheap, honest thing to add. If the goal is general AI search visibility, it currently isn’t.