The Real Workflow of a Solo Developer Using AI Agents

I opened this blog project today and had one of those small blank-page problems that somehow eats an hour. This is the real AI agent workflow I used as a solo developer, not the clean version people describe after the work already looks obvious.

I knew I wanted more posts. I did not know what the next post should be. That sounds minor, but it is exactly the kind of thing that slows me down when I am building alone. There is no editor asking for a draft by Friday. No teammate saying, "Write the API one first." Just me, the repo, and the quiet suspicion that I am about to make another list instead of publishing something.

So I used an AI agent for the boring first step.

I asked it what this workspace was about. It read the repo and came back with the shape of the project: Next.js, MDX posts, Supabase migrations, admin pages, content scripts, and a writing guide. That was useful, but the first recommendation leaned too much on what already existed in the folder.

The blog already had a lot of Chrome extension material. The agent noticed that and started recommending more of it.

That was reasonable. It was also not what I wanted.

So I corrected it:

dont rely on what i have

That one line changed the output. Instead of staying trapped inside the current archive, it suggested broader topics: AI-assisted building, solo SaaS, APIs, security, browser tools, build-in-public updates.

Then I asked it to create initial_blog.md and put the list there, including what each topic should discuss.

That was the moment the session became useful.

Advice Disappears. Files Stay.

I do not trust AI sessions that end with only advice.

Advice feels productive for about 15 minutes. Then the chat scrolls away and I am back where I started, except now I have the soft guilt of knowing I "planned" something without doing anything.

A file is different.

initial_blog.md is not magic, but it exists. It has 30 topic ideas. It has notes under each one. It has a publishing order. I can edit it, ignore half of it, turn one item into a post, or commit it as an editorial backlog.

That is usually how I judge whether an AI session helped:

• Did it create a useful file?
• Did it make a decision easier?
• Did it expose a mistake?
• Did it save me from explaining the whole repo manually?
• Did it give me something I can review instead of just something I can admire?

If the answer is no, the session was probably just a very polished distraction.

The Part I Still Had to Do Myself

The agent also generated this sample post.

The first version was clean. Too clean.

It had sections like "My Current Loop" and "Where AI Helps Me Most." Nothing was technically wrong with them, but the whole thing had that smooth AI smell: balanced, tidy, instructional, and a little too pleased with itself.

That is the danger with AI writing. It can produce something that looks finished before it has earned the right to be finished.

So I had to pull it back toward the actual experience:

• I was in this repo on July 4, 2026.
• I asked what the workspace was about.
• I corrected the direction when it leaned on existing posts.
• I created initial_blog.md.
• I moved the sample into content/blog/fityra.
• I set draft: false because otherwise the local preview would hide it.
• I generated a cover image and saved it under public/images/posts.
• I checked the post URL and image URL locally.

Those details matter. They are the difference between "AI can help developers" and "here is what I actually did this afternoon."

The smallest technical detail was also the easiest one to miss. The post had to be inside content/blog, and it had to be publishable:

featuredImage: "/images/posts/solo-developer-workflow-using-ai-agents/cover.png"
draft: false

If draft stayed true, the app would quietly filter the post out of the local blog list. That is not an AI problem. That is just me needing to understand my own content pipeline.

The Workflow I Would Reuse

The workflow is not complicated:

ask -> inspect -> correct -> create -> review -> preview

The important step is correct.

Without correction, the agent tends to follow the easiest visible path. In this case, that meant recommending more topics similar to the existing archive. In code, it might mean copying a nearby pattern that is outdated. In product work, it might mean giving you advice that sounds reasonable but has nothing to do with your actual constraints.

The agent is useful when I treat it like a fast junior collaborator with infinite patience and no real ownership.

It can read quickly. It can draft quickly. It can move files. It can generate variations. It can remember the structure of the repo better than I can after a long day.

But it does not know what I am trying to become.

That part still has to come from me.

A Small Checklist for Using AI Without Losing the Thread

If you are using AI agents in your own project, this is the checklist I would start with:

• Ask it to inspect before asking it to create.
• Correct the direction as soon as it makes the wrong assumption.
• Prefer files, patches, tests, and checklists over long explanations.
• Read the output like it came from a confident stranger.
• Preview the result locally before trusting it.
• Remove anything that sounds like it could belong on any other blog.

For this post, the preview checks were simple:

http://127.0.0.1:3000/blog
http://127.0.0.1:3000/blog/solo-developer-workflow-using-ai-agents
http://127.0.0.1:3000/images/posts/solo-developer-workflow-using-ai-agents/cover.png

That last one is the painful one.

Generic writing is comfortable because it is hard to disagree with. Personal writing has edges. It says, "This is what happened to me, in this project, with these tradeoffs."

That is also why people keep reading.

What I Learned From This Session

The useful lesson was not "AI makes blogging easier."

It was narrower than that:

AI is good at turning a vague intention into a first artifact. I am still responsible for making that artifact true.

That means I can use an agent to get unstuck, but I cannot outsource taste. I can ask it to draft a post, but I have to remove the parts that sound fake. I can let it suggest topics, but I have to choose the ones that match the kind of builder I want readers to meet.

That is the balance I want for this blog.

Every post should teach something useful. Every post should have enough personal detail that it could not have been written by a generic content machine. And every post should make another solo builder feel a little less stuck than before.

That is a high bar for a blog draft.

Good. It should be.