Reading About AI Is Not Keeping Up

Two people spend the same Tuesday hour on AI.

The first one reads the launch post for the new model, watches the demo, forwards it to the team with a line about what it means, and reads three replies from people who watched the same demo. The second one gives the new model a job in the repo, watches it fail on the second step, fixes the check it was missing, and ships the thing before the hour is up.

Same hour, same tools, even the same feed. From the outside both of them are keeping up with AI, and both of them would say so at dinner.

Six months later they are different people. The first one has a better take. The second one has a pipeline that a better model just landed on, and it got faster that afternoon without anyone touching it.

I read a lot. By consuming I mean taking in news and opinion about the tools without making anything the tools act on, and there is nothing wrong with it on its own. Consuming without building is the problem, and it is an arithmetic problem. The tools improve every month now, and each improvement lands on whatever you have built. If you have built nothing, it lands on nothing, and the distance between you and the person who built something grows by one release, then by another.

Path A: Keeping Up

You subscribe to the newsletters that matter and watch the keynote. You forward the good threads to your team. The seats are bought, a pilot is running, and someone on the team owns it. You can tell people which model is best this month, and you are usually right, and your take on agents is a reasonable one.

People choose this path for good reasons. It feels like diligence, because that is what diligence looked like for every previous technology shift, and it is cheap, since nobody was ever fired for reading the industry news. It is safe too, because a take can be revised and a thing you shipped cannot be unshipped. And “I will wait until it settles” sounds like the prudent sentence, the one the serious person says while the excitable people burn afternoons on tools that will be gone by spring.

What it gets you is real: a vocabulary and an accurate-sounding opinion about the state of the art. In most rooms that is enough to be the person who knows about AI, and it stays enough for about a quarter.

What it costs you is invisible for that quarter. Opinions do not compound. A month of reading leaves you standing at the same starting line as the person who read nothing, because on the day you finally open the tool the interface has changed, the model you read about has been replaced, and the thing you understood no longer exists. You have to start anyway. You could have started a month ago with less to unlearn.

I watched this once before, in the agile years, when I ran a consultancy that helped software organizations change how they worked. There were companies that read every book, sent people to every conference, and could explain the framework better than the people who wrote it. And there were companies that ran one bad sprint. The ones that ran the sprint learned more in two weeks than the readers learned in two years. The readers were always more articulate about it, and it never helped them.

The expensive part of Path A is the sentence that sounds safest. “Wait until it settles” is a decision, and the decision is to receive whatever settles. Somebody is going to decide what the tools do to your job and your team. Waiting is choosing that it will not be you.

Path B: Building With It

The other path is simple, and it is open to anyone with a job. Every week you give the tools a real job with an outcome you can look at: a script for the thing you did by hand on Fridays, a workflow that runs without you, a check that fails when the number is wrong, something at work that used to take a day.

You start with the model, and you do not spend the week deciding whether it can do the job. You hand it the job, watch where it fails, and fix the thing it could not see. Then, when the next model ships, you swap it in and watch the difference in your own work instead of on a benchmark someone else ran.

Building means making a thing that runs without you, out of whatever medium you have, and code is one medium of many. A recruiter who builds a screen that reads every resume the same way has built something. So has an operations lead with an agent keeping the runbook current. The skill list died a while ago, and the verb that replaced it is make.

Most of what runs this site now was written with agents while I watched: the pipeline that finds the Greek terms in a post and drafts their definitions, the script that generates the cover, and the daily workflow that turns an outline into an article, a social file, and a review. None of it is impressive on its own, and all of it is what a better model lands on. When a new model ships, I change one line, run the workflow, and find out in an afternoon what got better. Some afternoons the release breaks a step instead, and the time goes to fixing a check the old model never needed. Either way I learn more in that afternoon than the launch post could tell me, and that afternoon is the whole difference between the two paths.

Path B has costs. It is slower for the first month. Things break. You look less informed at dinner, because you spent the evening in the repo instead of the feed, and you will be wrong in public about what the tools can do, in front of people who read the launch post you skipped. Some of what you build will be made unnecessary by the next model, which turns your script into a built-in feature. Whether a thing you built survives the next release is not up to you, and it does not need to be, because the capability and the knowledge of where the tool breaks outlive the script.

What it gets you compounds, and compounding here has a plain meaning: one release improves everything you have already built at the same time, so the more you have running, the more each release hands you. Path B leaves you with a capability that is yours, real knowledge of where the tool breaks (which only builders have, because you cannot read your way to a failure mode), a judgment about AI you earned, and a growing thing that every release makes bigger without you asking.

Who does it serve? Anyone with something to make, which is everyone with a job.

Where They Look the Same

They keep the same hours, read the same feeds, and pay for the same seats. Both people feel busy, and both are. Each can say “we are doing a lot with AI” and mean it, and each can be wrong about the tools, though in the first quarter the reader is wrong less often, because reading is a faster way to get a correct opinion than building is.

That is what makes the fork hard to see. A reader can pass as a builder for about a quarter, to everyone including themselves. The tell shows up at the first hard question. Ask what got better last month, and the builder points at a thing while the reader points at a take. Underneath that is the real gap, which is the gap between opinion and knowledge. The reader knows what has been said about the tool, while the builder knows what the tool does, including where it fails on a Tuesday afternoon, and only making something produces that kind of knowing.

The Gap Is Monthly Now

Every previous technology shift gave you time. The web took about a decade to fork careers, and mobile took most of one. If you were slow to the web in 1996, you could catch up in 1999 with nothing lost but some embarrassment.

This one does not give you the decade, because the tools improve on a monthly cadence and each improvement lands on what already exists. A builder with a pipeline gets a better pipeline for the price of an afternoon. A reader with a take gets a better take, and a take was never going to be the thing that did the work. The distance between them is set by how many releases landed on something instead of nothing, and talent has little to do with it.

The forks coming behind this one are bigger, and they arrive the same way. AI is becoming the processing layer under every piece of software, and the application you used to build gets rebuilt around a model whether or not you were in the room. The tools to run your own health like an engineering problem are on the shelf. Brain-computer interfaces are in people. Space stopped being a government program while most people were not looking. The claim here is about how these arrive, and it holds whether or not any one of them pans out. Every one of them shows up as a tool you can touch before it shows up as news you can read, and the people touching it get a say in what it becomes, while the people reading about it get a summary.

That is why “I am not engaging with this yet” is not a neutral position. Not building is a choice, and it is the choice to let the fork be decided by whoever was building. It costs nothing this month, and then it costs the decade. The gap is what makes people notice, and it was never the reason to build. If everyone else stopped building tomorrow, you would still owe the work you can do with the tools in front of you.

Nearly everyone is going to use AI, so the gap will run between people whose use compounds into a capability and people whose use stays consumption. The sorting question is short. When the next model ships, what of yours gets better? If the honest answer is “my opinion,” you are on Path A, and no amount of reading moves you off it.

Start Tuesday

Give the model one real job this week. Something you would otherwise have done by hand, with an output you can look at on Friday. Ship it, however ugly. Ugly and running beats elegant and planned, and it is the only version a better model can improve.

Keep reading, and change what you read for. Reading has one job here, which is aiming the next thing you build. Attached to a build, an hour of it is worth the hour, and detached it is worth nothing, which is why a month of it can leave you at the same starting line as someone who read nothing. A launch post is worth an hour if you walk from it into the tool with a task, and it is worth nothing if you walk from it into a forward. Sampling every new tool is its own trap, and the fix is the same. A tool gets one real job or it does not get your afternoon.

Build things that run without you. A script, a workflow, a check, an agent with a standing task. Those are what the next release lands on. A conversation with a chatbot, however good, lands on nothing.

Swap the model, keep the thing. When a new model ships, put it in your pipeline and watch what changed. That is the only benchmark that tells you anything about your work, and it takes an afternoon.

If you lead a team, count builders instead of seats. Ask what got built with the seats last month and ask to see it running. A pilot that someone else owns is Path A with a budget line.

Show the ugly version. Put the thing you built in front of the team, with the failures in it, before you are proud of it. That is how the next person on the team starts building instead of reading about what you built.

You will hear four objections, and I have heard all of them from smart people. “I am not technical.” Building is not code, and the tools are the least technical they have ever been. “My company blocks the tools.” The free tiers run on a phone, and the obligation does not wait for a seat license. “It is changing too fast to invest in.” It is changing too fast not to, and a moving target rewards the person who is already moving. “I will wait until it settles.” It settles on the people who built, and it is settling now.

Final Thoughts

Consuming is fine. I read every morning, and I will keep reading. But reading does not compound, and this is a compounding decade. Every month the tools get better, and every month that improvement lands on whatever you have made. If nothing of yours gets better when the tools do, that is the whole gap, and it grows by one release at a time.

Code got cheap, and building did not, and that was the good news, because building was always the part that was yours. Pick a job, hand it to the model, and ship the ugly version on Friday. Then watch what the next release does to it.

If you want a room full of people who build with the tools every week and show each other the ugly versions, MasteryLab is where that happens.

FAQ

How do you actually keep up with AI?

Give the tools a real job every week and ship the result, however ugly. Keep reading, but read with a task in mind and walk from the post into the tool. When a new model ships, put it into the thing you built and watch what changed. Reading on its own leaves you at the same starting line every month, because by the time you open the tool the interface has changed and the model you read about is gone.

Is reading about AI enough to stay relevant at work?

No. Reading gives you a vocabulary and an opinion, and neither one compounds. Relevance comes from a capability that improves when the tools do, and that only happens if you built something for the improvement to land on. A reader can pass as a builder for about a quarter. After that, the question “what got better last month” separates the two.

What does building with AI mean if you are not an engineer?

It means making a thing that runs without you, out of whatever medium your job gives you. A screen that reads every resume the same way. An agent that keeps the runbook current. A weekly report that writes itself from the data. A check that flags a wrong number before a customer sees it. Building is the verb, code is one medium of many, and the tools are the least technical they have ever been.

Should you wait for AI tools to settle before investing time in them?

No. The tools settle on the people who built with them, and waiting is a decision to receive whatever settles. Each month’s improvement lands on what already exists. If nothing of yours exists, the gap between you and the people who built grows by one release, and the day you finally start you have more to unlearn than they did.