Best Programming Language for Coding Agents?

What’s the best programming language for coding agents? is a Dan Luu essay and measurement note about how programming languages consume model tokens when agents read and write code. It deals with a deceptively practical question: does choosing Python, Lua, Rust, Go, TypeScript, or assembly change how well a coding agent can work? The takeaway is simple: token count matters, but it is not a language ranking by itself. For agentic coding, the useful test is equivalent work in your repo, with the same acceptance criteria and the same review bar.

Token efficiency is the amount of useful program behavior an agent can fit into a model context window per token. That makes it tempting to prefer compact languages. It also makes it easy to overfit to syntax and miss the thing you actually ship: correct, maintainable code.

Read Dan Luu’s post as a question, not a leaderboard

Luu’s post is interesting because it treats programming languages as inputs to a token budget. Coding agents do not see source code the way a compiler does. They see token streams, and token streams affect context length, latency, and sometimes price.

That is why developers argued about it. If a dynamic language can express the same behavior in fewer tokens, maybe the agent gets more room for tests, errors, docs, and surrounding files. In long-context work, that extra room can be the difference between seeing the real invariant and guessing around it.

The trap is reading the post as proof that terse syntax wins. It is better read as a prompt for a local benchmark. A shorter snippet is not the same as an equivalent implementation, and an equivalent implementation is not the same as a change your reviewer will accept.

Take the compact-language argument seriously

The strongest compact-language case is not silly. Dynamic languages often omit explicit type declarations, generic bounds, trait plumbing, and error-wrapper ceremony. In a small task, that can make Python, Ruby, JavaScript, or Lua easier for an agent to produce and revise.

A commenter in the surrounding debate gave a useful flavor of this: on a creative graphics task, Lua gave richer results than integer-only C or hand-written assembly, even when the low-level target was impressive. That does not prove Lua is the best language for agents. It does show that expressiveness and search space matter, not just raw machine closeness.

The trap is assuming visual compactness equals tokenizer compactness. Symbols, punctuation-heavy code, and dense operator usage do not always chunk as cheaply as plain words. A language can look tiny to a human and still spend surprising tokens in the model’s tokenizer.

Take the typed-language argument seriously

The strongest typed-language case is also real. Rust, Go, TypeScript, Java, and similar languages spend tokens to encode constraints. Those tokens can buy compiler feedback, clearer APIs, safer refactors, and reviewable failure modes.

In a Rust service, for example, an agent may burn tokens on Result, lifetime hints, trait bounds, and explicit conversions. That cost can be annoying. But the compiler then becomes a hard reviewer that catches whole classes of hallucinated changes before a human reads the diff.

The trap is treating correctness tokens as free. A verbose language can crowd out neighboring files, tests, and design notes. If the agent loses the surrounding context, the types may be perfectly valid while the feature is wrong.

Compare accomplishments, not snippets

The best objection in the debate was about normalization. You cannot compare a memoized Fibonacci in one language with a web service in another and learn much. You need equivalent accomplishments.

A better comparison is a real change like this: add a paginated recipe search endpoint, enforce the existing auth rule, add the database index, update tests, and preserve the public API contract. Run that task in two or three languages or frameworks you actually use. Then compare the accepted diff, not the prettiest generated sample.

This matters for Claude Code, Anthropic’s coding agent, because the agent works inside a real repository with real files, test commands, and review habits. A concise CLAUDE.md note can help keep the experiment fair: name the test command, the style rule, and the files that define the contract. Do not turn that note into a language manifesto.

Settle it in your own repo

The practical move is small: run one representative task through the languages or frameworks you are already choosing between. Use the same prompt, the same branch state, and the same acceptance tests. If you are collecting notes under agentic coding governance, save the results as evidence, not as policy theater.

A Claude Code slash command is a tidy way to make the comparison repeatable without replaying a chat transcript. Keep it boring. The command should ask the agent to implement the same task, run the same checks, and produce a short receipt.

Here is a lightweight command file you can adapt:

# .claude/commands/language-token-trial.md

Run a language comparison for the current task.

Use the task description in the issue or prompt.

For each candidate implementation:
- inspect the existing repo conventions first
- make the smallest complete change
- run the documented test command
- record files changed, tests run, failures fixed, and unresolved risks
- do not claim success unless the checks pass

Return a short receipt:
- language or framework used
- implementation size in files and lines changed
- tests run
- compile or type errors encountered
- reviewer concerns a human should inspect

The trap is measuring only input and output tokens. Also record compile failures, test repairs, reviewer comments, and how often the agent needed a rescue prompt. Those are developer productivity costs too.

For a different story about coding agents coordinating through a protocol rather than choosing a language, see Parley Lets Coding Agents Talk.

Copy the two-hour language trial

Use this when the argument has become circular. Pick one task that matters, cap the time, and compare outcomes side by side.

Checklist:

• Choose one real task with clear acceptance tests.
• Freeze the repo state before each run.
• Use the same task prompt for each language or framework.
• Let the agent inspect existing conventions before editing.
• Run the same test command or the closest language-native equivalent.
• Review the final diff without looking at the chat first.
• Record the result as pass, pass after repair, or fail.

A good result is not the language with the fewest tokens. A good result is the language where the agent produced the smallest acceptable diff with the least repair work.

Common questions

• What is the best programming language for coding agents?

  There is no universal best programming language for coding agents. The best choice is the one that gives the agent enough context while still giving humans and tools strong review signals. For many repos, that means comparing one compact language and one typed language on the same task before making a call.

• Are dynamically typed languages cheaper for LLMs?

  They can be cheaper, but not always in the way people expect. Omitting type declarations often reduces source length, which may reduce token use. The caveat is that tokenizers do not price every character equally, and terse symbols or punctuation-heavy code may not compress as well as the code looks on screen.

• Does syntactic density always help coding agents?

  No, syntactic density does not always help coding agents. Dense code can hide intent, collapse important names, and make review harder. The number to watch is not just tokens per file; it is accepted behavior per repair prompt, with tests and reviewer notes included.

• Should we rewrite agent-facing code in Python or Lua?

  Probably not just for agent friendliness. Rewriting a working system to save tokens is rarely the first win. A safer experiment is to expose small scripting seams, examples, or task-specific harnesses in a compact language while keeping core production code in the language that fits its runtime and safety needs.

• How should Claude Code users test language choice?

  Use a repeatable slash command and a review receipt. Claude Code can run the same task against the same repo state, then report files changed, tests run, errors fixed, and risks left open. That gives you a local answer instead of a language-war answer.

Best ways to use this research

• Best for deciding language fit: Use the article as a benchmark design note, not as a ranking of Python, Lua, Rust, Go, TypeScript, or C.
• Best first artifact: Create one slash command that runs an equivalent-task trial and returns a short review receipt.
• Best comparison angle: Compare accepted diffs, test repairs, compile errors, and reviewer concerns alongside token counts.
• Best caveat to keep visible: Token efficiency helps most when context is the bottleneck; typed constraints help most when incorrect assumptions are the bottleneck.

Further reading

• Claude Code — overview
• Claude — Agent
• Model Context Protocol — specification
• OWASP — Top 10 for Large Language Model Applications
• Dan Luu — What’s the best programming language for coding agents?

Run one boring comparison

Pick one task your repo actually cares about and run the two-hour trial. If the result surprises you, keep the receipt; that is more useful than winning the thread.

One methodology lens

One useful way to read this through our methodology is the Design step: delegate option mapping and pattern exploration, review the interfaces and tradeoffs, and keep ownership of architecture and contracts. If that split is still fuzzy, the workflow usually is too.