AI Impact Summary

The Question: Could one designer ship a whole product with AI?

Solo practitioner startups were previously unrealistic

After bootstrapping my last startup for multiple years, I knew the limitations and costs of the full production process, even for a smaller app. When I wound down that product, I was certain I’d never attempt a startup by myself again. The sheer scale of work, decisions, and knowledge is a tremendous amount to keep top of mind across all job functions.

The math recently changed, significantly

In Q2 2026, I began reading about the advantages of Claude Code, and after understanding what it was capable of at a high level, it looked like it could be the answer to the challenges of work and knowledge scale of independent production.

In particular, AI could search for relevant information, organize it, reference it, and store it on your file system as a knowledge base. And it could be taught custom ways of operating.

Having no experience prior to this with AI beyond using a chat interface like ChatGPT for debugging work, this was both exciting and relevant. So, I set out to figure out if it was really possible to ship a high quality product independently, supported by a custom AI-org and custom agent team.

Design goals for the org

Based on what AI was proficient at at a glance, I specced out my intentions for the org.

• It would be a closed-loop org, as espoused by Diana Hu of YC. All assets and decisions would be recorded and available to the AI.

• I would not write any code this time - all code would be written by AI.

• The org would be self-improving based on how I worked.

• AI would be leveraged in every aspect of production.

• The design of the org would be iterative through observed need and friction.

Designing the org around the limits of AI

Over the first few months, most of the org’s practices took shape based on observed limitations and friction of working with AI within the org.

Collaborative session lifecycle: The backbone of the org

Below is a diagram of how AI is used in the org, from the start of a collaborative work session with the org, to its completion. These processes are designed from observing the limitations of AI in practice.

Balancing AI decision autonomy with cost of misjudgment, solved with autonomy upgrade processes

Initially, I weighed in on all decisions the AI was making. Over time, I provided feedback on where AI was successful in making autonomous decisions, and where it failed to be able to make reliable autonomous decisions.

This resulted in a log of decision types:

• That an AI role could be trusted to do autonomously.

• To make but review with me before finalizing.

• Decisions I would explicitly make.

I had many early experiences of having too much confidence in an AI role to fully make decisions and deliver on a goal, only to gradually discover (slowly through testing) some assumptions it made to complete the task that were far departed from what I’d advise.

The cost of one wrong product decision can cascade very quickly into product and technical debt, so while development proved it could be relatively autonomous, product decisions proved they largely couldn’t be trusted to AI.

How I ensured I never have to write code

The issue of “vibe coded” apps boils down to spaghetti code. Each session focuses on a new feature, refactors and adds to what is necessary, and that’s it. In that mode of operating, it’s not a surprise that the AI isn’t going out of its way for maintainability, as it wasn’t instructed to.

In order to ensure I didn’t have to manually code, I needed to design the Developer AI role so it emulated an experienced developer.

Choosing languages and stack that Claude was most proficient in

In the early stages of planning, I worked with Claude to understand what languages and technologies it was most proficient at using. The chosen technology stack all consisted of tools and languages where:

• Claude was proficient

• Well maintained documentation as a resource for Claude

• Has an active community to assist in troubleshooting

The AI developer role had defined practices to follow

Up front, the AI needed guidelines for writing and maintaining code. The developer role followed:

• A chosen architecture, following guidelines on best practices for modularizing the codebase.

• Best practices defined for each language in the codebase, and style guides.

• Guidelines for commenting and documentation.

• Best practices defined for using and maintaining Git.

Modularization in particular was important, not only because features are more susceptible to change early in MVP development, but because modular logic in the codebase is less context intensive for the AI to work within.

Documentation of decisions, rationale, and history was easily AI-navigable

To ensure the AI was making development decisions from an informed perspective, the product codebase and its documentation needed to provide a clear picture of what was decided, why, and most importantly what was tried and failed or decided against.

I defined a number of roles and practices for different file types, to provide an AI-navigable system.

• Code comments: Provide file-specific decisions and context when relevant, and link to other files. Half of the current 858 codebase files cite ADRs.

• Architectural Decision Records (ADRs): Provided comprehensive rationale for engineering decisions. Currently 38 in org.

• Product Requirements Docs (PRDs): Provided feature requirements and product rationale.

These files linked to one another when relevant, and allowed the AI developer role to gain relevant context on any file specific or systemic development task it was working on.

Automated test generation and checks

With any feature addition or change, the AI developer role creates tests and adds them to the full testing stack, so that we have some reassurance that recent changes have not had unforeseen impacts or break other parts of the product. The SHRP product currently has about 1,200 tests as of this writing.

How is code quality reviewed?

The AI developer role executes its own code review with Claude’s models. For larger code reviews, I also have it use GPT Sol as an adversarial reviewer, and use Ollama higher end local models for a second opinion.

New code is tested live on device during development. Once a feature is complete, it graduates to Canary track which is a release build on my personal device. Once that is soaked, I graduate it to the Staging track consisting of beta users and monitor its stability via Sentry analytics.

Is this preferable to working with a professional developer?

Absolutely not. Working with a human developer not only brings their experience and expertise, but also common sense, which AI can lack.

I have no doubt the code quality of the SHRP product is below what a senior+ engineer could deliver (even if they’re AI assisted). But given I don’t have the resources for that, the AI Developer role has far exceeded my expectations, and delivered a quality of collaboration and production performance that I am very happy with. There is no way I could have developed this product, of this scope, myself in even 10x the development time.

How I designed before, and how I design now

My design process changed pretty drastically, allowing both greater depth and quality in shorter timeframes.

Code went from the most expensive aspect of production, to the cheapest.

The classical design process front loaded lean research, to derisk initial product decisions as much as possible. Once engineering was involved, implementation was expensive, and changes later added significant cost. Not only accrued time cost, but technical debt, and increased pressure on developers who were managing multiple goals at any given time.

Initial discovery, research, lean testing, and all our usual up front methods as designers are all towards the purpose of making the case for a design as air-tight as possible prior to engineering.

When that flips, there are a huge amount of advantages and opportunities to improve the process.

Change #1: Due diligence research rigor

Competitive analysis, market evaluation, design precedent, problem scope, etc. All that initial research work understanding the playing field took time. Now, it can be strategically automated and explored conversationally.

This allows more data to be taken into account, more quickly, and intentionally. What would take a week or more, can be done in an afternoon.

Change #2: No more high fidelity in Figma

Once I had a low fidelity spec, I could take it and combine it with a loose set of typography and colors, and use AI to play and feel out what aesthetic matched the UI and experience I was trying to create.

Instead of taking a day to mock up a few high fidelity options, I was able to feel out over a dozen high fidelity versions of my UI over an afternoon.

Change #3: Live prototypes over less effective paper prototypes

This is the biggest shift. To get the most accurate feedback from a user, it is ideal to give them the closest experience to the one you want to release. Before, that meant paper prototypes, or shoddy functional prototypes that often were not cost effective.

Now, you can get the actual, fully functional idea in front of the user faster than if you created paper prototypes, or conducted a survey, or any other classical method.

The user is in the position to provide more accurate information, and you’re in the position to experiment freely. An absolute win-win, which makes testing more cost effective for the business, more accurate from the user, and more playful and enjoyable for the designer.

Change #4: Design through play

Using a development build on-device that updated the app live after any codebase change, allowed me to brainstorm with an AI session and design interactions iteratively. I’d try playing with a feature, and come up with ideas for how to change and improve the experience. Then I’d play with the change, and continue tweaking until I was happy with it.

This type of design iteration before AI would have significant time cost, outweighing the UX benefit many of the times, so lots of these tweaks and improvements wouldn’t be viable before AI. With AI, I can have fun iterating, and refine features delivering a much higher UX quality, with comparably negligible additional time cost.

What didn’t change: Ownership, low fidelity design, and interview strategy

AI is most helpful for scoped tasks with clear constraints, context, and criteria. But it has no actual responsibility for success or failure.

As full responsibility fell to me, I ensured at every step involving a product decision, that I either explicitly made that decision, or approved it from a fully informed perspective.

My low fidelity design process was also largely unchanged. While AI was helpful to conduct research and inform my perspective, it was not helpful as an actual designer. A first draft low fidelity spec takes a huge amount of context (problem, user, business, design, etc) and involves structuring a system balancing all that context and the product goals. Every flow, every page hierarchy, every piece of copy, works together to reflect the design intent defined by that context.

Because of the high complexity of reasoning and scale of context required for a new product low fidelity spec, I found AI (as of Q3 2026) consistently unable to make effective decisions of value. Therefore I kept its role as providing critique at this phase.

I also kept my previous interview practices. Interview strategy design is already highly complex; What are we looking to learn? How should it be learned from the user? What are our priorities?

Once you establish your study design and interview strategy, you need to conduct the interview. When should you refocus the user? When should you provide bias or withhold? When should you let the user run and explore an idea?

Getting the most out of a user interview also requires them to be comfortable, to trust you, and to enjoy talking to you. This takes practice, and in no way can be emulated by AI.

When is AI better, and when is a human designer better?

Through the experience of working with AI in the variety of ways required to produce and ship a product, I learned first hand AI’s significant strengths and weaknesses.

Bottom line: AI is strongest on problems it has been trained on, or that fit inside one session; a human is strongest where the decision needs more context than a session can hold.

AI wins: Large dataset, precise distillation, pattern recognition, rule-based labor, teaching

I found AI to be a boon of help executing rule-based thought labor, which would have taken me significant time and energy. Some general examples:

• Collecting docs to inform a decision during discussion.

• Pulling data to assess state of the product.

• Analysis over data or research papers.

• Automating code documentation and updating product policy as features evolved.

• Small scope autonomous coding decisions.

• Acting as a role in which I have less experience, and teaching me (with citations) specific to our work.

In these areas, some things that AI could do in minutes could have taken me days, weeks, or even months.

Designer wins: High context decisions, design system tradeoffs, product judgement, and in-person interaction

In some cases, I found AI to slow the process down, or to be unable to deliver competitive value vs doing the work myself. This was primarily in regards to decisions that required significant context, across a long timeframe, which considered priorities across domains.

A single design decision, let’s say adding a button on an app homepage, has a large number of considerations. Here is an incomplete potential example list:

• What are the functions of the homepage for the user, and does this button merit inclusion?

• What are the current business goals, and how does this button influence them?

• What are the engineering considerations of this button? Are there equally valuable leaner solutions?

• What are unknown potential risks of this change?

• Based on the potential value of this change, is its impact measurable, and over what timeframe?

• Are there other design strategies for using this button’s space on the UI that produce greater net user and business value?

• Will a user understand and value this button?

These are just some questions that can be asked depending on a single design decision on a single UI.

AI still is assistive for small scope, low complexity design. For example, drafting a confirmation pop-up modal with design and copy. But from my experience so far, I ensure that I explicitly decide or weigh in on every product decision.

A designer also is able to know when to distrust an idea or answer, and challenge the basis of a decision. That is a key design skill, and one that keeps AI assistance value net positive.

Designer vs AI advantage summary

Conclusions so far: A designer leads and carries responsibility, AI provides enablement, options, and speed.

Going into creating this org system, I was curious how much of my role as a designer could actually be emulated by AI.

Instead, I learned how many opportunities for improvement AI provides, opening up the potential to redefine many ways of how I previously worked.

At the same time, I got a strong dose of AI’s failures in my experimentation with it. I found what could be improved over time, and what it was unable to do.

I’m thrilled to be a designer in this new paradigm, compared to how I previously worked.

Granted, this is as of this writing (October 2026). I’m sure this assessment will be outdated in no time, and my practices will continue changing.

So, can one designer ship a whole product with AI? Yes*

My design experience combined with AI’s breadth of skills and enablement allowed me to produce a validated consumer app on the market.

• First commit landed May 13th, with store distribution approvals landing October 9th.

• App and infrastructure coded and managed with AI.

• Product validated in comprehensive beta test, with AI assisting distillation.

• Product documentation and testing was well maintained and robust with AI.

Based on the scope of the product I delivered, it would have easily taken me 18-24 months or more to produce what I did in 5 with the AI org. Plus, I was building the AI org itself at the same time.

It isn’t without friction

Improving the org, roles, and the AI to perform tasks in ways I found passable is a process. Along that process, the failures and friction in the AI’s work become the data needed to feedback into the org system to improve it. Over time, the org became better and better, as my practices and preferences became learned and encoded in how the org worked.

Along that journey there were countless decisions by the AI I qualified as mistakes. To name a few notable incidents:

• Before release gates were added, an over-the-air update pointed the production release at a dev database.

• Early on, decision autonomy for small product decisions (like data refresh rate) was often inaccurate, so I limited that autonomy significantly.

• Untraceable research claims were brought into discussion, so I incorporated required citation and citation chain traceability.

• Early privacy policy drafts were inaccurate to the product’s actual function.

• Early versions of monitoring systems failed silently.

Some of these failures were of org processes and instruction, which were improved upon and tightened to be reliable and verifiable. Other failures were from inherent limits of current AI and session constraints, so these failures caused task delegation away from AI to myself.

Can one designer ship any product with AI? No

This is my experience so far at the current scope of the product I produced. SHRP’s scope is a single app, on 2 platforms, whose system is across devices and servers. While the product requirements are design and research heavy, the technical requirements are well within a scope AI can collaboratively manage.

My previous development experience and high level understanding were enough to structure a system that the AI could work within to produce a product of this technical complexity.

This may not be true for a product of higher inherent technical complexity, like Netflix’s data distribution network (as an extreme example). Higher technical complexity would require greater human developer experience to define and guide AI towards technical solutions, beyond my experience.

Where it stands, and what’s next?

I currently use the org to improve SHRP based on user feedback, and monitor the product.

The org handles SHRP’s operations: a daily production health check that alerts me when something needs attention, a weekly analytics review, nightly maintenance jobs, monitoring user feedback submissions, and more.

Looking towards my next design role

The value I bring, more than any one system or technology, is the experience and insight into how AI can be used for greatest benefit, and how to manage and scope it to ensure it produces value.

Producing a product with AI taught me a huge amount of valuable lessons through experience. At this point, my next chapter is to do this within a team; to meet them where they are currently, and help strategically integrate AI into my own practice there, and with the team’s potentially existing practices.

This experience was terrific practice in learning and adapting my own practices, and questioning my own previous ways of doing things. I look forward to bringing my skills to a new team, and continue improving and growing along with them in the future.