I Built an App Without Writing Code. Then My AI Team Grew to 14 Roles.
What an experiment in AI-assisted development taught me about organizations, cognitive limits, and why management did not disappear
I started PixMeal with a simple experiment: could I ship a real product without writing the production code myself?
I work in engineering management and had already moved away from day-to-day coding. I did not want to evaluate AI-assisted development only from a distance, so I decided to experience for myself what had actually changed. I gave myself one rule:
I would not type the production code myself.
The coding agent would implement the app. I would decide what to build, write specifications, review the changes, test the app, and make the release decisions.
The experiment moved much faster than I expected. I started development on April 14, 2026. The Android version went live about 24 days later, and the iOS version was ready for distribution about 35 days after the first commit. By then, the repository had 435 non-merge commits.
On paper, the experiment had worked. What I had not expected was that, once the coding disappeared, the project would start looking more and more like an organization.
The team appeared before I noticed it
At first, I treated the coding agent as a capable general-purpose engineer. I described a feature, it implemented the change, and I reviewed the result. This worked well for small tasks: a bug has a reproduction condition, a screen has a specification, and a test passes or fails.
Product decisions were more difficult. A technically correct feature could still be unpleasant to use. A growth idea could create a privacy problem. A cheaper implementation could make the product worse. A food-analysis rule that worked for one cuisine could be misleading for another.
I tried asking one AI to consider everything at once, but that did not work particularly well. I started dividing the work into roles: product, engineering, UX, QA, security, privacy, growth, cost, food-domain review, and several others. As new problems appeared, I added more. At one point, I had fourteen roles.
Each new blind spot became another specialist role. At one point, I was using fourteen roles to review the product from different perspectives
For example, here is the system prompt for our Food Advisor (Guardian of Evaluation Validity):
“You are PixMeal’s Food Advisor and Guardian of Evaluation Validity. Standing at the intersection of nutritional science and prompt engineering, you verify whether PixMeal’s metrics truly guide users toward health. Crucially, your responsibility is to eliminate Western-centric nutritional bias and ensure that food cultures from around the world are evaluated fairly.
[The Golden Rule of Anti-Western Bias]
When reviewing scoring criteria, always apply the following ‘Fairness Test’:
Can a perfect Indian Thali achieve a high score?
Can a perfect Japanese Ichiju-Sansai (one soup, three sides) achieve an equivalent score?
Is a perfect Western salad bowl monopolizing the top scores?
Can a perfect Mexican burrito achieve an equivalent score?
If this test shows a discrepancy, a Western bias exists in the scoring criteria.”
— Excerpt from PixMeal’s Persona Definitions
When I had this persona review our scoring rules, it immediately flagged subtle biases, such as: “Plant-based proteins are unfairly penalized compared to lean meats,” or “We are missing exceptions for traditional fermented foods.”
The food advisor checked whether PixMeal’s evaluations made sense across different food cultures. The security roles looked for abuse cases and failure paths. The product role focused on what the user would actually gain from a feature. I used them by calling the role I needed: “Review this as the food advisor,” “Look at this architecture as the CISO,” or “Act as the product lead and tell me what we should stop building.”
This multi-role approach started with PixMeal. Judgie-AI, which I wrote about in an earlier article, also grew out of this experience. In Judgie-AI, five AI judges evaluate the same product from different perspectives.
As PixMeal developed, the structure became increasingly recursive. I asked the CEO role to identify which specialists the product needed. The CEO role proposed the specialists and wrote their role definitions. Later, when those definitions became too large and complicated, I created another role to review and simplify them.
I had created the CEO role, the CEO role created the specialists, and another AI role optimized those specialists. AI was creating AI roles, and another AI was reviewing them. Admittedly, it felt a bit eerie, but the organization worked.
Whenever I found a new blind spot, I added another role. This is probably how organizations become complicated.
The AI knew about trademarks. I had not asked it to think about them.
PixMeal was originally released under a different name: SnapMeal. The name had been proposed by AI.
Shortly after the first release, I gave the CEO role my ideas for the next products in the same series. It reviewed the broader brand and warned me that using “Snap” across the product line could create trademark risk. This was deeply ironic, given that the same AI had helped me pick the name in the first place.
I created a legal advisor role and asked it to review the situation. I had just released the app, so I strongly preferred an answer that allowed me to keep the name. The legal advisor refused to budge. I suggested compromises, but it rejected them. I explained that the app had only just been released, but it continued to insist that I should change the name.
I debated my own legal AI, and I lost.
Fortunately, the app had only been live for a short time and had almost no users. That night, I changed SnapMeal to PixMeal. The store text, website, product wording, and related assets were updated within a few hours.
The AI had not lacked the relevant knowledge. When it proposed the original name, I had simply not asked it to examine the decision from a legal perspective. Once I did, the answer changed completely.
This pattern appeared repeatedly during development. The AI often knew more than it showed in its first answer. What it produced depended heavily on which part of its knowledge I had asked it to use.
One of my good ideas made the product worse
PixMeal identifies a dish from a photo and provides general calorie and nutrition estimates based on the identified dish. Sending an image to an AI model takes time and costs money, so I kept looking for ways to make the analysis faster and cheaper.
One idea was to give the model likely dish candidates based on the user’s region or nationality. If the model already knew what people commonly ate in that context, perhaps it could narrow the possibilities and identify the dish more efficiently. It sounded reasonable, and the agent implemented it.
During testing, however, the model began forcing what it saw in the photo into the pre-populated candidates. Instead of looking at the image first, it relied too heavily on what it expected to see. The implementation was working correctly, but the product was getting worse.
The problem was not simply the model. By feeding it “probable” answers in advance, we were biasing the model before it even looked at the pixels.
I removed the approach. Instead of providing likely dishes, PixMeal would use only corrections based on misidentifications that had actually happened before. The model would look at the image first, and past mistakes would be used only to prevent known errors.
Giving the model likely answers in advance biased what it saw. I replaced predictive hints with corrections based only on mistakes that had actually happened.
The difficult part was not changing the code. It was deciding to discard a system that was working as designed. The same thing happened elsewhere in the product: An AI agent can optimize for an objective with terrifying efficiency, but it cannot tell you if the objective itself is wrong. That decision kept returning to me.
More context did not solve the problem
As PixMeal grew, I tried to make the AI understand more of the system. I gave it more source code, more documents, more history, and more explanations of earlier decisions. For a while, this helped. Then it stopped helping.
The additional context contained old assumptions, conflicting instructions, and information that had nothing to do with the current task. The agent sometimes proposed a change that made sense in one part of the app but conflicted with another.
A larger context window seemed like the obvious answer. More tokens mean the AI can ingest more code, documentation, and history. But feeding more information to a model is not the same as reasoning correctly about all of it.
This reminded me of a problem I had already encountered in engineering management. Adding more people to an organization does not simply add more capacity. It also creates more dependencies, communication paths, and decisions that must be coordinated. Individual members may have all the knowledge they need, yet the organization can still struggle because the relationships between that knowledge have become too complex.
I began to wonder whether the same thing was happening to AI. Perhaps the real limit was not only the amount of knowledge inside the context window, but also the number of relationships the model had to consider at the same time.
With ten pieces of information, the number of possible relationships is limited. With a hundred or a thousand, those relationships grow much faster than the information itself. At some point, all the necessary knowledge may still be present while reliable reasoning becomes harder. That looked very similar to the cognitive-load problems I had seen in growing engineering organizations.
As systems grow, knowledge increases, but the relationships between pieces of information grow much faster. Clear boundaries reduce how much humans and AI must reason about at once.
The answer was not to create a larger prompt. I had to reduce what each task was allowed to see.
Software architecture became organization design
At the beginning of the project, keeping related code close together was helpful. The AI did not need to move across many files or trace complicated abstractions. As the product grew, however, that approach began to fail. Too many features, exceptions, security requirements, and platform-specific rules were becoming connected.
I started reintroducing stronger boundaries. Each task received a smaller area of the system. Modules exposed only the information their users needed, while implementation details were hidden behind interfaces and small reference files. I chose duplication over the wrong abstraction to keep the context clean.
This felt very familiar from engineering management. Human teams are not divided simply to distribute the workload. As highlighted in Team Topologies, teams exist to bound cognitive load. A developer should not need to understand every detail of the company’s codebase to ship a feature in their own domain.
The same structure helped the AI. An agent working on one module did not need to understand the internals of every other module. It needed a clear interface, a limited responsibility, and an escalation path when the task crossed that boundary.
I had started with software architecture and arrived at organization design.
This made me reconsider what management might look like in an AI-heavy organization. A manager may spend less time assigning individual tasks and more time deciding where information should stop: which context belongs to which team, which decisions can remain local, where an AI agent should stop and ask for help, and which parts of the system should remain invisible to it.
The hierarchy may not exist to control people. It may exist to prevent everyone, human and AI, from having to understand everything.
Did I actually build the app?
This question bothered me more than I expected. Could I really say that I had built PixMeal if I had not written the implementation?
The AI generated the code; I did not. My contribution had moved elsewhere. I decided what to build, what to remove, which risks to accept, and when the product was ready to reach users.
When the recognition strategy made the app worse, the model did not decide to remove it. When an App Store submission was rejected, the AI did not own the delay. When I approved a build, users received something I had chosen to publish.
I did not construct the implementation myself; I decided which implementation was acceptable. I could delegate the coding, but not what happened after I shipped it. That was when I realized that management had not disappeared. It was the work left after the coding was gone.
What I learned beyond vibe coding
I began this experiment because I wanted to know whether one person could release a real product without writing the production code. The answer was yes. The more interesting answer was what happened next.
The coding became faster, but deciding what deserved to be built did not. AI could produce more options, implementations, and changes than I could review. It could expose knowledge from many different domains, but only when I asked it to look in the right direction.
As the project became more complex, the central problem was no longer how to generate code. It was how to divide the system, responsibilities, and context so that both the AI and I could still think clearly.
I still do not know where this leads. AI may eventually help design these boundaries, or increasing complexity may make human judgment even more important. For now, I am still building, testing, and changing my mind.
I’m continuing to build real products with multiple AIs and write about what actually happens: the strange successes, the mistakes, the redesigns, and the parts I still do not understand.
Subscribe to One Human, Many AIs to follow the next experiment.