Pinned Tweet
I am assembling the React Native Dream Team
The 1991-1998 Chicago Bulls of React Native teams
You'll be working alongside the most cracked engineers of your career
Harvard Business Review will write a case study about this team
The @Backpack app will be regarded with more reverence than the moon landing
DMs open. Remote OK
People are building the most radical things with AI and all I'm thinking about is hardening our company's engineering processes 😭
It makes sense that folks who aren't deeply entrenched in React Native or Expo think it's the end of an era.
They've probably never met the all stars behind the stack, or they've fallen for AI psychosis from their vibe coding peers.
Today is the worst RN will ever be.
What happens when you take a bunch of deeply experienced devs who've spent years working on both native and React Native, hand them an unlimited token budget, and tell them to rip?
They'll come up with something we've never seen before. These teams don't sleep.
Maintaining RN w/o agents was already brutal and they still managed to ship something great.
Now they've got the Death Star superlaser pointed at every perf bottleneck in the stack.
Hard to bet against these people.
This morning's agentic workflow. Claude insists I review every Linear ticket it updates so I just had Codex do it
Feels like the right time to create a new secret domain and isolate all of my important accounts to it
Frontend peeps were built for the new agentic era. This is our moment.
Over the last 15 years we’ve migrated entire companies to a whole new flavor of JavaScript at least 5 times
We went from PHP/Laravel to a Next.JS app with at least 12 different services we had to sign up for just to get that “hello world” route up and running
Agents are nothing
Personal Software Factories are a waste of precious time
It's so natural for a software engineer to want to build their own software factory. But I would implore you to abandon that idea immediately. I'd argue it's the last thing you should spend time on, unless it's for work, at least for now.
The tough pill to swallow is that we've entered an era where everyday non-devs are applying AI in mind blowing ways and you still haven't built shit. Many of these ideas are just demos on X, but that's still better than just a system for building software.
I can see why you'd want to build one though. It's close to what you've always been good at, and it feels good to stay in your comfort zone.
It's also the first thing that naturally comes to mind: if I can build this factory, I can build more side projects and eventually quit my job! But a software factory is just an extension of what you've always done: start projects, give up on them and go back to work on Monday.
I'm not saying you should stop exploring and building side projects. I'm just saying you should stop wasting time on your factory. Just type into the chat box and see what happens.
Having AI build your app doesn't take away all the frustration. The frustration is just different: miscommunication, building the wrong thing, building the thing you thought you wanted and getting it wrong, etc.
That's all part of the building process. It's also why you like feature-free rewrites to begin with, because you already know what the end result is. When you build a real product, the end result is nuanced and there is no end.
I still think you should learn how tools like Grok Bot or Claude work. They are amazing. Maybe you shouldn't, idk, but I am. At the very least, learning how they work has stopped me from trying to build another factory.
The frontier labs are working on both models and products, and the models get better based on the user's experience of a product. The labs' number one goal is to remove friction and let you build cool stuff. I'm having a hard time competing with that. Why would I even want to?
If you're still convinced you should build a software factory and think I'm an idiot, it better be for work. Your job is the most realistic scenario you can be in when it comes to automating away your job. You understand the system deeply (or should), and it has humans, timelines and years-old messy systems.
You probably have 12 different patterns for writing the same feature and 100 different edge cases. That's exactly why building one at work would be useful. The challenge is a much harder one, but so is the reward.
You've now empowered an entire team of product managers and designers to ship features with little friction and high trust. From there, your job is to maintain that platform or even apply your other skillset to other parts of the business.
If you can't come up with something to build besides a software factory, you're not the only one. This is actually a very hard task, and it's a muscle that needs to be developed just like anything else.
Take a look around you. Start writing down your problems. Start writing down ideas. Let your mind wander. If you write down 3 ideas every day, the first 30 ideas are going to be so silly and useless, but I guarantee that will start to change as your brain starts to think differently.
Did you see that guy who de-slopped his parent's Android TV using Claude? That's nuts. He saw a problem and used Claude to come up with a solution.
What about the guy who put that fruit fly brain into the real world, where it's been flying around? How does someone even begin to come up with stuff like this? I don't know, but I'll eventually get there myself through experimentation and letting my mind wander.
Anyway, don't build a software factory.
Verification and trust are everything. It is a hard problem to solve and requires a lot of effort from the team to get there.
Give your agent a way to verify its work. This can dramatically improve the quality of output.
With this process in place, Claude Code was able to write 90%+ of its code itself. When generating software at a faster rate than you can review it, the bottleneck shifts to proving that it works. @bcherny and team invested enough in verification, we've been able to move fast while maintaining stability.
Code reviews aren't going away, but you need to think of it differently. One human reading through line-by-line is no longer going to work as a gate, it needs to evolve into a multi-layered verification system, built with fast deterministic feedback loops for your agents.
This is where e2e tests, feature maps (as @poteto has been advocating), property tests and multi-agent adversarial reviews come in. These all provide opportunities to catch errors early and fix them before things get out of hand.
You don't have enough eyeballs for the amount of code being written so your focus needs to be on product intent, risk assessment and evaluating evidence rather than reviewing code. Delegate the code checking work to your automated tests, scale your approvals based on risk, and turn your test failures into living evaluations. This approach helps maintain speed without losing reliability.
Let the agents do what they do best and let you focus on what makes you irreplaceable: judgement, direction, and ownership. We tried to capture how we handle code review and verification in this writeup. Hopefully it's helpful.
“At our current rate of change, there is still an incredible amount of work for humans to do, and our team encounters new and novel challenges almost daily.”
Claude writes about 90% of Claude Code's code.
From June to September, merged PRs more than doubled while the share reverted fell by more than 40%.
We wrote about how we changed code review to get there, and how to adopt it:
claude.dev/blog/solving-code…
Whatever the Grok Bot engineering team is doing is pure magic
I know ppl say I shouldn't learn how always on agents work and instead just focus on spending tokens, but this the tech is incredible
How it works under the hood
@leerob's talk on how always-on agents like Grok bot work is world class.
I went deep on it and wrote an article covering the systems engineering, plus my best guesses where the talk leaves gaps.
Watch the talk. Then read this.
I'm now convinced that a projects UI with a solid model router are the future of software factories
I just send messages with feature requests. Each message gets processed, model gets decided, worktree gets created, job gets accomplished
Been working on a new detection stream for my Tapo cameras. They ship with pet and person detection but I think adding “code on screen” detection would be extremely useful in today’s economy
The last thing anybody should have on their screens is code. Having a monitoring system to prevent that will be useful