The 4 Modes of Modern Agentic Development

Stephen Poletto (00:00)

Hey Mike, nice to see you.

Mike Nakhimovich (00:01)

Hey Stephen, nice to see you as well.

Stephen Poletto (00:03)

So we met each other back at Dropbox, I think, when you were working on mobile products as an Android engineer. But you've had a very interesting career run since, and I know you've been working on AI enablement most recently at Airbnb. For our audience, maybe give us a little bit of background on who you are, the shape of your career to date, and how you ended up doing what you're doing now.

Mike Nakhimovich (00:27)

Perfect. At the end of it, I have no idea how I ended up where I am doing what I'm doing now, but I can tell you that it's really fun. I started as a web developer early in my career, and about five years in, mobile started becoming pretty popular, so I switched to Android. It was one of those Android or iOS things. I flipped the coin, went with Android, and did that for about a decade.

We met at Dropbox as I was joining. I think it was at the tail end of you being there. I was going to go work on Dropbox Paper, which I still feel like was the best text editor, past and present.

Since then, I went to Twitter at the tail end of Twitter. I was there for about six months as everything was burning down. I went to a hardware startup, and then ended up at Airbnb once I wanted to go back to a big company. That's right where the AI transition was happening.

I came to Airbnb to lead mobile testing, and mobile testing at that time was still writing screen robots, getting test coverage up, making sure things weren't flaky, getting onto the cloud. And AI was becoming a thing. Folks were starting to use Cursor, Copilot autocomplete existed, but it was before any of these agents. I saw the writing on the wall. Everything we were doing with AI, even super naive AI at that point (I think it was Sonnet 3 or something), was already able to generate test cases, start to do good work, and verify things.

So I looked around for roles that were close to AI at Airbnb, and there was this odd-looking one. It was DevTools Developer AI, which didn't really exist as a thing at the time. And lo and behold, I got the role. I sold it on: I was early on Android, I like things that are early, I like things that are fun.

For two years, I built a team and we drove AI adoption at Airbnb. It was an incredible ride, taking folks from 5% to 98% adoption of AI, but doing it in a human way, a way where we're not forcing it. It's new, it's shiny, but we're all doing it. Let's do it step by step. It was absolutely the most incredible experience of my career, seeing that transformation. I was a little too young for the web transformation, and I was on the tail end of mobile as it was already starting up. But seeing what happened with AI, from zero to what it is now, was super cool.

Stephen Poletto (03:00)

Incredible. So the experience you had at Airbnb has informed what you're doing now, right? You have this company you've started that you're calling Friendly AI. What's it all about, and how did the Airbnb experience shape the vision of what you're building now?

Mike Nakhimovich (03:19)

Yeah, absolutely. More than anything, my job was developer productivity. People are more productive when they're happy. I think that's kind of obvious. What we tried to do was teach people a new way to code. It was a process that started with autocomplete in IDEs, then building little iframes where people could do a bit of back and forth in their editors, then transitioning when terminal tools like Claude Code and Codex started coming out and figuring out: what tooling do we need, what safeguards do we need, what connectivity do we need, so we meet folks halfway.

From there we went to more web experiences. Now we have these agents, so why do we need them on people's computers? Maybe we can have hosted ones, so you can ask something like, "Hey, what's my standup?" Eventually that led to what I think are now called software factories, these setups where you have remote agent environments. That was the thing I've had the most passion for of anything I've worked on: creating collaborative environments for agents and humans that live off laptops. The same way we took websites off your computer. You no longer install applications; you just go to Amazon.com and start doing something.

So what I worked on internally was a remote agent platform. We had dev boxes, kind of like a Dropbox, where you spin up your dev box and all your stuff is there. But now it's agent first. You can have your Codex, your Claude Code, your tools, and you can access it from your phone, from Slack, from browsers, from Claude Code over MCP, and start building up this platform.

What I believe is happening right now is that how we build software is fundamentally changing. It's really hard to see who's going to win. Is it going to be a lab? Is it going to be open source models? But we're starting to converge on an AI software development lifecycle, where we want to be able to define agents, observe them, steer them, and review them. What I'm hoping to do with Friendly AI is give you a platform where the hardware you're using is no longer your bottleneck. It's not your battery, it's not your laptop, it's not what you have installed. You can just use agents. They can clone things, get information, be long running. It's like an IDE, but for agents, remotely. "Agent development experience" is kind of an overused term, but yeah, something like that.

Stephen Poletto (05:53)

There's a very interesting analogy with Figma, right? Everybody used to do design in Photoshop and other local software applications. Figma created a cloud-based offering and made it collaborative. And I think the fact that these agent sessions are still private, happening on people's local machines, where you only see the result of the work in the form of a PR, is a real inhibition. The reasoning chain, the specification of what needs to get built, the decisions that are made: those are locked in local transcripts. If you can move them to the cloud and make them collaborative, it unlocks a whole new way for teams to work together to shape software. So I'm pretty bullish on what you're doing.

What makes it hard, though? If I'm a listener, I might think, "I want to move my developer workloads off my laptop. I want to set up remote dev boxes and let engineers start building in the cloud. Why can't I just get a dev box, install some tools on it, and be off to the races?" What makes this hard enough that you think there's an opportunity for a vendor in this category?

Mike Nakhimovich (07:10)

One of them is economies of scale. Getting one dev box is expensive, even from AWS, even at the scale of a Dropbox or an Airbnb. We're trying to be a little more vertically integrated, with bare metal, so we can keep the cost down.

The other one is that it's a moving target. You're going to want Claude Code today. You're going to want Codex tomorrow when the model's a little better. You want to look at what OpenCode is doing. It's all of those integrations and updates and keeping the thing going. If you look at tech companies that have these internal platforms, it's not small teams keeping them going. You can get scrappy at first, and then you have to do all the support. Then you start thinking about Slack, and you want this in PRs as well, and you want it integrated with your CI system. It's no one thing. You start to see that it's closer to building something like Microsoft Office than recreating Notepad.

Stephen Poletto (08:05)

Totally. Constant upkeep.

Mike Nakhimovich (08:08)

And the sandbox. The sandbox thing is another one. You want all the permissions and all the security aspects, and you don't want to reinvent the wheel yourself. Use what others are using, and hopefully we can all standardize on the platform.

Stephen Poletto (08:23)

Makes sense. I know you're early, and you're building this with some early partners. As I talk to our customers and prospects, I see a lot of hesitation in the market around vendor lock-in, going fully into managed cloud agents or Cursor cloud agents or what have you, because of the exact dynamic you mentioned. A new model comes out, there's price competition between the labs and the vendors, and you want some agnosticism and the ability to switch without being locked in. How do you see that dynamic as it relates to Friendly AI? Is that a factor you're thinking about in how you build this for folks?

Mike Nakhimovich (09:12)

Yeah, absolutely. We don't want to reduce it to only the common parts. If something's missing in Codex and exists in Claude, we can propagate that up so you have both in a single pane of glass. But yeah, I think vendor lock-in is very dangerous right now. There's a lot of risk with it.

Developers are cats. It's like herding cats to get us to do anything. Getting folks who used IntelliJ to use VS Code is a tough sell. I know Cursor struggled with that, and I struggled with it when I tried to evaluate Cursor for the roughly 2,500 engineers we had. I think this has to be surface agnostic. It needs to be an API, something that can be headless. There was a lot of power when something like WordPress started going headless and we started thinking about what we could do with CMSs when they're not coupled to a UI. Maybe we'll be changing the engines under it, maybe we'll be changing the rendering. Maybe we'll use voice someday and you won't even need a website. But the fundamental part is that you need to be able to plug in any agent. You need to be able to plug in your tools. It needs to be your auth. You need some kind of proxy so you don't have to log everyone in every time there's a new machine. Having some memory is important.

To give you an example of what you described: we're a small startup, so I still use team accounts on Claude and Codex. My Claude ran out, and it's so nice mid-session to say "switch to Codex." We need a little bit of tooling to make that work, but I'm not losing the conversation, and I don't have to throw away the VM. It's those little moments. Or saying, "Claude, can you delegate to Luna? Luna is cheaper than Haiku, and I know both of them will do the same thing." That mixing and matching, one thing calling something that isn't the same.

In big tech, I found a lot of uses for that. We had everything, so we could use the best of all the tools. You can say, "Claude, why don't you do adversarial reviews with Codex?" But you don't want to set up all those skills and wiring yourself. A lot of this is the interoperability. Plus, OpenCode now has free models, and OpenRouter gives you free models if you sign up. I only explore those because they're in a single interface. Installing all that stuff separately is a bigger hurdle than I want to take on myself.

Stephen Poletto (11:38)

Incredible. So having seen the light and started developing this way, moving agentic workloads off device, what does it enable? If you fast forward and you've got tons of happy customers running on Friendly AI, shifting the way they develop to this cloud-based, remote dev methodology, what does the software development process start to look like?

Mike Nakhimovich (12:10)

For one thing, I don't burn my lap all day from my computer being so hot from running the Codex and Claude desktop apps. They're awesome, but it's a desktop experience. Since switching over, I've had the free time to go for walks, and I can still press "fix" on an agent from my phone. You start to be decoupled from your computer.

It works in both directions. You can run an agent on your laptop and relay it through our UIs, or you can run something in our cloud and see it from your laptop. Multiple people can collaborate with each of these agents, or agents can collaborate with each other. It gives you this agent-by-human graph, so your engineers are doing things in the place that's best for them.

For example, I'm no longer afraid of running migrations. If I see something's out of date and there are 1,000 modules to update, I can go into our Hive UI and say, "Here's one example. Here's how I do it manually. Now do it 1,000 times, but fan out to 1,000 computers." Then I can move on to something else and not have to babysit it.

The other thing it really enables is routines and scheduling. This was a huge miss by me initially, but I see people using it more: being able to trigger something on a schedule, where that schedule actually runs code while your laptop is closed. Or triggering off PagerDuty, or your metrics not looking right in Grafana, and boom, that hits an API that spins up an agent.

I'm kind of not a great programmer. I struggled my way through it. I was always so jealous of the engineers at Dropbox who created Python scripts to run all their stuff. I'd resize an image and think, "Just make a script to resize the image." Having an agent create scheduled routines and tasks for you gives me that same feeling, without the huge barrier of learning how to do it in code. I can say, "I'm working on something today. Schedule a routine for tomorrow to make sure I finish it and there are no dangling PRs open." Being able to tell an agent to do something in the future got all these gears spinning in my head. I don't have to do this now. I don't have to do this synchronously. I can jot down notes and schedules. And the environment it runs in is the same one I'll be working in if I want to go into deep flow and just talk to my agent.

Stephen Poletto (14:43)

That's really interesting. A lot of the development teams I speak with are still in a predominantly synchronous workflow. They might have two, three, or four agents running in parallel, but they're actively shepherding each of those sessions because they're running them on their device, and the agent needs direction. There are interrupts for human attention. Moving to a more async version of development, where workloads kick off from Datadog alerts, cron jobs, all of these asynchronous signals, and then proactively call human attention to where it's needed, is a really interesting shift from sync to async development.

When you think about software engineering: you said you're not a very good programmer, which I think is funny. You might not be a very good programmer, but you're a very good engineer, right? Solving problems for customers.

Mike Nakhimovich (15:51)

I'm very lazy. Yeah. I can solve problems.

Stephen Poletto (15:54)

When you think about what software engineering is going to look like a year or two from now, based on the frontier practices you've seen at Airbnb and what you're doing at Friendly AI, what do you think a typical day looks like? What skills will make people most successful in this new paradigm of engineering? I know it's hard to have a crystal ball with how fast things are moving, but you're at the cutting edge, so you're seeing a glimpse of the future. The future is here, it's just not evenly distributed. So I'm curious what you think the development job looks like a year from now, and what makes people successful at it.

Mike Nakhimovich (16:39)

I think our software development lifecycle is going to change a little bit. It'll be easy for you. You manage people, you delegate, you orchestrate. If I had to guess, I don't think you have any trouble with AI, because you're used to giving someone a task, hoping they do it correctly, and having some kind of validation loop to check it yourself.

I see the software development lifecycle switching to four modes. First, we're defining work. You could be defining work with a human or an agent. You can have another agent do your adversarial reviews or do research for you. You're in this defining-work mode where you're specing things out or setting goals.

Second, there's an observe mode. That's the one you're describing. I have an inbox, and things are pushed to me. We're no longer pull, we're push.

From there, I'm steering. Steering is looking at those systems while they're live and saying, "This isn't going the way it should. I need to tell the agent to do something." Maybe 20% of tasks we can one-shot into a magical slot machine solution, but for most of them you're going in, giving feedback, telling it to fix something or do something differently.

The last one is verify. Are we code reviewing it ourselves? Do we have agents doing it? Is it a process? Is it a human?

I think we're going to keep moving between these four modes. I'll define some work, observe it, steer the ones that need it, verify the ones that are done. Once I'm done verifying, let me see if anything else needs steering. Once I'm through that steering queue, maybe I'll define some more work. I think of it as four buckets that I keep balancing work through.

Right now, it starts with me doing a lot of it as a human. But over time, I start replacing some of the gates and questions I used to handle as a human with AI. We always did this as developers, even without AI. Maybe we used to release manually, and now it's on a schedule every four hours. I know we say we're working synchronously, but I don't think there are a lot of developers out there who ever really worked synchronously and didn't have at least two PRs up at a time, checking on them and going back to them.

So I don't want to reinvent how we code. I want to take what you're doing, write down the process you've been following, and then think about which of those buckets you can put AI in. Then with Friendly AI and Hives, we want to build the tools. You want pull requests automated? Sure, you can do that. You want planning automated? Sure. It's that handoff, the same way you'd hand something off to a contractor. So I think the folks who do best with this are the ones who can delegate, work with others, properly define a problem, and validate a result once they get a solution.

Stephen Poletto (19:28)

Very interesting. As you were describing that, I was thinking there's a lot of overlap with traditional software engineering management. You divvy up deliverables and delegate them, you want a way to check status and see whether things are on track or off track, and ultimately you want to verify a good job was done.

But I don't know if you've read the famous Paul Graham essay, Maker versus Manager. I really like that essay. He talks about how a manager's schedule is super fragmented. You're context switching between a lot of things, running from one meeting to the next. Historically, the software engineering calendar has been: I'm going to go deep on a certain problem and spend several hours in deep work mode. Do you see that changing? Are engineers going to be context switching and parallelizing a lot more, and operating more like managers did in the past?

Mike Nakhimovich (20:32)

I think it's going to be... I'm a bit of a Marvel fan. I don't know if you saw the Loki TV show?

Stephen Poletto (20:37)

I haven't seen it.

Mike Nakhimovich (20:38)

It's pretty good. They had timelines, and the timelines split. It kind of explains the multiverse. I think it's going to be more like that.

I sit down and start with a single task. I want to redesign an action bar in Android; I want to animate it down. As I'm deep working with my agent one on one, I notice my Git is slow. So I say, "Hey, side quest. Another agent, take over that work. I'll see you later." As I continue working and validating, the validator finds a few bugs and automatically logs Linear issues. Once those Linear issues get logged, they trigger something that automatically creates sessions to try to fix them and sends me an inbox alert: "Hey, this thing's being fixed."

I think it's going to look closer to that, where you keep going wider and then coming back together as you work on tasks. It's like we started splitting work into stacked commits, but rather than a stack, I see it almost like the Olympic rings. They overlap a little, but generally you can now split work and parallelize it rather than having to keep your own notes.

What I notice for me is that I don't have much of a backlog. I use Linear for automation, but I never log an issue anymore. I just write a prompt, give it to an agent, and tell it to go solve it. I haven't found a good reason to backlog something.

Stephen Poletto (22:04)

It's either worth the tokens to do now or not, right?

Mike Nakhimovich (22:07)

Yeah. Or I schedule a routine, give it the prompt, and say, "Do this in a month." But keeping it external to the system doesn't make sense to me anymore. I can now infinitely scale out to at least make a first attempt on a task. Then we get to good practices: start small, or moonshot it first, and if that doesn't work, make it smaller, have it fan out, try different models. But generally, it's the ability to get a second or third person, to clone yourself out. That's the new magical workflow that I think makes it happier, easier, and more fun than synchronous AI used to be.

Stephen Poletto (22:47)

Makes sense. This is a really fun conversation, speculating about what the future could look like. You brought up ticket management. Historically, there's been some source of truth for work to be done, either roadmap and specification documents or a ticketing system, where you've got your epics defined in Jira. What do you think becomes the system of work in this future? Is one of the aspirations of Friendly AI to be the place where people orchestrate all of this?

Mike Nakhimovich (23:25)

We're going to be the place where you orchestrate it, but I don't think the policies and processes are going to be ours. What we do internally (and we're landing 50 to 100 PRs a day) is keep a lot of Markdown files in the repo. We keep evidence files, specs, requirements, and goals, and any new agent that starts validates against what's already been written. It's almost like an OpenClaw setup with your memories of what everything is related to. Everything is written down. We keep screenshots of every change, and videos as evidence for anything we can record.

It's free now to do all that. It's free now to write every test. Free in the sense that it's not your brain power doing it anymore. I think we should lean more into over-documenting and keeping those audit trails, because they come in really handy now that agents are reviewing the code. They can look back at the evidence files, the goals, and the specs, and make sure something didn't go off the rails.

Stephen Poletto (24:28)

And you're thinking of that almost as your agent memory system: an expression of decisions and verification ledgers, all in the repo as Markdown for future agents to consult.

Mike Nakhimovich (24:41)

I keep it in the repo. I know some people use Obsidian vaults. You can keep it as external documentation, but Google Docs doesn't seem to work well for this. I think something like Dropbox Paper or Obsidian is the right fit. You need to be able to search through them and pull out various parts. It should be Markdown, it should be human readable. I think that works better than keeping docs in Google and then having to figure out where the design docs are.

Stephen Poletto (25:10)

Makes sense. Maybe one more question on this, because it's a theme that's very interesting to our audience: how do you cultivate that company brain and store the right decision records so future agents are more effective? How much of an active role do you play in shaping the layout of that documentation and how it's progressively disclosed, based on what work is being done by which agent in which part of the codebase? What does your memory management system look like?

Mike Nakhimovich (25:47)

I'm not great at this, but I think I'm further ahead than 99% of people. The people who are actually good at this are really good at it.

Anytime I start a new project, I pass my agent OpenAI's blog post on harness engineering, about how they built their harnesses, and tell it to research how other harnesses and harness engineering are currently working. I also pass it Anthropic's blog post on the AI SDLC and tell it to set things up. That's where all these evidence files and structures come from. Along with that, it sets up routines that run every two to four weeks, audit PRs and whatever else has happened, and update these files as they go.

I've never actually touched it by hand. Every time I do this, it's slightly better, because the research it can do is slightly better. I understand it about as well as I understand compilers. I know there are folders, I know there's evidence, I see it in the PRs, but it's not something I ever manage by hand.

Stephen Poletto (26:48)

Interesting, very cool. Thanks for sharing your journey, what you're working on, and how you see development evolving. If people want to follow along, where do they find you?

Mike Nakhimovich (27:03)

I'm not on Twitter anymore. Unfortunately, I used to work there as it went down, so I'm still in breakup mode. I'm on LinkedIn. We're going to post updates on FriendlyAI.dev, and we're spinning up a blog. We do have signups open right now. You can sign up and grab an account. It's all free until next year, and it gives you unlimited sandboxes to run your Claudes and your Codexes and all that.

Stephen Poletto (27:27)

Very cool. Hopefully people will come check you out. Mike, thanks so much for the time. This was a fun conversation.

Mike Nakhimovich (27:31)

Yeah, thank you. Till next time. Bye bye.