The 30-Day AI Challenge: Build Something Real With Your Team

Here is what I have learned after a month of writing about AI, and months of watching people around me try to adopt it.

Reading about AI changes nothing. Watching a demo changes nothing. Nodding along to a blog post, even a good one, even this one, changes nothing.

Building one small thing for thirty days changes everything. Not because the thing will work. Mine mostly did not, and I wrote a whole post about that last week. It changes everything because at the end of it you have stopped theorizing about AI and started shipping with it.

That is a different skill entirely from asking an AI a question, and the only way to learn it is to do it. By day thirty you have opinions, earned ones. You know where it helps and where it wastes your time. That knowledge does not come from reading. It comes from building.

So here is my challenge to you. Thirty days. One real thing. And I am doing it with you.

The promise

I cannot promise your agent will work. I genuinely cannot. If ninety percent of mine still break, I would be lying to promise you a clean win.

What I can promise is this. Do the thirty days, and your relationship with AI will be different at the end of it. You will have moved from someone who talks about the revolution to someone with the scars of having built one small clumsy corner of it. That shift always happens. It is the one guaranteed outcome, and it is worth more than any single working agent.

That is the deal. Not “AI is magic.” Just “commit thirty days and you will not be the same builder on the other side.”

And yes, I know what the current argument is. Everyone is saying it is not about the number of tokens you use, it is about the quality of the output. Fine. But no one ever learnt how to ride a bicycle by measuring the distance they could travel on day one. They learnt by trying, falling off, and having access to a bicycle every morning. There is a reason there is a gap between trying and measuring output. Do not focus on the right thing at the wrong time. First, get on the bicycle. Max out your tokens. Build the habit of building. The refining comes after.

The pre-work, before day one

A little setup saves you a week of flailing.

First, pick your platform, and pick it in the next five minutes. Use whatever you already know or already have access to. Your enterprise assistant, a coding-agent tool, the thing your organization already pays for and you have been meaning to try. Do not go tool shopping. Do not wait for the perfect one to arrive. The best platform for this challenge is the one you can open right now.

Second, pick one real, small, annoying task. Here is how to find it: for one full day between now and day one, take yourself off autopilot. Move through your day intentionally. Every time you hit a moment where you think “I wish I had a teammate sitting next to me who could help with this,” write it down. Every time you catch yourself pulling data, chasing a status update, or stitching together information from three different sources and you think “this is the kind of thing I would happily hand off,” write that down too. Your use case comes from the friction you feel in your hands, not from a brainstorm in a conference room. The test is simple: if you cannot describe it in a single sentence, it is too big for a first build. Resist the ambitious version. I built the ambitious version and it hung for hours on the nights I needed it most. Learn from my expensive mistake.

Third, write down your one-sentence success test before you start. How will you know, on day thirty, whether this worked? Decide it now, in writing, while you are still honest. It is very easy to move the goalposts at day twenty-eight when you are tired and want a win.

And fourth, go read last week’s post. The actual rules for how to build, the six lessons I earned the hard way, live there. I am not going to repeat them here. This post is about the challenge and the commitment. That post is about the craft. You want both.

The rules of the challenge

These are not build rules. They are the rules of the ritual, the things that keep you honest for thirty days.

Thirty days, one thing, ship something usable by the end, however small and clumsy.

A little every day beats a heroic weekend. Momentum matters more than intensity. Fifteen honest minutes most days will get you further than one guilt-fueled Sunday.

Keep a one-line daily log. What you tried, what broke. That log is not admin, it is your own lessons post writing itself. On day thirty you will read it back and be amazed at what you did not know on day one.

No pivoting after day seven. Pick your thing and commit, even when a shinier idea tempts you on day twelve. The constraint is the point. You are building the muscle of finishing, not the muscle of starting.

Build in public, at least to the people around you. Which brings me to the part that actually matters.

Take it to your team

You can do this alone. It will be good for you. But if you want the real unlock, take it to your team.

Here is why the team version is transformative and the solo version is merely useful. A shared thirty-day challenge gives everyone the same deadline, the same permission to fail, and by the end, the same vocabulary. Your team stops circling the question “should we be using AI” and starts asking each other “wait, what did you build?” That is a completely different conversation, and you cannot get there by sending around another article.

Keep it light. A ten-minute kickoff where everyone names their one thing and their one-sentence success test. A mid-point show-and-tell at day fifteen where people share what they tried and what broke, raw and unpolished, because the wins teach what to replicate and the fails teach where the gaps are, and both move the group forward. A demo day at the end where the bar is “show what you learned,” not “show something that works.” No leaderboard. No prizes for the shiniest output. The moment it becomes a polished-demo competition, people start hiding the mess, and the mess is where the learning lives.

I have run this. I will run it again. And the promise holds at the team level even more strongly than the solo one: even if ninety percent of what your team builds breaks, you finish with a team that has learned how to fail cheaply and learn fast. Most organizations never build that muscle, because they never give themselves permission to try. This is how you give them that permission.

I cannot promise your agent will work. I can promise the thirty days will change how your team builds. That part always works.

It works. I am not hedging on that one. The building might not. The transformation of the team will.

What I’m building

I am not going to sit this out and cheer from the stands. That would make me exactly the narrator-from-the-sidelines I spent all of last week arguing against.

So I am taking my own thirty days, and I will build in public right here on this blog.

Here is mine. I’m on a critical project that needs information from every people-manager on my team: updates, flags on what is stuck, what they need from me. I don’t want the same chase: send the questions, wait, remind, remind again, compile the answers. So I am building an information-tracking app. It sends managers the set of questions, collects their responses, tracks completion metrics, and sends reminders via email as the deadline approaches. One app, team-level, coordination over individual output, and deliberately the kind of thing my whole series has been arguing for. I picked it because it is what I actually need for my work right now, ideally in less than thirty days. That is the test: build something real enough that you would be annoyed if it disappeared.

I will share the wins, the breaks, and the one-line log. If it works, you will see how. If it does not, you will see that too, because a confident blank helps no one.

Your turn

So this is where the July series ends. Not with a grand conclusion about the future of work, but with a challenge and a promise.

Pick one small thing. Give it thirty days. Use whatever tool is already in front of you. Take it to your team if you possibly can.

I will report back on my own thirty days here. Working or broken, you will get the honest version.

Now go build the small thing.