AI抢走了写代码的饭碗，工程师还能干啥？

    我认为对于一位研发，一个工程师最为重要的能力指标就是其搭建系统的能力。
并且随着AI大模型技术的迭代升级，这点的重要性会更为凸显出来。因为Coding Agent和各种AI编辑器正在将研发工程师的生产力从业务、功能、代码的实现中解放出来 (目前保守来看至少有30%的增长)，未来工程师的任务将更多的从实现、落地端，转向设计、架构、规范端。
    其实，编写代码本身也是搭建系统的每一块砖木，每一砌水泥。有了Coding Agent的帮助，就好比雇了个长工，我们只需要承担设计者和裱糊匠的角色，便足以支撑一个稳定输出生产力的系统。编写架构设计、业务功能设计、模块边界和数据规范，会在研发工作中拥有更多的占比。以前，我们需要一个大的技术团队才能支撑一个大的系统，我们需要许多工程师承担不同的角色，有些工作甚至是内部平台、内部工具或者内部流程自动化的业务，例如大厂都会有的CICD自动化平台、日志上报跟踪系统、甚至是各种插件，这些业务平台的搭建是项目体量增长后的必需品。现在，我们即使不去畅想OPC的创业模式，我们也能看到，工程师现在可以借助agent做更多的事情，如果他本身就是一个多面手，一个架构师，他的能力将会被几何级的放大。市场对软件系统的需求不会因为AI时代的来临而减少，会细分和个性化，我们需要更多轻量级、可维护、可拓展的稳定系统，甚至工程师的能力横跨至硬件层面也有可能。
    现在因为AI爆发而引起的裁员热和初级岗位的减少，我觉得一方面是现有的互联网公司打着AI生产力的旗号，对于繁荣期招聘的冗余人力的裁剪（但未来依旧需要工程师），另一方面受到AI能力突飞猛进带来的震撼，我们过于放大对于AI落地生产产品的期望，而忽略了一个人草草上线雪崩，技术债台高筑，业务难以拓展维护的Web/APP产品，本身就不足以称之为一个完整的系统。系统不仅是项目稳定的架构、安全的规范边界和可用性，甚至可以是生产流程的重构。
    就好比之前提到CICD自动化平台和日志流程跟踪系统，在小公司可能上线发版出了问题只能回退一个一个排查，数据出了问题一个一个数据库的查找，而大厂可能上线推流时正好可以泡个咖啡，如果线上出现问题，有自动化的飞书预警和线上日志监控，更可以通过traceID实时跟踪每条数据的访问路径和实体内容。这样的工作本质上是把依赖于人的业务，变成了依赖系统的业务，只要这套系统搭建起来，整个项目就能稳定运行。以后也会是这样。
    我之前实习的时候一直想不明白为啥我的LD希望我不要过于关注眼前的活怎么干，而是要主动发现问题，如编写业务时涉及的每个模块，它的职责和边界，以及使用的每个工具背后的工作模式和底层原理是什么样的。于是，我逐渐学会了主动探索任何我不懂的东西，积累了边界以外的知识，才能跨越能力的边界。某种程度上来说，也是在引导我走向一个能力完备、懂需求又知晓原理的工程师角色，如果再加上不息的探索欲，就能不断迭代自身的生产力，做更多的事。
    能理解产品业务场景和技术架构设计，主动搭建出自己的系统，才是走向更高级的工程师的第一步。