马上 2027 了，还有人认为 AI 无法代替程序员么

替代的是单一的开发，前端、后端、移动端等等，新的岗位依旧是属于程序员的范畴，只不过名字可能叫什么 ai 全栈之类的。不过确实岗位缩减了太多，原本分工明确的全合并到一起了

我看 ai 写的还不错啊. 只是 ai 速度太快了,人根本看不过来.

程序员以后的竞争对手，估计不是 ai ，是能够熟练使用 ai 的程序员。前几天看到一个说法，说程序员是一个存量市场了

软件程序员是实打实替代了，搞硬件的还可以扛几年

字节码你也看不懂，但不耽误它有用。老板最爱说的一句话：到底能不能做？ 你应该升级下角色，下发任务，只管结果，不看过程。

替代什么水平的程序员？是直接完全替代，还是通过提高效率、抑制就业岗位的方式替代？

每个人说的“替代”可能意思完全不同。

替代到哪种程度？基础 CRUD 的当然可以了。那种业务很重的情况下，我认为不太行。

帮你想成产品策划 产品需要知道 代码什么样？ 能跑 性能达标 测试无 bug 管你什么语言框架呢

已经开始跑客户+写需求+开发了

替代什么，你们公司是产品经理直接写代码？

讨论这种问题首先得明确程序员的定义。
如果是指 XX(语言)开发，那么确实已经完蛋了。
如果是广义上的程序员，只有还有自研需求就还是得有人肉的程序员。

----

在我刚入行的时候，研发岗的工作内容里面就包含了需求对接、原型设计、服务端开发、客户端开发、测试、部署、运维这些几乎全流程参与。甚至还有一部分售后的使用支持与问题解答工作。
也没有语言限制，基本上客户都是按照客户要求来开发，没有特殊要求就按照个人熟练度来决定。直到 15 年左右开始细化岗位才开始重点聚焦于某几个环节和语言。所以现在对我来说 AI 只是帮我彻底从其中的某几个工作中解放出来。

代替不了我 我比 ai 便宜

@shangguanshaofu

不记得在哪儿看到的，只要一天还存在需要把人类语言转换成计算机可识别的一个过程，那就一直需要程序员这份职业存在，我在想可能未来某一天，脑机接口实现了？可能那时候就不需要程序员了吧。

@shangguanshaofu 扯淡，200 刀的 claude ，能干的事肯定超过你一个月干的事

能明确的是不再需要这么多人了，需求没有增长

现在替代掉 50%，两年后 80%

ai 能担责吗，这才是问题
它写的再好出问题了找谁

大部分情况确实比人强，但是它不能作为责任人

不能叫替代吧，只能叫共存

我觉得可以吧。


我想想，随便几个例子好了。

你要 RAG ？我不懂 RAG ，让我先打开 Codex ，然后跟他说「我要部署一个 X 公司的 Y 技术栈里使用 Z 模型的 workflow ，我需要在这里部署 RAG ，…（以下省略 1000 字）」（当然实际上没这么简单，需要的 prompt 数量和复杂度远比这个看起来轻松的要复杂得多，但原理差不多：

- 你要 Langchain ？那我打开 Claude Code ，把你给我的客户相关的需求信息 parse 进去，我自己再和 Claude 闲聊一晚上，Claude 自己跑一晚上第二天给你一整个工程项目还有个 handoff.md
- 你要什么 AI native 的 CI 管线？我用 Codex ，一样道理，再顺便把云端环境配好，GitLab 金钥接上，subagent 传完 credential 自己就关掉了，连你和我都拿不到，下次更新或者访问 CI 得你自己来，但没关系，handoff.md 给了指令
- 你要 Anthropic 认证？可是我没那么多精力，我直接让 Codex 帮我 computer use ，但问题是这违反认证机构的规则，所以我没法做认证，这不是我的问题，只是合规限制
- 你要配 Opencode 或者 pi 的运行时？参见前几条
- 你要配 oh my codex ，参见前几条，再顺便送你个 onboarding 下一个 agent 的 handoff

流程很简单：跟 agent 聊一晚上后，程序员睡觉去了然后让 agent 自己跑，也许 3 小时，也许 6 小时，权限全开（当然，B 端的时候不能这么做，那可以再开个 Claude Code 设计个 classifier ，做一轮测试，然后程序员继续滚去睡觉）。

这样的话，只要把中间这个「人」也拿走，那应该就可以完全不需要程序员了，我猜？毕竟软工总喜欢说 bus factor 。一个需要睡觉的程序员，这个 bus factor 等于一，可太严重了。拿走这个程序员，bus factor 清零，应清尽清。

AI 在没有自主意识之前，现阶段还依然只能是工具，还要靠程序员来指挥，现在用的大多数互联网产品和 APP 有几个是非程序开发出来和维护的，等真能替代了，人存在意义也没多大了。

今天 gemini 又写了好几个 final 又 final ，好几遍才通过。
即便是才 500 行的代码，需求还是人提供的。AI 根本不会提供 100%高效的代码。
就这么个日志呈现系统，每天发现点新问题。AI 自己都没经过测试 final 又 final N 遍也是很服。缺乏相关经验，惊艳于 AI 代码能力，细节仍得精敲细打。

回顾今天（ 2026 年 11 月 04 日）我们在本项目中协同推进的核心修改和功能迭代，主要完成了以下 4 项关键优化：
* 锚点架构回退与历史归档回溯（$historyDaysBack ）
* 将 PowerShell 脚本回退到了最稳定的 2026-11-04 经典底座，彻底移除了所有容易在 Windows Server 2019 (PowerShell 5.1) 环境下引发 Unexpected token '}' 解析报错的嵌套函数和三元运算符。
* 实现了跨天多文件归档日志的自动回溯与合并加载（支持配置 $historyDaysBack = 3 ，在重启时自动按时间先后顺序合并前 3 天的归档日志与今天的实时日志）。
* 保留核心保障机制
* 确保了 Instant Rotate “用完即放”（ Poll & Release ）架构的稳定运行，流式读取后立刻 Dispose 关闭文件流，99.9% 的时间文件无锁，完美放行 Visual Syslog 的日常自动 Rotate 归档重命名。
* 维持了 ConcurrentQueue 环形队列硬隔离与周期性 [System.GC]::Collect() 垃圾回收机制，使监控系统长期运行时的内存稳稳锁定在 100MB 级别。
* OpenWrt 与华为交换机时间戳格式强归一化
* 解决了 OpenWrt （原生双空格如 Nov 4 ）与华为交换机（单空格如 Nov 04 ）时间格式不统一的问题。
* 在 logdy.config.json 的解析中间件中加入了强力的时间规范化逻辑，自动将单/双空格及个位数日期补零，统一转换为标准双字符格式（如 Nov 04 10:35:19 ）。
* Logdy 全局搜索框精准命中优化
* 为了彻底解决在 Logdy 搜索框无法通过 Nov 04 搜到 OpenWrt 日志的痛点，直接在中间件底层对 line.content 原始内容进行了原地替换（ Normalized ）。
* 现在无论是前端表格展示，还是顶部的全局关键词搜索（输入 Nov 04 ），都能百分之百跨设备精准命中所有厂商的日志。

说几个角色，以前觉得不可能，现在已经被完全代替了的
1 、公交车售票员，可以说完全被替代了，老北京有是因为政策原因
2 、电梯驾驶员，这个估计年轻人都不知道曾经有这个么角色，对就是帮你按电梯的那个人
3 、地铁司机，我看过驾驶室，司机在那里也是完全啥都不用干

@datocp 是 Gemini 太拉胯，换 opus 5.5 体会震惊瘫坐。

还是水平太菜，不会用。。。
之前学习过用文本定义来让 gemini 高效运行，可能不会用效果比较差。
平时简单的对话 gemini 写，我来反馈运行结果，昨天给它限定了 server2019 它才写了适用的代码。

"黑灯运行半年后，系统还有人看得懂吗？"
> “当越来越多代码没有被人类真正读过，组织会逐渐累积一种新的技术债——理解债。系统正常运行时，它很难被察觉。直到周六凌晨出现 P0 事故，值班工程师面对一段完全由机器生成的故障代码，却不知道从哪里开始排查。”