AI Can Write the Code. You Still Have to Design the System.

When employing agents to generate code, the groundwork remains critical, regardless of the AI tools deployed. Many discussions revolve around the adage "garbage in, garbage out" concerning AI and machine learning. However, this adage loses its significance when an LLM is given a fully understood codebase and instructed to commence construction.

LLMs function as sophisticated pattern-matching black boxes. They excel when presented with a well-defined stack, comprehensive documentation, abundant examples, and distinct architectural boundaries. Nevertheless, if the initial conditions are lacking or subpar, the output will likely reflect that deficiency. Opus 5 and GPT 5.6 Sol are prime examples of this.

Delve into any discussion about AI technology to witness the impressive results they can generate. Yet, I harbor reservations regarding relying solely on such technologies for every coding challenge. I yearn for a system that I fully comprehend, one that I could manually code if required, and one that enjoys broad support rather than a bespoke or semi-custom solution.

Moreover, given recent deliberations surrounding the escalating costs associated with AI - while I am not entirely convinced that my coding agents will cease to exist - they may transition from a universal tool for coding all of my tasks to a more targeted instrument for tasks I would rather delegate. As a developer progressing forward, my role is to architect a system where the agent can make judicious decisions with minimal input.

This entails selecting a stack I am familiar with, ideally one that is popular and well-suited to my specific use case. The chosen stack should enable rapid deployment, seamless scalability, and minimal DevOps overhead. It should also allow me to review the entire codebase a year later, post the agent's contribution of approximately 30k lines of code, ensuring its comprehensibility.

I will not claim this is the optimal stack, but I will elucidate my decision-making process, the rationale behind my choices, and why I consider it the most suitable option, particularly for a solo developer or a small team. What am I constructing? The application in question is named lyphe, an opinionated task and life management application.

I am developing this due to my desire for a tool that operates in accordance with my cognitive processes. At its core, lyphe is a relatively straightforward consumer CRUD app, where tasks are inputted, organized, and eventually completed. However, certain requirements render the architecture more intriguing. I aspire for the initial prototype phase iterations to be as swift as feasible, rendering the application a Progressive Web App (PWA) during the feature development and UX enhancements.

I envision real-time updates, with aspirations to develop native iOS and Android applications, and the integration of native functionalities like notifications and widgets, which are deemed significant enough to warrant prioritization. My development process involves a solo effort, with coding agents contributing an extensive portion of the implementation.

Therefore, the chosen stack must be compatible and manageable for both the agents and myself. This leads to a set of useful constraints. Reduced Infra, Fewer Problems My previous employer instilled in me the principle that less infrastructure is better. Being a small team of just four developers (including the CTO), we recognized the value of automating or outsourcing infrastructure whenever possible.

Our APIs ran on Cloudflare Workers, the database resided on Supabase, and our NextJS application deployed on Vercel. If a service could be outsourced, it was. If scaling and deployment could be entrusted to others, we did so. This approach became particularly appealing to me, as it was the foundation for my subsequent projects. Platforms such as Supabase and Convex have become my preferred choices.

Convex, in particular, has garnered a recent preference of mine. Combining NoSQL and structured data, Convex's data structures and tables are defined in TypeScript, which are then automatically converted into APIs that the frontend application can instantly utilize. Moreover, Convex offers real-time updates. The beauty lies in its simplicity - defining data structures and tables in TypeScript, automatically generating APIs that can be seamlessly consumed by the frontend, and ensuring real-time updates without any additional effort.

This combination provides immense value, particularly when developing with agents. Reduced Architectural Decisions for Agents Developing with agents offers another advantage when using Convex: it significantly diminishes the number of architectural decisions the agent must make. By defining the schema in TypeScript, backend functions are also in TypeScript.

Convex automatically generates frontend-facing API interfaces, and it handles migrations on your behalf. This reduces the cognitive burden on both myself and the agent, enabling both parties to operate within the predefined rules, thereby maintaining a high velocity and minimizing the risk of the agent attempting to reinvent the wheel, such as the REST API.

Authentication Challenges Convex introduced me to Clerk, an authentication provider akin to Auth0 and Stytch. Clerk, however, offers unique features that make it ideal for a solo developer like myself. It is free for the first 50,000 users, which is particularly beneficial for those uncertain about their ability to generate revenue after reaching such milestones. Additionally, Clerk integrates a billing service via Stripe, further simplifying the process.