好问题。这个问题可以拆解成两个：谁来做，怎么做。
谁来做：“人人都是开发者”，只是分工不同。技术人员为主，业务人员为辅，技术人员（特别是架构师、高级开发人员）在多个团队/项目间共享
怎么做：多岗位协作，各司其职。普通技术人员和业务人员做页面、增删改查等简单的业务逻辑；开发人员做复杂的、核心的、高性能的业务逻辑；高级开发人员或架构师负责审查和指导系统功能划分、数据库设计和架构。
总之，用低代码开发是一个团队协作的过程。大型、核心业务系统，专业开发人员参与更多；小型、边缘业务系统，业务人员参与更多。这是一套被国内外一线厂商广泛验证的方法论，正是这套方法论，让低代码从“玩具”变成了“工具”，被软件公司和大企业IT部门看中，被用于高价值的核心系统开发。
此外，最近加了一个某丰银行（比较敏感）的技术交流，请了做低代码的外部公司，重点讲了低代码时代开发团队的构成和开发方式。截几张图分享给你看看吧。
企业在开始低代码开发之前，需要且必须了解以下这些重要信息：
平台集成性：即低代码平台是否与企业现有平台集成？大多数低代码平台允许通过API调用现有服务，并提供用于访问数据和服务的API，但并不是所有的平台都能实现这一功能。
成本：虽然低代码平台都是订阅制服务，但是不同平台的订阅价格还是有差异的，比如有些平台是年费制，有些平台则是按用户数付费。企业一定要提前了解清楚。
平台使用者角色：企业是否有开发人员或者开发团队负责将低代码平台与现有系统和软件集成。在开始使用低代码平台之前，公司需要考虑由谁来执行。
平台适用性：企业要考虑到应用平台是否适应业务和客户不断变化的需求，并不是所有低代码平台都有超强个性化能力的。
企业希望交付哪些应用？
每个低代码工具都提供不同领域的功能，包括业务流程、工作流和审批流——
审批流：比如一张报销单据的逐级审批，审批流上的活动仅改变审批状态。
工作流：比如一个工单需要多个环节的人处理后才能完成。不限于审批，涉及改变的单据状态也比审批流多而复杂。
业务流：比如依据请购单->采购订单->采购发票。业务流要处理上下游单据之间的数据映射、转换、合并或分单。
更多详细的应用搭建教程，有需要的可以找我哦
这种模式的低代码开发平台主要代表有MyApps低代码平台，他们的产品完全采用引擎式开发模式，整个过程都是可视化操作模式，不需要编码即可进行打包、编译及发布，开发和效率得到了极大的提高。用户通过少量代码即可以快速构建出OA协同、公文督办、KM文库、项目管理、采购管理、生产管理、供应链管理等一些列职能类和业务类管理系统。
第二种便是源码生成模式，这种模式主要通过桌面式设计器来定义业务模块，辅助生成源代码框架，然后用户可以在生成的源代码的基础上去编写、修改自己的源代码来实现业务逻辑，因此生成源码模式也可认为是一种代码生成器。这种模式对开发人员的要求比较高。本回答被网友采纳