Vibe Coding is a System Design Interview
I’ve been working on two fairly large vibe-coded apps, and my process has converged on:
Write a GitHub issue
(If complicated enough) tell an agent to make a plan and then update the issue
Have another agent read the issue and implement it
As the features get more complicated, I spend more and more time on step (1), and I’m finding that just taking the time to write a detailed enough issue is 90% of the work (and if I have a problem, going back and writing a much more detailed issue usually fixes it). The thing I realized this morning is that writing these issues and working through the plans is very similar to participating in a system design interview: You don’t need to implement anything, but you do need to have a good high-level design, and think through all of the edge cases and tradeoffs.
The fun part compared to a normal system design interview is that you don’t have to worry about impressing a coding agent, so it’s perfectly fine to just ramble as you think of edge cases and details that need to be handled. Also unlike a real system design interview, you’re free to pick reasonable tradeoffs instead of designing everything to support a trillion concurrent users[1].
System design interviews have traditionally been the hardest part of interviewing for senior+ software engineer jobs, so it feels meaningful that this is the only hard part left in coding for some domains. I’m curious to see what will happen to the current generation of junior engineers, freed from having to actually implement anything and able to focus purely on system design from the beginning. Maybe they’ll grow really fast?
- ^
Ironically, AI agents also mean this might be something you do have to design for in some cases now.
Thanks for sharing your approach. I think it is important that practical experience with vibe coding is shared. I think it is an area where a lot of exploration and adaptation to the code base at hand is needed. And probably also to future models.
I like how Victor Taelin (of Higher Order Company) shares updates on his efforts to use the latest models to help him build a new massively parallel provably safe programming environment.
It’s interesting that what you’re describing—detailed requirements, edge cases, tradeoffs, user-facing considerations—maps closely onto what design disciplines have been doing for decades. As implementation gets automated, if the remaining hard problems are fundamentally about problem definition rather than problem solving, I hope (perhaps naively) that this means designers and engineers might start exploring this territory together rather than separately.
I think this will probably lead to even less working together, since synchronous meetings are a huge bottleneck when designers can just prototype something with a coding agent and then throw it over the fence for a maintainable implementation from engineers.
I would never dare to suggest more meetings. I drown in meetings as is. I meant less that the process changes and more that design expertise becomes more visibly valuable, given that designers have been solving these issues professionally for a long time and have a lot of valuable insight that is often otherwise siloed away from engineers.
Yeah, I agree, and I actually think designers might stay useful longer than software engineers at this point.