AI Coding Bootcamp Week 1 Recap

Week One: Why We’re Doing This

We kicked off week one of the AI Coding Bootcamp this week, and I came away even more convinced that this is one of the most important skill shifts happening in software right now.

This is our first AI coding program, and we brought together 42 people from 22 companies for the first session. We had founders, developers, product managers, and technical leaders in the room, which is exactly what I hoped for, because this change is not just for engineers. It is for anyone involved in building products, improving systems, and helping a software company move faster. As I said at the start of the call, “It’s an extraordinary time in human history where we can utilize these tools to build products that matter.”

I have been building SaaS companies for a long time. In the session I shared, “I’ve been building SaaS companies for 23 years,” and that perspective is part of why I wanted to create this bootcamp now.

When I built iContact, we had 60 engineers across R&D, QA, and design. That was the reality of what it took to build and scale meaningful software in that era. Today, the leverage available to small teams is changing dramatically. I said this on the call, and I believe it deeply: “We can now build more with 2 or 3 developers than we could with 60 developers previously.”

That does not mean software got easy overnight. It does mean the people who learn how to use these tools well are going to have an enormous advantage.

What This Program Actually Is

This bootcamp is an 8-week agentic engineering program. Patrick van Staveren is leading the instruction, and Steve Canfield will be joining as assistant instructor starting next week. My role is to host the program through SaasRise and help connect what we are learning back to real company-building and operating realities.

The structure is intentionally practical. We are recording the sessions, sharing everything afterward, and keeping the conversation active through Slack, WhatsApp, and email. I told the group, “We’re gonna be recording these sessions and sending them around,” because I wanted everyone to know this is meant to be a working environment, not just a one-hour lecture each week.

Our first session focused on a few core pieces:

• a welcome and orientation
• the AI tool landscape for builders
• a live Claude Code demo
• install help and troubleshooting
• prompt ideas
• office hours for anyone still getting set up

In other words, the first goal was not mastery. The first goal was momentum.

The Big Shift We’re Teaching

One thing Patrick did very well in week one was explain that what is changing here is not just the toolset. It is the shape of the work.

He described how the old model was a developer sitting in an IDE, maybe using AI autocomplete around the edges. The new model is much more agentic. The AI can write code, run commands, inspect output, interact with a browser, and iterate against a working environment. That is a very different workflow from asking a chatbot for a snippet and then manually piecing everything together.

That framing matters because a lot of people still think AI coding just means better autocomplete. It is already much bigger than that.

Patrick’s goal for the first half of the course is to help people get dangerous with the tools quickly, and then spend the second half helping them become responsible and effective with them inside real businesses. I think that is exactly the right progression. First, you need to see the power. Then you need to learn how to apply it well.

Why This Matters Right Now

Part of why this first session felt important is that the timing really does matter.

I said on the call that, “This is our very first AI coding program,” and it felt like the right moment to launch it because this shift is already happening.

At the same time, I also tried to be honest about the pace of change. I said, “It’s in some ways easier to build software products. But in some ways, it’s challenging, because things are changing so quickly.”

That is the tension a lot of founders and technical leaders are feeling right now. There is more leverage than ever, but there is also more noise, more tooling, more experimentation, and more uncertainty around what the modern workflow should actually look like.

That is one of the reasons I wanted this to be an 8-week program rather than a single webinar. People do not need another high-level conversation about AI. They need reps. They need working sessions. They need room to ask dumb questions, break things, and figure out what is useful.

Patrick’s Framework for the Tool Landscape

Another useful part of week one was Patrick’s overview of the AI coding tool ecosystem.

There are now a lot of products in the market, and it is easy for teams to hear terms like Claude Code, Cursor, Codex, Gemini CLI, OpenClaw, Supabase, or Vercel and end up with a blurry picture of how they all fit together. Patrick broke the landscape into a few broad buckets: app builder systems, AI-assisted IDEs, full coding agents, and always-on agentic systems.

That context was important because the program is centered primarily around Claude Code, but not because it is the only good tool. It is because it is a strong way to understand what agentic coding feels like when you move past the old autocomplete model.

He also explained that while plenty of competitor tools are getting better fast, the key shift is not really about one vendor winning. It is that this is becoming a core competency for modern software teams.

The Live Demo That Made It Real

The strongest part of the session was the live Claude Code demo.

Patrick started in an empty directory and prompted Claude Code to build a small chat application. He let the tool choose Node.js, watched it create files, run commands, install dependencies, and launch a local server. Then he had it modify the app in response to follow-up requests, and eventually he had it inspect and test its own output through a browser running in debug mode.

That was the moment when the distinction between “AI that writes code” and “AI that acts like an agent” became much clearer.

This was not just a text generation exercise. The system was interacting with the environment, running things, seeing what happened, and iterating. That is a big part of what makes these workflows different.

It was also useful that the demo was imperfect. There were bugs. There were moments when things did not work the first time. Patrick let the room see that too. That was healthy. These systems are powerful, but they are not magic. The point is not that they are flawless. The point is that they can compress a huge amount of work and iteration into a much smaller amount of time.

The Conversation Got Practical Fast

One thing I really liked about the first session was how quickly the group moved from curiosity to practical questions.

People asked about Windows setup, WSL, GitHub, permissions, browser control, older .NET and Angular codebases, Laravel and PHP, WordPress integrations, Supabase, and how these workflows apply to existing systems rather than just greenfield demos.

That is exactly where the conversation should go.

It is fun to build a quick prototype or a simple game. Those are good first reps. But the real commercial value is not in toy apps. It is in helping real teams move faster inside real systems. It is in debugging faster, prototyping features faster, modernizing internal tools faster, and reducing how much expensive human time is spent on repetitive engineering work.

Patrick made that point clearly when he said that it is easy to build something new with AI, but harder to work on existing systems with AI. That is true. It is also where a lot of the real upside lives.

This Is Not Just for Hardcore Engineers

Another part of the session that I appreciated was Patrick’s encouragement to the less technical people in the room.

He specifically said some of his favorite learners are the people coming in with no experience. He acknowledged that AI coding can feel complicated and daunting at first, but he kept coming back to the idea that learning by doing is the only real path through it.

That matters because many of the people who most need to understand these tools are not career software engineers. They are founders. Product leaders. Marketing operators. Technical managers. People close enough to the work that understanding the new workflow will change how they make decisions, even if they are not writing production code full time.

This is one of the things I am most excited about with the cohort we have. It is not a room full of people trying to become internet demo stars. It is a room full of people trying to understand how this changes the economics and execution speed of their real businesses.

What We Wanted Everyone to Leave With

The immediate objective for week one was simple: get Claude Code working from the command line and build something.

That is why we split the room. One group stayed with me and started building small projects. The other went into a breakout room with Patrick for setup support and troubleshooting. I said during the session that the main objective in office hours was to make sure everybody had Claude Code working from the command line and was able to start building real software.

That was the right first milestone.

Not everyone needs to leave week one having built a production-ready app. But they should leave with the tool installed, the friction reduced, and enough confidence to start experimenting on their own over the next seven days.

What Comes Next

The homework from week one is not complicated, but it is important.

• get Claude Code installed and running
• create an empty folder and work inside it
• run one real prompt
• build one simple thing
• post a screenshot, question, or error in Slack
• keep going even if it feels messy at first

That is how intuition gets built here.

Patrick closed the session by encouraging people to grab one of the sample prompts, build something, and share not just what worked, but what felt confusing or even a little scary. I think that is exactly right. The fears people have with these tools are not irrational. The tools are powerful. They do make mistakes. They can act in surprising ways. The right answer is not to ignore that. The right answer is to build real experience and judgment.

My Takeaway After Week One

Week one did exactly what I hoped it would do.

It made the opportunity feel real. It gave people a practical starting point. It lowered the barrier to entry. And it got the cohort moving from passive interest into actual building.

After 23 years in SaaS, I do not think this is a minor workflow improvement. I think it is one of the biggest changes in how products will get built from here forward. And the companies that learn how to use these tools well are going to be able to move faster with smaller teams than most people still realize.

We are just getting started.