The senior builder becomes
the CIO.

The senior builder is management. They stand on the side that makes business decisions. The professional work is done by AI. This is not a role that fits inside a general-employee grade.

1-05 showed that customers themselves can become builders. 3-05 showed that AI-native development structurally resists producing lock-in. Put both together and the rational customer keeps the builder in-house. That single choice covers three things at once: the structural disadvantage of outsourcing, the path out of lock-in, and the preservation of business context. This chapter takes up where in the organization to place a builder, how to compensate them, and in what structure they actually function.

Outsourcing IT is the same as outsourcing the business

Start by re-examining what IT outsourcing means.

In the old model, business and IT were treated as separate concerns. Business is core, IT is a tool, and tools can be outsourced. That was the common assumption. Keep an internal IT department, write the requirements in-house, hand the implementation to an SIer. That was the standard model.

The premise held under two conditions.

• IT implementation required a large number of coders, and keeping them all in-house was impractical at the scale needed. Multi-tier subcontracting stacked head-count on the outside, and only then could an engagement secure enough person-months (the structure is covered in 3-07).
• IT was viewed as a thin surface layer of the business. Outsourcing it was not thought to pull the essence of the business out with it.

Both conditions break in the AI-native world.

Implementation is written by AI. A large number of coders is no longer needed. The reason multi-tier subcontracting existed in the first place disappears. And the business of the AI-native era is a continuous chain of judgments encoded as code. What to build, how to split it, which invariants must hold. These are the body of the business itself. Code is the mirror of the business, not a thin surface.

So outsourcing IT becomes the same as outsourcing the judgment of the business. The head-count stacked outside is no longer needed either. The rationale for letting the customer's context, the meaning of the business and the non-negotiable conditions flow outward, and the rationale for securing person-months outside, both disappear at the same time.

If the body of the business stays in-house, the judgment that directly drives the business stays in-house too. That role is the in-house builder.

The senior builder is management — into the CIO's seat

How should the in-house builder be positioned? An extension of the general-employee grade ladder does not fit. But neither is it "a profession that sells judgment, in the same position as lawyers and doctors." That reading mistakes the structure. The senior builder is management.

First, look squarely at what happens in the AI-native era. The professional work that sells judgment — lawyer, doctor, accountant — is done by AI.

• Legal judgment — legal databases are open to everyone and case law is published. Which doctrine to apply given the client's situation, and how to build the argument: this practical judgment descends into the layer AI can make.
• Medical judgment — diagnostic equipment is standardized and medical knowledge is in textbooks. Which tests to run given the symptoms, and how to diagnose: this practical judgment too enters the layer AI handles.
• Accounting judgment — accounting software is open to anyone and tax law is published. How to handle the case given the company's actual state: AI can make this call too.

Becoming a deeply specialized "profession" means descending into the layer AI takes. It is the same reason that "become a specialized engineer" (1-03) mistakes the structure. So the human senior builder must not be lined up there.

Where, then, does the human builder stand? On the side that directs the professional work (AI) and carries responsibility for the result. That is the side that makes business decisions. The argument runs in order.

1. The builder's judgment begins as a management decision — which business to change, and how. Which invariants to keep, and what to discard. This is a decision about how to run the business before it is a decision about IT.
2. IT judgment = business judgment = management judgment — the business of the AI-native era is a continuous chain of judgments encoded as code (previous section). Making those judgments is deciding the business itself, and deciding the business is deciding the management of the company.
3. So: management, the CIO (Chief Information Officer) — a C-suite officer who carries part of the management of the company. They direct the professional work (AI) and make management decisions through IT.

The qualities the builder needs do not change here. Carve the problem out of the business context (judgment), split it into structure (decomposition), bind AI and existing assets together (integration). That is the work of the side that makes business decisions. The tools — AI, IDEs, libraries — are open to anyone. What is tested is judgment and responsibility.

And that responsibility is heavier than today's CIO's. Today's CIO oversees IT as a support function of the business. But the AI-native senior builder treats IT not as a support function but as the core of management, making the business judgments themselves through IT. As IT moves from a thin surface layer to the core of the business, the weight of the judgments made there, and the responsibility carried, come to exceed today's CIO.

The parallel runs one step deeper. The foundation of the qualities for making management decisions is not fluency in a programming language but the liberal arts: logic, rhetoric, ethics, systems thinking, history (1-04). Those judgments cannot be reduced to technique. Hire someone who can judge, not someone who can write code. That is the axis toward which builder hiring properly points.

A general-employee grade cannot hold this role

Push part of the management into a general-employee grade and it breaks. The reason is not "because they are a high-grade professional." It is because they are a layer that carries management decisions and responsibility.

The structure of the executive layer makes the point.

There is no "level-5 director" on a salary table. Management does not ride on a grade ladder. A layer that carries management decisions is compensated by the volume of judgment and the responsibility, not by position grade. The senior builder belongs precisely to this layer.

What happens when builders are forced into the general-employee frame?

• Position-graded pay does not work — builders are not measured by level. The scale at which one builder's judgment changes a business exceeds what the grade system was designed for.
• Assignment does not control them — a vertical-silo split of "business systems" and "sales systems" blocks cross-cutting judgment. Builders cut across multiple business areas.
• Promotion to a management post does not reward them — the builder's advantage is in business judgment, not in line management. Promoting them into line management pulls them out of their actual role.
• The interchangeability assumption breaks — "if a person leaves, another fills in and the system keeps running" does not apply to a layer that carries management decisions.

Trying to run all of this inside the general-employee frame causes strong builders to leave. Compensation as a member of management is what the role requires.

• Position them by the scope and responsibility of their management decisions, not by grade or assignment.
• Reward them by expanding the reach of their management decisions, not by promoting them into line management.
• Treat C-suite or executive-officer compensation as the baseline.
• Independent-contractor and business-commission contracts are legitimate options.

Under that framing, the in-house builder sits closer to the CIO or an executive officer than to a member of the IT department. The compensation is compensation as management.

Bringing the website in-house changes cost and structure at once

Enough abstraction. Take a concrete example: building a corporate website.

Commissioning a corporate website the old way looks like this.

• A web agency or production company takes the order.
• Requirements, design, implementation and maintenance are all in scope.
• The initial cost is a substantial sum.
• Each revision triggers a new quote.
• Domain, server and analytics are separate contracts.

Doing it with an in-house builder (one person plus AI) looks like this.

• Builder labor: depends on scope.
• AI subscriptions: as 2-02 sets out (a hundred-odd dollars a month while building, about $40 in operation).
• Hosting: your own machine or Cloudflare Pages (2-11), at almost no extra cost.
• Revisions: the builder ships them the same day.
• The same in-house builder serves other business areas too.

The initial build cost drops by an order of magnitude, and operation gets faster by exactly as much as same-day revisions allow. The number comes out in your own company's figures once you set it beside your current agency's quote.

But the more important comparison is structural, not financial.

• Old — the website is an outsourced asset. Revisions go through the agency, with delay and added cost.
• Builder-driven — the website is part of the business itself. Revisions move at the speed of judgment. The marketing decision and the web change connect directly.

In the outsourced model there is a buffer step: the marketing team judges, then commissions the agency. With an in-house builder, judgment and implementation collapse into one. Closing the distance between judgment and implementation to zero is the real reason to hire a builder.

Hiring a builder changes how the company operates

Once a company places a builder in-house, the way the business runs shifts.

• Speed of decision-making — "we want to build this" to "it is running" shrinks from weeks to days.
• Unit of experimentation — "build first, think about it after" becomes possible. The old constraint of fully specifying requirements before commissioning falls away.
• Structuring of the business — in the process of preparing things for AI to act on, the business itself gets organized.
• Data goes upstream — business data moves from SIer-managed custodianship into forms the in-house builder can work with: standard databases, JSON, Parquet.
• Vendor dependence dissolves — lock-in eases and options expand (3-05).

This is more than cost reduction. It is a structural change. Hiring one builder can be the trigger that reshapes how the company operates.

The builder supply is not limited to former coders

1-03 said that people who can move to the judgment side and people who cannot will separate. Read only that and builders look like a scarce resource. But missing one other supply source distorts the picture. AI is lowering the barrier to entry.

The barrier to entry in software development has historically been a stack of layers: grammar fluency, framework learning, build and deploy, debugging experience. All of these are dropping right now. Three elements combine to make it possible.

• AI — the code is written by AI (1-01).
• Python — readable, and well-suited to working with AI.
• Flet — desktop, mobile and web apps in pure Python. Underneath is a native Flutter build (AOT-compiled), so cold-start is lighter than React Native's JavaScript-bridge stack (2-04).

With these three layers in place, the people who until now said "I want to build something but I cannot write code" flow into the base of the builder pool.

The VB / VBA generation comes back

Until about twenty years ago, a thick layer of casual personal programmers existed. Excel VBA, Access VBA, Visual Basic, Delphi. Clerical staff, accountants, technical generalists and lab assistants all built small tools for their own work on the side. In Japan that layer was routinely in the millions.

That layer shrank rapidly over the past fifteen years, because the center of gravity of programming moved to the web or to enterprise apps.

• Web — HTML / CSS / JavaScript, React, TypeScript, npm, webpack, deployment, CDN. There is a thick learning stack before anything runs.
• Enterprise apps — Java or C#. You cannot run a single line without a class. Build, test and CI/CD all have to be managed before anything moves. Security policies are strict. The management layer becomes the substance, and the joy of programming itself disappears.

"Like the VB days: open it, write code, hit Run, and something works." That feeling is essentially gone from current web and enterprise stacks. So the old casual personal programmer population lost its place, caught between competitive programming and Kaggle as ornamental hobby on one side, and full-time web or enterprise software work on the other.

AI + Python + Flet brings the VB / VBA feel back to this layer.

• Open, write, run — Python and Jupyter.
• The UI is largely declarative through Flet, close to the feel of a VB Form.
• The management layer is handled by AI — build, deploy, test.
• AI writes the grammar details.

This layer is made of people who have been thinking about what they want to build for twenty-plus years. Clerical staff who built monthly aggregations in VBA, shop-floor people who built inventory management in Access, graduate students who scripted instrument-output plots in their labs. They already carry what a builder needs: judgment, decomposition, integration. What was missing was only the will and the time to learn the current web or enterprise stack.

In AI-native development, that wall is lower. The VB / VBA generation comes back as builders. This is a particularly large supply source in the Japanese market, where that layer was widest (2-04, "Write the Logic — Own Your Tools with Python For You," covers the VBA to Python migration in concrete detail).

Makers and shop-floor engineers enter embedded programming

Software development used to be web-centric. HTML / CSS / JS, React, browsers, servers. Most of the learning cost concentrated there.

In the AI-native era, the barrier to embedded programming drops the same way. Raspberry Pi and ESP32 microcontrollers, MicroPython, AI generating circuit and control code. People who enjoy making things can step into writing software easily (2-14).

Robot programming is the canonical example. Historically it needed ROS, C++ and advanced mathematics, which made it the territory of research labs and specialist firms. In the AI-native present the stack looks like this.

• ROS2 + Python is standardized.
• Higher-level robotics frameworks are written in Python.
• AI fills in the details of control algorithms.
• Flet provides the operator UI.

A hobbyist maker builds a robot that runs at home. Until a few years ago this was a researcher's privilege. The kind of person who makes things already carries the qualities a judgment-centered role needs: picking what to build, debugging when something does not move, decomposing a system into parts and modules.

In Japan, builder supply is likely to surge

In the Japanese context, this supply source is especially large.

• Manufacturing base — engineers in factories and small machine shops have the experience of making physical things. AI gives them a path into software.
• Maker culture — Maker Faire, electronics hobbies and community activity have a long history here.
• Gadget culture — the underlying motivation "I want to build something myself" is broadly distributed.
• Education trends — high-school robotics contests, and Python education spreading through schools.

These bases cross the "I cannot write code" barrier through AI + Python + Flet and enter society as builders. While SIers shrink and customer companies expand builder hiring at the same time, the supply side sees former SIer coders converging with makers.

1-03 said that those who can move to the judgment side and those who cannot will separate. That was a statement about former SIer coders. What this chapter adds is that the doorway to the judgment side is not open only to people who came from coding.

Read this together with the labor demand outside the industry covered in 3-07 — manufacturing, agriculture, AI physical infrastructure — and the picture gets clearer. Human capital flowing out of the SIer industry and human capital flowing in from outside the industry as builders move in parallel. Labor reallocation is not a simple shrinkage-to-unemployment story but a multi-directional flow.

Summary

The senior builder is management. They stand on the side that makes business decisions.

• Outsourcing IT — in the AI-native era it is the same as outsourcing the judgment of the business
• Position — not a profession that sells judgment, but the CIO's seat. The professional work is done by AI
• Responsibility — heavier than today's CIO, because IT moves into the core of the business
• Compensation — positioned by the scope and responsibility of management decisions, not by grade or assignment. It does not fit a general-employee frame
• Corporate website — the initial build cost drops by an order of magnitude, but the substance is that the distance between judgment and implementation goes to zero
• Supply — not only former SIer coders. AI + Python + Flet open the VB / VBA generation and the maker population as new sources

By here, the case for keeping a builder in-house is clear. But the industry-wide shift will not happen all at once. Japan has its own dynamics: multi-tier subcontracting, long-tenure employment customs, and the intermediate forms that show up during a transition.

The next chapter takes up the SIer-industry transition in Japan and labor mobility. How do the coders inside SIers move? What happens to the prime-contractor and subcontractor structure? Which intermediate forms appear during the transition?

Related articles

• 1-04: The Builder Role
• 1-05: Customers Co-Develop with AI
• 3-05: The Lock-In Problem
• 3-07: Japan's SIer Industry Transition and Labor Mobility
• 2-04: Write the Logic — Own Your Tools with Python and Flet
• 2-14: From Electronics to IoT — Think in Python, Have the AI Translate
• Structural analysis 08: Subtracting the enterprise-IT tax
• Structural analysis 12: AI and the sole proprietor