When Software Production Is No Longer the Production of Code

Opening

The previous essay stopped at a question about programmers. But programmers are only one of many roles that produce software. In a typical software product, the number of people who don't write code usually exceeds the number who do: product managers, designers, QA, DevOps, SRE, business analysts, technical writers, support engineers, sales solution consultants, customer success. Each role is a link in the value chain. Each link is an assumption about division of labor — the assumption that certain tasks have to be separated and given to different people because no one can do them all well.

As AI gets better at each link, these assumptions about division of labor collapse — unevenly, at different speeds, but all of them collapse. And when the chain falls apart, the "software company" as an organizational entity has to be restructured from scratch.

This essay goes in four steps: break the assumption that "software production = writing code", trace back what software production actually is, examine how the value chain falls apart, and sketch what the new equilibrium might look like.

The tone is the same as the previous essay: reasoning to the end, no boilerplate optimism, no boilerplate pessimism. And at the end there's a "where this might be wrong" note, as with any reasoning that strays far from current data.

Part 1: What is software production, really?

The question sounds naive. But most people in the industry have never answered it seriously. When you ask "what does your company do?", the answer is usually "we build software X." That's a description of output, not of the process.

Reasoning from first principles, software production is a chain of information transformation, not a chain of material transformation. The chain has about five layers:

flowchart TD
    U[Vague user<br/>needs] --> T1
    T1[Layer 1 — Understanding the problem<br/><i>BA, PM, founder</i>] -->|Problem description| T2
    T2[Layer 2 — Designing the solution<br/><i>UX, architect, tech lead</i>] -->|Architecture, API, data model| T3
    T3[Layer 3 — Implementation<br/><i>Programmer</i>] -->|Source code, build| T4
    T4[Layer 4 — Putting it into operation<br/><i>DevOps, SRE</i>] -->|Service running 24/7| T5
    T5[Layer 5 — Closing the feedback loop<br/><i>Support, CS, sales</i>] -.->|Real behavior + feedback| T1
    T5 --> R[Value delivered<br/>to users]

Layer 1 — Understanding the problem. Customers/users have a vague need. Someone has to turn that vague need into a clear problem description. This is what business analysts, product managers, founders, sometimes designers do. The input is natural language, industry context, behavioral observation. The output is a problem description that can be solved.

Layer 2 — Designing the solution. The problem description becomes a solution description. This is what UX designers, software architects, tech leads do. The input is a problem. The output is architecture, user flows, data models, API contracts — things that aren't code yet but are concrete enough to be coded.

Layer 3 — Implementation. The solution description becomes runnable code. This is what programmers do. The previous essay focused on this layer. The output is source code, builds, deployable artifacts.

Layer 4 — Putting it into operation. Code becomes a service running 24/7 under real load. This is what DevOps, SRE, infrastructure engineers do. The input is the artifact and non-functional requirements (availability, latency, cost). The output is an operating system, monitored and recoverable.

Layer 5 — Closing the feedback loop. Users use the software, hit problems, raise new requests. This is what support, customer success, sales solution consultants — sometimes product — do. The input is real behavior and feedback. The output is the input for Layer 1 of the next cycle.

This five-layer chain exists because no single person has enough capability to do all five well. One person can't simultaneously understand the customer's domain deeply, design distributed systems, write good code, operate stably, and communicate with end users. Division of labor is a consequence of human cognitive limits.

This is the key point: the current software value chain is not a natural structure. It is the result of humans having cognitive limits. When that limit is reduced by AI — not making one person superhuman, but augmenting an ordinary person — the chain no longer has a reason to exist in its old shape.

Part 2: How each layer falls apart

Walking through each layer, reasoning to the end. Before details, here is the predicted order and degree of disintegration:

flowchart LR
    subgraph S1[Fastest to disintegrate]
        direction TB
        A[Layer 3<br/>Implementation]
        B[Layer 4<br/>Operations]
    end
    subgraph S2[Mid-term disintegration]
        direction TB
        C[Layer 2<br/>Solution design]
    end
    subgraph S3[Transforms but doesn't disappear]
        direction TB
        D[Layer 1<br/>Understanding the problem]
        E[Layer 5<br/>Feedback loop]
    end
    S1 ==> S2 ==> S3

Layer 3 — implementation — disintegrates fastest. The previous essay analyzed this thoroughly. This is the layer AI currently does best because the input (solution description) and output (code) are both structured text, with massive training data, and have a fast feedback loop (run/error/fix). This is why "programmer" has become a hot topic — but it's also why it's not the most interesting layer to analyze further.

Layer 4 — operations — disintegrates slower but more completely. Operating large-scale distributed systems used to be a senior fortress — tacit knowledge, incident experience, intuition about where the system is fragile. AI is now good at log analysis, debugging suggestions, even auto-fixing configurations. More importantly: AI has a structural advantage here that humans don't — AI can read millions of log lines simultaneously, correlate signals across services, remember every incident the organization has ever had. A great SRE can't compete on information bandwidth. This layer will become "AI operates, humans approve high-risk changes" — and after that, "AI operates, humans only see the reports."

Layer 2 — solution design — this is the real contested zone. Design requires holding many constraints simultaneously, aesthetic judgment, predicting long-term consequences. Current AI can propose options but is weak at evaluating trade-offs between options in a specific context. But "weak" here is relative — weaker than an exceptional senior architect, but already on par with an average architect. When seniors retire without a successor pipeline (because the training mechanism based on Layer 3 work has disappeared, see Part 5 below), AI will automatically take over this position not because AI got better, but because humans got worse.

Layer 1 — understanding the problem — the most durable, but not for the reason people think. Many essays say "understanding the problem" is durable because AI doesn't interact directly with customers. This reason is weak — AI can absolutely interview customers via voice, analyze calls, synthesize behavior. The real reason this layer is durable is legal responsibility and trust. Enterprise customers don't sign million-dollar contracts with AI. They sign with a person they trust, a person who is accountable if things go wrong. Layer 1 is durable because it is tied to social mechanisms (contracts, accountability, reputation), not because AI is bad. But the number of people needed at Layer 1 is much smaller than today — one person at Layer 1 today works with 5-10 engineers behind them; in the future they may work with 50-100 AI agents.

Layer 5 — feedback loop — transforms most radically. This layer is currently done by support and customer success — roles that are often undervalued. In the new world, this is the layer AI does better than humans on every dimension: instant responses, no emotions, remembers every previous interaction, multilingual. But at the same time, this is the layer that produces the most valuable training data for all other layers.

Here we need to separate two types of data clearly — because they have very different values and determine who really has the advantage. Behavioral data (clicks, sessions, time on page) decays quickly, is easy to collect, and the hyper-scale platforms will turn it into a commodity in the next few years — not a fortress. Domain-specific operational data (a specific bank's credit approval flow, a specific factory's production line, a specific marketplace's order fulfillment process) is a different beast — long-lasting, no AI can generate it because it only exists in actual operations. Companies that control the second type have a structural long-term advantage; companies that only have the first type will be swallowed by larger platforms.

Summing up: the five-layer chain doesn't fall apart evenly. Layers 3 and 4 disintegrate first, Layer 2 disintegrates after, Layers 1 and 5 transform but don't disappear. The consequence is that the center of value shifts away from implementation toward understanding the problem and closing the feedback loop. This is where many people in the industry today guess right but don't say enough — they don't say enough about the organizational consequences.

Part 3: The missing layer — who sets up and operates this pile of AI?

The section above said "AI does Layer 3", "AI runs Layer 4" as if AI just appears, configures itself, runs itself. That's not what happens. There's a new layer that emerged that the old five-layer model misses — call it Layer 0, or the AI infrastructure layer.

Layer 0 is people who do work like:

Choose which model for which task, how to fine-tune
Write prompts, agent loops, orchestration
Set up MCP (Model Context Protocol), tool integration, connecting AI to the codebase and internal infrastructure
Monitor output quality, intervene when AI drifts
Build evaluation systems, regression tests
Manage inference cost, choose which model for which task
Write guardrails, ensure AI doesn't break operating systems
Update when new models arrive (every 3-6 months)

This isn't a completely new profession. It's a merger of several old ones: DevOps + ML engineer + platform engineer + a bit of product thinking. The person who can do it has to understand infrastructure (to operate), models (to choose and evaluate), and the business problem (to know what AI should do). This is a "deep T, wide T" role — rare and expensive.

Layer 0 sits transverse to all other layers, not in the chain:

flowchart TD
    T0[Layer 0 — AI infrastructure<br/><i>AI platform engineer / AI orchestrator</i>]
    T0 -.provides AI to.-> T2
    T0 -.provides AI to.-> T3
    T0 -.provides AI to.-> T4
    T0 -.provides AI to.-> T5

    T1[Layer 1<br/>Understanding] --> T2[Layer 2<br/>Design]
    T2 --> T3[Layer 3<br/>Implementation]
    T3 --> T4[Layer 4<br/>Operations]
    T4 --> T5[Layer 5<br/>Feedback]
    T5 -.-> T1

An important footnote: "Layer 0" is not a single job. In reality it's already splitting into three distinct specializations — model & eval ops (choosing and evaluating models), integration & MCP (tools and integration), cost & guardrails (inference cost and safety controls). One person can be good at all three at the start; at larger scale, the three split into three sub-teams working together.

Five things worth saying about this layer, reasoned to the end:

One, this is the highest-leverage role in the new organization. A person who sets up AI well can multiply the productivity of 50 others. A person who sets up AI poorly can make the whole organization slower than not using AI — because AI is wrong silently, burns inference cost, and creates technical debt faster than humans can untangle it. The gap between "good" and "bad" at this role is larger than at any current technical role.

Two, this may be the most durable fortress for humans at the technical layer — more durable even than the "critical systems" the section below mentions. Because AI cannot reliably set up AI at the organizational level — that's a problem with too much tacit context (internal data sources, compliance constraints, team culture, system history) that can't be extracted into a formal description for AI to read. At least for the next 10-15 years.

Three, this role creates a new power asymmetry in the organization. The person setting up AI knows exactly what AI can and can't do — knows better than the CTO or CEO, because they're the only one touching the actual configuration. This has two sides. The positive side: they're the most trustworthy person to consult on AI strategy. The negative side: they can "perform" productivity by hiding costs, or "perform" limits to keep their status. Traditional organizations don't have mechanisms for this new political dynamic — because no one has ever held the keys to a resource with such powerful leverage before.

Four, this role is itself being eaten by AI. Some startups are building "AI agents to set up AI agents" — a suspicious recursive loop but not unreasonable. If it succeeds, this is the small-scale tipping point: AI self-organizes the work of building software. At that point, the "AI setup person" shrinks to a few dozen people worldwide, working at foundation labs. This is how Layer 0 might disintegrate itself — but slower than the other layers, perhaps 10 years or more.

Five, Layer 0 is where new competitors to your company form before you notice. If your customer hires a good Layer 0 person, they can build software to replace you. The mechanism of Shift 3 ("company in industry X builds it themselves") in the next section is exactly because Layer 0 exists. Without Layer 0, the "build it yourself" story is still just theory.

Part 4: Organizational consequences — how the software company changes

When the value chain changes, the shape of the company has to change with it. Four shifts with the highest probability:

Shift 1 — The optimal size drops sharply. Software companies today have 50, 500, 5000 engineers because division of labor at Layer 3 requires many people. When Layer 3 needs one-tenth the number, a 500-engineer company either shrinks to 50, or makes ten times the products. Most will make ten times the products — because that's more natural organizationally (not layoffs, but scope expansion). The consequence: the average company does more things, product boundaries blur, "company that does one thing" becomes rare.

Shift 2 — The advantage of scale in pure software disappears; the advantage of distribution rises. The advantage of large companies over startups today is largely based on: more engineers, better infrastructure, more sophisticated internal tools. AI flattens all three. A 5-person startup with AI can build a product with technical quality on par with a 500-person company. The advantage of large companies shifts to three other things: distribution channels, data, relationships. Of these three, distribution channels are the most durable fortress — because it's a human battlefield, not a technical one. AI can't flatten the relationship with the purchasing director of a corporation, can't replace the integration partner network built over ten years, can't create the trust of a customer who has bought four times before. This is why the current "big players" don't collapse immediately even when being eaten from below technically. And this is why technically-good startups without distribution often fail — they win at the most easily flattened layer.

Shift 3 — The boundary between "software company" and "company in industry X" dissolves. When making software is 10-100x cheaper, every company in every industry can build their own software — provided they can hire a few good Layer 0 people. But "build it yourself" also has limits: systems with strong legal constraints, very high switching costs, or long-term vendor lock-in are still unlikely to be self-built. Banks won't build their own core banking (Temenos, Finastra hold these positions; the central bank doesn't encourage changes), but they will build their own KYC/onboarding pipelines, fraud detection, ops tooling, internal analytics systems — things they used to buy from large systems integrators. Manufacturers won't build core ERP but will build custom MES, quality systems, operations dashboards. "Software vendor" as an independent business type shrinks — remaining only in fields with very specialized requirements or high legal barriers. In the middle — what we call "enterprise SaaS" — is squeezed from both sides: from above (hyper-scale platforms swallow the foundation layers) and from below (customers build what they need themselves). This trend has started; AI is just accelerating it.

Shift 4 — The "sell software licenses" business model weakens; the "sell outcomes" model rises. When software itself becomes a commodity, customers don't pay for the software — they pay for the outcome the software delivers. This is a shift from "selling tools" to "selling services with tools behind them". Salesforce sells licenses; the next generation sells "sales results increased by X%". Harder to measure, but value captured per customer is higher — and most importantly, makes software into something that can't be simply replaced by self-built AI. This may be the last fortress of current software companies.

These four shifts don't happen at the same speed. Shifts 1 and 2 are already happening, observable in recent layoffs and cutbacks. Shift 3 is in its early stages — most traditional companies still buy software from vendors, but the "build it yourself" ratio is rising. Shift 4 is just emerging in vertical-specific AI agents — and will accelerate when the licensing model becomes harder to defend.

Part 5: Two vicious loops in the system

There are two vicious loops in this process, worth naming clearly. Here is a diagram of their motion — note how the two loops feed each other right in the middle:

flowchart TB
    subgraph L1[Loop 1 — Loss of training pipeline]
        direction LR
        A1[AI writes code<br/>instead of junior] --> A2[Layer 3 fewer<br/>junior positions]
        A2 --> A3[No succession<br/>for Layer 2]
        A3 --> A4[Old seniors<br/>retire]
        A4 --> A5[Architectural judgment<br/>passes to AI]
        A5 --> A1
    end

    subgraph L2[Loop 2 — Loss of judgment diversity]
        direction LR
        B1[New generation<br/>learns from AI] --> B2[Judgments converge<br/>to AI aesthetic]
        B2 --> B3[No one dares<br/>challenge AI]
        B3 --> B4[Loss of incentive<br/>for independent skill]
        B4 --> B1
    end

    A5 -.reinforces.-> B1
    B3 -.reinforces.-> A1

Loop 1 — Loss of the succession training pipeline. Today's Layer 2 seniors were yesterday's Layer 3 juniors. An exceptional architect isn't born as an architect — they're an engineer who has written code for ten years, met every kind of mistake, understood why a certain architectural decision leads to three years of pain later. When Layer 3 no longer has junior positions, there is no way to produce Layer 2 seniors. Over 5-10 years, the current senior generation retires without a replacement. Layer 2 doesn't disintegrate because AI is better — it disintegrates because humans lose the ability to be good at it.

This is a slow and, on realistic time scales, irreversible kind of collapse. Medicine, law, civil engineering have all observed milder versions of this problem. In software, because the rate of change is faster, this vicious loop will manifest more clearly.

Loop 2 — Loss of judgment diversity (a weaker thesis than Loop 1, read with the counterargument). Each generation of engineers today learns from many different sources: school, books, mentors, real projects. Source diversity creates judgment diversity — judgment diversity is important capital for a creative industry. The next generation will mostly learn from AI.

There's a counterargument worth mentioning: in the short term, the foundation labs (Anthropic, OpenAI, xAI, Mistral, Google) are diverging in aesthetic, not converging — Claude's code style is distinct from ChatGPT, distinct from Cursor, distinct from Copilot. Users who use multiple models may still maintain judgment diversity. The "convergence" thesis only holds if: (a) the model market consolidates to 2-3 players, (b) models copy each other via synthetic data, or (c) a generation of engineers grows up using only one model from the start. All three are plausible but not certain — and if they don't happen, Loop 2 is just a theoretical warning, not a prediction.

Assume those three conditions hold: the judgments of the next generation will converge to a common aesthetic — the AI's aesthetic. The consequence: future organizations will look diverse (many people, many countries, many backgrounds) but think uniformly. Diverse on the surface, monotonous in depth. This is a dangerous kind of uniformity because it's invisible — no one feels it's missing, no one knows what's missing.

These two loops interact. Loss of training pipeline leads to more AI dependence, leads to loss of judgment diversity (if the above assumption holds), leads to no one daring to question AI, leads to no incentive to train independent skills. The loop self-reinforces — provided Loop 2 actually happens.

Part 6: What the new state might look like

Reasoning to the end, the new equilibrium (if one exists) might have these features:

Feature 1 — Three distinct types of software companies, not just two. The common description today says there are two extremes: small studios and hyper-scale platforms. Correct but not enough. A third type is taking shape.

Type one — small studio (5-50 people): each person has a very wide scope because AI amplifies them. This is a "studio" form — closer to how an advertising or architecture firm operates than to current software companies.

Type two — hyper-scale platforms (multi-billion-dollar revenue and up): they own the foundational AI infrastructure, models, GPUs, global distribution channels.

Type three — vertical integrators (the third path): companies combining hardware + software + services in a specific industry. Different from studios because they have physical capital (factories, equipment, warehouses, deployment networks). Different from hyper-scale platforms because they're narrow on industry, deep on domain. Examples: a company making retail kiosks that produces hardware + writes software + deploys services at the point of sale; a smart manufacturing company integrating PLC + MES + AI ops in factories of a certain industry. This type has a double barrier — technical and physical capital — so it's not attacked by pure software AI startups, but also not swallowed by hyper-scale platforms because they don't go down to the physical layer.

The middle layer — software companies of 100-5000 people without either physical capital or hyper-scale — gets squeezed. Mid-sized organizations either shrink into studios, get acquired by hyper-scale platforms, evolve into vertical integrators (if they can go down to the physical layer), or change profession (into "industry + tech" companies — see Feature 2).

Feature 2 — Non-software companies absorb most current software workers. This is a point easy to miss. When making software gets cheap, companies in other industries (manufacturing, retail, healthcare, finance, logistics) will hire more software people — but under a different title. They won't call themselves "software engineers" but "production operations engineers", "financial automation specialists", "patient systems engineers". Software skill becomes a base skill, not a professional identity. Similar to how "knows Excel" today is a base skill, not a profession.

Feature 3 — Software becomes invisible infrastructure. Today, end users know they're using "software" — they open Microsoft Word, they log into Salesforce, they download apps. In the new state, software is an invisible layer between users and the outcomes they want. They tell AI "I want a revenue report for this quarter by region" — AI creates just-enough software to answer, used once, then discarded. The concept of "application" as a durable deliverable may no longer be necessary. This is a longer-term scenario than 5-10 years — but if it's right, the entire current software business model (product, license, subscription) is broken.

Feature 4 — Two last fortresses for humans at the technical layer: Layer 0 and the critical systems layer. Layer 0 (AI infrastructure) is durable because AI can't yet set up AI at the organizational level — it's a high-leverage role, with more positions than the critical systems layer, and demand is growing fast. The critical systems layer (software running nuclear plants, aircraft, implantable medical devices, the power grid) is durable because legal liability and physical consequences are so high no society will accept AI being in charge — but the number of positions is very small and the entry threshold very high. Layer 0 is a viable path for many; critical systems is for a small few. But both can self-disintegrate in the long term — Layer 0 through AI setting up AI, critical systems through law and social acceptance changing.

This is the central scenario. There are many other scenarios. The important thing is not to confuse "the current intermediate state" with "the long-term equilibrium state". Most people in the industry today are planning their careers based on the intermediate state — as if it were stable. It isn't.

Part 7: Implications for decision-makers

The previous essay was written for juniors and seniors as individuals. This one is for decision-makers — founders, CTOs, engineering heads, business unit leaders.

For software company founders/CEOs: The most important question isn't "how to use AI to boost productivity" — most of your competitors are doing that, so it doesn't create durable advantage. The more important question: what does your business model still mean when making software is 10x cheaper? If the answer is "the same, just with higher margins", you probably haven't thought deeply enough. Your new competitor may not be another company in your industry — it may be a company in your customer's industry, building themselves what they used to buy from you.

For CTOs/engineering heads: What's worth investing in that will still have value in 5-10 years? Not frameworks, not tools. The most worthy investments are: internal knowledge systems (tacit knowledge written down), the domain-specific operational data warehouse (not behavioral data — see Part 2), the ability to integrate with industry-specific systems (domain barriers), and most importantly — in-house Layer 0 capability. Don't outsource Layer 0; don't hand it to a vendor. This is the asset that AI doesn't flatten. The size of your team — especially at Layer 3 — will have to shrink. Confront this honestly as soon as possible, because your choice isn't "to shrink or not" but "to shrink proactively and reinvest, or to be forced to shrink by the market."

For business unit leaders in non-software companies: Your question is the opposite. What software are you buying that you could actually build with 3-5 internal people + AI? This isn't a question of "how to save costs" — it's a strategic question about controlling what's core to your operations. Software is where your business model is encoded. Letting someone else write it is letting someone else understand your company better than you do. The companion question: do you have a Layer 0 person yet? If not, no amount of money will get you "self-built". And know how to distinguish what to build (KYC, ops tooling, internal dashboards) from what not to touch (core banking, core ERP, systems with legal vendor lock-in).

These three perspectives are not compatible with each other. Software founders see customers building it themselves as the threat. Customers see controlling the technology layer back as the opportunity. This is a battle over redistribution of value within the value chain — and each side has a reasonable argument from their position. Whoever recognizes this early and acts early will have the advantage.

Part 8: Specifically for Vietnam

All the sections above are written for the global software industry. But Vietnam is in a special position in this story — worth a few dedicated paragraphs because what this essay predicts will hit Vietnam sooner and harder than many other markets.

The IT outsourcing industry is the first group to disintegrate at scale. FPT Software, NashTech, KMS, TMA, Bagel, and hundreds of smaller outsourcing companies — most of their revenue comes from pure Layer 3 (writing code per foreign client specifications), with some Layer 4 (DevOps, operations for clients). This is exactly the two fastest-disintegrating layers from Part 2's analysis. The current competitive advantage — engineer cost 1/3 to 1/5 of US/Europe — will vanish when AI does Layer 3 at near-zero cost, 24/7. Not because Vietnamese engineers are weak, but because the entire outsourcing industry stands on the most easily disintegrated layer of the chain.

This isn't a far-off prediction — large Indian outsourcing companies (TCS, Infosys, Wipro) have laid off tens of thousands in the last 18 months, and India is usually 3-5 years ahead of Vietnam in these trends. The question isn't "will it happen in Vietnam" but "when, and who prepares now."

Two escape paths for Vietnam's outsourcing industry. One, move up the value chain — shift from "writing code per spec" to "designing solutions" (Layer 2) or "understanding customer problems" (Layer 1). This is the hard path: requires years of investment in training, a fundamentally different organizational culture, and overcoming language/cultural barriers to work deeply with clients. Two, move down to the physical layer — become a vertical integrator (Feature 1 in Part 6) in industries where Vietnam has existing physical capital: manufacturing, logistics, retail, agriculture. This path is more viable because it leverages domestic production capacity, but requires a fundamental business model shift, not incremental upgrades.

Companies that don't choose either path will shrink — not collapse immediately, but gradually lose customers, lose margin, lose top talent, until what remains is a shell.

Layer 0 in Vietnam remains an open opportunity. This is the good news. Layer 0 (AI infrastructure) in Vietnam currently has very few people doing it for real — a few dozen to a few hundred nationwide capable of setting up AI systems for large organizations. While demand is growing exponentially: banks (Techcombank, MBBank, TPBank, VPBank are all building internal AI teams), conglomerates (Masan, Vingroup, FPT, Viettel), startups. People who can do Layer 0 in Vietnam over the next 3-5 years will be in extremely strong negotiating positions — high leverage as mentioned in Part 3, plus the scarcity of the Vietnamese market.

Concrete recommendation for individuals: if you're a young engineer in Vietnam, investing in Layer 0 is very likely the best career decision of the next 5 years — better than trying to be better than AI at Layer 3. If you're a CTO or head of engineering, building an in-house Layer 0 team is the most urgent item on your 2026 roadmap, not 2027.

The special role of Vietnamese diversified conglomerates. Masan, Vingroup, Hoa Phat, THACO, Viettel — conglomerates with both physical capital (factories, retail, telecom) and large financial resources and control over domain-specific operational data (the durable kind — see Part 2). This is exactly the most favorable configuration to become a vertical integrator (Feature 1, type three). While Vietnamese pure software companies (even large ones like FPT) are in a difficult position, traditional conglomerates — who don't even call themselves "tech companies" — are in the most favorable position. The strategic lesson: in the AI wave, companies with physical capital + operational data + Layer 0 people will beat companies with many pure software engineers.

One final warning. Vietnam has a tradition of training software engineers through technical universities — Bach Khoa, the national universities, FPT University. Currently, most curricula still train students for Layer 3. In the next 5 years, students graduating with pure Layer 3 skills will enter a market where Layer 3 no longer needs many people. This is a systemic problem no individual can solve — but it is a real risk for an entire generation of young engineers studying now.

Closing: Four different questions

Continuing the structure of the previous essay — four questions you don't need to answer to anyone, only to yourself:

One, which link in the software value chain is your company in, and does that link still exist? This is a question of structural position, not a tactical question. A pure Layer 3 IT outsourcing company has a very different position from a deep vertical product company in a specific industry. The answer has no value if it avoids the truth.

Two, if software becomes a commodity, what are you selling? Not the default answer ("services", "experience"). The specific answer: what are you selling that AI + 5 other engineers can't sell? If the answer is vague, you probably don't have anything specific — and that's a warning, not an excuse.

Three, who in your organization is doing Layer 0, and do you know what they're doing? This is a question many organizations can't answer. Someone is setting up AI for your company — possibly officially, possibly informally. If you're a founder/CTO who doesn't know who that person is, doesn't know which models they're choosing, doesn't know the monthly inference cost, doesn't know which systems AI is being granted access to — then that person is actually running your company more than you think. Invisible Layer 0 is a new governance risk that doesn't even have a name yet.

Four, what state are you building your organization for — today, three years from now, or ten years from now? Most organizations are designed for today's state, with a bit of adaptation for three years. Ten years from now almost no one is thinking about. But the decisions you make today — about team structure, culture, technology investment — will shape what that organization looks like ten years from now. There is no non-decision; not acting is also a kind of decision.

Note: Where this essay might be wrong

As in the previous essay, there are places worth doubting:

One, the reasoning about the value chain might be too neat. The five-layer model (plus Layer 0) is one cross-section — reality is more complex, with many cross-layer feedback loops. The speed of disintegration of each layer depends on many non-technical factors (law, industry culture, product lifecycle) that this essay doesn't address enough. Layer 2 might be more durable than I think, or Layer 4 might disintegrate faster than I think. Layer 0 might be eaten by AI faster than predicted if "agents that set up agents" systems progress further than expected.

Two, "non-software companies building it themselves" might be exaggerated. History shows most traditional companies that try to build their own software fail — because of organizational culture, decision-making mechanisms, lack of talent (especially Layer 0 talent). AI may reduce the technical barrier, but doesn't automatically solve the organizational barrier. "Software vendor" might be more durable than predicted because customers still don't want to build it themselves, even if technically they could.

Three, the demand-side question isn't answered. This essay assumes the total software market stays the same, just redistributing value between parties. But there are two opposing possibilities, both reasonable. One (Jevons paradox): when software is 10x cheaper, demand might rise 100x — because problems previously not worth solving with software are now worth solving, and the total market expands. Two (radical commoditization): when software becomes a commodity, value is captured by the AI infrastructure and end customers, the middle layer shrinks. The answer determines the entire strategy of founders — and this essay doesn't try to answer, only to pose the question so you can think.

Four, there may be a new kind of value not yet anticipated. All the reasoning above assumes the "value chain" framework holds its shape. Tech history shows major shifts often come with new kinds of value contemporaries can't see — the internet wasn't just "faster mail", smartphones weren't just "phones with web". AI may create a kind of value neither writer nor reader of this essay has conceived. If so, the entire analysis here is obsolete from the moment it was written.

Read this essay as a scenario worth thinking about, not a confident forecast — just like the previous one.