A friend who does IT for a living — and helps small businesses on the side — brought me a client's problem: their email had quietly stopped reaching Gmail. Every diagnostic tool said the setup was perfect. It wasn't. I wrote up the full fix and gave away all of it — every record, every gotcha. Because the *what* was never the hard part. The hard part was the *how* Quiet AI organized the solve: it read four layers of live infrastructure at once, spotted the one that was lying, and had the answer in minutes — on a problem that had been stuck for weeks. That's the part you can't lift from a checklist. It does nothing magical. It makes the right move obvious, fast, and quiet — then the email goes through and nobody sees the machinery. Invisible competence, job done. Full detective story (sanitized) 👇 https://medium.com/@gabeyoga/the-email-that-vanished-3a78e1a70df6?sk=50bba8bd11104c317a390d6ce8f13fcb My friend was rather blown away by how I was using "AI."

Twelve months ago i'd never touched code. i'm a marketer and a teacher. A head full of ideas and no technical training whatsoever. So when i started building learning resources for the college i work at, i did the obvious thing. i wrote prompts. Good ones. Then i saved them into projects. Then i had a different set of prompts for every part of the process, one for this, one for that. It worked. Sort of. It was tedious and the output was right most of the time but not all of the time. (half the words people used for this stuff went straight over my head, by the way. "agentic", "RAG". i used to nod quietly and google it later.) Anyway. The thing that actually moved me forward wasn't technical at all. It's that i ask a lot of questions. And since i can't lean on knowing how the code "should" work, i ask them from everyone's seat instead. When i plan a stage i'll sit in the chair of the learner, then the assessor, then the auditor, then the poor admin who has to upload the thing. What does each of them need. What breaks for them. That's the whole edge. Empathy, basically. Asking what the person on the other end actually needs before you build a thing for them. The tools came out better because of it, not despite me not being technical. (Learnbuilt, the thing i've been building, basically exists because i kept asking those questions until the answers had to live somewhere.) So if you're in here feeling behind on the technical side, i'm not sure that's the gap you think it is. The questions are the job. The code is downstream of the questions. anyone else find the non-technical background is the part that actually carries the build?