What Makes an Engineering Team AI-Native? People, Projects, Platforms, Processes

Almost every engineering team now uses AI somewhere. Very few have been redesigned around it. That gap is the subject of a recent letter from Andrew Ng, founder of DeepLearning.AI and co-founder of Google Brain, who speaks regularly with engineering leaders and boils his advice down to four words: People, Projects, Platforms, Processes.

This article takes his framework and checks it against the evidence: McKinsey's 2025 global survey, the first DORA report on AI-assisted software development, the Stack Overflow Developer Survey and a randomized controlled trial from METR. The result is less hype than you might expect, and more practical than most “AI strategy” advice.

AI-assisted is not AI-native

Ng draws a clear line. The goal is not a traditional engineering team that happens to use AI. It is a team that is designed to take advantage of what AI can do and to work around where AI gets stuck. With a brand-new team of two or three people you can hire AI-native engineers from day one. Most companies cannot, so they have to move existing teams forward.

The wider data shows why the distinction matters. McKinsey's 2025 survey found that 88% of organizations use AI in at least one business function, yet most have not embedded it deeply enough in their workflows to see material enterprise-level benefit. Of 25 organizational attributes it tested, redesigning workflows had the biggest effect on whether a company saw financial return from AI. Not budget. Not talent. Not which model they picked.

Using AI is common. Redesigning work around AI is what separates the teams that profit from it.

If you want the adoption-curve view of the same problem, I wrote it up in Where Is Generative AI on the Diffusion of Innovation Curve?. This piece zooms in on the team that has to do the redesigning.

1. People: proficiency beats policy

A team is made of individuals, so an AI-native team needs individuals who are good at AI engineering. Ng's advice to leaders is concrete: give people space and budget to experiment, and build a culture where that growth is expected rather than tolerated.

He adds a point many leaders skip. You cannot learn what steering a coding agent feels like by watching someone else do it, just as you cannot learn to ride a bicycle from the pavement. Leaders who build their own small projects develop intuitions that improve both their technical and their business judgement.

The developer data explains why intuition matters. In Stack Overflow's 2025 survey, 84% of respondents use or plan to use AI tools and about half of professional developers use them daily. But more developers distrust the accuracy of AI output (46%) than trust it (33%), and only 3% say they highly trust it. Nearly half say debugging AI-generated code takes a lot of time. The skill that counts is not prompting. It is knowing when to believe the output.

METR's trial makes the same point with numbers. Sixteen experienced open-source developers completed 246 real tasks in repositories they knew well, with AI allowed on a random half. They expected a 24% speed-up. They took 19% longer, and afterwards still believed AI had made them about 20% faster. When AI was allowed they spent less time coding and more time prompting, waiting and reviewing.

The honest caveat: the METR authors are explicit that this result belongs to a specific setting. Experienced people, large mature codebases, early-2025 tools, and many participants new to the main tool. They do not claim AI never helps, and one participant who knew the tool well saw a large speed-up. Read it as a warning against assuming, not as a verdict against AI.

2. Projects: back a few, and include growth

Ng still argues for bottom-up innovation, where people try ideas themselves. But he adds that a handful of promising projects need top-down backing to scale and show business impact. Engineering leaders who understand AI better than other business functions are well placed to help pick them.

His sharpest point is about ambition. Too many companies still see AI mainly as a way to save cost. It can do that, but he argues the larger opportunity is new products and new ways to serve users, which drives growth. So the project mix should include some growth bets, not only efficiency work.

• Let people experiment bottom-up, with a small budget and no approval queue.
• Choose a few projects to back from the top, with named owners.
• Make sure at least one project aims at growth, not only savings.
• Define the business metric before the build starts.

3. Platforms: make your context agent-ready

An agent is only as useful as the context it can reach. Ng's platform layer is about making that context available safely: data organized so agents can find what they need, repositories visible to agents, design decisions and support tickets documented where agents can read them, and internal tools built for agents to call. All of it with appropriate security and governance.

Around that sits the delivery machinery: AI code review, CI pipelines that help agents debug and deploy, sandboxes for agents to run in, and a way to codify and share reusable agent skills. For some companies the first step is simpler and harder at once: persuading leadership that developers can stop coding exclusively by hand. That too, he notes, is progress.

The 2025 DORA report, the first one dedicated to AI-assisted software development, backs the idea that this is a systems question. Its central finding is that successful AI adoption is a systems problem, not a tools problem. It introduces a model of seven capabilities that amplify AI's effect, and warns that local productivity gains can turn into downstream chaos if the rest of the delivery system is not ready for them.

For teams in Germany and the EU, governance belongs here from the start: which data may an agent read, who reviews what it produces, and where are decisions recorded. Obligations for providers of general-purpose AI models under the EU AI Act began applying on 2 August 2025, so accountability is part of the platform, not a later add-on.

4. Processes: follow the bottleneck

Here is the logic that ties the framework together. The cost of building software to a clear spec has fallen sharply. That makes everything else look slow by comparison: deciding what to build, designing it, explaining it to the market, getting it reviewed.

In an earlier letter on AI-native teams, Ng gave examples. A team can build a feature faster than marketing can work out how to describe it. Or it can build software in a day that legal needs a week to review. His response is to form teams with high context and high empowerment: they have the information they need and the authority to act, with modest safeguards against serious risks such as leaking confidential data, a major outage or data loss.

Generalists over hand-offs

In a team of two to ten, a product needs engineering, product management, design, marketing and legal input. With fewer people than functions, each person must cover more than one role. Engineers pick up product sense; product managers learn to build.

High context, high empowerment

People who understand the product deeply can decide across functions instead of escalating every question up a chain.

Safeguards, not gates

Light guardrails for the real risks: confidential data, outages, data loss. Everything else moves at team speed.

Agents that share context

Coordination between teams is the old problem. Getting different teams' agents to share information with each other is a promising direction, though practice is still emerging.

Reporting on how leading AI companies work points the same way. According to the Engineering Leadership newsletter, OpenAI's Codex team has engineers own projects end to end, and Anthropic's teams run without a dedicated QA role while handling several projects at once. Treat those as examples to learn from, not templates to copy: they are companies building AI products, which is a different job from yours.

Where to start on Monday

Ng's letter is a framework, not a checklist. This is my own synthesis of how I would turn it into a first month, combining his four layers with the evidence above.

1. Pick one real workflow and record a baseline: cycle time, review time, defects. Without a baseline you will only have feelings.
2. Give a small team time and budget to rebuild that workflow with agents, and ask the leader to build something too.
3. Make context reachable: decision records, tickets and code in a form agents can read, behind proper access control.
4. Add guardrails early: automated tests, AI-assisted review with a human owner, and no secrets in prompts.
5. Measure again, then find the next bottleneck. It will probably be outside engineering.
6. Fund one growth project alongside the efficiency work.

What this means for small and mid-sized teams

Most European businesses do not have an engineering organization the size of a big-tech lab. For them the useful part of the framework is the small-team logic: a few people with high context, working end to end, with light guardrails and a clear business metric.

That is also how I approach my own work: build the working system, show the team how it runs, and leave them able to own it. If you are deciding where AI fits in a team or a workflow, my services page explains how I work, and you can follow what I am learning in public on the Learning Journey.

AI-native is not a tool you buy. It is a team you design.