Claude Code Engineering Lead Fiona Fung: How to Build the World's Most AI-Native Engineering Team?
What got you here won't necessarily take you further.
What got you here won't necessarily get you there.
👩 Compiled by: Shirley
🧑🎨 Layout: NCon
Fiona may be leading the most AI-native engineering team on the planet.
When writing code itself is no longer the bottleneck, she's grappling with an entirely new set of questions: how to validate, how to measure, how to restructure teams?
This nearly two-hour episode of Lenny's Podcast is a rare field manual for frontline managers. But what it's really trying to say, perhaps, is that thread running through it all:
What got you here won't necessarily get you there.
Guest Background
Fiona Fung | Head of Claude Code and Cowork, overseeing all engineering and PM for both product lines. Boris Cherny and Cat Wu, among others, report to her.
She's a veteran leader who understands both low-level engineering and hyper-scale organizations, with over 25 years of engineering experience: starting at IBM, spending 11 years at Microsoft building Visual Studio and TypeScript; then joining Meta to launch Facebook Marketplace from zero to one (now with annual GMV exceeding $100 billion), working on Meta's first-generation smart glasses and Orion AR glasses, and leading infrastructure, growth, and safety teams at Instagram with 500+ people under her management.
Core Insights
-
Writing code is no longer the bottleneck — validation and measurement are. Even designers and PMs are submitting code. The constraint has shifted from "who writes it" to "how do we validate": codify "what good looks like" into specs in your repo for Claude to check against, while staying vigilant against mistaking "motion" for "progress."
-
Hire only two types: product-minded dreamers who build end-to-end, and systems experts who chew through hard problems. One type takes ideas to finished products; the other guards deep domains like distributed systems. Underlying both: trust but verify.
-
Management workflows are being automated, work is going asynchronous. A persistent Claude hooked across all codebases knows the team's pulse; Routines outthink cron jobs.
-
High agency must come with high accountability. Give everyone freedom to run, but be clear about what hypothesis you're testing and who owns the outcome. Freedom and accountability are two sides of the same coin.
-
Managers must live inside the product. No dashboard, however good, replaces the feel of hands-on use. Many critical judgments come from specific cases. When data and anecdotes conflict, sometimes trust the anecdote.
-
Growth mindset is what pulls people ahead; fear is what holds them back. "What got you here won't necessarily get you there." Faced with fear, first ask "what's within my control," then go do the thing that scares you.
From VIM to Visual Studio: Writing Code Is Exiting the Bottleneck
👱♂️ Host Lenny
I went to Code with Claude a month ago, heard your talk, and thought "I have to get Fiona on the podcast" — because you're thinking further ahead than most people.
You've been an engineer for 25 years, starting at IBM, which looks like a completely different place today. The job has changed absurdly fast these past two years: not long ago 100% of code was written by humans, and now we're heading toward 100% written by AI. As Boris Cherny's famous line goes: "coding is solved."
You all also posted this recently:
Anthropic engineers now submit roughly 8x more code per quarter than before 2025.
As someone who's lived through this, what moments along the way really changed how you think?
👩💻 Fiona Fung
I love looking back at timelines like this.
At IBM I was on the OS services team for DB2, and I was determined to go "to the hardest part of the stack," thinking the closer to the operating system, the more I'd learn. What's interesting is that IBM to Microsoft was itself a huge leap.
At IBM I basically just used VIM and terminal debugging. The company had Eclipse licenses, but most people didn't use them. When I got to Microsoft — and don't laugh — I was naive enough that I didn't even know what an IDE was.
This was the early 2000s, right as the dot-com bubble burst. A lot of companies had hiring freezes that year, so when Microsoft gave me an offer, I was incredibly grateful.
They said "you're going to work on Visual Studio," but I came from a Unix background and had no idea what Visual Studio was. I actually asked: "Is this some kind of advanced drawing software?" I'll never forget my manager's face. But Visual Studio became the love of my career for the next 11 years.
I was on the VS editor team, using the VS editor every day to build the VS editor itself — that's where my love of dogfooding comes from. (Dogfooding means the team uses its own product first, to catch problems immediately.)
There was no social media back then, so engineers couldn't get user feedback quickly. Fortunately our entire team were heavy VS users, so we could give each other feedback incredibly fast.
When I worked on Visual Studio, software was still shipped on CDs. You had to make sure it was ready for manufacturing, pressed onto discs, and on shelves by the deadline. Because engineering time was scarce and the deadline was immovable, you did a ton of planning to squeeze the most out of limited time.
Now, witnessing the shift alongside Claude Code and Cowork: writing code is no longer the bottleneck. It's not just engineers — designers, PMs, everyone on the Claude Code team is submitting code.
So when more and more people are submitting code, from increasingly diverse professional backgrounds, and at this level of productivity, how do we think about "validation"? That's the other major shift I'm seeing.
Managers Are Handing "Seeing the Big Picture" to a Persistent Claude
👱♂️ Lenny
Let me set the frame for this conversation: What does an AI-native software team look like in 2026?
👩💻 Fiona
Because roles are converging, everyone is moving toward being a builder. Everyone's a builder.
I've been trying something recently: I have a persistent Claude Code remote session hooked across all our codebases, so I have a global view of what every team member is working on. This instance also has access to all our Slack channels and the metrics we track.
So every month I'll say "hey, let's do a retrospective," share my screen, open the Claude Code session, and ask it: "What were the priorities this month? What shipped? What's the market feedback? What channels is it coming from?"
I used to use sessions like this just to generate PRs and fix bugs. Now I use it so I can sit down with the people I manage, look at these insights together, and have a conversation.
👱♂️ Lenny
So this is a management technique: while shipping product, you can also be clearer on the actual impact of what the team is producing?
👩💻 Fiona
Exactly. Beyond the act of "submitting" itself, you also look at how it's performing in the market, whether it's catching bugs.
I have a phrase: make new mistakes. It's okay to make mistakes, but make new ones, so we're always learning. If you're pursuing zero mistakes, it probably means you're not moving fast enough or you're being too cautious.
With Claude, I can also have it look horizontally: for example, "looking across these incidents, can you extract a common theme? Where's the most valuable place to invest in quality next? Where are hidden hotspots we're overlooking?" A year ago this was almost entirely manual work — I couldn't get these kinds of insights.
👱♂️ Lenny
Beyond this, what else helps you and the team keep pace while ensuring quality?
👩💻 Fiona
Feedback channels matter a lot to us. My old morning ritual was: grab a coffee, scroll through the feedback channel, and if I had time, pick one gap to patch. That changed completely a month or two ago when we launched Routines — I set one up to automatically monitor feedback, cluster themes, and by the time I wake up, there's a summary waiting, sometimes even a few PRs ready for me to review.
👱♂️ Lenny
Where's the feedback coming from? Email, Twitter, or a mix of everything?
👩💻 Fiona
Lots internally, plus all kinds of external feedback — DMs from friends, LinkedIn, social media, we forward everything into Slack, and of course partners. We have different channels for different sources. Because the volume's so high, I need Claude to help me keep up.
From Writing to Validation to Quality Monitoring
👱♂️ Lenny
Code review is obviously another big challenge. Claude now has its own automated code review too. Any new tricks you've figured out there?
👩💻 Fiona
It's wild to say, but we didn't even have Claude's automated code review last year. So when we talk about bottlenecks, manual review was a massive one. For critical areas that need deep professional judgment, we still make sure the right people are reviewing.
But what really helped us: the more you can codify "what good looks like" into a framework, the more automation can take over. When you give Claude a "what good looks like" framework to validate against, it tends to perform exceptionally well.
We recently turned our content design standards — button copy, error messages, tone and voice, all those UX writing guidelines — into a Skill and checked it into the codebase. So as long as you have a Spec, check it into the repo, keep it with the code, and update it alongside the code, Claude's code review can compare outputs against the "latest standard" every time.
👱♂️ Lenny
So this is essentially an evolution of test-driven development (TDD).
👩💻 Fiona
Right. TDD was huge in the 2000s: write the test first → run it and watch it fail (red) → write code to make it pass (green). The principle is flawless, but I personally struggled with it back then. It felt like "eat your broccoli first" when I wanted to get my hands on the product and feel the rush of shipping.
The interesting thing is, the first bug I fixed with Claude Code, I told Claude: "I want to do TDD — help me write the test first, confirm it fails, then make the fix and get it to pass."
Test generation used to be a tax I had to pay. Now that it's automated, those old engineering principles — TDD, Specs, Skills — actually become more effective, because the model can carry more of the load for you.
👱♂️ Lenny
With so much output, how do you still keep quality in check?
👩💻 Fiona
Something we're really trying to nail, and still refining, is proactive quality — catching issues as early as possible.
I came up with a simple framework called bad & sad: bad is terrible and unrecoverable (like the CLI crashing and losing work); sad is painful but recoverable (like UI flickering). What's interesting is that a pile of sads often snowballs into a bad.
I should mention agency here: each team defines for themselves, within their product surface, what counts as bad, what counts as sad, and what they're targeting.
👱♂️ Lenny
What I'm hearing is that the best quality tool is actually monitoring and testing, not spending more time on manual review — essentially giving the agent a closed loop: if it knows what success looks like, it can find and fix issues itself.
👩💻 Fiona
Exactly, that's where we're headed. The more quality can be pushed toward "catch early, catch automatically," the less you need humans reviewing line by line.
Don't Mistake Motion for Progress
👱♂️ Lenny
There's been a noticeable shift in vibe lately: from token maxing (cranking usage to the limit) toward "what did we actually get, what's the ROI." Boris worked on engineering effectiveness at Meta, and there's been ongoing debate about how to measure AI productivity gains. What's your take?
👩💻 Fiona
We initially considered "lines of code," but that got controversial fast: someone's line count explodes, but they just copied a library and checked it in; so do we count "effective lines of code"? But what if you update a framework, generate less code, and deliver the same value? Should we look at "time to PR merge"?
After going in circles, my conclusion is: first check whether the output actually connects to outcomes.
Don't forsake motion for progress. Don't let "busy" impersonate "progress." If you're only tracking tool usage, you're measuring activity — but is it actually making the result you want happen? Let me give you an example: Facebook Marketplace launched region by region early on, and the metric we tracked was "number of sellers." After the first region launched, I noticed seller count wasn't high, but buyers were actually finding what they needed. That region didn't have many sellers, but it had a group of "power sellers," and buyers finding what they need was what we actually wanted.
So whether you're measuring productivity or product, keep looking back: is this metric still serving your real goal? The environment changes so fast that the metrics themselves need to change too.
Dreamer Product Builders and Hard-Problem Systems Experts
👱♂️ Lenny
Speaking of builders, my favorite slide from your talk was about who you hire. You said you're now mainly looking for two types: 1) creative builders with product sense; 2) deep systems experts who can tackle the hardest parts.
👩💻 Fiona
Right, let me start with the deep expertise side.
When I first joined Claude Code, the team had great generalist product builders, but I found we were missing people with systems backgrounds, especially distributed systems. The principle is trust but verify — models are genuinely powerful, but many areas still need validation. Wherever deep professional judgment is required, it's worth continuing to invest in these people.
The other type is the product-oriented dreamer: passionate about product, takes an idea end-to-end, ships it, gets feedback, iterates, polishes, makes it actually good to use. These "idea to shipped, all on one pair of shoulders" people have been huge for us on Claude Code.
👱♂️ Lenny
Really resonates. The word that comes to mind is ambition. I was talking to a 10x engineer the other day — someone proposes a feature idea, and his old reaction would be "that's too hard, too complex." Now it's "that's totally possible, I'll have Claude Code do it, and it just works."
So the question becomes how ambitious can you be. Theoretically everything's possible now — the key is how big you dare to think.
👩💻 Fiona
Exactly. I was talking to an engineer yesterday — he's not from a mobile background, but we urgently needed a mobile feature. He said "thanks to Claude, I can actually do mobile work now." Even if you're not an Android expert, you now have a partner to help you pull it off. Claude raises the ceiling for everyone's capabilities.
What Creates Distance Is Growth Mindset; What Keeps People Out Is Fear
👱♂️ Lenny
Following that thread: as roles shift, some people thrive while others get frustrated and resistant. What do engineers who adapt well have in common?
👩💻 Fiona
Growth mindset really makes a difference — actually I felt this even before AI tools existed. The core is always learning with curiosity, and admitting: what made you successful in the past won't necessarily keep working in the future.
As for frustration, I sometimes see fear underneath it.
Frustration often comes from fear, from feeling like nothing's in your control, like this is happening to you. If you reframe it: this isn't happening to me, it's happening for me — what can I change? That helps a lot. Let me share a personal story.
In high school I wanted to be a visual artist. Computers were expensive then, but my school had a typing class, and the next one was HTML programming. I fell in love with programming for the same reason I loved art: you have an idea, and you can create, tell a story.
But I had a bigger fear: "how am I going to afford engineering school?" I grew up in Ontario and knew about OSAP (Ontario Student Assistance Program), but didn't know how much it would cover. I thought "what can I do right now?" — and happened to see a flyer from National Bank of Canada at our high school, recruiting high school interns as bank tellers. It was minimum wage, but I saw it as a lifeline.
The funny thing is, my most hated class in high school was accounting, but I signed up anyway. I worked all summer saving money, then went to school Monday through Friday and worked Saturdays as a teller for two years. It was the only actionable thing I could grab within my control, to fight the fear of "I might not be able to afford school at all."
So two other phrases I love: "What would you do if you weren't afraid?" and "Do something that scares you every now and then."
When you're peaking at something you're already great at, how do you keep growing? You go do something you've never done before, something that scares you. You'll hit a dip because you have to relearn, but that's where growth comes from.
👱♂️ Lenny
The line I use most on this podcast is:
The cave you fear contains the treasure you seek.
👩💻 Fiona
That's cool, I'm writing that down.
Where Users Detour Is Your Next Product
👱♂️ Lenny
Anthropic always seems to spot bigger opportunities before others — coding, Cowork, the emphasis on model personality. What do you think the team is doing right to find these opportunities ahead of other labs and actually bet on them?
👩💻 Fiona
I haven't been at other labs, but we pay a lot of attention to latent demand: for coding, we were our own first users, so feedback loops were tight. Later we noticed non-programmers using Claude Code, and wanted to make that experience better — that's how Cowork came about. I've also always been interested in small businesses; after visiting a few, the team actually built out Claude for Small Business as a packaged offering.
So my advice is: beyond continuously polishing your own product, watch for unexpected new uses that are starting to bubble up.
There's an iron law in software: users will always use your product in ways you didn't design for, for better or worse. When you see people going through all kinds of workarounds to get something done, that's usually the next experience you should smooth out.
Routines Have a Brain That Cron Jobs Don't
👱♂️ Lenny
How do you see the next frontier in engineering? Fleets of agents, or something else?
👩💻 Fiona
We're moving toward async. Before, I'd send a prompt synchronously, maybe manually run a few in parallel. Now I can use a Routine to generate those prompts for me — the level of abstraction keeps rising.
👱♂️ Lenny
Help us understand what Routines actually are.
👩💻 Fiona
Simply put, it's taking the things I manually repeat every day and making them into a scheduled, automatically running routine.
👱♂️ Lenny
Kind of like a cron job.
👩💻 Fiona
Right, but it can actually dispatch agents for you.
Before, a cron job could automate things, but now it's "look at this feedback, and if there are bugs, which ones can we fix along the way?" — it spins up agents, and by the time I wake up, I have a batch of PRs to review.
Before, AI would run different agents and I'd still have to figure out "what do I do with this information next?" Now I write a routine that generates and dispatches prompts to different agents for me — it's like a cron job with a brain added on top.
We're going to keep moving in this async direction.
👱♂️ Lenny
So as a manager, all those things you do every day — how's the project going, who's falling behind, what needs unblocking, where can we polish more — you can write them as prompts, have Claude do them daily, and present you with "here's what I did, here's what you can review."
👩💻 Fiona
Then give it more autonomy — where validation is going well, tell it "go ahead."
👱♂️ Lenny
This reminds me of a great talk by Tyler Cowen. He said the people who do best in this era have one key trait: initiative, also called agency.
👩💻 Fiona
I love the word agency — it's exactly what the Claude Code and Cowork teams value most. But we always pair it with "high": a problem comes up, and everyone on the team has their own solution. That's high agency.
And with high agency, we pair high accountability: give people the freedom to cook, but also ask clearly "who owns this, and what's the hypothesis you're testing?"
Like two sides of the same coin — it works really well for our team.
Managers Must Start as ICs and Stay in the Product
👱♂️ Lenny
Back to how you run teams. I heard you've pushed some pretty unique practices, one being: every manager has to start as an IC, and after becoming a manager, they keep working part-time as an IC — a "player-coach" model.
Why is this so important today?
👩💻 Fiona
As a leader, if you start as an IC and give yourself hands-on time to dig into code, to really get the codebase and product under your skin, it's incredibly valuable. I do PRs myself — not because of what I fix, but because it forces me to use the product every day and stay sharp. Cowork and Claude Code move so fast.
If you're not personally using your product every single day, you gradually lose your feel for it.
Having new managers start by embedding as engineers — the rapport they build with the team is so much better. Otherwise managers come in thinking "I need to manage," and do all these management motions. But if you first actually experience "what's it like to be an engineer on this team," you earn trust in a completely different way.
I joined every team I've been on (VR, smart glasses, Instagram), and one of the first pieces of feedback I always got was "I really love that you actually use what we build." At Meta, I interviewed in as a manager but spent my first quarter also working as an IC, because the tools, codebase, and language were all new.
The last time I shipped production software was probably 2017, and I hadn't touched it in a long time. But in my first week at Claude, I was going to do my old thing of scheduling coffee with every engineer, then thought "let me ask Claude first." It became a great onboarding buddy: helping me with automated testing, and when I wanted to test manually, it helped me think through how to cover all the cases.
👱♂️ Lenny
I've talked to a lot of people who've worked with you, and what comes up most is your obsession with living and breathing the product — personally using it, dogfooding. Why is this so important?
👩💻 Fiona
There's always this dream in product: you want to enable some experience or make it better, and dogfooding gets me closer to that tactile sense. When I was on Meta's VR/AR team, I'd often discover weird ground-height bugs just from how I set up my device — I accidentally had this perfect reproduction environment.
Second, it's often the most helpful thing I can do for the team. When I led the VR team, I never submitted code to that codebase because I was afraid of breaking the OS, but we were doing a lot of polish fixes. So I said, "I'll use my dogfooding time to go through the experience and validate it for you." That maintained quality, and team members usually really appreciated it.
Beyond metrics, everyone wants to confirm "my work matters." When they see leadership using what they built, it creates more belonging.
👱♂️ Lenny
That's important — there's always this "anecdotes vs. data" debate, and what you're saying is that as a product and engineering leader, you actually get a lot from those specific, one-off personal experiences.
👩💻 Fiona
Right. If you're leading a team where it's genuinely hard to use the product yourself, then go meet customers — find that path to stay close to real usage.
When Facebook Marketplace was launching in Latin America, we tested in Chile and the numbers were consistently worse than other regions. Later three of us did a small field research trip. The moment I landed and opened a local Android phone, I understood: LTE was so much slower than in the US that Marketplace's feed simply wouldn't load on weak networks. If the page won't even open, what a massive growth barrier that is.
So always listen to customer feedback, keep that tight feedback loop.
👱♂️ Lenny
I think it was Jeff Bezos who said: when data and anecdotes conflict, all else being equal, trust the anecdotes. This is a perfect example.
Roles Are Converging, But Some Things Must Hold
👱♂️ Lenny
The team you run is literally the team most transforming what it means to be an engineer — it's very meta. So let me follow that thread: are you worried that engineers' coding skills will atrophy if they're no longer writing code by hand? Does that matter to you?
👩💻 Fiona
We actually discussed this internally.
Take Boris, for example — he used to write code by hand in the early days, and now he doesn't, but that engineering mindset was earned in the codebase. So to engineers joining us, I'd say: whatever you're doing, still spend time understanding the architecture and the change you're making. It comes back to trust but verify.
Maybe someday that won't matter, but at the current pace, I still recommend going one layer deeper, understanding the layer you depend on. That way when a dependency changes, you see it more clearly, and you don't miss the new capabilities it brings.
👱♂️ Lenny
Beyond engineering, what's the second-most transformed role inside Anthropic?
👩💻 Fiona
Every coding-adjacent role is changing.
You also talked to Cat Wu — PMs have changed a lot. Having an idea is no longer blocked by engineering bandwidth. Our PMs have actually fixed features that engineering didn't have time for. Next up are design, data science — these are areas where we should improve the experience.
Most commits are now Claude-assisted, which is a shift. It's important for engineers to build that product sense muscle. Work that was traditionally non-engineering is now often done by engineers themselves, because you're no longer waiting for a cross-functional partner to unblock you. The model fills in capabilities you didn't have.
👱♂️ Lenny
So it's a two-way street: engineers become more product-oriented and accountable for product outcomes, while everyone else becomes more like engineers.
👩💻 Fiona
Yeah, everything's converging.
👱♂️ Lenny
What about deep specialists? You left an open question in your talk too: do we still need separate iOS and Android orgs?
👩💻 Fiona
We still think bringing in that kind of deep expertise matters, just not at the same scale, because everyone is flexing now. So you still need Android and iOS specialists, but not a big mobile org. The balance of "enough and right" — we're still figuring that out.
👱♂️ Lenny
There's another one I'm especially curious to hear your take on: AI should theoretically make engineers less essential, yet you, OpenAI — everyone's hiring engineers like crazy. Where do you think this is headed?
👩💻 Fiona
The way you and I got into engineering is so different from now.
How do people graduating today quickly find their footing while also truly understanding what I mean by "going one layer deeper"? I wonder if software engineering becomes more like a fellowship. We have internships, but those are three-month projects. How do we pass down the years of experience and intuition our generation built up to the next generation of builders? That's something I keep thinking about.
👱♂️ Lenny
Right — if you never have to look at code, what's the motivation for a new engineer to really understand infrastructure, memory allocation, all that low-level stuff?
👩💻 Fiona
Maybe models get good enough that none of that matters. But I still think there's value in going one layer deeper — opportunities to improve the product or system often hide in that layer. It's just that learning it may not require years of typing code anymore.
I had an early manager who started out on punch cards, and now he sends me stuff he built with Claude Code every day. What a career arc. The changes he lived through were just as seismic.
So maybe the question is: what will always matter, what will matter less, and how do you build real skill in the thing that truly matters.
👱♂️ Lenny
The argument I often hear is: this is just another layer of abstraction, like the path from binary to assembly and up. Now we don't look at code, prompts and Claude's thought process are the new layer.
👩💻 Fiona
And the pace of change is so fast. I remember around Sonnet 3.5 or 3.6, it would still make mistakes, and engineers who were resistant to AI tools would say "see, this doesn't work."
But the hard part is understanding that exponential progress: things I had automated that failed before, the next model made good enough. So it's worth constantly asking: what didn't work then that deserves another try, because it might be a new capability now.
👱♂️ Lenny
Do something that's "almost working, right at the edge of capability" — once the model crosses that line, you'll be way ahead.
I was an engineer for ten years. The best feeling was getting into flow, writing code, watching it compile and run. But now you don't do that — you just sit and wait for the agent to build something.
What else do engineers lose in this new world?
👩💻 Fiona
I just talked to an engineer about flow. You used to hit a really hard problem, put on music, get in the zone, and there was always that "finally cracked it" moment of insight. Now the joy comes more from the product itself, but some people do say "what I used to enjoy most was precisely the hardest parts."
There's another phenomenon: people increasingly work only with their own agent, and slowly become isolated. So we've done pair programming, and we've run a few hackathons — everyone uses Claude Code and Cowork differently, and you learn a lot just by being around each other.
Fiona's mention of hackathons has a very concrete recent example.
At the "Built with Opus 4.7" Claude Code hackathon, the first-place winner was Bedirhan Keskin, an engineer by way of medicine. He built Medkit, a virtual clinic for medical students and residents to practice on: you interview simulated patients, order labs, read imaging, diagnose, prescribe — and finally an agent grades you against real clinical guidelines, like an examiner.
He worked almost entirely by voice, running four parallel Claude Code sessions for voice engine, content generation, 3D game layer, and core application — each with clean context, all advancing simultaneously. Three medical schools and one pharma company are now preparing pilots.
His advice to other builders:
Work with Claude as a thought partner, not just a coding agent.
This is exactly what Fiona means by the AI-pilled builder — having an idea, discussing it with Claude Code first, then turning it into something real.
Cut the dead weight: JIT planning
👩💻 Fiona
One practice our team really values is explicitly allowing ourselves to cut processes that no longer serve us.
A recommendation for anyone leading a team: pick the process you dread most, the noisiest, the most expensive, or the most manual one — and ask it "do you still deserve to exist?" Planning, for example. When I first joined Claude Code, I thought "maybe a six-month roadmap, but super lightweight."
That exercise was useful for starting conversations and aligning direction, but three months later I realized "wait, have we looked back at this once?" — because things changed so much.
👱♂️ Lenny
So how do you plan now?
👩💻 Fiona
I call it JIT planning — just-in-time planning.
Six months is too long. Now it's monthly planning, super lightweight, not even a document — just a small table aligning what we think matters. Weekly, we quickly confirm "is this still the priority for the month?" I'm still thinking about how to automate even this step, because I never want anyone to feel like "updating the table" is a burden.
So once priorities are set, it goes back to agency — everyone decides how to push forward themselves. Every six months we gather the whole team to set big themes, but those become outdated quickly as the environment shifts.
After listening to this nearly two-hour conversation, you'll notice that on certain questions — whether iOS and Android should still be separate, how far automated review can go, how to keep everyone equally productive when role boundaries blur, how this generation's accumulated experience gets passed to the next generation of builders — Fiona barely gives standard answers.
But what got you here won't get you there.
So faced with change, she first asks "what's within my control," then does the thing that scares her, moving toward the fear. Faced with process, she regularly asks "is it still working?" — and cuts it if it's not. Faced with her work, she automates what she can with Claude, and saves her energy for the judgment and connection that only humans can provide.
Writing code is moving out of the bottleneck position, and the engineering profession is being redefined.
What truly carries you through cycles is a growth mindset, attention to real feedback, and dogfooding your own product.
Crossing is looking for independent writers to cover AI products and model evaluations.
If you've written pieces like "Hands-on with PixVerse C1[1]" or "Hands-on with LibTV[2]," please contact zeo0811@gmail.com. Your email should include: ① a brief bio, ② AI evaluation pieces you've written.
We offer competitive compensation. We look forward to observing and documenting the AI era with you. 🎪