Part 2 of 5 — When the Machine Codes series
Part 1 of this series argued that the conventional case for Python as the default language in LLM-first development rests on assumptions that do not transfer from human developers to large language models. This article makes the positive case: the specific properties of statically typed languages that make them better suited to a development model where the LLM is the primary implementer. The argument proceeds from generation time through review time and finally to scale — and ends with an empirical comparison of which statically typed language to choose.

The primary argument applies to any statically typed language. The Java-specific recommendation follows in Section 5 and is grounded in a comparison across six languages. Readers with a preference for another statically typed option will find most of Sections 1–4 applies to their chosen language.

Technical detail is marked where it appears. The argument holds without it.

The conventional wisdom about static typing is that it benefits large teams working on long-lived codebases. The overhead of declaring types, maintaining type annotations, and fixing compiler errors pays off over years of maintenance by multiple developers. For small projects and rapid prototyping, the conventional wisdom continues, dynamic typing is faster — you write less, you iterate more freely, and you deal with type problems when they arise rather than upfront.

This argument is not wrong for the case it describes. It is wrong in assuming that case is the only relevant one. When the primary implementer is a large language model, the properties that make static typing valuable change, and some of the properties that made dynamic typing attractive disappear. The result is a different calculation — one that the conventional wisdom was not designed for and does not accurately reflect.

1. At Generation Time: The Token Cost Argument

The most immediate objection to statically typed languages in LLM-first development is verbosity. A Java class with type declarations, package statements, imports, and explicit generics is longer than the equivalent Python. Longer output means more tokens. More tokens mean higher cost.

This objection has the right structure but the wrong accounting.

Token costs for LLM APIs are not uniform. Output tokens — the text the model generates — cost between three and ten times more than input tokens, because generation requires more computational resources than reading. A longer Java class does cost more to generate than a shorter Python equivalent. But that is one side of the ledger. The other side is the debugging cycle.

When an LLM generates code that contains an error, what follows is a cycle: the error is discovered, the error is fed back to the LLM as input, the LLM reasons about it, the LLM generates a correction. Each cycle consumes input tokens (the error and context), output tokens (the correction), and — critically — reasoning capacity. Research on LLM debugging behaviour documents this as the Debugging Decay Index: models lose between 60 and 80 percent of their debugging effectiveness within two to three attempts. The first cycle is the most effective. Each subsequent cycle is progressively worse. This means the cost of a debug cycle is not simply its token count — it is its token count multiplied by the degraded quality of the reasoning that produced it.

Into this calculation, introduce the finding that 94 percent of LLM-generated Java compilation errors are type-related (Mündler et al., PLDI 2025). The paper studies Java compilation; the inference to Python is the series’ own: to the extent equivalent code in Python would encounter equivalent logical errors, those errors would surface at runtime rather than compile time — requiring a debug cycle. In a statically typed language, they surface at compile time, before execution, with precise location information and a clear description of what was expected versus what was provided. The LLM can act on a compile error immediately, often within the same response, without triggering a full debug cycle.

The arithmetic inverts. The verbosity of static typing is paid once, at generation time. Python’s type errors are paid repeatedly, at debugging time, with degrading returns. If a statically typed language eliminates even one substantive debug cycle per implementation unit — and the evidence suggests it eliminates several — the net token cost of a correct, working implementation is lower than the equivalent Python. The verbosity is in the output. The savings are in the cycles. To be precise: the direction of this argument is supported by the evidence cited above; the magnitude is a structural inference. No controlled study yet quantifies the token cost differential across language choices at the level of complete implementations. That study is called for in the series conclusion. The argument here is the case for why it will find what the structure predicts.

But the verbosity argument deserves a sharper response than token arithmetic alone. The additional declarations in a statically typed language — the type annotations, the record definitions, the explicit interfaces — are not merely less costly than they appear. They are not overhead at all. The untyped Python dict that saves five lines of declaration also withholds five lines of verified structural information from every future session that reads that code. The verbosity is the specification. Removing it does not save work; it transfers the work from the type system to the reasoning process of every LLM session that subsequently touches the code. Against Pydantic-modelled Python the argument narrows — discussed in full in Section 2. This point is developed in Section 4.

A fair counter: Java-specific error surfaces. The argument above establishes that Java catches errors earlier. It does not establish that LLMs make fewer errors in Java. Java’s stricter structure creates error surfaces that Python avoids by being permissive: bounded generic wildcards (? extends, ? super) that LLMs frequently mis-specify; checked exceptions that must be declared or caught at every call site; access modifier semantics that differ from Python’s conventions; CDI injection rules that must be satisfied structurally; JAX-RS annotation requirements that must align across endpoint declaration, parameter binding, and response type. These are real sources of initial errors that do not appear in equivalent Python code.

The net argument is not that LLMs generate fewer errors in Java. It is that the errors they generate are caught earlier, more precisely, and at lower correction cost. A Java generic type error is caught at compile time with a message that specifies exactly what was expected and where. A Python type mismatch may surface as a runtime exception whose cause requires several reasoning steps to trace. Even if LLMs generate more Java-specific structural errors per implementation unit, the correction cost of a precisely located compile error is lower than the correction cost of a runtime error that requires diagnostic reasoning — particularly as debugging effectiveness degrades with each attempt. Whether this net effect favours Java is the controlled study the series calls for. If the correction cost advantage is sufficiently large to outweigh the higher initial error rate — which the structural argument suggests but has not demonstrated — the net effect favours Java.

The enterprise implication. At the scale of enterprise software development — many developers, many projects, many LLM sessions per day — this differential becomes material. Enterprise AI coding costs are substantial: published figures show heavy Claude Code usage running to thousands of dollars per month per developer at high session volumes, with output tokens costing three to ten times input tokens. A consistent reduction in net correction cost across a large engineering organisation is not a marginal efficiency gain. It is a structural cost reduction driven by a language choice. The precise magnitude requires controlled study — no such study exists yet at the time of writing — and the direction depends on whether the correction cost advantage outweighs the higher initial error rate acknowledged above. The structural argument predicts it does; the controlled study would confirm it.

2. At Review Time: Static Read-Through Reliability

Code review in LLM-first development has a property that distinguishes it from human code review: every review session begins cold. A human reviewer who has worked on a codebase for months carries an internal model of what the code is supposed to do, what conventions are in use, what the data looks like at each point. An LLM reviewer begins each session from the code alone, with no memory of previous sessions, no accumulated familiarity, and no ability to ask a colleague what was intended. The quality of the review is bounded by what can be reconstructed from a single read of the codebase.

This is where the gap between statically and dynamically typed code becomes concrete.

When a reviewer reads List<MdIssue>, they know — with compiler-verified certainty — that the list contains instances of MdIssue, that each MdIssue has the fields declared in its record definition, and that nothing in the codebase has been permitted to violate that structure without producing a compilation error. The reviewer does not need to search for where MdIssue is constructed, or check whether it might sometimes be populated differently, or caveat their findings against the possibility that the type constraint is violated in some edge case. The type system has already answered those questions.

When a reviewer reads a Python function that accepts a list of dictionaries, none of that certainty is available. The reviewer must infer the shape of each dictionary from how it is used — which keys are accessed, what operations are applied to the values, whether the same name is used for structurally different objects elsewhere in the codebase. This inference may be accurate. It may not be. It is always inference, and the review findings must be qualified accordingly.

What this means for review confidence. An LLM reviewing a statically typed codebase can make definite claims: this method cannot receive a null where it expects a String; this list cannot contain an element of a different type; this record cannot be partially constructed. An LLM reviewing equivalent Python code must make probabilistic claims: this dictionary appears to always contain these keys; this function appears to be called with this type of argument; this pattern appears to be consistent across the codebase. The word appears carries all the uncertainty. In a review whose purpose is to find what is wrong, qualified confidence is weaker than verified confidence.

A concrete example from this project. During the development of the Stage 4 refinement pipeline described in Part 3 of this series, a separate LLM session was used to perform a static read-through of the implementation — verifying that the code matched the specification without running either. The review identified structural issues that had been missed during implementation. This was possible because the data contracts — RefinementRule, FenceBlock, ReplayResult — were Java records with compiler-enforced fields. The reviewer could reason about what each method received and returned, what the replay engine guaranteed, and where the implementation diverged from the specification, all from the code alone. The same exercise on equivalent Python code would have required either running the code or accepting inference as a substitute for verification.

The type hint caveat, stated fairly. Python’s type system in 2025 is substantially stronger than a characterisation focused on optional hints would suggest. Two developments matter. Pydantic v2 provides runtime type enforcement — not merely annotations. A Pydantic model validates incoming data at the boundary where it is parsed, raising precise errors when types mismatch; the structural guarantee is enforced by the library, not merely declared by the developer. FastAPI builds on this to generate OpenAPI specifications from typed endpoint signatures, producing the same non-divergence between implementation and contract that Quarkus/JAX-RS provides. pyright in strict mode — with noImplicitAny and strictNullChecks enforced — provides type guarantees comparable to a statically typed language for codebases that adopt it consistently.

The honest comparison is not Java’s best-case against Python’s baseline. It is Java’s disciplined use against Python’s disciplined use: Quarkus with records and CDI against FastAPI with Pydantic v2 and pyright strict.

That comparison still leaves a gap, but it is more precise than “Python’s type hints are frequently absent.” The genuine remaining distinctions:

Pydantic enforces types at data-ingestion boundaries — when models are constructed from incoming data, errors are raised immediately at that point, not lazily later. Java’s compiler enforces types everywhere in the codebase, including internal function calls, method chains, and refactored paths that Pydantic never observes because they are not data boundaries. In practice, this distinction is compounded: Pydantic’s validation overhead is real and documented — the library’s own guidance recommends using it at service boundaries and plain dataclasses internally for performance-sensitive code. This means even well-engineered Pydantic codebases have a call graph without runtime type enforcement by design — Pydantic validates at data-ingestion boundaries; internal dataclass fields are checked only by static analysis tools like pyright, not at execution time. Java enforces types throughout, at compile time, everywhere in the call graph.

Beyond the boundary distinction: type annotations and Pydantic models are adopted rather than enforced by construction — a mixed codebase imposes inference costs at the boundaries between typed and untyped regions; and the Python library ecosystem is unevenly typed, so imports from third-party packages often lack Pydantic enforcement even when the consuming code has it.

For LLM cold reads specifically: a well-typed Pydantic codebase is substantially more legible than untyped Python and approaches Java’s legibility. The argument for Java’s advantage is strongest against the Python baseline; against well-engineered modern Python, the advantage narrows to the compile-time versus runtime distinction and the adoption-consistency argument. (See Technical Companion, A1 for the related refactoring completeness argument.)

A practical asymmetry: what LLMs generate by default. The comparison between disciplined Java and disciplined Python is the correct theoretical comparison. In practice, an important asymmetry operates. In Java, type discipline is the default — the compiler refuses untyped code, and deviating from type safety requires deliberate effort. In Python, Pydantic, FastAPI, and pyright strict are opt-in — active choices that must be made, configured, and enforced.

The practical evidence for this asymmetry is locally observed, structurally predicted, and repeatable. The Sparge Python server documented in Part 3 — built by an LLM from design specifications without explicit instruction to use typed patterns — used plain Python dictionaries throughout its state management layer with no Pydantic models. This is one observation, not a controlled study. But it is consistent with what the training data distribution predicts: the vast majority of Python code in LLM training corpora — Stack Overflow answers, tutorials, GitHub examples, documentation — uses plain dicts and untyped functions rather than Pydantic models. The implication is systemic: across the world, LLMs are generating far more dynamically-typed Python than typed Python, because that is the distribution they learned from.

The objection that “the spec could have mentioned Pydantic” is valid — and this is precisely the asymmetry. In Java, the spec does not need to say “use the type system”; the compiler enforces it regardless of what the spec says or omits. In Python, typed patterns must be explicitly chosen, configured, and specified. Java’s type enforcement does not require instruction; Python’s does.

This is not a claim that LLMs cannot produce typed Python, or that they always produce untyped Python given any prompt. It is the observation that typed patterns require explicit specification, while untyped patterns are the default — and that this default has real consequences at scale. Reaching the disciplined Python comparison point requires the human architect to choose Pydantic, include it in the project, specify it in the design, and review output for slippage. Java requires none of this. The best-case comparison remains valid as a theoretical ceiling; the default-state comparison is not symmetric.

3. At Scale: Parallel Development and Integration Coherence

The arguments in Sections 1 and 2 concern a single project developed by a single LLM working session at a time. They show that static typing reduces debugging cost at generation and improves reliability at review. Both arguments are real. Neither is the strongest one.

The strongest argument for static typing in LLM-first development operates at scale — across multiple projects developing concurrently, sharing integration contracts, evolving in parallel. At this level, static typing is not merely a quality improvement. It is an enabling condition for coherent development that dynamic typing cannot replicate structurally.

The integration contract problem. When two systems communicate — System A exposing an API that System B consumes — they share a contract. That contract specifies what System A will provide, in what form, with what guarantees. System B’s correctness depends on that contract being honoured. In traditional software development, enforcing this contract at scale is an unsolved problem. Documentation drifts. APIs evolve. Consumers are not always notified. Integration failures surface at runtime, in production, far from the change that caused them.

In a statically typed ecosystem, the contract is expressed as types. When a type-safe REST client for System B is derived from the same type declarations that define System A’s API surface, a change to System A that alters its API types will cause System B’s client code to fail to compile. The failure surfaces immediately, in the build, before either system is run. The developer — or LLM — working on System B learns about the breaking change at the earliest possible moment, with the most precise possible information about what changed and where.

In a dynamically typed ecosystem, the same contract is a convention. It is expressed in documentation, in comments, in the shared understanding of developers who have worked on both systems. When System A evolves, that convention may or may not be updated. System B may or may not be notified. The failure, if it occurs, surfaces at runtime — during integration testing if you are disciplined, in production if you are not. The distance between the cause and the observable effect is measured in time and in the accumulated work built on the broken assumption.

The integration debt concept. In high-volume parallel development, this asymmetry compounds. Consider five systems developing concurrently, each making multiple changes per session, each depending on APIs exposed by the others. In a dynamically typed ecosystem, each integration point is a convention that may drift. At low volume — one change per system per week, integration testing after every change — the drift is manageable. At high volume — many changes per system per day, integration testing only when systems are run together — the gap between assumed contract state and actual contract state widens faster than it can be closed. By the time an integration failure surfaces, multiple layers of additional work have been built on the broken assumption. The failure is expensive to diagnose and expensive to correct.

Static typing prevents this at the source. The convention becomes a compiler-enforced type. The drift is impossible — not improbable, not discouraged, but structurally prevented. A system that cannot compile cannot be committed. A contract that has changed announces itself immediately to every dependent. The gap cannot widen because the tools that would let it widen are not available.

This is not hypothetical. The five systems referenced in this series — casehub, claudony, qhorus, ledger, work — are under concurrent development in the model described here: design spec-led, LLM-implemented, Java from inception. These systems are not independent. They depend on each other through shared APIs that have been growing and changing throughout development — new endpoints added, existing contracts extended, data models revised as requirements evolved. LLM sessions working on different systems in isolation — each beginning without memory of previous sessions, each unaware of what other sessions were doing simultaneously on sibling systems — had to navigate those evolving contracts and adapt their implementations accordingly. The type system was the mechanism that made this tractable: each session could read the current API types, know with certainty what was expected, and produce code that either compiled against the contract or failed with a precise description of the mismatch. Part 5 of this series examines the git history of these five systems — API evolution, integration changes, and how each was propagated — as the empirical record of this claim in practice.

What dynamic typing requires instead. It is worth being explicit about the alternative. Dynamic typing does not make coherent parallel development impossible — it makes it procedural rather than structural. The coherence must be maintained by discipline: comprehensive documentation, regular integration runs, explicit coordination between developers or LLM sessions working on different systems, and thorough testing at every boundary. These practices work. They are also expensive, prone to lapses, and dependent on the consistency of the team or system applying them. Static typing makes coherence a property of the code rather than a property of the process. The distinction matters most when volume is high, sessions are many, and the people or systems doing the work cannot coordinate in real time.

The OpenAPI connection. Typed API frameworks — Quarkus/JAX-RS in Java, FastAPI/Pydantic in Python — both generate OpenAPI specifications from typed endpoint signatures, producing non-divergent specs where the implementation and the documentation are the same artifact. This is not a Java-exclusive capability. The Java-specific advantage is narrower: when both the server and the consuming client are statically typed Java, a change to System A’s API types propagates as a compilation failure in System B’s generated client — not as a runtime negotiation failure or a documentation mismatch. The spec-to-client pipeline is compiled, not interpreted. For LLM sessions working on System B, the OpenAPI document is a machine-readable, always-current description of what System A provides — this is equally true of FastAPI. What differs is how strongly that contract is enforced when the client is compiled. (See Technical Companion, A3.)

4. The Continuity Mechanism

The three arguments so far — reduced debugging cost, more reliable review, and parallel development coherence — all have analogues in human software development. A human team also benefits from catching errors early, reviewing code accurately, and maintaining integration contracts. The advantages are real for humans too, which is why large teams have long preferred statically typed languages for complex systems. What makes these arguments specific to LLM-first development is the degree to which they apply — the compounding of debugging decay with type errors, the cold-session review problem, the volume and parallelism of concurrent LLM work — rather than the direction.

The fourth argument has no analogue in human development at all. It is specific to how large language models work, and it is the one that does not appear in any conventional comparison between statically and dynamically typed languages.

The session boundary. A human developer working on a codebase across multiple sessions carries their understanding with them. They know what they built last week. They remember the design decisions that were made, the constraints that shaped them, the parts of the codebase that are fragile or incomplete. When they return to a project after a break, they resume — imperfectly, but substantially. Their prior context reduces the time needed to return to productive work.

An LLM has no such continuity. Every session begins from the code. There is no memory of the previous session, no accumulated understanding of the codebase’s history, no recollection of what was decided and why. The LLM working on a system today has exactly the same starting point as a different LLM working on the same system for the first time: the files as they currently exist, whatever documentation is present, and nothing else.

This means the code is not just an implementation artefact. It is the complete and sole record of everything the next session needs to know. The quality of that record — how accurately it communicates architectural intent, data contracts, system boundaries, and design decisions — determines the quality of the session that follows.

What static typing contributes to continuity. A statically typed codebase encodes structural information in a form that is verified, explicit, and immediately readable. A record type RefinementRule(String check, int fenceIndex, String fingerprint, String contentSample, Map<String, String> fix) tells the next session, with certainty, what a refinement rule is, what it contains, and what types its fields carry. A sealed class hierarchy tells the next session what states are possible and that the list is exhaustive. A method signature replay(String md, List<RefinementRule> rules) tells the next session what the replay engine accepts and what it returns. None of this requires reading the implementation. All of it is available from the declarations alone.

A dynamically typed codebase communicates the same information less reliably. A dictionary named rule might contain the same fields — or it might not, in some paths. A function named replay might accept a list of dicts — or it might accept a single dict, or something else, depending on the call site. The next session must read more code, make more inferences, and carry more uncertainty before it can reason accurately about what the system does. That uncertainty is not eliminated by reading further — it is reduced, incrementally, with each additional piece of code that confirms or challenges the inference. In a large codebase, the inference is never fully resolved.

The design implication. If the code is the sole continuity mechanism for LLM-first development, then the design of the code is also the design of the continuity. Every structural decision — whether to use a record type or a dict, a sealed class or a string constant, an explicit interface or an implicit convention — is also a decision about how much information the next session will have available when it begins. Well-named record types, explicit data contracts, and compiler-enforced interfaces are not merely good software engineering practice. They are session continuity infrastructure. Designing for LLM-first development means designing code that communicates its intent to a reader with no prior context, because that is exactly the reader the next session will be.

This reframes the verbosity argument one final time. The additional declarations in a statically typed language — the type annotations, the record definitions, the explicit interfaces — are not overhead. They are the mechanism by which architectural intent survives the session boundary. The untyped Python dict that saves five lines of declaration also withholds five lines of verified structural information from the next session. That information must either be reconstructed by inference, carried in separate documentation that may be stale, or simply not known. Against Pydantic-modelled Python the gap narrows (see Section 2); compile-time-verified structure remains more reliably available to a cold-reading session than runtime-enforced structure.

Tests as a further reinforcement layer. Before making this argument precisely, it requires a qualifier: Python’s testing ecosystem is in many respects more expressive than Java’s. pytest fixtures provide dependency injection more flexibly than CDI test context; @pytest.mark.parametrize is more concise than JUnit 5’s @ParameterizedTest; the hypothesis library provides property-based testing with no equivalent in the Java ecosystem. The testing advantage claimed here is not general — it is specific to one property that statically typed test suites have and Python tests do not.

That property: in a statically typed codebase, tests interact with the typed API under compiler verification. A test that calls RefinementReplay.replay(md, List.of(rule)) and asserts result.refinedMd().contains("``java\n”)` is simultaneously a behavioural claim and a compiler-verified usage example of the exact API surface. The compiler ensures the test is using the API correctly — the method exists, the argument types match, the return type has the accessed methods. This is verified at the moment the test is written, not at the moment it is run.

In Python, the behavioural specification is present but the structural verification is not. A test calling a function with a dict argument cannot verify at write-time that the dict has the right shape; the test passes until the wrong shape is provided at runtime. When the development model is TDD — tests written before implementation — statically typed tests give the specification a dual role from the first compile: behavioural claim and structural proof. For future LLM sessions reading the codebase cold, the test suite provides compiler-verified usage examples that reinforce the type declarations throughout. This specific advantage is real. The broader claim that Java tests are generally superior to Python tests is not one this series makes.

5. Among Statically Typed Languages: Why Java?

The four sections above argue for static typing over dynamic typing in LLM-first development. That argument applies to any statically typed language — TypeScript, Go, Kotlin, C#, Rust, and others all share the advantages over Python described here. The question of which statically typed language to choose is a separate one, and deserves an empirical answer.

The table below compares six candidates across dimensions relevant to LLM-first development of application software.

Dimension TypeScript Go Kotlin C# Java Rust
LLM generation quality Very high Good Good Good High Moderate
Type system for application code Good† (Excellent w/ strict mode) Good Excellent Excellent Excellent Excellent‡
Type system escapable? Yes without strict; Hard with strict Limited Hard Moderate Hard Near-impossible
Enterprise installed base Web/frontend Cloud/infra Android/growing Microsoft shops 57% app server market Systems/emerging
Deployment as embedded server Node bundle Single binary JVM / native .NET / AOT Uber-jar / native Single binary
Startup time Fast Very fast Fast (w/ Quarkus) Fast (AOT) Fast (w/ Quarkus) Very fast
LLM training data volume Very high Good Moderate High High Moderate
Verbosity (2025) Low Very low Low Medium Medium (improving) Medium
ML / data science ecosystem Weak Weak Via JVM ML.NET limited Via JVM / DJL Emerging
Integration contract tooling TypeScript APIs gRPC / protobuf Same as Java .NET ecosystem OpenAPI / JAX-RS Strong
Cold-read legibility for LLMs High High High High High Moderate
Concurrency model (app code) async/await§ Goroutines ✓ Coroutines ✓ async/await Virtual threads + structured concurrency ✓ async (complex)
Native binary option No (needs Node) Always Yes (Kotlin/Native) Yes (AOT) Yes (GraalVM) Always
Multi-vendor governance Microsoft Google JetBrains Microsoft Multi-vendor (OpenJDK) Rust Foundation
Value types / zero-overhead data No Yes (structs) Partial (inline classes) Yes (structs) Arriving Java 27–28 Always

† TypeScript in strict mode (noImplicitAny: true, strictNullChecks: true, typescript-eslint banning any) provides type guarantees that substantially close the gap with Java for application code. Modern TypeScript projects at scale (Next.js, tRPC, Prisma) enforce strict mode as a baseline. The “Good” rating reflects the modal case; strict-mode TypeScript deserves “Excellent” on this dimension. The same LLM default-generation asymmetry applies as noted for Python: LLMs do not currently default to generating TypeScript with strict mode enforced, and any appears in LLM-generated TypeScript without explicit instruction. The type safety advantage of strict TypeScript is real; reaching it requires active enforcement.
‡ Rust’s type system catches an additional class of errors — memory safety and data races — via its ownership and borrowing model. These are valuable for systems programming. For application development, a garbage collector already handles memory safety, making Rust’s additional constraints a complexity cost without commensurate benefit. Rust’s borrow checker is also the primary reason LLM generation quality is lower: the compiler rejects ownership violations that LLMs produce more frequently than humans, requiring additional correction cycles.

§ Python’s GIL historically prevented true multi-threaded parallelism. Python 3.13 introduced free-threaded builds (PEP 703) that remove this constraint as an official CPython release. Current caveats: opt-in, C extension compatibility incomplete, still stabilising. Python 3.14 is expected to mature this further. The asyncio model remains dominant for I/O-bound concurrency; free-threading specifically addresses CPU-bound parallelism. See Technical Companion, A2.

Developer distribution (Stack Overflow 2024, 65,000+ respondents): TypeScript 38.5% · Java 30.3% · C# 27.1% · Go 13.5% · Rust 12.6% · Kotlin 9.4%. RedMonk January 2025 rankings: Java #3 · C# #5 · TypeScript #6 · Go #12 · Kotlin #14 · Rust #19. TypeScript leads Java in overall developer count; Java leads in enterprise backend specifically, where it holds approximately 57% of the application server market (Grand View Research 2024).

Reading the table. No single language dominates across all dimensions. TypeScript leads on LLM generation quality and training data volume. In strict mode, its type system is substantially stronger than the modal-case “Good” rating suggests — approaching Java’s level for application code. The table’s TypeScript rating reflects the default generation state; strict-mode TypeScript deserves higher marks on type safety dimensions. Go leads on simplicity and binary deployment, making it the strongest choice for cloud infrastructure. Kotlin is arguably the most technically capable JVM option — more concise than Java, with built-in nullable safety — and is a legitimate alternative for teams already comfortable with it.

The Java-specific argument. Java’s case is not that it is technically superior on most individual dimensions. It is that the combination it offers for enterprise backend application development is unmatched:

The largest enterprise installed base — by a substantial margin — means existing Java infrastructure, tooling, hiring pipelines, and institutional knowledge are already in place for most large organisations. This is a human-team-context argument, not a technical one, and the series acknowledges the apparent tension: Part 1 criticised human familiarity as insufficient to choose Python when technical merits favour Java. The distinction is that here, human factors compound an already-supported technical recommendation rather than substituting for one. The symmetrical concession: Python’s human familiarity is a real factor for teams with deep Python expertise using modern typed Python — the series argues it is insufficient to override the LLM-first technical analysis, not that it is irrelevant.

Quarkus specifically provides properties that compound the static typing advantages: fast startup that makes embedded server deployment viable, the uber-jar packaging model that suits desktop and cloud distribution alike, JAX-RS annotations that make REST endpoint patterns consistent for LLMs to generate and review, CDI that makes dependencies explicit, and OpenAPI generation that makes integration contracts machine-readable. These are framework properties, not language properties. OpenAPI generation from typed endpoints is not Java-exclusive — FastAPI/Pydantic provides it equivalently for Python. The Java-specific advantage is that when consuming clients are also Java, API contract changes propagate as compilation failures rather than runtime mismatches. The other Quarkus properties — fast startup, uber-jar, CDI, annotation consistency — are more distinctly Java/Quarkus-specific in the enterprise application development space.

The JVM ecosystem’s decades of enterprise tooling — monitoring via Micrometer, tracing via OpenTelemetry, APM integration, mature build tooling via Maven and Gradle — is available without configuration work that comparable ecosystems require.

The multi-vendor governance of OpenJDK — with Oracle, Red Hat, Amazon, Microsoft, and Google all contributing — means no single-vendor language risk for organisations with long planning horizons.

The Panama / Valhalla / GraalVM roadmap provides a concrete, tracked path to closing the remaining gaps with Python’s scientific computing ecosystem, on a timeline visible from today’s Java releases. (See Part 4 of this series.)

Part 4 of this series includes a visual timeline diagram showing which Java ecosystem gaps are already closed, which are closing on a defined schedule, and which remain open — across six gap categories from Java 21 through Java 28.

The honest note on Kotlin. Kotlin shares the JVM, runs on Quarkus, and has technical advantages over Java in several dimensions: null safety enforced by the type system, more concise data classes, cleaner coroutines. The series’ reasoning on this requires care.

The only LLM-specific technical argument for Java over Kotlin is that teams already on the JVM already access the same Quarkus ecosystem, performance characteristics, and static typing advantages that Kotlin would provide — Kotlin’s technical improvements don’t add to the LLM-first benefits for teams already there. Beyond that, three practical considerations favour Java for enterprise contexts: a directed governance model (JetBrains-led development, Kotlin Foundation oversight) vs OpenJDK’s multi-vendor community governance — a real enterprise risk factor for organisations with long planning horizons; a substantially smaller developer pool (9.4% vs 30.3%, Stack Overflow 2024); and more LLM training data for Java-specific patterns.

For greenfield development without existing JVM investment, Kotlin’s technical advantages — null safety, concise data classes, cleaner coroutines — are genuine LLM-first considerations the series’ own analysis supports. Teams already using Kotlin should not read this series as an argument against it. The static typing arguments apply in full; the JVM-specific properties apply equally. The series recommends Java as the modal enterprise starting point for teams already in the Java ecosystem, not as a universal recommendation.

Closing

The five arguments developed here — at generation time, at review time, at scale, as a continuity mechanism, and as a test reinforcement layer — share a common structure. Each identifies a property of static typing that is genuinely more valuable in LLM-first development than in human development: specifically and measurably more valuable when the implementer generates text rather than types it, begins each session without memory, and may be working simultaneously on multiple integrated systems without real-time coordination.

Taken individually, each argument is modest. Taken together, they describe a compounding effect. The code that is cheaper to generate correctly is also easier to review accurately, which is also easier to navigate across sessions, which is also easier to integrate at scale, and which is also easier to verify through a type-reinforced test suite. The properties reinforce each other. A codebase that earns the first advantage tends to earn the others.

Part 1 of this series argued that the case for Python as default had not been examined. This article has examined what replaces it — for any statically typed language, and for Java specifically. Part 3 documents what that examination looks like in practice: a completed migration, a working system, and the evidence of what the port revealed.

References

  • The Debugging Decay Index: Rethinking Debugging Strategies for Code LLMs — arxiv.org/html/2506.18403v2
  • Mündler, He, Wang, Sen, Song, Vechev — Type-Constrained Code Generation with Language Models — PLDI 2025 (94% of compilation errors are type-related) — arxiv.org/abs/2504.09246
  • LLMs Love Python: A Study of LLMs’ Bias for Programming Languages and Libraries (2025) — arxiv.org/html/2503.17181v1
  • LLM Token Optimization: Cut Costs & Latency in 2026 — redis.io/blog/llm-token-optimization-speed-up-apps/
  • Stack Overflow Developer Survey 2024 — survey.stackoverflow.co/2024/technology
  • RedMonk Programming Language Rankings January 2025 — redmonk.com/sogrady/2025/06/18/language-rankings-1-25/
  • Grand View Research — Application Server Market 2024 — grandviewresearch.com/industry-analysis/application-server-market
  • JetBrains State of Developer Ecosystem 2024 — jetbrains.com/lp/devecosystem-2024/
  • Project Panama (JEP 454) — stable Java 22 — openjdk.org/jeps/454
  • Project Valhalla (JEP 401) — openjdk.org/jeps/401
  • Quarkus REST client and OpenAPI documentation — quarkus.io/guides/rest-client

For technical supporting arguments referenced in this article (A1, A3), see the Technical Companion document published alongside this series.

<
Previous Post
When the Machine Codes: Against the Python Default in LLM-First Development
>
Next Post
When the Machine Codes: From Python to Quarkus — A Migration Playbook