When Guy Guyadeen left LA in 2009, the tech industry was a tiny niche. He moved to the East Coast and eventually landed in Mountain View as a Product Manager at Google. He decided to move back to LA and thought, “This is going to be career suicide.” But after arriving in 2018, Guy was blown away, “What’s going on here? There is so much happening!”
Guy joined Act One Ventures as Entrepreneur in Residence, followed by product roles at Quibi and Tapcart. He eventually rejoined Google. This time, working out of the LA office. Guy spent these years on teams building high-quality complex software at scale.
Now, Guy is building litFit, an AI nutrition coach that keeps track of your eating habits and learns them over time. litFit’s nutrition data comes from food databases like Open Food Facts and the USDA’s Food Data Central rather than the model’s guess. While training for a triathlon, Guy saw a gap in the market, “There are apps that try to do part of this, but none of them feel like I have a $120-an-hour coach on speed dial. If you try to do this with bare ChatGPT, it can’t do the math reliably. It forgets one day to the next. It cannot maintain a ledger reliably.” Guy uses coding agents, but not the way most people do. This is because “what LLMs are trained on is not what we do internally at companies doing software engineering.” The question for him became: “How do you build something in a way that would meet the same quality bar at the places I’ve worked in the past, like Google?”
His thesis? The way to reach the quality bar is by using the same software engineering processes that have worked for years: “I, as a product manager, write a product requirement document [PRD] with engineers who write technical architecture and technical design documents [TDD], and then other engineers implement them.” On his current team-of-one, the “other engineers” are Claude and Codex.
“I have a corpus of five or six PRDs and nine or ten TDDs that I've put my blood and sweat and love into,” says Guy. He then built a tool called “Throughline” to keep litFit’s code connected to the product decisions behind it. The AI agents don't have to understand the entire project in their limited context windows. Throughline “enables you to run a shell command that says, ‘Given this line of code, how does it connect to all the documentation?’ So it goes up to the technical docs. It also goes up to the PRDs.”
Guy adds, “Agents love to declare victory when the tests go green. Throughline won’t let them. Done means the promise to the user is kept.”
Guy gave me a concrete example, which I’m paraphrasing. A user says, “I had two eggs for breakfast.” The product promise is that litFit records the meal as stated by the user, and the technical design reflects that promise. The AI shouldn’t hallucinate a different meal.
But passing tests still doesn’t mean the feature is done. If the user then quickly says, “Actually, make that lunch,” litFit still has to honor the original promise and record the meal the way the user ultimately stated it. Until that behavior is implemented, Throughline considers the feature incomplete.
But he understands this might not be the only way to build: “I'm rebuilding the whole playbook – specs, reviews, traceability, how you steer a team – for teams that wield coding agents. I'm curious who else is converging on the same ideas, or has better ones.” Guy believes that we’re at a new frontier with AI, “Compilers didn't replace programmers in the 70s, they raised the level of abstraction you could work at. That's how I see coding agents: they raise the level you can create at, but we haven't figured out the processes yet. That’s what’s really exciting and fun about this.”
Building with coding agents too? Guy is interested in comparing notes with other teams doing the same. Reach him on LinkedIn.