THE BUILDER LAYER — PART 1: ACT

AI did not replace software engineers. It removed some of their hiding places.

When execution gets cheaper, it becomes easier to see what actually creates value - and what only looks like work. The bottleneck moves up: from writing code to making decisions, coordinating people, and designing systems that do not collapse under change.

But AI also creates another layer of abstraction, with new dark corners to hide in. A team that does not understand those layers can create a hole in its budget and drain its energy without moving anything meaningful forward.

Take AI-assisted code review. It can generate something that looks like deep, multi-angle analysis: performance, security, data integrity, and edge cases. But when the existing data and system constraints are ambiguous, many of those considerations are generic patterns applied to the wrong situation.

Worse, when the model “enriches” missing information, it is often not enriching anything. It is guessing, or making silent decisions. The result can be unnecessary work, more model calls, and a higher monthly bill for analysis that did not improve the system.

There is another distinction worth protecting. The best answer an AI can give after a failure is: “I understand your concern, and I made a mistake.” But the mistake is still yours to own. “The LLM said that” is not a way to shift responsibility.

That is one of the best principles we can carry forward from the old world. Without it, we could easily end up in a delusional one: blaming AI for every failure while claiming every positive result for ourselves. Plenty of people would enjoy that arrangement. I hope we never build it.

THE LAYERS

I have noticed a pattern: as AI compresses execution work, coordination and system design become the constraint.

Software has always been abstract and complex. That complexity can obscure contribution: walls of tasks, specialist language, and unclear ownership make it difficult to see what is actually moving a product forward.

AI disrupts that behaviour. It makes the gap between real contribution and performance harder to ignore—although the new border is still unclear.

We will move from the bottom up. That gives us a fuller picture of how small mistakes at higher layers create a mess below.

The first three layers are all about acting: doing the work, making decisions, and shaping the system. I will use that term to avoid confusing the broader idea with the execution layer alone.

1. EXECUTION LAYER

I have seen teams struggle at this layer for three different reasons:

1. Lack of knowledge
2. Lack of experience—or fear
3. Attitude

Lack of knowledge

This is the easiest problem to solve: articles, workshops, deep review sessions, and better planning. A good team learns quickly, opens up, and asks questions.

The first and most important step is simply being able to identify a gap in knowledge. Once people can say, “I do not know this yet,” the gap can be filled.

Lack of experience (fear)

By default, we are afraid of new things: paths with unknown outcomes. Putting your name on something you do not fully understand creates anxiety at the very least.

This can change, but it requires real examples and repeated practice. It requires empathy: helping people feel that you understand where they are, while still asking them to keep moving despite the fear. You feel it too, and that is fine.

Attitude

This is harder to solve through training. Teams need a shared standard for ownership, follow-through, and constructive disagreement. When that standard is missing, look at the incentives and the leadership system—not only the individual.

Do not rely on words alone. Make expectations, responsibility, results, recognition, and compensation visible. Otherwise, the people doing the extra work will eventually stop doing it.

What changed

AI can reshape this layer. Small utilities, prototypes, and integrations that once needed a separate discussion can now be tested quickly. That does not make the outcome free; it makes the feedback loop shorter.

The gap between intent and result becomes easier to see.

And that brings us to the next layer.

2. COORDINATION LAYER

Execution is getting cheaper. Coordination is becoming the constraint.

Even the sharpest minds need rest, and coordination is where decisions are made - not silently in code, but explicitly and visibly.

It requires clear, direct communication. More than that, it requires a communication system that does not turn the coordinator into a bottleneck. This layer has never received enough attention, and lately it feels as if our collective ability to communicate has been getting worse.

Coordination failures used to be difficult to measure because the execution layer was often silent and overworked. Poor decisions, absent decisions, and late communication could be absorbed by the people doing the work. AI makes these failures more visible. Execution is becoming more measurable, more precise, and harder to blame for everything.

At the end of the day, you still cannot push responsibility onto the model.

High-quality communication has a few properties:

1. Timely
2. Sent through the right channel
3. Addressed to the right audience
4. Clear and concise
5. Grounded in context
6. Explicit about ownership and next steps
7. Clear about facts versus opinions
8. Closed-loop: the outcome is confirmed
9. Documented when the decision matters
10. Designed with the recipient in mind

In practice, a decision should leave behind a small, usable trace: what was decided, why, who owns the next action, and when the loop will close. Without that trace, teams keep paying to rediscover the same context.

This is also why “prompt engineering” gave way to “context engineering.” Good context is timely, clear enough to act on, connected to the environment, and documented. It is a decision record the machine can use.

It also reveals how easily poor communication can persist when its cost is hidden. On the other side, engineers who were already close to fact-based, complex communication can practise those skills more often and grow quickly.

This is where many great engineers become good managers. It is also a universal skill: it matters when communicating with people and when directing machines.

3. SYSTEM-DESIGN LAYER

This is where the leverage compounds.

Completing tasks one after another can make you a good executor. But it leaves the largest source of leverage untouched. A task is a unit of work; by itself, it creates no value.

Value appears when task results are assembled into a system, then supported with documentation, deployment, and marketing. Only then can the work reach customers—customers who put money on the table and are satisfied with what they receive.

That is already a system.

In software systems, I have seen this break when the people making product and operational decisions do not share an accurate model of the system. The model misses too many important details.

Here is how it happens. Team members generate code quickly, and features start arriving in hours rather than weeks. Each feature works in isolation. But when the features need to meet, it turns out they were built for different systems. Each person had a different application architecture and data model in mind. IDs do not match, records cannot be mapped across modules, and the same data means different things in different places.

Local productivity looked high. System-level progress was negative.

Then support starts fixing records manually. Finance sees different numbers. The “cheap” features create months of reconciliation work. What looked like fast execution was a missing source of truth.

Every commercial organisation ultimately operates for profit. That is why system design cannot be treated as a purely technical concern: every decision-maker who influences the system needs enough understanding to see its trade-offs and risks.

The useful starting point is not a bigger diagram. It is a shared model of how data, decisions, and people move through the system. Here are a few questions that have consistently helped me understand and improve it.

Data pipeline and consistency

1. Data pipeline: Where does data come from, where is it stored, and where does it go?
2. Data type: Is it a copy (safe to use independently), a snapshot (precise at a given moment), or a reference (connected to its source or destination)?
3. Data ownership: Where is a piece of data born, and who owns it?
4. Data processing: Is it processed, aggregated, or passed through unchanged?

Processing: the flow

1. Simple pipeline: input → process → output
2. Complex pipeline: input → aggregate / compare / validate → process → output
3. Human-in-the-loop processing: At which points can a person influence the system? For example: by providing input, editing processed data after it is stored but before output is generated, or changing historical data.

The third question is crucial. The more human synchronisation points a pipeline contains, the more complex—and usually less reliable—the process becomes.

CLOSING: THE ACT LAYER

Execution, coordination, and system design form the Act layer. This is where ideas become real work: code is written, decisions are made, data moves, and customers eventually receive something useful. AI can make this layer faster, but it cannot make it coherent for us. Without ownership, clear communication, and a shared model of the system, speed only produces more work to reconcile later.

The Act layer is the foundation, not the whole picture. Once a team can act with clarity, the next question is how it decides what deserves that effort in the first place. In Part 2, I will move to the Think layer: the place where direction, judgment, and the quality of decisions determine whether all that new execution power creates value at all.