📺 Today’s recommended deep-dive video: https://www.youtube.com/watch?v=AmdLVWMdjOk

Beyond the Code: Boris Cherny on Latent Demand, Side Quests, and the AI Coding Revolution

Boris Cherny, the creator of Claude Code and former Meta Principal Engineer, has spent his career mastering the art of the “side quest” to drive massive organizational impact. From rewriting Facebook Groups to migrating Instagram from Python to Hack, his trajectory offers a masterclass in how generalist skills and product sense outperform narrow technical specialization. Now at Anthropic, he is leading the transition from manual coding to agentic orchestration, helping engineers achieve 70% productivity gains through AI.

Core Question: How can engineers evolve from manual coders into high-leverage orchestrators by identifying latent demand and embracing the power of agentic AI?

Highlights

• The Latent Demand Principle: The most successful products are built by observing how users “abuse” existing tools and then formalizing that behavior into a dedicated feature.
• The Power of Side Quests: Sourcing and automating “toil” through weekend projects or infrastructure improvements is the fastest way for an engineer to build credibility and influence.
• Thinking in Types: Moving away from syntax toward type signatures as the primary architectural tool, a philosophy born from a literal need to reduce keystrokes after a motorcycle accident.
• Agentic Orchestration: The future of software engineering isn’t writing code by hand; it’s managing a “swarm” of AI agents that can build entire feature sets in parallel.

⏱️ Reading time: approx. 8 minutes · Saves you about 77 minutes vs. watching.

Want to take notes while watching? Click the image below and let AI Notebook capture the key points for you 👇

The Philosophy of Product-Minded Engineering

Identifying Latent Demand

The most important principle in product development is latent demand—the observation that you cannot force people to do something new, but you can help them do what they are already trying to do more easily. Cherny points to Facebook Marketplace as the ultimate example; it wasn’t a top-down idea, but a response to the fact that 40% of group posts were people trying to buy and sell items in a space not designed for it. By identifying where users are “hacking” a system, engineers can build products with built-in product-market fit.

This mindset requires engineers to be generalists who look beyond their immediate tickets to see the broader user behavior.

At Meta, Cherny’s team for Facebook Groups didn’t have user researchers, so they performed “cafeteria research,” literally stopping workers during lunch to see if they could navigate new features. This scrappy, observational approach provided raw data that no formal dashboard could replicate, proving that engineering excellence is inseparable from product intuition.

💡 Digging Deeper

Q: Why is “hacking” the best indicator of a new product?
A: Because it proves intent. Users are willing to deal with a “jank” experience to achieve a goal, which means the value proposition is already validated.

Q: How do you train “product sense” as an IC?
A: Spend time in observational studies. Watch users struggle with your interface without prompting them; their points of friction are your next high-impact projects.

Scaling Influence through Technical Side Quests

The Strategy of Automation

Cherny credits a significant portion of his career growth to “side quests”—projects that weren’t part of his official roadmap but solved systemic pain points for the entire organization. When he found Redux too complex, he built Unux; when he saw common bugs in large-scale data sets, he built testing infrastructure for 10-million-member groups. These projects weren’t just “extra work”; they were high-leverage tools that improved the productivity of thousands of other developers.

Better engineering is the most direct path to growing your network and influence within a large company.

He suggests keeping a “toil tally.” During code reviews, if you find yourself making the same stylistic or architectural comment three times, stop talking and write a lint rule instead. This turns a repetitive manual task into a permanent, automated improvement for the entire codebase, effectively “hiring” a robot to do your code reviews for you.

💡 Digging Deeper

Q: How do you find time for side quests in a high-pressure environment?
A: Cherny suggests being “situationally aware.” Look for areas where the organization is already incentivized to improve (like “Engineering Excellence” pillars) and pitch your side quest as a solution to those existing goals.

Q: What should you look for in a side quest?
A: Sourcing is simple: find something that annoys you two or three times. If you have the problem, it’s a mathematical certainty that other engineers have it too.

Leading Through Technical Conflict and Change

The Art of the Design Competition

As Cherny moved into senior leadership roles, he faced massive scoping challenges, such as merging the data models for Facebook Pages and Groups—a project involving hundreds of engineers. To break a deadlock between senior architects, he organized a “technical design competition,” splitting engineers into two teams to whiteboard the problem for three hours. This revealed that the designs were 80% identical, allowing the team to start execution immediately on the shared foundation while focusing technical spikes on the 20% difference.

This “game-ified” approach to architecture builds consensus without the friction of traditional top-down decision-making.

When navigating technical disagreements, Cherny emphasizes the need to “earn trust” before pushing back. In one instance at Meta, he followed a senior engineer’s (Bob) advice for a massive, year-long migration even though he disagreed. When the migration eventually proved unnecessary, he pushed the same senior engineer to lead the reversal. This showed maturity—proving he was willing to execute someone else’s vision, but also bold enough to admit a mistake and fix it for the sake of the codebase.

The Instagram Migration: From Python to Hack

Moving to Instagram’s Tokyo office forced Cherny into a productive isolation. In a time zone with zero meeting overlap with the US, he returned to deep coding, realizing that Instagram’s product-driven culture had left it lagging in infrastructure. He began the Herculean task of migrating Instagram from Python to Hack, not by mandate, but by building trust with the “info old-timers” over beer in New York and finding the silent majority who knew the change was necessary but were too afraid to start.

The Future: From Coder to AI Orchestrator

The Claude Code Revolution

At Anthropic, Cherny’s creation, Claude Code, has transformed the internal engineering culture. Productivity per engineer has grown by nearly 70% because the team doesn’t build for the model of today; they build for the model six months from now. Cherny describes the current state of engineering as a transition from manual line-writing to agentic orchestration, where one engineer can manage a “swarm” of 20 agents to build entire plugin suites over a weekend.

Engineering is becoming a manager’s role, where you wake up, start a few agents on your phone, and check their PRs by lunch.

While some worry about “slop” or low-quality AI code, Cherny maintains a strict rule: the bar for code quality is the same whether a human or a model wrote it. If the code sucks, you don’t merge it; you ask the model to improve it. This “pairing” approach—aligning on a plan first, then executing—ensures maintainability while capturing the massive speed gains of LLMs.

Key Takeaways

Engineering impact is rarely about how many lines of code you write; it’s about your ability to identify where the system is failing and building the tools to fix it for everyone. Boris Cherny’s career illustrates that “side quests”—the lint rules, the testing frameworks, and the infrastructure rewrites—are the most powerful way to build credibility. By solving your own frustrations, you naturally solve the organization’s frustrations.

The shift toward AI-driven development is not just an incremental improvement; it is a fundamental change in the developer’s day-to-day life. We are moving toward a world where the “maker schedule” and “manager schedule” merge. Engineers must learn to trust agents to handle the “toil” while they focus on high-level architecture, type signatures, and product strategy.

Finally, “common sense” remains the ultimate engineering tool. In large companies with misaligned incentives and organizational inertia, the ability to step back and ask “Does this actually make sense for the user?” is the rarest and most valuable skill an engineer can possess.

Q&A

Q1: What is the single most important technical book Cherny recommends?
A: Functional Programming in Scala. Even if you never use Scala, it teaches you to “think in types,” which Cherny believes is more important than the code itself.

Q2: How did a motorcycle accident change his coding style?
A: After breaking both arms, Cherny had to minimize keystrokes to reduce pain. This led him to functional programming (Haskell, Scala) and CoffeeScript, eventually resulting in a deep obsession with the efficiency and expressiveness of TypeScript.

Q3: What was the “Middle Option” trick for VP reviews?
A: Cherny jokingly noted that when presenting to non-technical leaders, providing three options usually results in them picking the middle one 80% of the time, as it feels like the most balanced trade-off.

Q4: How does Anthropic approach AI safety in model releases?
A: The company has actively held up model releases because safety risks were not fully understood. Cherny notes that as models like Opus reach higher capabilities (e.g., potential bioweapon design), safety is no longer a “tax” but a literal fight for humanity’s existence.

Q5: What is “unshipping” at Instagram?
A: It is the practice of deleting features that don’t meet a specific usage bar. Even if 5% of users are upset, removing clutter improves the experience for the other 95% and frees up limited screen real estate.

Q6: Does Cherny still do one-on-ones?
A: No. Since moving to Japan, he stopped doing standing one-on-ones to prioritize deep work and coding, a habit he has maintained even back in the US.

Q7: How should junior engineers start with AI coding?
A: Don’t just “vibe code” everything. Use “plan mode” to align with the model on the logic first, then treat the model as a pair programmer, maintaining the same high bar for its code as you would for your own.