C -> Java != Java -> LLM

C -> Java != Java -> LLM
C –> Java != Java –> LLM

原始链接: http://www.observationalhazard.com/2025/12/c-java-java-llm.html

大型语言模型（LLM）正在革新软件开发，但其影响不同于以往的转变，例如从汇编到Java的转变。之前的转变从根本上*改变*了中间产物——源代码本身，需要新的工具、范式和工作流程。然而，LLM主要*增强*了现有流程。中间产物仍然是传统的源代码（Java、Python等）。我们仍然从提示到源代码，然后完善代码，最终构建二进制文件。 LLM加速了这个过程，但并没有取代架构、审查和协作源代码的核心需求。这意味着既定的软件开发实践在很大程度上仍然存在，只是速度更快。作者提出了一种潜在的未来转变，即转向动态、解释型语言作为中间产物，从而实现对正在运行的程序的即时、提示驱动的更改——这是一种由LLM实现的真正新的工作流程。

一个黑客新闻的讨论围绕着大型语言模型（LLM）在软件开发中的潜力。一位评论员认为，如果LLM能够可靠地处理高度详细的规范，并为模糊之处做出“合理”的决策，那将代表着向确定性代码生成的一个重大转变。然而，另一位用户驳斥这篇文章是又一次LLM炒作的例子，认为“感觉编码”——依赖直觉和快速迭代——才是当前的现实。他们担心LLM正在通过生成低质量的AI生成文档，从而*损害*软件开发，并有效地终结了全面的人工编写的“阅读手册”资源。这场对话凸显了LLM驱动的精确性与对其代码质量和文档影响的实际担忧之间的紧张关系。

原文

Many have compared the advancements in LLMs for software development to the improvements in abstraction that came with better programming languages.

But there’s a key difference. While the end product of software development, a binary, has never drastically changed its form (though its distribution has radically changed), the intermediate product did with programming language transitions.

The intermediate product is the source code itself. The intermediate goal of a software development project is to produce robust maintainable source code. The end product is to produce a binary. New programming languages changed the intermediate product. When a team changed from using assembly, to C, to Java, it drastically changed its intermediate product. That came with new tools built around different language ecosystems and different programming paradigms and philosophies. Which in turn came with new ways of refactoring, thinking about software architecture, and working together.

LLMs don’t do that in the same way. The intermediate product of LLMs is still the Java or C or Rust or Python that came before them. English is not the intermediate product, as much as some may say it is. You don’t go prompt->binary. You still go prompt->source code->changes to source code from hand editing or further prompts->binary. It’s a distinction that matters.

Until LLMs are fully autonomous with virtually no human guidance or oversight, source code in existing languages will continue to be the intermediate product. And that means many of the ways that we work together will continue to be the same (how we architect source code, store and review it, collaborate on it, refactor it, etc.) in a way that it wasn’t with prior transitions. These processes are just supercharged and easier because the LLM is supporting us or doing much of the work for us.

As an aside, I think there may be an increased reason to use dynamic interpreted languages for the intermediate product. I think it will likely become mainstream in future LLM programming systems to make live changes to a running interpreted program based on prompts. The hit run refresh cycle will be reduced to zero. That will be vibe coding to the max. Perhaps this is already more mainstream now than I’m aware.

C -> Java != Java -> LLM C –> Java != Java –> LLM

C -> Java != Java -> LLM
C –> Java != Java –> LLM