我觉得有几个原因：

1. 大多数受雇于公司的程序员没自由发挥的机会。什么需求都是由产品经理定的。AI 产生代码的速度受限于大公司产品经理产生需求的速度。

2. 大多数程序员产生的是业务脚本。当需求已经确定的时候，代码实际上也确定了。这种业务脚本，程序员需要花大量的时间来对接与其它人写的黑箱业务模块。

3. 拿 AI 改旧代码并没有太多的改进。因为在旧的代码上面修改要防止 AI 破坏旧的代码功能。AI 一通瞎改，修起来特别麻烦，还不如人工出手。

4. AI 适用创新型的代码。可以帮助程序员进入各种不熟悉的领域。但是对于程序员已经非常熟悉的领域，未必有多好用。
--
修改:hgoldfish FROM 59.61.208.*
FROM 59.61.208.*

别的不说，让ai分析个c++内存泄露估计都搞不定，不然没有rust什么事了。



【 在 hgoldfish 的大作中提到: 】
: 我觉得有几个原因：
: ...................
--
FROM 222.129.50.*

有些代码没办法微服务，比如Linux，cpython,oracle，chrome。。。。当然这些大部分人都接触不到。


【 在 hgoldfish 的大作中提到: 】
: 可以拿来分析这种 sh*t 山代码。
: 不过想在里面改的话，还是算了吧。
: 在 AI 时代，应该用好微服务这一坨。发现有人离职，最佳的办法不是找人去接手 sh*t 山代码，而是让新人用 AI 重写一遍。说不定可以做得更好更快。
: ...................
--
FROM 222.129.50.*

你说现在的AI会不会 把本地的代码，上传到云端，或者的把本地代码分析之后上传？

现在很多公司会不会有这种顾虑你
现在很多鼓励使用的AI写代码的，会不会被当作 素材生产者罢了

【 在 hgoldfish 的大作中提到: 】
: 我觉得有几个原因：
: 1. 大多数受雇于公司的程序员没自由发挥的机会。什么需求都是由产品经理定的。AI 产生代码的速度受限于大公司产品经理产生需求的速度。
: 2. 大多数程序员产生的是业务脚本。当需求已经确定的时候，代码实际上也确定了。这种业务脚本，程序员需要花大量的时间来对接与其它人写的黑箱业务模块。
: ...................
--
FROM 120.244.54.*

你这个观点好像一直就没变过。
我还记得年初的时候,你这么说的时候,我还跟你讲。我用AI扩展了一个规模是100万行的项目。给其中一个4400行的一个python ext模块，用rust改写了。
那个时候还是claude3.5，一次还只能看200行。

到现在快一年了,AI的天都变了几层了，你这言论还是老样子，还觉得AI是一顿瞎改。还觉得AI不懂这个，不懂那个。
不过也正常,当初我也有好几个朋友也跟你一样。打电话说也没用。最后都是我当着他们面,花半天时间,在他们的机器上给他们做他们认为搞不定的事情。给他们亲自演示了一遍,他们才接受的。

跟水平没关系,人都是很厉害的人，都是acm队的。有一个还是google出来的,google都red alarm了，丫还在google员工群里舌战群儒呢，总之就是不愿意相信这一天已经到来了。

所以我说我现在也懒得说啥。
我前面说八仙过海各显神通，这只是不愿意说太透彻，比较委婉的说法。
真相是AI时代,你的核心竞争力由你跟AI的适应性来定义。
这是一道横在每个人面前的big filter，如何解决这个问题是每个人要自己去面对的考题。所以我只会点明现状，而不是分享这个分享那个，毫无意义。连我自己都不敢说我已经通过了big filter。
在过海之前,你只是人，等过了海,你才是仙，以后是神仙打架的世界。

另外，如果觉得我这段话太冷酷太傲慢，请珍稀这最后不多的还能看到我说这种话的日子。以后说不定我这个账号说话会非常有同理心，情绪价值拉满，说的话要多好听就有多好听。那肯定不会是我在说话。

【 在 hgoldfish 的大作中提到: 】
: 我觉得有几个原因：
: 1. 大多数受雇于公司的程序员没自由发挥的机会。什么需求都是由产品经理定的。AI 产生代码的速度受限于大公司产品经理产生需求的速度。
: 2. 大多数程序员产生的是业务脚本。当需求已经确定的时候，代码实际上也确定了。这种业务脚本，程序员需要花大量的时间来对接与其它人写的黑箱业务模块。
: ...................
--
FROM 116.233.45.*