What it means to be a truly AI-native software company
Everyone says they’re rebuilding their company in an AI-native way. But what does that mean? Most companies look at what their existing employees do and try to automate it with AI. That’s not it. That’s dabbling. A truly AI-native company rethinks every role and tears down the walls between them. None of us can 8-ball this but here’s my sketch. It’s not exhaustive but hopefully it sparks something: The QA team typically finds bugs and dutifully files them in Jira. Engineering has finite capacity, so they fix the P1s and freeze the rest. P2 and P3 bugs die in the backlog — the UX nits, the copy, the small fixes. An AI-native QA team files the bug and immediately points an agent at it. The agent takes a first pass, finds a root cause, proposes a fix, and opens a PR — then sends a test build right back to QA to verify. Along the way the bug is updated in detail, so if it needs escalation to the engineer who built it, all the context is right there. A more advanced team has a loop wired to trigger the minute a bug is filed. A PM understands the business and goals well. They write a thoughtful PRD — but it’s often 70% done. How are they to keep the full codebase and every edge case in their head? The engineer starts building, hits those edge cases mid-feature, and bounces it back to the PM who has better intuition. Tweak the PRD, back to the engineer. This can happen for every slice of that remaining 30%, and it’s frustrating for everyone. An AI-native PM sends an agent to walk the real code, surface those forks up front, and spin up throwaway prototypes to explore each one. They keep a knowledge base of past decision briefs so the team doesn’t rebuild what was already ruled out. With that in hand, they produce a fully specced PRD — and maybe pushing further, include end-to-end tests defining what done looks like. Designers mock up screens in Figma and ship them over, hoping what shows up in production matches their pixel-perfect specs. Realistically, how often does that happen? When they run user research studies or are testing the app, they find plenty of design nits, UX failures, and copy suggestions — then file tickets and wait. An AI-native designer prototypes variants on the real app with real data and real states. They get to play with throwaway builds of the actual codebase and can design towards a stronger, more realistic spec — with real constraints, like how that animation actually runs on an Android 12 device. Polish-related work doesn’t die in ticket wasteland anymore. It runs through the same loop QA uses: the agent makes the change and preflights a build for the designer to check by eye. They have the taste, and now the agency to ship it on the spot. Data scientists live downstream, so they feel every change last. They’re often looped in at the end, when the feature is mostly built and engineers need to tack on the instrumentation. Or worse, they discover engineering renamed an event in a refactor and mission-critical dashboards quietly broke in production — caught days later, when the build is already out. The old move: file a ticket and wait for engineering’s queue. An AI-native data scientist reaches for an agent instead — tracing a break to a renamed event and sending the fix as a PR, or instrumenting a metric they couldn’t measure yet without waiting on anyone. Pushing further, the old way to test a hypothesis was to ship, wait for real data to accumulate, then lean on engineering and product to make changes. An AI-native data scientist runs the test before anything ships — generating synthetic data and simulating scenarios with agents to show the PM which option wins, then putting up the winning approach as a PR for engineering to review, tweak, and ship. If you noticed a trend above, we’re distributing a lot of what engineering typically does to other roles. So what’s left for engineers? Plenty. I see three roles emerging: Product engineers : If I’m being honest, the line between this role and the AI-native PM blurs — eventually converging. I’m not saying engineers become PMs or PMs become engineers. I think both are heading toward a “product specialist” role: highly opinionated people who understand the product so well that they can take an idea to a live feature in days. System engineers : The platform watchers. They ensure the codebase is healthy, understand the infrastructure constraints, and make the judgment calls on how the architecture has to evolve. When there are five ways to build something, they pick the one that won’t hurt later. Loop engineers : I think this becomes the generalist SWE role. These are the people who build and maintain the loops for every other role: the inboxes, the triggers, the verification gates, the escalation paths. QA, PMs, designers, and data scientists shouldn’t be wiring those connectors — they should be doing the work described above. When the walls between roles come down, the loop engineer is the load-bearing structure. I went deep on the mechanics in loop engineering . It’s real engineering work, and someone has to own it. Bolting AI onto the jobs we already have isn’t how you build an AI-native software company. You have to rethink the roles and tear down the walls between them. Product engineers : If I’m being honest, the line between this role and the AI-native PM blurs — eventually converging. I’m not saying engineers become PMs or PMs become engineers. I think both are heading toward a “product specialist” role: highly opinionated people who understand the product so well that they can take an idea to a live feature in days. System engineers : The platform watchers. They ensure the codebase is healthy, understand the infrastructure constraints, and make the judgment calls on how the architecture has to evolve. When there are five ways to build something, they pick the one that won’t hurt later. Loop engineers : I think this becomes the generalist SWE role. These are the people who build and maintain the loops for every other role: the inboxes, the triggers, the verification gates, the escalation paths. QA, PMs, designers, and data scientists shouldn’t be wiring those connectors — they should be doing the work described above. When the walls between roles come down, the loop engineer is the load-bearing structure. I went deep on the mechanics in loop engineering . It’s real engineering work, and someone has to own it.
Business
AI
Open Source
Tutorial
Shell
Programming
DevOps
Rust
Python
Career
Java
Kotlin
Machine Learning
Mobile
Hardware
Android
C++
Security