引入
低代码越来越火了。低代码并非不需要专业工程师，只是尽量少写代码文本。如果低代码仍然需要专业的工程师，那低代码的优势究竟在哪里?工程师会不会因此而失业呢?
分析
真实的优势
那么不写代码，如何实现程序呢? 一般是通过控制块加输入输出来构造程序，也就是用图来表达程序结构。
那么我们就抓住了第一个差异，一个是用「流程图」，另一个是用「文本码」。
这两者之间有何差异？
其实最先看到的就是一个直观的差异。小孩子都知道的道理，看一幅画比看一封信要简单。这里面就在于：
「流程图」的信息密度低
「文本码」的信息密度高
因此，这里可以看出低代码的第一个优势：
通过降低信息密度，增加可读性和可维护性
不要小看信息密度的降低这一点。信息密度的降低，可以大幅降低认知成本，对应的就是人力成本。
再者，如果玩过图形化机器人编程工具，你就可以知道，构造控制流的单元结构是非常有限的，而且输入输出的确定性是非常高的。所以甚至是小孩子，能够理解顺序、分支、循环和基本的数理逻辑后，就可以构造程序了。而且其图形化界面会阻止你瞎搞，并且告诉你不能瞎搞，即除了正确的使用外，绝不可能出错。
思考一下大学的时候学习C语言的过程，少写个分号，循环就不一样了；指针操作变一下，意思就不同了。这代表什么? 这代表代码的灵活性是非常高的，高到你意识不到的错误都可以成为合法的操作。有句黑话怎么说来着，不要修这个bug，因为我们的功能依赖它。
因此，我们可以知道
「流程图」的流程单元结构灵活性更低
「文本码」的代码语法结构灵活性更高
这里可以总结出低代码的第二个优势：
通过限制灵活性，降低出错概率，提高可靠性
虚假的优势
低代码不需要工程师
有些文章在宣传低代码可以让90%的工程师下岗。这句话虽然不见得错误，但是明显是误导读者，让读者认为低代码就等于不需要工程师，低代码可以让所有人都拥有编程能力。这个理解应该是错误的。
上面我们分析了，低代码是降低复杂度和出错概率，但是其并不改变问题本身的规模，也不会改变问题本身的性质。即我们仍然需要有经验的工程师对问题本身做抽象建模，并工程化实现，这一点永远不会变。持续认知业务实质的能力，与持续支持工程实现的能力，永远是工程师的核心技能。
低代码与人工智能结合可以替代掉工程师
这也是一个错误的认知。但我的意思并不是否认有人会失业。我的意思是真正的工程师是不会失业的。人工智能这个词其实更多的表达的是人自身的一种期望，本质上目前的所有已经实现的人工智能，即使是类人的智能，都无法摆脱一点，即它是解决已经被定义的问题的工具，即人工智能并没有主体性。工程师首先是人，是有自己的主体性的，是可以定义问题，决定目标是什么的。有人工智能的帮助，工程师可以更好的专注于目标，而不是手段，这可以让工程师更多的关注到目标本身，这是对人的一种解放。所以真正的工程师并不会失业，而把自己定义为工具的虚假的工程师，注定会被淘汰。
总结
低代码是一种降本提效的工具，人工智能的加持可以让真正的工程师不被达成目标的手段所困，专注于更好的定义问题，从而解决问题。只有做一个真正的工程师，才不会被世界所淘汰。