Office Hours The Side Projects Edition N°313 happened on June 19, 2026 at 0900 California time (UTC-7).

This one turned into a deep, messy, very useful tour of vibe coding as personal software craft. The important shift was away from building software products for some imagined market of “users” and toward building sharp little tools for your own real problems. Sometimes the right scale is a broom closet: one person, one irritation, one workflow, one instrument that makes a particular life or practice easier to handle.

Eric shared a weed app he has been building for more than a year with AI coding tools. The app is less interested in brand names, strain folklore, and dispensary vibes than in the chemical profile of a plant: terpenes, cannabinoids, and the measurable composition that might let someone compare one strain to another with more precision.

That changed the conversation. The app became a way to see strain drift over time. The same named strain can change across states, growers, dates, labs, crops, and terpene composition. Once the data is visible, the brand name starts to look like a very rough handle for something much more variable underneath.

This is where personal software becomes interesting. Eric’s app did not need to become a startup to matter. It solved a real problem for a real person with enough specificity to become useful. The group kept returning to that point: AI coding tools make it newly possible to build strange, situated, one-off instruments that would previously have required either a professional engineering team or an unrealistic amount of patience.

Then came the discipline question. Vibe coding can produce working software quickly, yet it can also produce one giant impossible file if nobody tends the system. The group dug into code hygiene: modular files, explicit naming, smaller scopes, reusable components, and regular cleanup. The practical advice was familiar engineering practice, newly important for AI-assisted development: keep responsibilities separated, give the model smaller surfaces to work on, and refactor before the project becomes too tangled to understand.

Eric’s “Robot Oil” project pushed the discussion into multi-agent systems. The vocabulary got more architectural: personas, flows, coordinators, librarians, reviewers, memory areas, queues, load tests, model slots, and prompts that improve themselves over time. The work sounded less like a single chatbot and more like a small organization of software roles passing work between each other.

Drew offered a clean frame for the stack. The model reasons. The harness manages the runtime. MCPs act like wall sockets for tools and data. Skills teach the system when and how to use particular capabilities. That was useful because it separated the magical part from the plumbing. A lot of agentic software becomes easier to reason about when the model, runtime, tools, data access, and operating instructions are treated as distinct parts of the system.

The strongest practical warning was about context pollution. Every tool, MCP, file, remembered note, stale instruction, random aside, and ambient bit of project history can shape the model’s output. Good AI work increasingly means managing what gets into context and when. The question is no longer only “what can the model do?” It is also “what did we just cause the model to pay attention to?”

That warning matters for teams and organizations as much as for side projects. Juniors still need to learn the work manually long enough to know what should be automated. Otherwise they only learn how to ask for things they do not understand. The group kept circling the same concern: automation is powerful when it is guided by taste, domain knowledge, and direct experience. Without those, it can create a very confident layer over shallow understanding.

The session ended on a broader software culture shift. The moat is moving away from interface alone and toward data, domain knowledge, taste, and the ability for one person to assemble serious tools very quickly. Interfaces can be generated. CRUD apps can be scaffolded. The harder advantage is knowing what deserves to exist, what data matters, what weird edge case is meaningful, and what kind of tool would actually help a specific practice.

That is the best version of vibe coding: software as a personal craft, tuned to a real situation, cleaned up often enough to keep going, and modest enough to remain useful at the scale where it began.

Watch Office Hours The Side Projects Edition N°313 on YouTube

Get on the newsletter list to get reminders for weekly Office Hours.

Want to share your own side project? Sign up to share at Office Hours The Side Projects Edition and please support this all on Patreon. It’s only $10/month and you get access to a remarkable supportive community, weekly Office Hours, and the Discord community. Thanks for your support.