AI systems /
The winning skill is knowing the building blocks
The first version of a Shopify agent I built could talk to Shopify. It could not be trusted to write to it. Those are two different problems, and the second one is not solved by a smarter model. It is solved by knowing that a validation layer exists, that a store needs a dry-run environment, and that a write action needs a confirmation step before it touches a real product. None of that is in the model. It is in the builder.
That is the shift worth naming. Coding agents made typing cheap. They did not make knowing what to build cheap.
The blocks that made it trustworthy
A Slack-native Shopify agent I run is a working example of the point, not a diagram of it.
- The model decides whether a request needs live Shopify data, then calls a tool rather than guessing an answer.
- A validation layer checks any write mutation against Shopify's own developer docs before it runs, so the system is not operating on the model's memory of an API that has since changed.
- Store routing is explicit. Product IDs, currencies and catalogues differ by region, so the system asks which store when a request is ambiguous rather than picking one.
- Every tool call comes back wrapped as a clear success or error, and the system will not report an action as done unless that wrapper says so.
- Conversation context is rebuilt from Slack history on each request instead of living in a separate database, because for this system that was the simpler and more honest choice.
None of that came from the model reasoning its way there in a single pass. It came from someone who already knew a validation layer was a thing worth having, and asked for it.
Assembling, not coding
Writing code used to be the bottleneck. If you could not write the function, the feature did not exist. That made "can you code" the whole test.
An agent can now write the function. What it cannot reliably do is know that a Shopify write should go through a docs-validation step before the mutation fires, or that a support agent replying in public needs a deterministic rule checked before the model ever sees the message. That knowledge lives one level above the code. It is the map of what exists, what each piece is for, and which piece to reach for.
Assembling is choosing the right blocks and wiring them together correctly. Coding is one part of that. It used to be the hard part. Now it is often the easy part.
The blocks that matter for AI systems
A useful AI system is rarely one clever prompt. It is a stack of ordinary, well-understood pieces, each solving one narrow problem:
- A model to reason and write.
- A retrieval layer so the model can pull the right facts instead of guessing.
- A guardrail layer that decides what the model is allowed to do without a human.
- An identity and routing layer so the system knows which store, region or account it is acting on.
- A persistence layer to hold state between requests.
- A tool or API layer connecting the model to the real system it is meant to operate on.
- An observability layer so a human can see what the system did and why.
None of these are exotic. Most existed before language models did. What is new is how often you now need all of them at once, wired around a model that can reason but cannot be fully trusted on its own.
Why agents amplify the people who know the map
An agent will happily assemble whatever you point it at. That is the amplifier. It also means a bad map gets assembled just as fast as a good one.
A builder with a clear picture of the blocks can describe a system in a few sentences and get a working version quickly, because the agent is filling in code, not filling in judgement. A builder without that picture gets a plausible-looking system that is missing a guardrail nobody thought to ask for, or a validation step that only would have mattered on the one week it did.
Agents also do not automatically know about the newest blocks. Many of the tools that matter, docs-validation layers, agent frameworks, guardrail patterns, were built after most models' training data ends. A builder who reads the actual documentation for a new tool, rather than trusting the model's half-memory of it, still has an edge that will not go away soon.
The blocks you don't understand yet are the dangerous ones
More blocks make more systems possible. They also make more ways for a system to fail quietly.
A retrieval layer that returns confident but stale answers looks fine until the one time it matters. A guardrail that only checks for obviously bad output will miss the plausible bad output, which is the dangerous kind. A persistence layer with no clear ownership of what counts as true will drift from reality without anyone noticing until a customer does.
Knowing a block exists is the first half of the skill. Knowing where it breaks, and building around that, is the second half, and it is the half that separates a system someone can trust from a demo that only worked in testing.
The rule
Do not try to become the person who has memorised every framework. Try to become the person who can name the blocks a working system needs, knows which one is missing when something breaks, and lets the agent handle the typing.
The blocks will keep changing. The skill of knowing they exist, and choosing the right ones for the system in front of you, is the one that compounds.