AI Won't Take Your Job, But Not Using It Might
Adopting AI isn't a skill you lack: it's a mindset. Build repeatable machines that do your work, then become the person who grades them. Read: "Everything starts looking like a toy" #295
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: a brilliant way to “watch” MLB games rendered in 8-bit fashion - retro and clever. Now all they need to do is add the video game sounds from the Princess Bride.
Edition 304 of this newsletter is here - it’s June 22, 2026.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ Build Little Machines, Then Grade Them
We just finished annual planning at work, and there’s one small moment that keeps coming to mind.
It was a Wednesday morning, and other product managers updated the shared spreadsheet overnight with brand new assumptions for the number of developer months required.
I didn’t panic and rewrite my plan.
Instead, I pressed “resync” in a tool I built to read the changed shared spreadsheet. The tool compared the results to the last snapshot and showed me what had actually been updated. Then it replayed my analysis against the new state.
Instead of rebuilding the plan from scratch, I asked “does my recommendation still hold given the new information?” into a chatbot (thanks my Neighbor Claudoro) and got an answer in a minute.
It was the same feeling I had three years ago wiring API calls into a spreadsheet, which was the first time I reached past the edge of a tool and made it do something it wasn’t built for. Back then I thought I’d discovered fire, and now I’m arriving at AI use cases that are actually useful.
I keep noticing that a lot of smart, capable people haven’t had that moment yet — and from the outside, it’s not clear why.
Ask anyone why they’re not using AI more, and the reasons are real. They’re afraid they won’t be any good at it. They’re worried it’s coming for their job. They look at the firehose of models and updates and decide the whole thing is too much to learn, maybe unfathomable. And underneath that, a few have a quieter objection. Using AI at all is a small act of betrayal because it helps build the thing that replaces them.
I don’t think any of those reasons are stupid. I think they’re mostly pointed at the wrong threat. The people who’ve gotten past them aren’t braver or more technical. They do one concrete thing differently than their peers.
They stop asking AI for answers and start building little machines, then they make themselves the person who grades what those machines produce.
What people say when you ask why they got laid off
Recently, Gallup asked laid-off workers what they thought happened to them.
The answers were boring:
Restructuring and downsizing, fifteen percent.
Budget and cost cutting, eleven.
Economic conditions and lost business, another eleven.
AI and automation came in at one percent.
But in that same research, sixty-two percent of laid-off workers reported that they used AI rarely or never in their last role. Among people who still have their jobs, it drops to fifty.
I can’t tell you the non-users got cut because they didn’t adopt. The same people whose roles get restructured away are often the ones furthest from these tools to begin with.
AI adoption isn’t armor against a budget cut.
But when the cut comes, the people who’ve made themselves visibly more capable are the harder ones to let go. It doesn’t keep the axe from swinging. It keeps you on the keep list.
Productive AI use is a mindset, not a skill
What if the most effective AI users in the org aren’t necessarily the most technical people?
Some of the most fluent AI users I know would fail a coding quiz on the spot. But they think differently about the work they’re doing than other people who never use AI, and those who use AI like a search engine or a one-shot magic generation machine.
Effective AI users don’t one-shot a solution. Google Search has trained us all that you type in your question, get a ranked list of answers, and you’re done. With AI, that’s more like a starting point.
The good side of this paradox is that the more you engage in socratic dialog, the better an answer you’ll get. The bad side is that you might see an answer that looks “pretty good” and your brain will pattern match on it being right whether it is or it isn’t.
So treat the first answer as an opening move. Ask “how could we do this differently,” because they take friction personally. A clunky process should offend you, and not only because you can do something about it in an afternoon instead of filing a ticket and waiting for engineering to respond with “it’s in the backlog.”
Software is much messier than it lets on. When we use Apple products, we assume “it just works” and don’t think much about the reality that these services we use every day are mostly computers calling other computers.
Once you believe there’s an engine under there and you’re allowed to open the hood, AI stops being magic and becomes something you can aim.
Stop asking AI for answers, start building little machines that deliver results — and then become the person who grades what they make.
Stop asking, start building
Even past the one-shot habit, most people stop at the answer. Ask, read, copy it out, leave. The people who get compounding returns build the solution instead of stopping.
This is not necessarily about writing code. The move is more general. You take some input, turn it into some output, and then you make that turn repeatable.
Let’s use my planning spreadsheet as an example. The one-shot version is what most people do: open the sheet, stare at it, form an opinion, and pray the numbers don’t move before the meeting. What I built is a little machine — input is whatever the live sheet says today, output is my tradeoff analysis, replayed.
Because it’s repeatable, the cost of asking “what if we funded this instead” dropped from an afternoon of re-reasoning to a button and a coffee. I didn’t get a smarter answer. I got to ask the question twenty times instead of once.
None of that is pure engineering. It’s learning to see your own work as a pipeline instead of a heap of one-off tasks, and most people were simply never taught to look at it that way. That’s the gap the usage numbers are pointing at in the Gallup poll. It’s about who stopped asking and started building.
You also have to know when it’s lying to you
Building the machine is only half of it. The other half is grading what it makes, and that takes expertise — yours.
That planning tool is only useful because I can grade it. When it tells me to fund feature A over feature B, the real question isn’t whether the answer sounds reasonable — they all sound reasonable.
It’s whether it’s a genuinely solid tradeoff or whether the model quietly hallucinated a dependency, missed the compliance constraint, or invented capacity that isn’t there. I’m the one who has to know the difference, because I know the team and the commitments and which corners are load-bearing. The tool replays the analysis. I decide whether the analysis is real.
That’s the new job, and we’re all making it up as we go. That’s the actual skill of the next decade. Not prompting. Judging. And we’re all going to be practicing it whether we signed up or not. The people who start now are getting reps on the only part of the work that keeps getting more valuable.
What you could do this week
If any of this landed, reading more about it is the wrong next step. You don’t install a mindset by understanding it. You install it by doing one small loop, twice. So:
Download Codex, Claude, Gemini, or VS Code — anything that lets you talk to a model about your own files, not a sealed chat window across the room from your actual work.
Make a directory for a real, small, slightly annoying problem you’d like gone.
Put the model in plan mode. Don’t ask it to do the thing yet. Ask it to plan the thing.
Then make it interview you: “Ask me clarifying questions before you start.” That one line changes the entire character of what comes back.
Build something. Anything. Start embarrassingly small — the point is to finish one full loop, not to impress yourself.
Now do it a second time and watch what changed. You’ll prompt differently without trying. You’ll catch yourself steering instead of asking. That shift, the one you feel on the second pass, is the whole thing.
One small loop, run twice.
The better question
The fear under all of this is will AI take my job? It’s a fair question, but it’s mostly out of your hands — and going by what laid-off people actually say about themselves, mostly not what’s happening anyway.
There’s a better question, and it’s one you actually get to answer: am I the kind of person who’s bothering to learn how this works?
Not an expert. Not a prompt wizard. Just someone who stopped asking for answers, started building little machines, and got serious about grading what they make. That’s not a talent you were born with or missed. It’s a posture, and you can pick it up this afternoon.
What’s the takeaway? Stop waiting to feel ready. Pick one small, annoying thing, build a little machine that does it, and then get strict about grading what it hands back. That loop is the whole skill, and it compounds every time you run it. Make the folder. Build the small thing. Then build it again.
Links for Reading and Sharing
These are links that caught my 👀
1/ Why are magnets important? - It turns out that building atoms in the US is more complicated than building bits. Like the basic building blocks of software platforms, carefully machined magnets are the stepping stone to better electric motors.
2/ The mechanics of great demos - The folks at Posthog have written a suprisingly good primer for delivering an awesome demo.
3/ Agents and Memory - AI agents need memory just like humans do. How do we build it?
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.