Meta Engineer Says He's Now Shipping Code He Doesn't Fully Understand

A software engineer at Meta has said publicly what many developers have only hinted at: he is shipping code he doesn't fully understand.

In a LinkedIn post this week, Ali Hamie wrote that he has never felt as uncomfortable in his job as he does now. AI tools have sped up development so much, he said, that reviewing every line would slow his work to a crawl. He understands the systems he builds at a high level, but he can no longer account for every detail of how the code works.

He said that runs against his instincts as an engineer. "I'm used to understanding what I'm building," he wrote. He is now trying to work out how much understanding is enough before he moves on, and he ended the post by asking whether other engineers feel the same way. Going by the available industry data, plenty of them do.

What Meta is asking of its engineers

Hamie didn't name a project or team, and he didn't say his code was failing. His comments do come against a backdrop of open pressure inside Meta to write more code with AI.

In March, Business Insider reported on a set of internal targets at the company. Meta's creation organization, which covers Facebook, WhatsApp and Messenger, set a goal for 65% of its engineers to write more than 75% of their committed code with AI tools in the first half of 2026, according to People Matters' summary of the report. The company's Scalable Machine Learning group set targets of between 50% and 80% AI-assisted code. Employees were also encouraged to describe their AI use in performance self-assessments.

Meta isn't an outlier. Sonar's 2026 State of Code survey of more than 1,100 developers found that 42% of committed code is already AI-generated or AI-assisted, and respondents expect that share to reach 65% by 2027. When a model can produce in minutes what used to take a day, the person reading each line becomes the slowest step in the process. That is where Hamie says he finds himself.

Developers don't fully trust the code they ship

The same Sonar survey found that 96% of developers don't fully trust AI-generated code to be functionally correct, yet only 48% said they always check it before committing (Sonar). Another 38% said reviewing AI-written code takes more effort than reviewing a colleague's work. AWS CTO Werner Vogels has called the gap "verification debt".

Stack Overflow's 2026 Developer Survey, released earlier this month with more than 30,000 responses, found much the same thing. Nearly half of respondents said they trust AI output when they can verify it, and just 6.6% said they would trust AI with an important decision.

So engineers trust AI-written code roughly as far as they can check it, while the speed of the work leaves them less time to check.

Researchers are calling it comprehension debt

Engineer and author Addy Osmani has written about what he calls comprehension debt, the growing gap between how much code exists in a system and how much of it anyone actually understands. Unlike ordinary technical debt, it doesn't show up as slow builds or fragile modules. Tests can pass and dashboards can look healthy while a team's grasp of its own system gets thinner. The bill usually comes later, during an outage, a big refactor, or when the one person who knew how something worked leaves the company.

There is some early evidence on how this happens. In a randomized study of 52 engineers, Anthropic found that participants who relied on AI scored 17% lower on a follow-up comprehension quiz than a control group, 50% versus 67%, with the largest drop in debugging (Augment Code). How people used the tool made a difference. Engineers who asked the AI questions and explored tradeoffs held on to their understanding far better than those who simply handed the work off (Tessl).

The case that this is nothing new

Some engineers will push back on how Hamie frames the problem. Nobody at Meta reads the Linux kernel, the compiler or every dependency in their build, and software has always depended on trusting layers someone else wrote. Seen that way, AI-generated code is one more layer of abstraction, and the unease is similar to what earlier programmers felt about compilers.

The comparison only goes so far. A compiler behaves the same way every time, is heavily tested, and is maintained by people whose job is to understand it. A third-party library has maintainers and a changelog. Code written by an AI agent lands in the engineer's own repository, under their name, built for their specific system. Once they approve it, they are its author of record whether or not they can explain how it works.

How teams are responding

There's no agreed answer yet to Hamie's question about how much understanding is enough, though a few practices are spreading among teams that worry about this.

One is to match review to risk. An internal script and a payments service don't need the same scrutiny, and some teams now spell out which code can ship on tests and spot checks and which needs a reviewer who can explain every branch. Another is to put more effort into the specs, tests and evaluation gates that constrain what the AI writes (Augment Code). A test suite the team actually understands will catch more than a rushed skim of a thousand generated lines.

Some teams also assign a named person to every AI-written change who must be able to explain it on request, and they don't allow agent-generated pull requests to be approved without comment (The Note). Individual engineers can change how they use the tools, too. Asking the model to explain what it wrote, and what it considered and rejected, takes longer than accepting the diff. The Anthropic study suggests that kind of use is what keeps an engineer's understanding intact.

Our take

Some readers will see Hamie's post as an engineer missing an older way of working. We think he's raising a fair professional concern. Wanting to understand what you've built is a safeguard, and the companies pushing hardest on AI adoption have good reason to protect it.

Meta and others track how much of their code AI writes and how widely the tools are used. We haven't seen a company publish any measure of how well its engineers understand the code they ship. Until someone does, engineers who say openly that they're losing track of their own systems are one of the few early warnings available.

Hamie asked whether other engineers feel the same, and the survey data says most of them do. Whether they can say so in a code review without being seen as slowing things down depends on their employers.