Vercel CEO Guillermo Rauch
Guillermo Rauch built a virtual record player with WebGL2 and Web Audio. It converts music into the shape of a record groove, then samples the motion of a simulated stylus 384,000 times per second and renders the voltage that motion would induce in a cartridge. In his description, pops, speed variation, and changes in tone toward the inner groove arise from the simulation. Users can also play with the record like a DJ. Rauch says the songs are in the public domain or Creative Commons licensed and links to code people can remix.
Builder Zara Zhang
Zara Zhang says the fun of building products comes from the collision between predictable technology and unpredictable human behavior. She has also mostly stopped saying “vibe coding” because it can imply the maker put little thought into the result. In her experience, people using AI coding tools can still put considerable effort into what they make.
OpenAI Codex product team member Nan Yu
Nan Yu recommends starting with the most straightforward architecture or interaction that gets the job done and iterating toward simplicity. A clever design can require users to follow the designer’s reasoning. He says AI makes it easier to reach a solution when the goal is clear and easier to spend money shipping useless output when it is vague.
Designer Ryo Lu, formerly of Cursor, Notion, and Stripe
Ryo Lu shares the full video of his AI Engineer Shanghai talk with Chinese and English subtitles. In the post he asks, “When we can do anything, do we still know what we want?” He says he made every slide by hand in Keynote.
Y Combinator CEO Garry Tan
Garry Tan argues that frontier models reduce the friction of changing software and make everyday bugs harder to tolerate. He expects just-in-time personal software to become more common. Separately, he says his gstack-evals project tried to reproduce a Jev Engineering experiment and reported a similar result, with particle-1 doing better in his trial. The post gives his own replication judgment and does not spell out the full experimental conditions.
Box CEO Aaron Levie
Aaron Levie argues that some digital work can be split across agents and that more compute may reduce elapsed time or broaden the scope of review. He names coding, security, and research as examples and makes a forecast about the potential ceiling on productivity. He suggests revisiting previously infeasible tasks every three to six months to see whether models can complete a specific workflow using existing tools. His examples include security tools and data feeds, cross-system migrations, and CAD.
FPV Ventures partner Nikunj Kothari
Nikunj Kothari suggests that people visiting San Francisco show someone a concrete piece of work or send a short note with a clear reason to talk. His examples include a shipped side project, a meetup they are organizing, and a few lines in a focused direct message. He says that even as AI makes writing easier, he is more inclined to meet people who put thought into reaching out.
Latent Space — [One Million AI Engineer Special] How Stanford Teaches AI-Native Engineering — Mihail Eric, Monaco
Key takeaway: Mihail Eric is moving Stanford’s AI coding course into real open-source repositories. Students have to make changes that maintainers can understand and accept, and know where an agent’s context and verification conditions come from.
Mihail Eric, head of AI at Monaco, teaches Stanford’s CS146S. In the first run, he found that some assignments could be completed in a single prompt. The new version adds real open-source contributions. Students work in existing codebases and have maintainers review their changes. An early exercise still asks them to build a coding-agent harness of roughly 200 lines. Eric also recommends inspecting the requests existing tools send to models to see how system prompts, tools, and context fit together.
In a large, unfamiliar repository, Eric recommends researching the code and constraints first, proposing several approaches, letting a person choose the direction, and then specifying, implementing, and testing it. An exercise can give different tools the same ten-minute task and compare how each finds context and verifies its work. Before splitting work among agents, he asks how understandable the repository is and how readily results can be checked. As code generation speeds up, merge queues, environment startup, and review can all slow delivery.
He gives two examples from Monaco. The team built Monocoder on Coder to run long tasks in isolated environments. Its Slack assistant Hal helps debug incidents, proposes pull requests, and answers product questions from sales staff. When evaluating review tools, Monaco looked at how frequently they posted on real PRs, how verbose they were, and whether their feedback was useful. Engineers later asked for Devin access themselves, and the team kept using it for review.
Later in the course, Eric asks students which changes can be verified well enough to approve automatically and which call for human review. Data storage, billing, and authorization deserve particular care. Monaco’s PR descriptions explain what actually changed and point to the relevant files. The host also raises a concern that even an accurate description of one PR can miss the long-term intent spanning many changes. Eric expects people to keep defining what should be built and judging whether the result serves that purpose as automation deepens.