use your words

this field has a lot of people who got here sideways. i’m one of them.

i know enough to get around. i can read code, understand what it’s doing at face value, catch something that looks wrong. years of working alongside engineers will do that for you, and honestly, it had to: you can’t manage a technical team from a position of total bewilderment. but building something from the ground up was always where i’d hit a ceiling. i was a GUI guy in a world that occasionally required a terminal.

the project

in late 2024, after we migrated from Jamf to Fleet, we had a small visibility problem. our zero-touch enrollment process was rebuilt, tested, and launched, but when things went sideways, we found out the slow way: an employee messaged us hours after something broke on their first day. there was no real-time window into what was actually happening on a device as it enrolled.

it was a low-risk gap. onesies and twosies, not a crisis. but i was starting to see enough of what AI could do that i thought: this is exactly the kind of problem worth pointing it at. small enough to experiment safely. real enough to matter if it worked.

so i gave AI a job. no procurement process required.

the result was echo: a system that watched Fleet MDM enrollments in real time, coordinated a team of specialized agents on AWS Bedrock, and posted live progress updates to Slack. when all the policies verified, it celebrated. when something went wrong, it escalated. it watched so we didn’t have to, at any hour, without needing to be asked.

the full architecture story is on YouTube, but that’s not really what this post is about.

what shifted

here’s the thing i didn’t fully appreciate until i was in the middle of building echo: i wasn’t primarily writing code. i was primarily writing instructions.

now, there was real code involved. Lambdas, Terraform, API wiring. i had touched this stuff before, but this was more advanced than anything i’d tackled on my own. AI coding tools did a lot of the heavy lifting.

and i mean that literally. the way you built with AI back then was: describe what you need, get code back, apply it, see what breaks, describe the problem, get a fix. you were the glue. not writing from scratch, but not copy-pasting blind either. you had to know enough to ask the right question, understand the answer well enough to apply it, and iterate until the thing ran. that loop, it turned out, was where i did my best work.

for someone who’d spent years knowing what they wanted but struggling with the translation, that was the revelation.

the same instinct carried into writing instructions for echo itself. not code. a job description. and if you’ve ever written one for an actual human, you’ll find the instinct is immediately familiar. the difference is, this one was written for exactly our environment, our tools, our workflow. nobody else’s.

the answer to “how specific do you need to be” was: very specific. more specific than felt necessary. the kind of specific that requires you to close every door you didn’t know you were leaving open.

and that, it turned out, was something i had been practicing for years.

use your words

when our kids were young, my wife and i said this to them constantly. when they’d get frustrated and shut down, when they’d give up on communicating because articulating what they needed felt harder than just hoping someone figured it out, we’d tell them: use your words. the more precisely you can describe what you want, the more likely you are to actually get it.

we said it like it was obvious. it isn’t. it’s a skill. and it compounds.

what i discovered building echo was that the skill i’d spent my whole career developing, the ability to communicate clearly, specifically, and creatively about what i wanted a system to do, was the exact skill that made all of it work. the prompting to build. the instructions for the agents. all of it. not just helpful. essential.

it didn’t matter that i couldn’t recite syntax from memory. what mattered was whether i could describe what i needed precisely enough to get something useful back, and then precisely enough again when that something broke. and then precisely enough again when i was writing the job description for an agent that had no common sense and would absolutely make things up if i left a door open.

i wasn’t limited anymore by what i could write in a code editor. i was limited only by how clearly i could describe what i wanted. and for the first time in my career, that was a race i knew how to run.

the change

this might sound like a story about a cool monitoring tool we built. it isn’t, really.

it’s a story about a category of work that hadn’t existed for me before: building a product from a vague idea, through to something running in production, without needing someone to write the technical parts i couldn’t write myself. not copy-pasting from a forum. not asking a colleague to handle the hard bit. designing the thing, describing the thing, and iterating until the thing worked.

back then, building with AI meant you were the glue: chat window open in one tab, code editor in another, you in the middle, doing by hand the kind of coordination you were trying to automate. it was slow. it was often humbling. and it worked. and the more i sat with it, the more i started to wonder what else was possible.

but it starts here: with a non-technical person realizing that the thing they were actually good at, using their words, was the unlock. everything else followed.