Core Viewpoint - The core argument presented by Sean Grove from OpenAI is that the primary output of engineers should not be viewed as code, but rather as specifications that effectively communicate intent and values, bridging the gap between humans and machines [1][3][4]. Group 1: Code vs. Communication - The value created by engineers is largely derived from structured communication, which constitutes approximately 80% to 90% of their work, while code itself only represents about 10% to 20% of the value [8][10]. - Effective communication is essential for understanding user challenges and achieving the intended goals of the code, making it the true bottleneck in the engineering process [10][12]. - As AI models advance, the ability to communicate effectively will become a critical skill for engineers, potentially redefining what it means to be a successful programmer [11][12]. Group 2: The Superiority of Specifications - Specifications are considered a superior product compared to code because they encapsulate all necessary information without loss, unlike code which is a "lossy projection" of the original intent [24][25]. - A well-structured specification can generate various outputs, including code in different programming languages, documentation, and other forms of communication, thus serving as a more versatile tool [25][27]. - The OpenAI Model Specification serves as an example of how specifications can align human values and intentions, allowing for contributions from diverse teams beyond just technical personnel [27][28]. Group 3: Case Study - The Sycophancy Issue - The "Sycophancy Issue" with GPT-4o illustrates the importance of having clear specifications to guide model behavior and maintain trust with users [30][32]. - The existence of a specification that explicitly states "Don't be sycophantic" allowed OpenAI to address the issue effectively and communicate their expectations clearly [31][32]. Group 4: Future Implications of Specifications - The future may see specifications becoming integral to various fields, including law and product management, as they help align intentions and values across different domains [26][47]. - The concept of specifications could evolve into a more dynamic tool that aids in clarifying thoughts and intentions, potentially transforming integrated development environments into "Integrated Thought Clarifiers" [48][49].

整理 | 华卫 刚刚，OpenAI 正式对外推出了 AI 编码神器 Codex，其目前向 ChatGPT Plus 用户开放。据 悉，Codex 在限定时段内提供宽松的使用额度，但在需求高峰期间，可能会对 Plus 用户设置速 率限制，以确保其能广泛可用。 并且，现在 Codex 可以在任务执行过程中访问互联网了，用户可用其安装基础依赖项、运行需 要外部资源的测试、升级或安装构建新功能所需的软件包等。互联网访问功能将向 ChatGPT Plus、Pro 和 Team 用户开放，之后也将支持企业版用户。不过，该功能日常默认处于关闭状 态，在创建新环境或编辑现有环境时可随时启用。 "我们不再处于集成开发环境（IDE）时代了。我们进入了自主开发时代。"有网友激动地表 示，"这是一个能自行搜索、安装、编码、测试、修复错误并发布的 AI。"此前 OpenAI 的 CEO Sam Altman 曾坚称，到今年年底，AI 模型将能够超越初级软件工程师。 值得一提的是，在发布推出 Codex 前，OpenAI 首先宣布了用 Rust 重写 AI 命令行编码工具 Codex CLI 的消息，称此举可提升性能和安全性并避免对 N ...

Group 1 - OpenAI has rewritten its AI command-line programming tool Codex CLI in Rust to enhance performance and security while eliminating dependency on Node.js, which may frustrate some users [1][2] - Codex CLI is an experimental programming agent that can run in the ChatGPT web browser environment and locally, featuring a chat-based user interface that operates in both interactive and silent modes [1] - The source code of Codex CLI was originally in TypeScript and required Node.js, but the team has now completed the rewrite in Rust [1][5] Group 2 - The decision to rewrite in Rust is driven by four key reasons: zero dependency installation, sandboxing requirements, performance optimization, and the ability to reuse existing Rust-based Model Context Protocol (MCP) implementations [2][4] - The current tool requires Node.js version 22 or higher, which may pose a barrier for some users [4] - Rust's lack of a runtime garbage collection mechanism leads to lower memory requirements, contributing to performance improvements [5] Group 3 - The Codex project currently has a composition of 46.7% Rust, making it the leading language, followed by TypeScript at 44.7% [5] - Codex CLI will still support code extensions in other languages such as JavaScript and Python, although specific details are yet to be disclosed [5] - Vue creator Evan You has also praised Rust for its efficiency, noting that the new version of Vite, using Rust-based Rolldown, has reduced production build times by 3 to 16 times and memory usage by up to 100 times [6]

Core Insights - The article illustrates the paradox of success in technology, where a highly efficient system can lead to the perception that fewer developers are needed, ultimately jeopardizing the use of that technology [1][29]. Group 1: Technical Debt - The company had a traditional tech stack and needed to develop a real-time service to support 100,000 concurrent users, displaying user activity information [2]. - The initial choice of Ruby was deemed inadequate, prompting discussions on technology selection [3]. Group 2: Technology Selection Battle - The development team proposed using Rust, but management was cautious and requested comparisons with other languages [4][5]. - Concept validation versions were created using Elixir, Rust, Ruby, and Node.js, with Rust being developed by a novice [5][6]. Group 3: Performance Results - The performance results showed Rust as the fastest and most memory-efficient option, followed by Elixir, Node.js, and Ruby [8][10]. - The final decision favored Rust not only for its performance but also for its versatility in future applications [10]. Group 4: Rapid Development - Due to time constraints, a single developer with Rust experience was tasked to lead the project, collaborating closely with the team [11][13]. - The architecture was designed to handle 100,000 connections efficiently, utilizing a WebSocket-based API and in-memory data storage [14]. Group 5: Performance Challenges - The service performed stably under the expected load, but management later decided to shift it to maintenance mode, leading to a lack of oversight [16]. - The service was initially successful, but as the company expanded, management questioned the need for Rust developers due to the service's stability [19][20]. Group 6: Management Decisions - The new director's perspective led to the departure of experienced Rust developers, as they were deemed unnecessary due to the service's lack of issues [22]. - The decision to abandon Rust in favor of more mainstream technologies raised concerns about the existing Rust service's future [23]. Group 7: Node.js Rewrite Attempt - The attempt to rewrite the service in Node.js failed due to its single-threaded nature, which could not handle the required load [24][25]. - The company resorted to using a third-party service, which also proved inadequate [26]. Group 8: Lessons Learned - The Rust service continued to operate effectively but without a dedicated maintenance team, highlighting the risks of having a highly efficient system [28][29]. - The article concludes that sometimes, a less-than-perfect system may be perceived as safer, emphasizing the impact of management changes on technical decisions [29].

Core Viewpoint - The article discusses the paradox of a successful Rust project leading to its eventual abandonment within a company due to management changes and a lack of understanding of its value [2][12][15]. Group 1: Project Background and Development - The project took place in a rapidly growing unicorn startup that primarily used Ruby on Rails and Node.js, with no initial use of high-performance languages like Rust or Go [3]. - The team decided to develop a real-time service to support 100,000 concurrent users, leading to a comparison of different programming languages including Rust, Elixir, Ruby, and Node.js [4][10]. - Rust was ultimately chosen for its flexibility and performance, despite initial bugs, and the team completed the MVP in just two weeks [8][9][10]. Group 2: Performance and Stability - The Rust version outperformed others in speed and memory usage, successfully supporting 100,000 concurrent users without issues [10][11]. - After a month of stable operation, the service was put into maintenance mode as company strategy shifted, leading to the disbanding of the Rust development team [12][13]. Group 3: Management Changes and Consequences - A new management team, unsatisfied with the perceived lack of activity from the Rust service, decided to phase out Rust in favor of more familiar technologies like Ruby and Node.js [13][14]. - The decision resulted in the departure of three experienced Rust engineers, which was seen as a missed opportunity for the company to leverage Rust's capabilities further [15]. - Ultimately, the management's decision to rewrite the Rust service in Node.js led to complications and performance issues, highlighting the challenges of maintaining high concurrency with Node.js [16][17]. Group 4: Industry Insights and Reactions - The article sparked discussions among developers who shared similar experiences of successful projects being undervalued or abandoned due to management decisions [17][18]. - Many industry professionals noted that such occurrences are common in companies as they grow and management changes, often stifling innovation [18].

Core Viewpoint - The company initially adopted Rust for its advantages in speed, safety, and modernity, but ultimately banned its use due to the discomfort it caused within the organization by exposing inefficiencies and raising performance expectations [1][22][28]. Group 1: Initial Adoption of Rust - Rust was seen as an ideal choice for the company, promising rapid development and safety features [2][6]. - The first service rewritten in Rust was a high-traffic application that had significant memory leak issues, which Rust effectively resolved, leading to impressive performance metrics [7][17]. Group 2: Consequences of Using Rust - The development speed increased dramatically, with new features being developed in just three months, which was deemed unacceptable by management [10]. - The ease of hiring Rust developers led to an influx of highly qualified candidates, making existing engineers feel inadequate [12][14]. - The internal toolchain was found lacking compared to Rust's ecosystem, highlighting organizational inefficiencies [15][16]. Group 3: Organizational Response - The CTO held a meeting questioning if the company would still be bogged down by bugs and technical debt without Rust, leading to a decision to ban its use [20][21]. - The decision was framed as a response to Rust's ability to expose the company's inefficiencies and elevate performance standards that the organization was not ready to meet [22][28]. Group 4: Aftermath and Reflection - Following the ban, 90% of services reverted to using Go, which was seen as adequately slow and safe, aligning with the company's strategic approach to managing technical debt [23]. - The company expressed regret over the decision only when stability was desired, indicating a complex relationship with the efficiency Rust brought [25][26].

还记得不久前的那篇《"因为一次成功重写，我们 CTO 彻底封杀了 Rust！"》吗？ 当时，许多读者留言称这故事"离谱"得像是由 AI 杜撰的，其中就包括了本文的主人公——一位 Reddit ID 名为 Drogus 的开发者："一篇用 AI 生成的帖子"、"明显是假的"。 话虽如此，Drogus 却不由得联想到了一段他自己的真实经历，与其中某些情节有几分相似："Rust 项目 做得太成功，反而导致这门语言在公司内部被「判了死刑」"。 项目背景：一个快速成长的独角兽初创公司 Elixir 次之； Node.js 表现还可以，但受限于单线程运行时； Ruby 最慢。 值得注意的是，Rust 版本最初存在也一个小 bug：开发者用 async futures 给客户端发消息时，会遍历所 有客户端来获取发送通道列表，这在高负载下会阻塞运行时几秒。不过这个问题属于实现细节，对熟悉 Rust 的人来说并不难修复。 这件事发生在几年前。那时，Drogus 刚加入了一家在疫情期间快速成长的独角兽初创公司，其主力应 用采用 Ruby on Rails 编写，一些视频处理相关工具则用 Node.js 实现。当时，这家公司并没有 ...