· 2 min read

The company we are building

In two weeks our product manager shipped more pull requests than anyone on the team, having barely written production code before. What that changes about who builds, and why engineering still owns the guardrails.

Our first hire was a product manager. She came from a computer engineering background but hadn't really written production code before.

She spent the first couple of weeks getting familiar with the product and how we work. Over the last two weeks, though, she's probably contributed more pull requests than anyone on the team — including the one that shipped document uploads, so a customer can send a file straight into the platform.

That happened because we're trying to build a different kind of company.

Until recently, every company was organized around one constraint: only a small group of people could actually build software. Work had to move from one function to another until eventually it turned into code.

AI changes that.

Now someone can understand an issue in the morning and have a pull request ready by lunch. The hard part is knowing what to build.

For us, titles define responsibility, not authority. Sales still owns sales, design owns design, and engineering owns whether the system stays healthy. But anyone who sees a problem and thinks it through should be able to help ship the solution.

Our PM didn't suddenly learn how to code. She expressed her thinking through AI, and AI handled much of the implementation. That changes what we should expect from people. I think the people who will thrive in an AI-native company will be the ones who spend more time thinking deeply about the problem. What are we actually trying to solve? What should we build? What does good look like?

The implementation can increasingly be handled by AI. The thinking still needs to come from us.

Engineering discipline matters more than ever because of this. Tests, architecture, reviews, agent instructions, and all the other guardrails are what allow everyone else to contribute without breaking the system. Engineering still owns that responsibility.

This isn't a philosophy we're writing down after the fact. We're trying to practice it from day one.

The platform we're building is meant to help companies become AI native. So it feels obvious that we should try to be one ourselves.

We don't want to build one way and work another. We want our own company to run on the product we're building. Every workflow that can run on our platform should run on our platform. We want to be our first customer and learn from actually using the system every day.

If we believe this is how companies will work in the future, then our company has to be the first case study.

That's the experiment we're running.