100 AI-Assisted Projects

Hi, I'm Sargon.

I'm a software engineer, and I'm starting a new personal challenge: building 100 small-to-medium software projects with the help of AI.

Not as a stunt.

Not as a productivity challenge.

Not because I think every idea needs to become a startup.

I'm doing this because I want to turn potential into artifacts.

For a long time, I've had the feeling that I can build a lot, but not enough of it has existed outside my head. Too many ideas stayed as notes, unfinished repositories, half-built systems, or private thoughts. At some point, that starts to hurt. Not because someone else is judging you, but because you know there is a gap between what you are capable of and what you have actually made real.

There is another version of the same problem: consuming too much and making too little.

It does not always look dramatic. Sometimes it is just a quiet drift: opening YouTube for one useful video, checking a few posts, reading about other people's projects, and realizing later that I spent my attention on watching instead of making. The problem is not any single video or post. The problem is the habit of staying close to creation without actually creating.

I don't want to keep living mostly inside potential.

BUILD100 is my attempt to close that gap.

The goal is simple: build, finish, publish, learn, repeat.

Some projects will be useful. Some will be experiments. Some will be open source. Some will be tiny. Some may become real products later. Some will probably fail, or stop at the prototype stage, or teach me that the idea was not interesting enough to continue.

That is fine.

The point is not to make every project perfect. The point is to create a visible body of work: something I can look back at and respect, not because every piece was impressive, but because the work actually happened.

Why 100?

One project is too precious.

When there is only one idea, it becomes heavy. It needs to be good. It needs to justify the time. It needs the right stack, the right name, the right architecture, the right positioning, the right repo structure, the right design. Before long, the project is no longer a project. It is a small psychological negotiation.

One hundred changes the frame.

With one hundred projects, the individual project can become lighter. It does not have to carry my whole identity. It can be a question, a sketch, a study, a tool, a mistake, or a way to understand one narrow thing better.

Quantity is not the goal because quantity is impressive. Quantity is useful because it weakens perfectionism. It creates motion. It makes room for patterns to appear.

The first ten projects will probably be awkward. The next twenty may reveal what I actually enjoy building. Somewhere later, I expect the process to become more honest: less performance, more signal.

I want to learn what happens when building becomes a practice instead of an event.

Why AI-assisted workflows?

AI changed the activation energy of software development for me.

It did not remove the need to think. If anything, it made thinking more important. But it changed the shape of the work. Starting is easier. Exploring alternatives is cheaper. Rough prototypes can appear before the initial excitement disappears. Boilerplate matters less. Dead ends cost less.

That matters because a lot of projects die before they become concrete enough to argue with.

AI gives me a way to move faster from "what if" to "here is a thing." Once the thing exists, I can inspect it. I can dislike it. I can refine it. I can throw it away. I can learn from it.

I do not think of AI as a replacement for the engineer. I think of it more as a creative amplifier and a friction reducer. It expands the number of ideas that can be tested, but it does not decide which ideas matter. It can generate code, but it cannot care about the shape of a life, a taste, a system, or a body of work.

That part is still mine.

I want to understand how modern AI-assisted development actually works in practice. Not from tweets, not from demos, not from hype, but by building real things again and again.

I want to test workflows like:

• AI coding agents
• Cursor
• acceptance-criteria-first development
• automated tests
• rapid MVP shipping
• cloud-first SaaS patterns
• reusable infrastructure
• project documentation
• public launches

I want to learn what works, what breaks, what scales, and what only sounds good in theory.

Why document it publicly?

Private projects are useful. Public projects are different.

When I document the process, I have to explain what happened. I have to name the decision, the mistake, the shortcut, the thing that worked, the thing that felt wrong. This turns building into reflection instead of just output.

I also want the archive to be useful later. Not just as a list of finished things, but as a record of how I learned. What changed in my workflows? Which parts of AI-assisted development were genuinely helpful? Which parts were noise? Which tools became part of my system? Which habits survived?

The public part is not about performing certainty. It is about leaving traces.

A project can produce code, but it can also produce notes, questions, reusable patterns, better taste, and a more accurate sense of what I actually want to build.

This is also about identity.

I don't want to be a person who only thinks about building things. I want to be a person who builds things.

I don't want my work to exist only in private folders and unfinished plans. I want it to leave a trail.

This series is that trail.

Project by project, I'll share what I build, what stack I use, what I learn, what fails, and what patterns emerge.

What kinds of projects?

I expect the projects to cluster around the things I already care about:

• developer workflows
• personal knowledge systems
• small web apps
• automation tools
• writing and publishing systems
• experiments with AI agents
• interfaces for thinking
• product prototypes
• utilities that remove small frictions from everyday work

Some may become real tools. Some may become posts. Some may become notes. Some may only teach me that the idea was not interesting enough to continue.

Not every project needs to become a startup. Not every experiment needs a market. Software can also be a way to study a problem, organize attention, express taste, or recover momentum.

That is the spirit I want for BUILD100.

What this is really about

I am not trying to optimize myself into a machine that ships more.

I am trying to rebuild a relationship with creating.

Less scrolling. More making.

Less abstract planning. More contact with real constraints.

Less waiting for the perfect idea. More small experiments that reveal the next question.

AI makes this possible in a new way, but the deeper reason is not AI. The deeper reason is attention. I want to spend more of it on things that become part of the world, even if they are small.

This is the beginning of my 100 AI-assisted projects journey.

I do not know what all 100 projects will be. I do not know which ones will matter. I do not know what the process will change in me as an engineer.

That uncertainty is part of why it feels worth doing.