Are business professionals using AI for software development more impactful than IT staff writing code manually?

Recently, I've seen many so-called business experts showing off their skills on social media platforms: with years of business experience and various small tools built with AI, which are small, specialized and highly scenario-aligned, they even claim that these tools can replace the information department. Some people also say that with AI tools like WorkBuddy now, technology has been democratized, and business experience is the most valuable asset.

So is this really the case in reality?

Lao Yang believes that when business personnel develop software with AI tools, they do have strong competitiveness, but the advantage does not lie in "replacing IT to write code", but in "bypassing the requirement translation chain and delivery queue of the IT department". The real problem is not only CI/CD, but that a large number of "developers without engineering awareness" suddenly emerge in the enterprise, whose tools will grow like weeds, being effective in the short term but likely turning into a governance disaster in the long run.

I. The Real Advantages of Business Experts + AI Coding: More Than Just "Speed"

"Business experience is the most valuable asset, and technology has been democratized" — this statement sounds reasonable at first glance. When business teams use AI tools for software development, they have the following advantages:

1. Requirement translation loss is almost zero.

The traditional path includes requirement submission, understanding, analysis, development and implementation, testing and acceptance. Each additional layer of translation brings a new layer of distortion. When business personnel develop tools on their own, they know exactly what they want, where the exceptions lie, and what results count as correct. AI only turns their ideas into code. With one less intermediate link, the delivery accuracy is greatly improved.

2. Long-tail requirements are activated.

Normally, when the business department wants to develop personalized system functions, they will turn to the information department, which is always prioritizing core systems, regulatory projects and platform construction. A large number of front-line "small and specialized" requirements, such as automatic cleaning of a certain report, automatic judgment of a certain approval flow, batch processing of a certain type of data, etc., often cannot be scheduled for processing. Now business personnel can build these tools in one afternoon with WorkBuddy, which is an effective supplement under the production capacity bottleneck, not a replacement.

3. Tacit knowledge is visualized and solidified.

The rules, experience and judgment logic in the minds of business personnel used to be difficult to be implemented in the system, but now they can be solidified through scripts and small tools with AI tools like WorkBuddy. Even if the tools are not perfect, at least the knowledge is recorded and reusable, which is an asset for the organization.

4. It forces business teams to understand data and processes.

Only when business personnel build tools by themselves will they realize for the first time that the data calibers are so inconsistent, the master data is so messy, and there are so many branches in the process. This process of "being educated by data" is far more effective than IT teams explaining data governance ten times.

5. Extremely low trial and error cost.

Business personnel can verify an idea with small tools, no need for project approval, no budget, and no need to wait for three months. If the idea works, they can then carry out engineeringization; if not, they can discard it directly, which is a typical agile exploration.

Therefore, it can be seen from the above five points that the advantage of business personnel using AI tools for system development does not lie in code quality, but in "domain judgment plus rapid verification". The code generated by WorkBuddy and ChatGPT may be of good quality, but the core competitiveness of business personnel lies in knowing "whether the generated content is correct, whether it should be used, and in which scenario it is applicable".

II. Deeper Hidden Pitfalls Beyond CI/CD

Many people will think of CI/CD when talking about business personnel developing with AI tools, but Lao Yang believes these are only superficial phenomena. The more serious problem is that once these self-built business tools enter the production environment, they become "shadow IT", whose destructive power goes far beyond iteration difficulties. The specific problems are as follows:

First, loss of control over security and compliance.

Business personnel generally do not understand the concepts of least privilege, data desensitization, PII protection, and multi-level protection requirements. They may pull production data to their personal computers for processing with Python, hardcode database account passwords into scripts, upload customer information to public AI platforms, and directly connect to the core system API without approval. The data leaked by one business tool may offset the compliance efforts of the IT system for a whole year, and the losses caused may even be higher than the cost of purchasing a set of standard software.

Second, data silos and caliber division are accelerated and deteriorated.

This is the most undesirable but unavoidable problem. In order to achieve the application effect of their respective departments, business personnel will pull data and calculate indicators separately. For the same "number of active customers", Department A calculates 100,000, Department B calculates 80,000, and Department C uses AI to generate a piece of SQL and calculates 120,000. In the past, data silos at least existed in databases controlled by the IT department, but now they are scattered in personal computers, temporary scripts, shared cloud disks, and online Notebooks, making all data governance measures completely ineffective.

Third, technical debt accumulates exponentially.

Code generated by AI often has no tests, no documents, no version management, all path parameters and environments are hardcoded, and it depends on a specific library version. Business personnel do not understand these at all. Worse still, the requirement can be modified the next day after the tool runs successfully today, but they do not know how to modify it; once the person leaves the job, the tool crashes; once the environment is upgraded, the tool breaks down. This is not technical debt, but a technical landfill.

Fourth, the responsibility boundary is blurred.

If a business tool miscalculates data and leads to decision-making errors, who is responsible? The business department says the code is generated by AI, the IT department says the tool is not built by them, and the AI vendor says the output is for reference only. In the end, no one takes responsibility, and only the enterprise itself bears the losses.

Fifth, the consistency of the architecture is broken.

In the future, the information department may face a more chaotic technical architecture. For example, the development department uniformly uses Java + Spring Cloud + K8s, while the business department may use Python, Node.js, Excel macros, low-code, and RPA. The result of this is that each tool becomes a silo: the operation and maintenance team does not know its existence, the security team does not know where it is running, and the architecture committee cannot manage it. It is far more chaotic than a single word "mess" can describe.

Sixth, supply chain and AI hallucination risks.

Due to the gap in professional capabilities, the open source libraries introduced by AI according to business requirements may have vulnerabilities, malicious code, non-compliant licenses and other problems, but the business department basically has no awareness of these problems until accidents happen. The information department has software supply chain management, while the business department does not. Business personnel may also over-trust the AI output: the SQL generated by AI has correct syntax but wrong logic, and the business personnel cannot understand the execution plan, so they think the output result is correct. Once the model version is updated or the prompt is fine-tuned, the result may be that the output is correct today but wrong tomorrow, and people will always be dealing with errors.

III. It Is Not "Business Replacing IT", But Division of Labor Restructuring

It is not difficult to see that the competitiveness of business personnel using AI tools for software development does not lie in writing better code than IT, but in bypassing the IT management system to quickly generate business value.

At this time, the information department needs to face the reality: the role of IT must change from "the builder of all software" to "the provider of platforms and governance". In the past, the value of IT lay in "implementation", but now implementation has been democratized by AI. The value of IT must be upgraded to platform engineering, data governance, security compliance, architecture standards, observability, and asset lifecycle management. If the information department still follows the traditional way of working, the final result may be marginalized, because the technical barrier that they used to be proud of has been broken by AI.

IV. How to Solve the Dilemma?

Lao Yang believes that enterprises currently need a set of "citizen development" governance framework system.

1. Set guardrails by classification.

Classify business tools according to risk levels:

Low risk: Read-only, no access to production data, no external exposure, no impact on core processes, can be self-service;

Medium risk: Read and write non-core data, internal use, with certain impact, need IT review;

High risk: Involving core systems, sensitive data, external services, capital compliance, must be led or deeply involved by IT.

2. Provide a controlled sandbox for business teams.

The information department needs to provide a unified data platform, API gateway, and development environment, with built-in identity authentication, permission control, data desensitization, audit logs, code scanning, version management, monitoring and alarm functions. Let business teams develop and test in the sandbox instead of directly connecting to the production database.

3. Encapsulate CI/CD into one-click release.

Business personnel do not need to understand GitLab CI, Jenkins, K8s. The information department provides a templated process: upload code, automatic testing, automatic scanning, deploy to the specified environment. Turn CI/CD into a platform capability, not a burden for business teams.

4. Establish asset registration and indicator dictionary.

All business tools must be registered, and the data source, indicator definition, person in charge, and usage scope must be recorded. Enterprises build a unified indicator dictionary and certified data sources, and business teams prioritize using certified sources to avoid caliber division.

5. Open an incubation-to-official launch channel.

If a business tool runs successfully and has value, it cannot be unmanaged forever. After IT assessment, it will be "officially launched": included in the official code library, supplemented with tests, connected to monitoring and CI/CD, and added to the asset list. The business team is responsible for innovation, and the IT team is responsible for engineering integration.

6. Train business personnel on "lightweight engineering" capabilities.

Business personnel do not need to become programmers, but they need to understand the basic concepts of version management, the red line of data privacy compliance, how to write simple tests, and how to record the tool logic and dependencies. This is more useful than teaching them to write Java.

7. Shared responsibility and controllable cost.

The business team is responsible for the correctness of business logic and the rationality of usage scenarios, and the IT team is responsible for platform security, infrastructure, and operation and maintenance baselines. When a problem occurs, first judge whether it is a logic error or a platform error. AI calling fees, cloud resource fees, and storage fees are allocated to the business department to prevent cost explosions caused by unrestrained large model running, table creation, and data storage.

V. Final Summary

For business personnel to use AI tools for development, it is a productivity release in the short term, but a governance challenge in the long run. Its competitiveness lies in "speed, accuracy, and high alignment with business", but without proper governance, the enterprise will eventually face a large number of data silos, security vulnerabilities, technical landfills and blurred responsibilities.

The real problem to be solved is not "whether to let them do it", but "how to let them do it on a controlled platform". Business teams innovate at the "point" level, and IT teams provide support at the "whole surface" level. Only by well connecting the two tracks can we avoid failures.

Lao Yang believes that the future digital organization will most likely adopt a dual-track system: business experts build tools to solve the last-mile problem and carry out rapid trial and error; IT teams build platforms and governance systems to provide the underlying support for security, data, CI/CD, monitoring, and asset management. But taking this path requires the test of time.

This article is from the WeChat official account "Xiangjiang Digital Review" (ID: benpaoshuzi), the author is Lao Yang, and it is published with authorization from 36Kr.