I’ve spent the last week diving headfirst into Claude Code, and I’ve gotta say, it’s been a wild ride. I went from being impressed by the basic “out-of-the-box” experience to building my own little crew of AI agents that has totally changed how I build software. It’s been a game-changer for the quality of the outputs and is saving me a lot of time and a lot of rework.

Key lessons learned

• Agents and tasks take Claude Code from being a novelty to being a real partner.
• Commit often. If something goes wrong, or you don’t like the direction that Claude Code is taking you, it’s a lot easier to start some changes over from scratch.
• Compact often! When the session context gets full, Claude Code will auto-compact your context. While a necessary feature, it can cause important context to be lost, and the chance of rework increases.

The Honeymoon Phase

When I first fired up Claude Code, I was blown away. The speed was amazing. I could throw prompts at it, watch it map out a plan, and see code appear. There is just no way that I, or any individual can beat the development speed vs manual coding, and it has solidified for me that we are never turning back.

But it didn’t take long for me to figure out that just having a back-and-forth chat wasn’t going to cut it for bigger, more serious projects. I needed a better way to keep things organized and delegate work.

The .claude folder

After a lot of Youtube rabbit holes, and countless blog posts, it was apparent that my initial setup was subpar. Given how novel the technology is, I found it difficult to find out how to best create and orchestrate agents and to reduce the need for every action to be a prompt from me.

The answer, it turns out, was a lot more simple than I had thought.

The .claude folder had everything I was looking for. Let’s take a look at the structure and how it helps to make the creation process easier.

Agents

The agents folder is a collection of .md files that define the various agents that you can use in a claude session. When you session loads, Claude scans the folder and if the markup is in the right format, it will make the agent available in Claude Code. To call an agent, just @ the agent name. For example:

@agent-architecture-agent Perform a comprehensive review of the project to date to ensure it aligns with the architecture plan

And here is an example of the header structure required for the agent to be picked up by Claude Code on start:

---
name: architect
description: Enterprise software architect for large-scale, internet-facing applications. Use when designing systems for millions of users, high availability, and zero-downtime deployments.
tools: Read, Grep, Glob, Bash, Write, Edit
model: opus
---

There are a couple of ways to speed the creation of agents. One would be by using the /agents menu, and then select Create new agent.

Next you will be prompted to select if this is a Project or Personal agent. A personal agent is available across all projects, where a Project agent is limited to the current project

Next you will be prompted to either Generate with Claude, or manual configuration. I have only tried generating with Claude to date because, well it’s a lot faster.

Last, enter the prompt that will be used to generate the agent. Once you’re satisfied, hit enter to create the agent.

Next you will be prompted to select what tools are available to your agent. Choose what you are comfortable with, then click Continue.

Then select the model you would like the agent to use.

You will then be asked to select a color for the agent, then review and confirm the details of the agent. Then you’re done!

Skills

Claude skills allow you to quickly call repetitive functionality using the /skill-name convention. For more info on creating skills, check out the Claude Documentation.

Automating the agents and skills creation process

You could go through and create every agent and skill manually. But I found it was a lot more convenient to just prompt Claude Code to create the folder structure required, and start with a prompt like this.

Create a .claude directory. The directory must contain agents and skills that will support the creation of enterprise scale applications. The agents and skills must always keep in mind strict security requirements, adherence to international data protection legislation such as GDPR, CCPA, PIPEDA, and other applicable legislation. Assume that security issues and downtime with the resulting application could result in loss of revenue, regulatory action, or legal liability.

You may need to tinker a bit with the resulting agents and skills but it will get you going out of the gate.

The new creation process

As mentioned above, my projects now start with me setting up my crew and giving them a shared “docs” folder to keep their notes. Each agent has its own file to track its work, and they all chip in on a shared context.md file, which is basically our team’s daily stand-up report.

My go-to roster of agents usually includes:

• An Architecture Agent to think about the big picture.
• A Front-end Dev Agent for the UI.
• A .NET Agent for the back-end stuff.
• A Security Agent to keep things locked down.
• A UI Design Agent to make it look good.
• Test Writer & Runner Agents to make sure things actually work.

As far as the skills that I have implemented, my go-tos have been for commits and security checks. But my absolute favorite is my “orchestrate” skill, where I can just line up the agents I need, give them a goal, and watch them go to work as a team.

My New Game Plan

Here’s what my project kick-off looks like now:

1. Figuring out what I want: I start by chatting with my Requirements Agent. It’s like a brainstorming session where it helps me flesh out my ideas and even suggests new features I hadn’t thought of.
2. Drawing the blueprints: The Architecture Agent steps in next to make sure the app will be scalable, secure, and built on a solid foundation.
3. Planning the UI and Data: The UI Agent and Database Agent then work together to plan out the user experience and how the data will be stored.
4. Designing the API: The API Designer takes the data model and writes up the specs for the API.
5. Building the Backend: My .NET Agent grabs the API specs and starts building out the backend.
6. One small step at a time: From there, I build out the rest of the app one small feature at a time. This keeps things manageable and lets me test as I go.

So, What Did I Build?

I used this exact setup to start building an e-learning app for the Power Platform community. It’s a pretty hefty project with user accounts, course catalogs, progress tracking, and admin panels. Because I live in Canada, I had to make sure it complied with GDPR, CCPA, and PIPEDA. I told my agents this from the very beginning, and they factored it into everything they built, including a detailed audit log.

The Good, The Bad, and The Human

The results have been awesome. My Security Agent has been a lifesaver, catching issues with how I was storing JWTs and suggesting things like rate limiting to prevent attacks.

But it’s not all magic, and you definitely still need a human in the driver’s seat. One of those moments was when the agent implemented IP-based API rate limiting. I realized that if 20 people from the same office were using the app, they’d all get locked out. It was a classic case of the AI being logical but lacking real-world context. It’s a great reminder that these tools are here to help you, not replace you.

The Biggest Change for Me

Honestly, the biggest shift has been in my own mindset. I’ve gone from being a hands-on coder to more of a manager. I delegate tasks to my AI team, review their work, and provide course corrections along the way. It’s like being the conductor of an orchestra instead of playing every instrument yourself. It’s freed me up to focus on the more creative, high-level parts of building software.

My first week with Claude Code showed me that the real power isn’t just in the AI itself, but in how you organize it. By building a team of agents, I’ve created a development process that’s not just faster, but smarter and more robust.

For a long time, I’ve been a skeptic about AI-driven development. Sure I’ve tried GitHub Copilot for a few small things there and there, like a PCF control for a demo I was doing at a conference. But even with that, my inner skeptic has been a loud and persistent presence in my AI journey.

One doesn’t have to look further than message boards and comment sections to see the critics warning that the end result of these tools is often garbage. (LinkedIn being the exception)

They argue that developers spend more time reviewing and fixing buggy, AI-generated code than it would have taken to write it from scratch. Plus there’s the existential and ego part of it that scares me a bit. If these tools are as good as they say they are, uninitiated or lagging developers like me are in trouble. The reality today is we either learn or get left behind.

Holding onto that healthy dose of skepticism and my bruised ego, I decided to see for myself if these tools had matured beyond simple novelties. And the one screamed most often from the rooftops was Claude Code.

Like many, I have a backlog of personal projects. Web applications I’ve envisioned but never quite found the time to build manually. When I decided to dive into Claude Code, I didn’t want to start with a trivial “Hello, World!” My goal was ambitious: to replace a well loved but tedious spreadsheet, a cash flow forecasting spreadsheet for my consulting business, with a fully-fledged, modern web application.

Jumping Right In: A Full-Scale Project

My approach was direct: I fed Claude Code the functional requirements of the entire application right out of the gate.

I wanted to see if it could handle the complexity of taking a high-level concept and translating it into a working solution. What I discovered was Claude’s surprisingly collaborative “planning mode.”

Instead of simply generating code based on my initial prompt, I was surprised to see that Claude was more interactive than I thought. It presented me with a tabbed list of questions, guiding me through architectural decisions like the technology stack and database choices. I could select from its suggestions or provide my own responses. This process felt less like giving commands and more like co-designing the application. I could push back, Claude could push back. It seemed a healthy give and take.

Given my familiarity, I opted for a .NET Core backend and a React/Vite frontend, paired with a PostgreSQL database. Once all the decisions were made and I approved the refined plan, it was time for implementation.

Claude Code Setup

There are a few ways to run Claude Code, but I opted for the Command Line interface via VS Code for a few reasons:

• The availability of planning mode (apparently it is not available in the UI app)
• Familiarity – it feels more like developing in the terminal
• Features – the ability to see session capacity remaining, for example.

The Iterative Build: Backend First, Then Frontend

The implementation unfolded in a systematic way. Claude Code began by scaffolding the basic project structure: empty .NET Core projects for the API and a React/Vite project for the frontend.

It then moved to the data layer, leveraging .NET Entity Framework to create a migration for the PostgreSQL database. As the API functionality was built out, Claude adopted an interactive testing approach. It would generate new endpoints and then prompt me to test them via Swagger, ensuring that each piece was working as expected before moving on.

The frontend development followed a similar iterative pattern. Claude generated full pages, complete with React routing, TypeScript types, authentication contexts, and service integrations. The workflow involved a continuous loop: Claude would ask for input, make changes, and I would validate them directly in the browser.

All the while, I was able to fold laundry in between prompts and thinking and testing. What an age.

RIP My spreadsheet: Behold the Transaction Timeline!

While the initial version of the app was “bare bones,” it laid a solid foundation. The real breakthrough, my “aha!” moment, came after many iterations when we (jeez, I’m speaking like it’s a coworker now) built the transaction timeline.

This feature allows me to see a list of all upcoming transactions and, crucially, what my account balance will be after each transaction completes. It’s like a bank statement that includes future activity, providing a proactive view of my cash flow weeks or months ahead.

It’s been around for many years, but I’m not going to miss that spreadsheet after seeing this.

Lessons Learned and Frustrations

My biggest lesson learned was the importance of detail in the initial prompt, and in all subsequent interactions. While Claude’s planning mode is excellent, I realized there were many functional details I knew I wanted but hadn’t explicitly specified upfront. More detailed initial prompts would have streamlined the planning phase even further.

On the flip side, not everything was seamless. One frustrating bug I encountered was an issue within Claude Code itself: the terminal window would occasionally get stuck in an infinite scroll, which disrupted the workflow and if stared at for long enough, could give you a headache. Hopefully help is on the way for that soon.

Despite these minor hiccups, my first experience with Claude Code was overwhelmingly positive. The ability to articulate a vision and see a full-stack web application emerge within 24 hours was nothing short of sorcery.

However, it’s clear that this, or any of these tools, are only as good as the prompts you provide and the person using it. It’s a powerful partner, but it requires a knowledgeable person in the driver’s seat who can guide it, validate its work, and understand the underlying code and infrastructure.

For those willing to collaborate, it can bring projects to life with incredible speed.