The Last Programming Language Won’t Be for Humans

Coding has been declared dead three times. This time it’s the language that goes, not the job.

essays
AI
programming languages
Coding has been declared dead three times. This time it’s the language that goes, not the job.
Published

September 29, 2026

Coding agents already write close to half of professional developers’ code, yet trust in that code is falling. This post maps six futures for programming, the evidence behind each, and the four gates between today and a language only machines read. My bet: people keep writing precise specifications, and everything beneath them stops being written for human eyes.

1. Coding has died before

In 1957, John Backus’s team released Fortran as an “automatic coding system” (Backus et al. 1957). The compiler would write the machine code, and much of the programmer’s job was supposed to go with it. In 2023, Andrej Karpathy declared English “the hottest new programming language” (Karpathy 2023). Two years later he named “vibe coding”: building software by talking to a model and never reading the code it writes (Karpathy 2025).

In between, Edsger Dijkstra made the case for the defence. Programming in natural language, he argued in 1978, is foolish, because precision needs formal notation (Dijkstra 1978).

Both sides were half right. The layer being mourned never died; it sank. Nobody writes machine code by hand anymore, yet every program still becomes machine code. I think the same thing is happening again, one level up. Typing code is dying; code is not. What humans write is moving up, toward the specification. What machines exchange is sinking below readability: first into something no human needs to read, and eventually into something no human can.

Making that case takes three things: an honest look at where we are, a map of where today’s research leads, and an account of the gates between the two.

2. What the data says

Two claims circulate more than any others: that coding is dead, and that almost nobody writes code by hand anymore. Neither survives the surveys.

JetBrains asked more than 15,000 professional developers how last month’s code was produced. On average, they said agents had written about 47% of it on their own, while 27% was still written entirely by hand (JetBrains Research 2026). Over half now hand-write less than a fifth of their code, and one in five writes none at all. But the fully agentic group, where agents produce more than 80% of the code, is still a 22% minority. Ninety percent of professional developers use a coding agent at work at least weekly (Bogdanov 2026). At the top end, Google says 75% of its new code is AI-generated and approved by engineers, up from 25% in 2024 (Semafor 2026).

Adoption, then, is solved. Trust is not. Stack Overflow’s survey of 49,000 developers found that 84% use or plan to use AI tools, but only 29% trust their output, down from 40% the year before. Another 46% actively distrust it, and 45% say debugging AI-generated code takes longer than writing it themselves (Stack Overflow 2025). Sonar found that 96% of developers do not fully trust AI code to be correct, yet only 48% always check it before committing (Sonar 2026).

The productivity evidence is just as mixed. In METR’s 2025 randomized controlled trial, experienced open-source developers working in their own repositories were 19% slower with AI, while believing it had sped them up by about 20% (Becker et al. 2025). An earlier Copilot trial found a 56% speed-up, but on a single, simple, greenfield task (Peng et al. 2023). Context matters. METR’s 2026 follow-up could not produce a reliable estimate at all: too many developers declined to submit tasks they did not want to do without AI, which skewed the sample (METR 2026). That says more about adoption than productivity, but it says it loudly.

So hand-written code is a minority, not a rounding error. And the variable that decides what happens next is not adoption but trust, because trust decides whether a human still has to open the file.

3. Six futures on one map

Any proposal for the future of programming can be placed on two axes: who reads the code (humans, or only machines) and how it is represented (text tokens, or latent vectors). Hover over a point to see its trajectory, its evidence, and what would break it.

Figure 1: Six scenarios for the future of programming. Everything in production sits bottom-left; every research trajectory pushes up and right.

The question that matters is what would move the industry along that diagonal, and whether every step on it is one we should want. Here are the six scenarios in brief.

S0 · Plateau: “AI as autocomplete”

  • Trajectory. Adoption without trust. Agents draft, humans review, and code stays multilingual and human-owned.
  • Evidence. The trust numbers and METR’s measured slowdown above (Stack Overflow 2025; Becker et al. 2025).
  • Breaks if. Trust and measured productivity rise together.
  • Status. Today. This is the null hypothesis, and the data currently supports it better than any alternative.

S1 · English on top: “The prompt is the program”

  • Trajectory. Karpathy’s arc: English in, code out, code never opened. Source becomes a build artifact.
  • Evidence. Agents alone write about 47% of professional developers’ code; Google reports 75% (JetBrains Research 2026; Semafor 2026).
  • Breaks if. Dijkstra’s precision objection bites. Already 45% of developers say debugging AI code takes longer than writing it (Stack Overflow 2025).
  • Status. In production, though “never opened” is aspirational: about half of developers still check every commit (Sonar 2026).

S2 · Typed bridge: “The spec is the source”

  • Trajectory. Languages that give agents machine-checkable feedback win. Humans read types, contracts and specifications; machines write the function bodies.
  • Evidence. TypeScript overtook Python as GitHub’s most-used language in 2025, a shift GitHub partly credits to AI (GitHub 2025). JavaScript/TypeScript and Go developers delegate 54–55% of their code to agents, against 33% for C and C++ (JetBrains Research 2026). Closed-loop pipelines such as Clover check generated Dafny code against its own annotations and docstrings (C. Sun et al. 2023).
  • Breaks if. Verification tooling stays niche while AI code passes security tests only 56% of the time (Veracode 2026).
  • Status. In production for types; pilot stage for proofs.

S3 · Compressed grammar: “Same meaning, fewer tokens”

  • Trajectory. Keep the language but strip out the parts only humans need. Humans see Python; the model sees a token-lean twin.
  • Evidence. Formatting alone is 13–15% of Java, C# and C++ tokens, and SimPy trims a further 10–13% with identical syntax trees (Pan et al. 2026; Z. Sun et al. 2024). Section 4 has the details.
  • Breaks if. Tokenizers disappear, or models stay clumsy in unfamiliar notation (Gate 3).
  • Status. Research prototype.

S4 · Universal IR: “One machine language”

  • Trajectory. An AI-native intermediate representation one rung above LLVM: the thing agents write and exchange, with English above it and machine code below.
  • Evidence. LLVM, MLIR and WebAssembly are already universal, unreadable targets, and the Platonic Representation Hypothesis suggests model internals are converging (Huh et al. 2024).
  • Breaks if. No cross-vendor standard emerges. Every lab has its own tokenizer and its own representation space.
  • Status. Analogy only. No artifact exists yet.

S5 · Neuralese: “No language”

4. What code costs a machine

Programming languages were designed for three audiences: the machine that runs the code, the person who writes it, and the person who reads it six months later. Language models are a fourth audience, and they pay for code in tokens.

Code is more predictable than prose. In 2012, Hindle and colleagues showed that source code has markedly lower cross-entropy than English under the same n-gram models: it is “natural” in the sense of being repetitive and conventional (Hindle et al. 2012). Casalnuovo, Sagae and Devanbu later confirmed the gap across corpora and model families (Casalnuovo, Sagae, and Devanbu 2019). Shannon had estimated printed English at roughly one bit per character (Shannon 1951). Delétang and colleagues tied that tradition to today’s models: a language model is a general-purpose compressor, and its loss is a compression rate (Delétang et al. 2024). Seen this way, any token the model could have predicted is overhead. It is there for some other reader.

A coding agent pays that overhead in two ways. The surface cost is the tokens needed to write the program down. The process cost is the tokens the agent burns reasoning, compiling, failing and revising on its way to a working program. The two are measured differently, and they rank languages differently.

Figure 2: Two bills for the same program. Left: output tokens a coding agent spends relative to Python on the same problems, after controlling for problem difficulty (Wu, Anderson and Guha 2026); faded bars are not statistically significant. Right: share of tokens that are whitespace, indentation and line breaks only (Pan et al. 2026).

Process cost. Wu, Anderson and Guha ran five current models as coding agents on the same 100 competitive-programming problems in Python, Java, Rust and OCaml: 2,000 runs in all (Wu, Anderson, and Guha 2026). A mixed-effects model let them compare languages on identical problems. Every model was cheapest in Python. OCaml cost 1.28–1.69× as many output tokens across all five. Rust (1.07–1.57×) and Java (0.85–1.34×) depended on the model, and Gemma was the one model where neither penalty was significant.

The mechanism is the interesting part. The extra tokens do not come from longer programs; they come from struggle. In Gemma’s stalled OCaml runs, 92% of the failed intermediate solutions were compile errors: the agent was fighting the syntax, not the algorithm. GPT-5.5 fell back to Python to prototype on 27% of OCaml problems before translating. The authors point to training data: The Stack v2 holds roughly 200 GB each of Python and Java, but only 12 GB of Rust and even less OCaml. They add their own caveat: these are self-contained problems, and repository-scale work may behave differently.

Surface cost. Martin Alderson ran the GPT-4 tokenizer over Rosetta Code solutions to the same tasks in 19 popular languages. He found a 2.6× spread, from Clojure (the most compact, at 109 tokens per task) to C (the most verbose). Dynamic languages generally won by skipping type declarations, with Haskell and F# close behind thanks to type inference. In a later run, J, an array language written in plain ASCII, averaged about 70 tokens. APL’s famous terseness, by contrast, did not survive tokenization: its unusual glyphs each split into several tokens (Alderson 2026). Surface cost depends on how well the tokenizer knows the notation, not just on how short the code looks.

The right-hand panel isolates the purest surface cost: formatting. On The Stack v2, whitespace, indentation and line breaks make up 14.7% of the tokens in Java and 13.2% in C# and C++, but only 4.0% in Python, where indentation carries meaning (Pan et al. 2026). Roughly one token in seven in a Java file exists only so that a human can read it. In the authors’ code-completion experiments, advanced models lost essentially nothing when the formatting was stripped out.

The next step is to redesign the grammar itself for the model. Sun and colleagues’ SimPy rewrites Python’s grammar to drop the tokens and layout only humans need, while keeping the abstract syntax tree identical, so programs convert losslessly in both directions. It cuts token usage by 13.5% for CodeLlama and 10.4% for GPT-4, with task performance maintained or improved (Z. Sun et al. 2024). Token Sugar extends the idea with reversible shorthands for recurring code patterns (Z. Sun et al. 2025). Humans see Python; the model sees something terser.

To see what the process-cost multipliers mean for a real bill, pick a model and a workload.

Readability, in other words, is a tax. It has always been worth paying, because humans read code. The rest of this post asks what happens to the tax when they stop.

5. Four gates between agents and neuralese

Here is the argument that started this post. Agents keep improving, so more people rely on them. Human supervision shifts from reading code to testing what it does. With no one reading it, code no longer needs to be readable, so the language is free to optimize for tokens. It converges on a single machine-facing representation. Eventually agents skip language altogether and exchange latent state directly.

Every arrow in that chain is a gate, and each gate has a metric you can watch.

flowchart LR
  S1["S1 English on top"] -->|"G1 agents own
the debug loop"| S2["S2 Typed bridge
spec is the source"]
  S2 -->|"G2 review moves
to specs and tests"| G3{"G3 where is token
pressure absorbed?"}
  G3 -->|"in the language"| S3["S3 Compressed grammar"]
  G3 -->|"in the model"| S4["S4 Universal IR"]
  S3 --> S4
  S4 -->|"G4 auditable
projection kept?"| S5["S5 Neuralese"]

Figure 3: The chain from coding agents to neuralese. Each arrow is a gate that current data either supports or contradicts.

Gate 1: agents must own the debug loop

“Test the outputs instead of reading the code” frees humans only if the agent also fixes what fails. The moment a person opens the file to debug, the pressure for readable code is back. So the thesis is really a claim about agent reliability, not about languages. Current data cuts against it: 45% of developers say debugging AI code takes longer than writing it (Stack Overflow 2025), and 96% do not fully trust it (Sonar 2026). METR sharpens the point. Roughly half of the test-passing SWE-bench Verified pull requests written by agents between mid-2024 and late 2025 would not have been merged by the repositories’ own maintainers (Whitfill et al. 2026). Passing the tests is not the same as being done.

Note

The share of developers who say debugging AI code takes longer than writing it, and the share of agent pull requests merged without human edits. Gate 1 opens when the first falls and the second rises.

Gate 2: tests are weaker than reading

Tests check what you thought to test. Security, privacy and side effects are exactly what you didn’t. Veracode tracked more than 100 models across four snapshots and found the security pass rate stuck at 56%. Syntax success was near 100%, yet nearly half of tasks introduced a vulnerability, with Python passing 63% of the time and Java only 30% (Veracode 2026). Veracode tests raw models with no security prompting or human review, so the figure measures how often flaws are generated, not how often they ship. But review is precisely the step this chain proposes to remove.

The remedy is specification and proof: the S2 world of Dafny, Lean and Clover. That means the human-facing language does not disappear; it moves up a level. Humans stop typing code, but they do not stop writing precise text.

Note

Adoption of verified-code tooling in CI pipelines, and the continued drift of language share toward statically typed languages.

Gate 3: the model may absorb the token pressure, not the language

Grammar redesign saves 10–13% of tokens; stripping formatting saves 4–15%. Meanwhile, the price of a given level of capability has been falling by roughly an order of magnitude a year (Appenzeller 2024), and tokenizer-free architectures have arrived. Meta’s Byte Latent Transformer reads raw bytes, grouped into patches by how predictable the next byte is, with no tokenizer at all, and matches token-based models at the 8-billion-parameter scale (Pagnoni et al. 2024). If that approach wins, the inefficiency S3 targets vanishes inside the model, with no change to the language.

Section 4’s process-cost data adds a second objection. Agents are cheapest in the languages they have seen most, and burn tokens fighting the syntax of the ones they have seen least. A brand-new, token-optimal language would begin life as the least familiar language in the world (OCaml’s problem, magnified) until models were trained on it at scale.

So “less supervision leads to token pressure” holds, but “token pressure leads to a new language” is the weakest link in the chain. The likelier outcome is that the language stays, the tokenizer dies, and S3 is skipped.

Note

Whether a frontier lab ships a tokenizer-free production model, and whether any vendor ships an AI-oriented grammar. Either would settle the question.

Gate 4: neuralese needs permission, not just capability

The chain needs less human oversight; governance is moving the other way. Korbak and colleagues, writing across the major labs, argue that the ability to monitor a model’s chain of thought is a safety property worth protecting in how models are built (Korbak et al. 2025). Liability and regulation both push toward a readable trace. The technology is not ready either. Cache-to-Cache works across models only through a learned projector between specific pairs (Fu et al. 2026), and cross-vendor latent communication would need a standard nobody has agreed on. The nearest precedent is the Model Context Protocol, which went from announcement to de facto standard for tool calls in about a year (Anthropic 2024). S5 will most likely arrive as a capability permitted only where S4 keeps an auditable projection alongside it.

Note

Any cross-vendor cache or latent-state protocol, and whether monitorability requirements make it into regulation.

Put the gates back into the chain and the argument changes shape. Agents become reliable enough to own the debug loop (Gate 1). Human review moves to specs and tests (Gate 2, S2). Code stops being written for human eyes. Efficiency pressure appears, but tokenizer-free models absorb it instead of new grammars (Gate 3, skipping S3). Multi-agent systems adopt latent communication wherever auditability survives (Gate 4, S4 and S5). The destination looks similar; the route does not.

6. What “universal” actually means

The universal language already exists; it just isn’t one anybody writes. LLVM IR (LLVM Project, n.d.b), MLIR (LLVM Project, n.d.a) and WebAssembly (WebAssembly Community Group, n.d.) are universal, machine-targeted and effectively unreadable. Dozens of source languages compile into them, and nobody complains that they cannot read the result. My prediction is an AI-native IR one rung above LLVM: the thing agents write and exchange, with English above it and machine code below.

Three lines of research suggest this is more than an analogy.

The representations are converging. The Platonic Representation Hypothesis holds that, as models scale, their internal representations converge across architectures and modalities toward a shared statistical model of reality (Huh et al. 2024). If internal representations converge, a shared external one becomes an engineering problem.

The artifacts exist. DroidSpeak passes embedding and key-value caches between agents built on the same base model instead of re-tokenizing text, cutting prefill latency by up to 2.78× with negligible loss of accuracy (Liu et al. 2024). Cache-to-Cache extends this across different models using a learned projector and a neural cache fuser (Fu et al. 2026). Coconut does the same thing within a single model, reasoning in continuous latent space instead of decoding tokens (Hao et al. 2024).

The precedent is old. In 2017, Lewis and colleagues’ negotiation agents drifted from English into a shorthand of their own once the reward stopped caring about English (Lewis et al. 2017). Lazaridou and Baroni survey a decade of research in which agents invent communication protocols under pressure (Lazaridou and Baroni 2020). And in 2025, the Gibberlink hackathon demo showed two voice agents switching from English to a data-over-sound protocol once they recognized each other. It was scripted by prompt rather than emergent, but it went viral because it made the idea concrete (Starkov and Pidkuiko 2025). The S5 future has already happened in the lab, more than once.

So the universal coding language is real. It is an IR, it sits below humans, and it will probably take two forms: a symbolic one for auditing and a latent one for speed.

7. Not a winner, but a stack

Put the scenarios together and they stop looking like competitors. They are layers.

flowchart TB
  H["Humans · intent in English (S1)"] --> P["Spec · types, contracts, proofs (S2)
the human-readable contract"]
  P --> I["Universal IR · machine-facing, token-optimal (S4)"]
  I --> N["Neuralese · latent exchange between agents (S5)"]
  N -.->|"auditable projection"| P

Figure 4: The likely endpoint is a stack, not a winner. The compiler stack never deleted a rung either.

Assembly still runs under C, which still runs under Python. The likeliest endpoint is S1 as the human interface, S2 as the verifiable contract, and S4 and S5 as the machine representation, with S3 a transitional hack that tokenizer-free models make unnecessary.

Three signals will tell you which scenario is winning:

  1. The trust number. If the share of developers who trust AI output climbs back past 40% in Stack Overflow’s survey while “debugging takes longer” falls, Gate 1 is opening.
  2. Verified-code adoption. If proof-carrying or contract-checked generation moves from research into CI pipelines, Gate 2 is holding the human-facing layer at the spec.
  3. A cross-vendor latent protocol. The first standard that lets one lab’s agent hand its cache to another’s, with an auditable projection, is the moment S4 and S5 leave the lab.

Until then, the honest reading of the data is S0 sliding into S1. That is a long way from coding being dead. It is the distance between “nobody types assembly” and “assembly is dead.”

Hands will leave the keyboard. What they leave behind is the spec: the one artifact that has to be precise, checkable, and readable by the people who bear the consequences. The spec is the new source code.

References

Alderson, Martin. 2026. “Which Programming Languages Are Most Token-Efficient?” January 2026. https://martinalderson.com/posts/which-programming-languages-are-most-token-efficient/.
Anthropic. 2024. “Model Context Protocol.” November 2024. https://modelcontextprotocol.io/.
Appenzeller, Guido. 2024. “Welcome to LLMflation – LLM Inference Cost Is Going down Fast.” Andreessen Horowitz. November 2024. https://a16z.com/llmflation-llm-inference-cost/.
Backus, J. W., R. J. Beeber, S. Best, R. Goldberg, L. M. Haibt, H. L. Herrick, R. A. Nelson, et al. 1957. “The FORTRAN Automatic Coding System.” In Papers Presented at the Western Joint Computer Conference, 188–98. https://doi.org/10.1145/1455567.1455599.
Becker, Joel, Nate Rush, Elizabeth Barnes, and David Rein. 2025. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” https://arxiv.org/abs/2507.09089.
Bogdanov, Mikhail. 2026. “AI Coding Agents: Adoption Trends.” JetBrains Research. August 2026. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/.
Casalnuovo, Casey, Kenji Sagae, and Prem Devanbu. 2019. “Studying the Difference Between Natural and Programming Language Corpora.” Empirical Software Engineering 24: 1823–68. https://arxiv.org/abs/1806.02437.
Delétang, Grégoire, Anian Ruoss, Paul-Ambroise Duquenne, Elliot Catt, Tim Genewein, Christopher Mattern, Jordi Grau-Moya, et al. 2024. “Language Modeling Is Compression.” In International Conference on Learning Representations (ICLR). https://arxiv.org/abs/2309.10668.
Dijkstra, Edsger W. 1978. “On the Foolishness of ‘Natural Language Programming’.” https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html.
Fu, Tianyu, Zihan Min, Hanling Zhang, Jichao Yan, Guohao Dai, Wanli Ouyang, and Yu Wang. 2026. “Cache-to-Cache: Direct Semantic Communication Between Large Language Models.” In International Conference on Learning Representations (ICLR). https://arxiv.org/abs/2510.03215.
GitHub. 2025. “Octoverse 2025: A New Developer Joins GitHub Every Second as AI Leads TypeScript to #1.” October 2025. https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/.
Hao, Shibo, Sainbayar Sukhbaatar, DiJia Su, Xian Li, Zhiting Hu, Jason Weston, and Yuandong Tian. 2024. “Training Large Language Models to Reason in a Continuous Latent Space.” https://arxiv.org/abs/2412.06769.
Hindle, Abram, Earl T. Barr, Zhendong Su, Mark Gabel, and Premkumar Devanbu. 2012. “On the Naturalness of Software.” In Proceedings of the 34th International Conference on Software Engineering (ICSE), 837–47. https://dl.acm.org/doi/10.5555/2337223.2337322.
Huh, Minyoung, Brian Cheung, Tongzhou Wang, and Phillip Isola. 2024. “The Platonic Representation Hypothesis.” In International Conference on Machine Learning (ICML). https://arxiv.org/abs/2405.07987.
JetBrains Research. 2026. “How Much Code Do Developers Really Let Agents Write?” JetBrains. August 2026. https://blog.jetbrains.com/research/2026/08/how-much-code-do-developers-really-let-agents-write/.
Karpathy, Andrej. 2023. “The Hottest New Programming Language Is English.” January 2023. https://x.com/karpathy/status/1617979122625712128.
———. 2025. “There’s a New Kind of Coding I Call ‘Vibe Coding’.” February 2025. https://x.com/karpathy/status/1886192184808149383.
Korbak, Tomek, Mikita Balesni, Elizabeth Barnes, et al. 2025. “Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety.” https://arxiv.org/abs/2507.11473.
Lazaridou, Angeliki, and Marco Baroni. 2020. “Emergent Multi-Agent Communication in the Deep Learning Era.” https://arxiv.org/abs/2006.02419.
Lewis, Mike, Denis Yarats, Yann N. Dauphin, Devi Parikh, and Dhruv Batra. 2017. “Deal or No Deal? End-to-End Learning for Negotiation Dialogues.” In Proceedings of EMNLP. https://arxiv.org/abs/1706.05125.
Liu, Yuhan, Yuyang Huang, Jiayi Yao, Zhuohan Gu, Kuntai Du, Hanchen Li, Yihua Cheng, et al. 2024. “DroidSpeak: KV Cache Sharing for Cross-LLM Communication and Multi-LLM Serving.” https://arxiv.org/abs/2411.02820.
LLVM Project. n.d.a. “MLIR: Multi-Level Intermediate Representation.” https://mlir.llvm.org/.
———. n.d.b. “The LLVM Compiler Infrastructure.” https://llvm.org/.
METR. 2026. “We Are Changing Our Developer Productivity Experiment Design.” February 2026. https://metr.org/blog/2026-02-24-uplift-update/.
Pagnoni, Artidoro, Ram Pasunuru, Pedro Rodriguez, John Nguyen, Benjamin Muller, Margaret Li, Chunting Zhou, et al. 2024. “Byte Latent Transformer: Patches Scale Better Than Tokens.” https://arxiv.org/abs/2412.09871.
Pan, Dangfeng, Zhensu Sun, Cenyuan Zhang, David Lo, and Xiaoning Du. 2026. “The Hidden Cost of Readability: How Code Formatting Silently Consumes Your LLM Budget.” In Proceedings of the 48th IEEE/ACM International Conference on Software Engineering (ICSE). https://arxiv.org/abs/2508.13666.
Peng, Sida, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. 2023. “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” https://arxiv.org/abs/2302.06590.
Semafor. 2026. “Google CEO Says 75% of Company’s New Code Is AI-Generated.” April 2026. https://www.semafor.com/article/04/24/2026/google-ceo-says-75-of-companys-new-code-is-ai-generated.
Shannon, Claude E. 1951. “Prediction and Entropy of Printed English.” Bell System Technical Journal 30 (1): 50–64. https://doi.org/10.1002/j.1538-7305.1951.tb01366.x.
Sonar. 2026. “Sonar Data Reveals Critical ‘Verification Gap’ in AI Coding: 96% Don’t Fully Trust Output, yet Only 48% Verify It.” January 2026. https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/.
Stack Overflow. 2025. “2025 Developer Survey: AI.” 2025. https://survey.stackoverflow.co/2025/ai.
Starkov, Boris, and Anton Pidkuiko. 2025. “GibberLink: Two Conversational AI Agents Switching from English to a Sound-Level Protocol.” February 2025. https://github.com/PennyroyalTea/gibberlink.
Sun, Chuyue, Ying Sheng, Oded Padon, and Clark Barrett. 2023. “Clover: Closed-Loop Verifiable Code Generation.” https://arxiv.org/abs/2310.17807.
Sun, Zhensu, Xiaoning Du, Zhou Yang, Li Li, and David Lo. 2024. “AI Coders Are Among Us: Rethinking Programming Language Grammar Towards Efficient Code Generation.” In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). https://doi.org/10.1145/3650212.3680347.
Sun, Zhensu, Chengran Yang, Xiaoning Du, Zhou Yang, Li Li, and David Lo. 2025. “Token Sugar: Making Source Code Sweeter for LLMs Through Token-Efficient Shorthand.” In Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2440–51. https://arxiv.org/abs/2512.08266.
Veracode. 2026. “LLMs Are Getting Smarter, but Not Safer: Veracode 2026 GenAI Code Security Report Finds AI-Generated Code Security Has Stalled at 56% Pass Rate.” July 2026. https://www.businesswire.com/news/home/20260728207685/en/.
WebAssembly Community Group. n.d. “WebAssembly.” https://webassembly.org/.
Whitfill, Parker, Cheryl Wu, Joel Becker, and Nate Rush. 2026. “Many SWE-Bench-Passing PRs Would Not Be Merged into Main.” METR. March 2026. https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/.
Wu, Zixuan, Carolyn Jane Anderson, and Arjun Guha. 2026. “The Best Programming Language for Tokenmaxxing: An Investigation of Coding Agent Behavior Across Programming Languages.” https://arxiv.org/abs/2607.22807.