It Felt Like Having a Small Development Team

Watching several agents work and commits accumulate changed how it felt to develop a project on my own.

Where the idea began

The initial inspiration came from how other people were using AI. I had heard about startups and companies connecting AI across their operations, beyond individual tasks. I also saw someone I know using an AI pipeline to manage website QA, with what appeared to be a connection from identified problems into development work. I had not inspected the whole system, but the way those steps were connected caught my attention.

It made me want to try something similar. What if organizing ideas, identifying problems, and breaking down the next tasks could also become part of the workflow? Those examples gave me a starting point for experimenting with a process suited to my own projects.

The first impression

Over the past few days, I have spent a lot of time trying a development workflow I had previously only imagined. I chose a project, assigned work to AI, and kept supplying missing features and problems. I also watched tasks being divided among agents and their results brought together.

Seeing the work and commits accumulate quickly gave me a striking impression: it felt as though I had a small development team at my fingertips. In the moment, I even described it as having a large company in my hands. I do not mean that the system had the capabilities of an organization. The feeling came from watching several tasks advance at once after being used to the pace of typing instructions and waiting on my own.

It was genuinely enjoyable. Each result suggested something else to try, and I found myself preparing the next request while work was still underway. Once a blocker cleared, I sometimes lost track of time. The appeal was not just faster output; more of the ideas in my head had become practical to test.

The workflow

My goal extended beyond a single code-generation request. I wanted to collect feature ideas and improvements, record errors encountered during development, review related items together, and turn them into tasks that could be assigned to suitable agents.

record ideas and problems
→ review, group, and prioritize
→ break down tasks and assign agents
→ implement and verify
→ commit and integrate
→ assess whether refactoring is needed
→ continue with the next task

I wanted to see how far this could continue without repeatedly entering the same instructions. Ideally, bounded work could progress while I was doing something else or asleep, leaving results and questions for me to review when I returned.

I have not completed that whole system. Testing parts of it made the missing connections clearer. In particular, collecting problems and turning them into appropriate implementation tasks still requires review and adjustment.

From brainstorming to tasks

The PetV3 brainstorming records gave me a concrete example of part of this idea. I had not prepared a detailed technical specification for the domain. I wanted a process that researched external examples, compared them with the current project, and organized the next steps. Seeing that request develop into a report and proposed work was interesting in itself.

The first report examined comparable products and user complaints, then separated what to build, reject, or defer. Its conclusion went beyond proposing features: connecting existing sounds to actual state changes should come first. Making prior work useful to the user took precedence over adding something new.

The second report revisited the twelve earlier work items. It identified implemented interface components that were not connected to the running application and reassessed performance work against existing measurements. The resulting queue prioritized wiring up existing features and completing measurements. I also confirmed that both rounds of decisions were recorded in commits separate from implementation changes.

What surprised me was not the length of the reports or their technical vocabulary. A process I had imagined had become research, comparison, and prioritized proposals for work. I could experiment with that review process without preparing every technical detail myself. I have not independently verified every source and judgment in the reports. What this demonstrates is an experience of using AI to help turn ideas into actionable work, rather than a completed system of full automation.

What I observed

With parallel assignments, one task could be under implementation while another task or check proceeded separately. Results and commits came back, and work could move to the next item. The pace felt different from a process where I entered every step myself.

More commits did not necessarily mean proportionally more completed product. I needed to check whether changes had been integrated, whether the program I was running included them, and whether the behavior matched the request. Sometimes a completion report arrived while the screen still looked unchanged. Sometimes a new feature made an existing interaction worse.

That shifted my attention from code volume to work status. I wanted to see what was being implemented, what was waiting for review, and where a decision was needed. The dashboard development story follows that need. The PetV3 log covers how those requirements affected the wider project.

My role

My role became more about describing the intended result, identifying discrepancies, and adjusting the next steps than writing every line of code. I did not design the entire stack or implementation. The AI proposed and handled much of that work, while I kept judging whether it served the project I wanted to build.

My requests became more specific. Alongside what to add, I needed to state which existing features should remain and when the work should pause for review. I also wanted refactoring to follow an assessment of the changes, rather than become an automatic activity repeated without a clear need.

More automation did not make my involvement disappear. It moved my attention toward task boundaries, priorities, and review. As more results arrived together, the amount I could meaningfully check became an important constraint.

Speed and cost

The experiments also consumed usage. Initially, I wanted to explore what was possible, so I tried different models, reasoning settings, and ways of dividing work. I now want to be more deliberate about matching the model to the task instead of always reaching for the strongest option.

My recent tests with Astra left me with an impression of faster responses and execution on small tasks. Whether that improves the cost of the whole workflow is a separate question. Finishing sooner, consuming fewer tokens, and needing less of my review time are different measures.

I want to track how long it takes to reach an acceptable result, how much rework is needed, and how much usage it consumes. The goal is to keep work moving effectively at a sustainable cost, not simply to keep increasing the number of agents.

Why continue

This is not yet full automation. Still, seeing several tasks progress and produce results made a strong impression. I could test part of a workflow I had only imagined using tools already available to me.

The phrase “a small development team at my fingertips” captures that excitement. The next question is whether the experience becomes repeatable: requirements understood, problems recorded, and results supported by evidence I can review. That would give me a sound reason to take the experiment further.

This article was also developed by talking through the experience with AI and reviewing the resulting draft. I want the record to retain the enthusiasm while making clear what I have actually observed and what I still hope to achieve.