Designing the AI-native engineering organization

This post was originally published in Engineering Enablement, DX’s newsletter dedicated to sharing research and perspectives on developer productivity. Subscribe to be notified when we publish new issues.

In an opening session at DX Annual, Abi hosted a discussion with Tim Bozarth (CVP, CoreAI at Microsoft), Nancy Wang (CTO, 1Password), and Taroon Mandhana (CTO of AI & Teamwork at Atlassian) to learn how they’re adapting to the impact AI is having now and in the future. The panel covered topics such as org design, managing costs, and how the developer role is changing.

Below is a lightly edited excerpt from the discussion. You can watch the recording here. Stay tuned for the full DX Annual recording library to be released next week.

What does an AI-native SDLC look like?

Tim: If we use a five-stage frame: plan, create, validate, deploy, operate. Create is already changing. AI is incredibly good at writing a line of code. Whether it’s good at building complex systems remains to be seen. Historically, roughly 80% of engineering time goes to operate, 10 to 15% to create, and the remainder splits across plan, validate, and deploy. In the most effective teams, that’s inverting: plan and validate now consume the majority of time, because create and operate are compressing. Those are the stages where humans are tastemakers, where understanding of craft matters most. But don’t delegate validate to AI yet. We still need humans in the loop for important systems. And don’t delegate security to AI. Use it for pen testing, use it for red teams, use it to battle-harden your system, but don’t trust it to deliver secure products on its own.

Nancy: We’ve stopped writing full-length PRDs at 1Password. Teams build prototypes and put them in front of customers instead. That’s eliminated almost half of the back-and-forth where engineering asks product, “How do you handle this edge case?” You’ve already answered that during the plan and validate phase. But think about the SDLC as a pipe: adding more to the front means you add more to the back. More makers writing PRs means more code reviews, more reliability and maintainability work. We’re running an experiment with a reinforcement learning lab to build a DevOps agent customized to our environment, trained on real incident data and how our engineers respond. The goal is to delegate a significant portion of operate to an agent.

Taroon: The area with the most untapped potential is operate. Our engineers spend an insane amount of time responding to alerts, customer issues, and incidents. We’re seeing agents start to respond to alerts and only wake up a human if it’s real. Post-incident reviews are getting automated. 50% of simple vulnerabilities at Atlassian, things like library version bumps, are now resolved using AI. Accessibility bugs that were taking a backseat are getting done much faster. A lot of this is being run in the background by central dev infra teams to give time back to engineers.

Has AI changed how your engineering orgs are structured?

Taroon: We haven’t restructured the org. What’s changed is how teams form. For zero-to-one projects, we’ve moved to squads of 3 to 4 people. That would have felt too small a year ago, but AI has compressed the building part enough that the bottleneck is now alignment and decision-making. You don’t need 8 engineers when 3 can move faster, as long as they have the context and the authority to make calls without waiting on a chain of approvals. The org chart looks the same. The way work actually happens inside it looks very different.

Tim: Similar story. We haven’t redrawn boxes on an org chart. What we’ve done is shift to eight-week cycles with small, mission-specific v-teams. The point of those teams isn’t sustained delivery. It’s speed of learning. You form a team around a specific question, give them 8 weeks, and then decide whether to continue, absorb the work into a larger team, or stop. That cadence lets us stay responsive without constantly reorganizing.

Nancy: At 1Password, the biggest shift has been in planning horizons. We used to plan 12 to 18 months out. Now we’re down to a single quarter. When the tools and the capabilities are changing this fast, anything beyond 90 days is guesswork. That compression hasn’t required a reorg, but it has required a completely different operating rhythm from leadership. You have to be comfortable making decisions with less certainty and revisiting them more often.

Do any of your organizations mandate AI usage?

Tim: No. We track daily active AI use across Microsoft, and we invest heavily in enablement, training, and incentives to make adoption easy.

Activity is a diagnostic signal. If adoption is low in a particular team, that tells us something is blocking them, and we go figure out what it is.

Taroon: Same philosophy. We have a central team that ensures easy access to tools and removes friction from onboarding. Beyond that, what’s worked is organic champions. In groups of 100 to 200 engineers, someone naturally emerges who’s excited about this stuff and starts showing others what’s possible. We amplify those wins across the company. That’s been far more effective than any top-down mandate.

Nancy: We built a guild of AI champions at 1Password. The thing that actually moves adoption is celebrating concrete examples. When someone uses AI to pull a launch date forward by two weeks, and you tell that story publicly, it does more than any mandate ever could. People see the result and want to figure out how to get there themselves.

How are you managing AI costs?

Taroon: I’m on my third budget forecast since January. Token costs are volatile, and the models and pricing are shifting underneath you constantly. It’s the hardest part of financial planning I’ve dealt with in a while. We literally started to think about managing it like AWS COGS cost because it requires that level of rigor and sophistication.

Nancy: We built an internal SaaS cost management tool that maps token spend by repo and project. Without that visibility, you’re flying blind. That lets us map token spend back to intent, so we know what tokens are actually being spent on. We’re also looking at guardrails and abstractions, like mapping token usage by build volume to a CI automation service, so if something goes out of whack, you can catch it. Having frameworks and hypotheses about how tokens are being spent in your organization can prevent surprise conversations with your CFO. My recommendation to other leaders: negotiate forward-projected commitments with your model providers. If you can commit to volume, you can significantly reduce your per-token cost.

Tim: One thing I’d add is that not every token needs to produce direct value. Some of this spend is learning and experimentation. The fastest learners will win, and that means we are going to spend tokens on things that do not create value, but they create learning amongst the workforce. Teams need room to try things that don’t immediately pay off, and leaders need to create headroom for that when they’re reporting to boards.

How do you define the skills profile of a great engineer 3-5 years from now?

Tim: Projecting three to five years out right now is hallucinating. What we focus on is what’s durable. And the pattern we see consistently, inside Microsoft, with our customers, in the startup community, is the maker’s mindset. You’re not attached to a specific tool. You’re oriented toward an objective, toward building something that creates a business outcome, and you drive toward it with whatever you can. That’s what we’re looking for in new hires and encouraging in existing engineers through how we structure incentives, rewards, and how we talk about the speed of experimentation and learning.

Nancy: I’ve shifted between product and engineering roles throughout my career, and the lines between them are blurring fast. What I’d look for is generalists with strong product instincts. The best advice I give new grads right now is to try to span the entire product development lifecycle through the software development lifecycle. Don’t specialize too early. The engineers who are seeing the most impact from AI are the ones who can move across codebases, work across craft, and operate at a higher level of abstraction. They’re not just writing code faster. They’re making better decisions about what to build and how to ship it, because they understand the full picture.

Taroon: I’d add that agency is becoming as important as technical depth. The willingness to step up, have the right conversations, and make decisions without waiting to be told. When AI compresses the time it takes to build something, the differentiator becomes the person who can figure out what to build next and move on it. That’s not a technical skill. It’s a disposition. And it’s something we’re starting to look for explicitly in how we evaluate engineers.

Where are the boundaries when non-engineers contribute code?

Taroon: Designers at Atlassian are submitting PRs. That’s real, it’s happening today, and it’s genuinely useful. The fidelity of early conversations has gone up dramatically because instead of debating a static spec, you’re looking at something interactive. But I want to be honest about the friction. Engineers are escalating daily about quality issues in those contributions. Prototyping by non-engineers is a clear unlock. Shipping to production is a different bar. The teams that are most comfortable accepting contributions from non-engineering roles are the ones with robust test suites and deployment checks already in place. If your right-of-code processes are weak, AI-assisted contributions from anyone, engineers included, are going to cause problems.

More broadly, we’re seeing patterns of duplication and tech debt increasing as people quickly produce features. The maintainability of the code is suffering. It’s prompted us to go back to standardized approaches and more right-of-code quality checks.

Nancy: Our CX associates are now generating PRs for front-end test coverage across browsers and mobile clients. These are people who know the product deeply from a customer perspective, and they’re using AI to translate that knowledge into actual test code. Engineering’s role has shifted. Instead of writing those tests themselves, they’re building the testing harnesses and review processes to evaluate the contributions. It’s a different kind of engineering work, but it’s just as important, and arguably higher leverage.

Tim: There’s a second dimension to this that I think gets overlooked. Yes, more people can now take an idea in their head and turn it into something you can interact with. That’s the prototyping side. But the non-engineers who are getting the most out of AI aren’t contributing code to products. They’re using it to optimize how they work: how they gather and distill information, how they communicate, how they run their own workflows. That doesn’t go to production in the traditional sense, but it goes to production in how the business operates. And that’s happening right now.

You can listen to the full discussion here.