How to Pick a Project for Learning Agentic Coding

In the previous post, I defined my first goal: create a zero-cost environment where I can learn agentic coding without worrying about consuming credits every time I make a mistake. But having an environment to experiment with creates another question:

What should I actually let the agent work on?

I could create a new project specifically for the experiment. A simple calculator, a task list, or one of those small applications we usually build when learning a new technology. That would certainly make testing easier, but I don't think it would make the experiment very realistic.

At the same time, connecting an AI agent to one of my large commercial projects would go too far in the opposite direction. Those projects have years of development behind them, multiple applications, infrastructure, integrations, business rules, and real users.

I needed something in between: something real enough to challenge the agent, but safe enough that I wouldn't care too much if the experiment went completely wrong.

My portfolio became the sandbox

I already had two good candidates sitting in my Git repositories.

The first is My Finances API, a backend project built with Java and Spring Boot. It's part of my portfolio and contains the basic structure of a real backend application, including Controllers, Services, Repositories, entities, authentication, database access, and tests.

The application isn't deployed and currently focuses mostly on basic CRUD operations—Create, Read, Update, and Delete. That makes it useful for this experiment because there is already enough architecture for an agent to understand, but the application is still relatively small.

The second project is My Practice Next, a guitar and bass practice application I built recently with Next.js. This one is more complex. It has a frontend and backend, user authentication, a database, application settings, and quite a bit of logic around instruments, exercises, fretboards, music notation, staff, and tablature.

My Practice Next is deployed and publicly available, but it's still an early project without significant traffic. There are features I want to add, but nothing happening there is critical enough that an AI experiment going wrong would become a serious problem.

Together, the two projects give me two different environments:

Project	Stack	Current complexity	Why it's useful
My Finances API	Java + Spring Boot	Low	Clear backend architecture and simple business logic
My Practice Next	Next.js	Low to medium	Full-stack application with more specialized logic and room to grow

That combination wasn't something I had planned when I originally built these projects. It just happened to fit the experiment surprisingly well.

Why not start with an empty project?

An empty project would definitely make the agent's job easier, but that's also the problem.

If I ask an AI to create a new Service class from scratch and it creates one, what exactly did I learn? I already know AI can generate code. What interests me more is whether it can enter a project where decisions have already been made.

There is already a folder structure. There are naming conventions. There are patterns for Controllers and Services. There are shared classes. There are ways I normally handle errors, map objects, write tests, and organize features.

The agent shouldn't simply write valid Java or TypeScript. Ideally, it should recognize:

This is how this project works.

Then continue working in the same direction.

That's much closer to what I would eventually expect from an agent in a real development environment. Most professional software development isn't starting with an empty folder. It's opening an existing codebase and figuring out how your change fits into everything that's already there.

For that reason, I think a useful learning project should already contain enough code to have an identity.

But not too much identity

There is a limit, though.

I also have access to much larger software projects. My commercial ERP platform, for example, would provide a far more realistic test. It has multiple applications, relationships between projects, considerably more business logic, and a much larger codebase.

That's exactly why I don't want to start there.

If a small local model struggles with a task, I want to have some chance of understanding why it struggled. Starting with a large system introduces too many variables at once. Did the model fail because the task was difficult? Was the codebase too large? Did it miss a relationship with another project? Did I give it the wrong information? Did it simply get lost?

My two portfolio projects aren't trivial, but I already understand them well and their overall complexity is manageable. That gives the models a reasonable challenge without immediately asking them to understand years of software development.

It's a little like learning to drive. An empty parking lot eventually becomes too easy, but your next step probably shouldn't be downtown traffic during rush hour.

You want some roads, intersections, traffic lights, and other cars—just not everything at once.

I need somewhere to increase the difficulty

There was another reason these projects worked particularly well: I can easily think of things to build next.

If I only have one task, I can find out whether a model succeeded or failed at that particular task. It doesn't tell me much about where its limits are. With these projects, I can gradually increase the difficulty.

Conceptually, the progression looks something like this:

Simple change -> Existing code modification -> Multiple related files -> Tests and debugging -> More business logic -> Complex feature

I'm not trying to define the exact tests yet. I just need a project where this progression is possible.

That gives me something more useful than a pass-or-fail result. If a model performs well on simple tasks but starts struggling when several parts of the application are involved, I've learned something about its practical limits.

Git makes failure much less scary

There is one requirement I wouldn't skip: version control.

Both projects use Git, which means I can see exactly what the agent changed. If it modifies five files when I expected one, Git will show me. If it removes something unexpectedly, Git will show me. If the entire experiment goes terribly wrong, I can restore the project.

That turns Git into more than a development tool for this experiment. It becomes part of the safety net.

Because these are my projects, I'm also free to create branches specifically for experiments, restart tests, or repeat the same task under different conditions. Failure becomes reversible, which is a pretty useful property for something I'm intentionally expecting to fail occasionally.

A successful experiment should still be useful

Another characteristic I particularly like about these projects is that the work doesn't have to be thrown away.

Both have roadmaps. There are features I genuinely want to implement in My Finances API and features I want to add to My Practice Next. That means some of my agentic coding tests can eventually use real tasks instead of artificial exercises.

If an experiment fails, I learn something.

If it succeeds, I may learn something and get a feature implemented.

It also makes the evaluation more realistic. If I invent a meaningless feature just to test the AI, I don't care much about the result beyond whether the test passed. If it's something I actually intend to keep, my standards change.

Would I merge this code? Does it follow the existing architecture? Would I maintain it? Would I be comfortable coming back to it six months from now?

Those are much closer to the questions that matter in real software development.

What makes a good sandbox project?

Looking at these two projects, I think the criteria for a useful agentic coding sandbox are relatively simple:

• Low to medium complexity. Enough code to navigate, but not so much that understanding the codebase becomes the entire experiment.
• Existing standards and patterns. The agent has something to learn and follow instead of inventing everything from scratch.
• Room for new features. You can create tasks ranging from simple changes to increasingly complex functionality.
• A codebase you understand. If you don't know what good looks like, evaluating the AI becomes much harder.
• Git versioning. You have a reliable way to inspect, compare, and reverse changes.
• Low consequence of failure. Avoid projects where a bad experiment can affect customers, important data, or business operations.
• A real purpose. A portfolio project, hobby application, or early business idea gives successful changes somewhere useful to live.

The project doesn't need to match mine. A small Python API, an unfinished mobile app, a personal website, a game, or a tool you built for yourself could all work.

The important part is finding the middle ground.

Not Hello World.

And definitely not your company's production platform.

Something real, understandable, expandable, and safe to break.

A sandbox that can grow with me

I started this step thinking I simply needed a repository where an AI agent could modify some code. What I actually needed was a project that could grow with the questions I want to ask.

That's why I'm starting with My Finances API and My Practice Next. They already have enough code and structure to challenge an agent, but they're still small enough that I can understand what went wrong. They're versioned, safe to experiment with, and have real features waiting on their roadmaps.

For learning agentic coding, that sounds like a pretty good sandbox.

And if the agents actually manage to implement some of those features along the way?

Even better.