The recent SG GovTech’s restructuring is a useful trigger for this conversation, because it exposes what happens when a waterfall organization tries to respond to AI without asking the right question first. GovTech retrenched 93 workers in the first phase of a 2-year exercise expected to affect around 300 roles, or 7 to 9% of its workforce. The agency describes it as changing shape rather than shrinking, and says it expects to employ more people once the transformation completes.

GovTech Chose Vertical, Not Horizontal

A waterfall organization moves through a chain of gates, each one requiring sign-off before work continues. AI compresses the work sitting in front of those gates without compressing the gates themselves, since a checkpoint is sized to a reviewer’s calendar and a committee’s cadence, not to how fast the work arrives. Andrew Ng described this in software: when building gets 10 to 100 times faster, almost everything downstream becomes a bottleneck. The same logic holds outside software. Any checkpoint sitting downstream of faster work becomes a constraint, regardless of what industry the checkpoint belongs to. That mismatch is the real disruption, and GovTech’s restructuring is a useful place to see how an organization responds to it.

GovTech’s chairman said the transformation predates the AI wave, and there is no reason to doubt that account. The restructuring was framed around moving from vendor-managed delivery to in-house ownership, not around AI adoption. That distinction matters and should be taken at face value.

Read the GovTech transformation again with that in mind. The move from vendor-managed delivery to in-house build, operate, and secure is vertical integration. It collapses the handoff between GovTech and its vendors, pulls ownership inward, and reduces the number of external checkpoints a project has to clear. That is a real fix, and it solves a real problem.

What it does not do is address the horizontal question, and this is where the AI decision actually sits for any organization: does an AI investment make every existing team and function more valuable, or does it just concentrate the same amount of value into fewer people? Vertical integration answers who owns the work. It says nothing about whether the checkpoints inside that ownership, security review, compliance, testing, still match the speed of the work now arriving at them.

The same choice repeats everywhere organizations respond to AI. Using AI means pointing a tool at a stage of the waterfall and making that one stage faster. Applying AI means asking where the new bottleneck actually sits after that stage speeds up, and redesigning the checkpoint around it, not just the headcount around it.

Most restructurings right now do the first thing and call it the second. Consolidate roles, bring capability in-house, reduce vendor layers, announce the transformation. All of it is vertical. None of it touches the gate that will now stall the faster work sitting in front of it. The organization gets leaner without getting less bottlenecked.

What Actually Needs Reassessing

The honest diagnostic is not whether your organization runs Agile or waterfall. It is whether you can name, stage by stage, which checkpoints were sized for a throughput AI has already made obsolete. A legal review built around one contract a week does not survive a tool that can draft ten. A security clearance process built around one system launch a quarter does not survive a team delivering features daily.

The claim is not that AI caused GovTech’s layoffs. It is that any organization trimming operations today is doing so in an environment where AI has quietly become one of the considerations, whether or not it appears in the official explanation. The checkpoint problem described above is where that consideration will actually get tested, months after the restructuring is announced, when the faster work starts arriving at gates that were never rebuilt for it.

Horizontal improvement is the actual AI at Work strategy question, and it is the one vertical integration skips. It is not about consolidating ownership into fewer hands. It is about whether the same AI investment lifts every existing function, finance, legal, operations, delivery, so each one produces more value without anyone being pulled off the org chart to make the math work. That is value augmentation in practice, and it is a harder result to show in a board update than a headcount reduction, which is exactly why fewer organizations bother pursuing it.

None of this starts with the technology. An agentic harness is not a new capability dropped into an organization. It is an artificial replica of the working loop that already runs between people, the data that moves from one desk to another, the approvals, the informal checks, the conversations that fill the gaps no policy document ever wrote down. Deploy a harness before that loop is mapped and the agent is not automating a workflow. It is guessing at one. Bottleneck management, not agent deployment, is the actual next task sitting in front of most organizations, and it starts with writing the workflow down honestly enough that a machine, or a person, could follow it without you standing in the room.

Share HOW - Everything About AI Literacy

Both accounts are about the model. That is where the attention goes. It is also where the attention is least useful.

My own path ran through both. I started building with the frontier models, the way most engineers did. Recently I moved much of my work to the Chinese models. Not only for the cost. For the design decisions they pushed me toward.

The price gap is real

Search the topic and the headlines agree on one point: the Chinese models are taking share in software development, mostly on price. That part is accurate.

Here is what it looks like in practice. Ask a frontier model to build a CRM in a single prompt and the run can cost over US$20. Ask a Chinese model to do the same and it can cost under US$1. The frontier model is more likely to get it right on the first attempt. The cheaper model usually needs a few rounds of iteration to reach the same place. Even so, the price difference is large enough to pull a lot of engineers across, and it has.

So the incentive is real. But price is not what decides the quality of what you build.

Design decides more than price

Set vibe coding aside for a moment. That is exploration: one prompt in, one output out, and there the model does most of the work.

Building an actual AI application is a different story. If you construct a good data layer to support the prompt, then instruct the model to analyze and respond against that data, a less advanced model can produce results comparable to a frontier one. The model is one component. The data layer, the retrieval strategy, and the synthesis framework are the parts that shape the output.

The price comparison hides this. Two engineers using the same cheap model will not get the same result. The one who built a design specification, a logical workflow, and a data foundation beneath the prompt more reliably, and can explain why. The one who only picked the model cannot.

Less from the model, more from your evidence

There is a deeper reason to care about the layer beneath the model, and it is what separates building an application from using a chatbot.

A consumer chatbot relies on parametric knowledge: the information built into the model during training. You ask, and it answers from what it absorbed. That is fine for general questions. It is a liability for work that has to be correct, because that knowledge can be outdated, generic, or wrong, and you cannot see which.

When you build an AI application, you want the opposite. Less reliance on what the model memorized. More output grounded in evidence you supply from your own data. The model stops being the source of the answer and becomes the reasoning engine that works over your material. Handled this way, the raw capability of the model matters less, because you are no longer asking it to know things. You are asking it to reason over things you already trust.

That is why a smaller model on a strong data layer can match a frontier model running on its own memory. The intelligence moved. It went from inside the model to the structure around it.

The harder audience is the end user

Explaining this to a developer is one task. Explaining it to the person who used to search on Google is harder.

That user opens a chatbot and asks a question the way they used to type it into a search box. They have no reason to know what separates an evidence-based AI application from a chatbot, or what parametric data is versus a dataset supplied at the point of use. What they see is a clean answer, delivered fast. From there the conclusion is easy: the chatbot is more advanced than Google, and Google is old-fashioned.

Look at what each system actually does, and that conclusion inverts.

Google builds a model of relevance before it answers you. It crawls and indexes the web, ranks pages against each other with a system that began with PageRank and now includes a knowledge graph of how entities relate, and then shows you the sources and why one page sits above another. You can inspect the reasoning. The work is visible.

A chatbot answers first from its pre-trained data. When it does reach the live web, the method is often opaque, and in the weaker case it does not build a model of relevance at all. It relies on the one Google already built. This is the part worth emphasizing. Reporting has shown that several leading AI systems lean on search engine results to ground their answers, at times reaching them by scraping the results page through third-party services. The chatbot is not discovering relevance. It is borrowing it, then presenting a synthesized answer with the sourcing out of view. Is this not the same objection the frontier makers raise against distillation, one system taking the value of another's foundational work without reproducing it?

So the user rewards the fluent answer and penalizes the system that showed its evidence. That is a perception bias, not a judgment of quality. And it sits above the model competition without being touched by it. Frontier or Chinese, US maker or Chinese maker, none of it changes what the user adapts to. They adapt to the interface and the instant answer, not to what was built underneath.

Openness decides reach

There is a second reason to look at the Chinese models, and it has nothing to do with price.

The two sides have taken opposite positions on access. The US frontier labs keep their strongest models closed, and access itself has become a policy lever. Most leading Chinese models run the other way. They are open-weight: free to download, adapt, and run on your own servers, in any region.

For a product built to reach the world, that difference outweighs a benchmark. An open-weight model can be deployed on any cloud, in any country, or on your own hardware, without depending on one vendor who can be cut off by a single government decision. A closed frontier model gives you the vendor’s reach, and the vendor’s limits. An open one gives you your own. It runs anywhere. For a global build, that is the part you can plan on.

The competition worth watching

The model makers will keep overtaking each other. A cheaper model closes the gap, a frontier model opens a new one, and the benchmark tables keep changing every month. That contest tells you little about what your own system will produce, and even less about whether an answer in front of you can be trusted.

The competition that decides quality is not between the models. For the developer, it is between a system with a real data layer and a system that only wraps a model. For the user, it is between an answer that shows its evidence and one that hides it. The same distinction, seen from two places.

Pick the cheaper model if the economics favor it. Most of the time now, they do. Just do not confuse that decision with the one that matters. Everyone competes on the model. Fewer build the foundation underneath it, and that is the part that separates the results, whether you are building a system or only reading what it returns.

Share HOW - Everything About AI Literacy

A survey collecting answers through a web page is not digital research. It is a survey with a web form in front of it. The collection method went digital. The research did not.

AI added a new version of the same confusion. A model that crawls hundreds of sources and returns a written brief gets called deep research. It is deep search. It reads what is already published and reports back what it found. And most of what sits on the web is second-party or third-party data: someone else’s collection, gathered for someone else’s question, shaped by someone else’s design. Reading a lot of it quickly is retrieval. It is not research.

Collating a series of those secondary sources into a summary is editorial compilation. It stays compilation until someone does the surgical part: pulling the contextual signals out of the raw data and turning them into measured differences in meaning. Skip that step and you have gathered sources, not studied anything.

That surgical step is the subject of this article. Not the tool. It is the method that researchers need to learn.

Correlation is easy. Dimension is the work.

For years I trained people in web analytics, and one principle sat at the front of every session: do not measure in straight lines.

A single timeline is a straight line. It shows one thing over time, and all you can read is the difference between one point and the next. Traffic rose in March, fell in June. That is linear measurement, and it stays shallow, because a line can only describe itself.

Add one variable and everything opens up. Put a second timeline beside the first. Sales against sentiment. Sign-ups against price. Now you can read three things instead of one: how the first line moves, how the second line moves, and how the two differ at the same point in time. One variable turned a line into a dimension. That two-line read was the first thing I taught, because it is where measurement stops being flat and starts having depth.

When you work from a compiled summary, you rarely get past the single line. You get “these two things seem related,” which is correlation, the easiest observation to make. What you cannot do is measure the relationship, because the raw data that would let you model it was never handed to you. Noticing two lines move together is not the same as measuring how, how much, and when the pattern breaks.

What it gets right

None of this makes compilation worthless.

A skilled editor can take those curated sources and produce something genuinely useful. Direction. A first map of a market. A briefing that saves a team a week of reading. With judgment applied on top, secondary research can be insightful and can occasionally change a decision.

The problem is not that it is useless. The problem is its limitation.

The limitation

Secondary research carries whatever bias came with it. The question someone else asked. The sample they chose. The angle they were paid to take. You absorb all of it the moment you cite the summary, and you usually cannot see it, because the assumptions are buried underneath.

Depth suffers too. A summary compresses. It keeps the headline and drops the exceptions, and the exceptions are often where the real insight lives.

There is a quieter cost. Trusting a cited answer because it is cited is the same reflex people once had for a government index or a famous study. Authority is not the same as validity. A source can be well known and still be the wrong source for your question.

Where serious research begins

Serious research starts one step earlier than the compiled summary lets you start.

It starts with data you gathered yourself, for your own question, before anyone summarized it.

The strongest version of this is behavioral data. What people actually did when no one was watching and no one was asking. A search query is behavioral. So is a click, a purchase, a moment someone gave up and left. Nobody framed it for a study. The person framed it themselves, for themselves. That honesty is something no commissioned report can give you.

When you own that data, AI stops being an answer machine and becomes something more valuable. A researcher’s lens.

What building an AI research platform taught me

I built an AI platform to do this at a depth no spreadsheet reaches.

Plain text search measures how often a term appears and ranks by that count. It is shallow. The platform goes past word counting to nearest-neighbor discovery, finding the records that sit closest in meaning even when they share no words. Each method like this adds another dimension to read across, and reading across dimensions is where discovery happens.

A table cannot hold that for long. A table is a two-dimensional matrix: rows, columns, a flat grid where relationships are read one pair at a time. So I do not stop at the table. I model the data as a graph. Every record becomes a node. Every relationship becomes a link between nodes. A node connects to many others, and those others connect onward, until the data stops being a grid and becomes a network you can move through. A flat table tells you that A relates to B. A graph lets you follow A to B to C, and reach a connection no pairing of columns would surface.

This is the two-line principle taken to its end. One line is flat. Two lines make a dimension. A graph makes a space: a data universe of connected nodes, where a relationship can run in any direction, and depth is measured by how far the connections reach rather than how many columns you can fit.

Depth is worth nothing without accuracy, so nothing is taken on trust. Every pattern the model reads is checked against the actual records, matching its meaning-based reading against exact counts in a structured database, confirming the data is really there and not inferred. One method finds what the data means. The other proves it exists. A finding only stands when both agree.

No human working data by hand reaches this depth at this scale. That is not a criticism of the analyst. It is arithmetic. A person can hold a few relationships in mind at once. The machine can weigh hundreds and check every one against the source.

The methodology is the point

The technology is not the center of this. The methodology is.

The algorithms create the dimensions. The researcher decides which ones matter, what question they answer, and whether a pattern means anything at all. AI did not replace that judgment. It extended the reach of it.

This is what augmentation truly is. Not a faster tool. A wider analytical mind. The human still does the thinking. The machine lets that thinking travel further than one person could carry it alone. Call it a technical advance and you have missed what changed. What changed is how far a serious researcher can now see.

You can borrow the finding, not the practice

AI did not lower the standard for research. It lowered the effort, which is not the same thing. Effort dropping is only good news if the standard holds.

Secondary research can borrow a serious researcher’s findings. It cannot borrow the practice that produced them. The finding is the part you can quote. The practice is everything underneath it: the question framed before the tool was opened, the data gathered first-hand, the dimensions tested against each other, the results checked against the source until they held. None of that travels with the citation. You get the answer without the discipline that earned it.

That is the difference between borrowing a conclusion and standing behind one.

I am serious about research. I choose the serious side, and I always have. The tools will keep changing. My choice will not.

Share HOW - Everything About AI Literacy

“Google data is not legitimate. We need an authoritative source.”

“But you use Google every day.”

“Of course. And the search results it gives me are not considered as a legitimate source of data.”

I have a version of this conversation almost every time I mention Google data. It is short, and it hides two mistakes that explain why so many people misunderstand AI.

Start with the first one. Ask a room of professionals what data is and you get a confident answer. Numbers in a spreadsheet. Records in a CRM. Rows, fields, tables. The confidence is real, and it comes from control. They enter the figures, sort the columns, run the filters. Managing the software feels like understanding the data.

It is not. Before a single number reaches the screen, something decided it was fit to show: scored for quality, filtered against rules, checked against other records. Most people never see that this layer exists. They manage the output and call it the data.

The person in that conversation pictured the search results page. The blue links you scroll past on the way to an answer. That is not Google data. That is the output. The data is something else entirely, and the distance between those two ideas is where most people’s understanding of AI quietly comes apart.

Data Is Not Flat

Most people treat data as one thing. Information that happens to be stored somewhere. A spreadsheet of sales. A folder of reports. A list of contacts. All of it filed under a single word: data.

But data is not flat. Every source has a characteristic. It was created for a reason, through a specific action, in a specific context. That reason is built into the data whether you notice it or not. Read the source correctly and the data tells you something true. Read it wrong and you build on a meaning that was never there.

The Truth Inside a Search

Take Google again. Search data is not marketing data, even though marketers use it every day. A search query is a record of intention. Someone typed what they actually wanted to know, in their own words, at the moment they wanted it.

Read those words and the intention sharpens. “Should I learn AI” and “how to learn AI” belong to the same category and reveal different mindsets. One is still deciding whether it is worth the effort. One has already committed and wants a path. The word choice, the subject, even the time the search was made all form a behavioral pattern. If you cannot read the intention, you are looking at text, not data.

One query is a single intention. Put many together and a larger signal appears. A sudden spike in searches for one problem is a trend forming, and the timing shows the moment it began to matter. A rising volume of questions about a subject is demand made visible: what people want, what they need, what they are trying to solve. When many people search for something the market has not supplied, that gap is the opportunity, already measured by the number of people asking for it.

Authority Is Not Validity

The second mistake in that conversation was the demand for an authoritative source. Most people judge data by where it came from. A government index. An academic study. A report from a large research agency. The name carries authority, so the data feels valid.

That instinct confuses two different things.

When you use those sources, you are doing secondary research. In data terms, call it second-party data. It is someone else’s collection, gathered for someone else’s question, shaped by someone else’s design. You inherit their assumptions along with their numbers.

There is comfort in that, and it has nothing to do with accuracy. An authoritative source also shields you from blame. If the number is wrong, the mistake is theirs, not yours. If the expert was wrong, everyone who trusted the expert was wrong with them, and there is safety in a shared mistake. That is an attitude, not a practice. It is a quiet way of refusing to own the data you use.

Run your own study and you get first-party data, which sounds better. But a focus group or a survey is a controlled environment. The room, the moderator, the order of the questions, and the researcher’s own expectations all bend the answer before it is recorded. Control adds rigor and adds bias at the same time. A question written to test one idea rarely leaves room for the answer nobody expected.

The data that escapes this is behavioral. It is collected in an uncontrolled environment, where no one is asking anything and no one is watching. A search query is behavioral data. So is the subject pursued, the words chosen, and the hour it happened. Nobody framed the question. The person framed it themselves, for themselves.

This does not make behavioral data perfect. It makes it honest in a way commissioned research cannot be, because nobody was in the room shaping it. A record of what people actually searched can reveal more than a study designed to find out.

What AI Does With Data

An LLM does not create knowledge. It works with meaning that is already in the data, and it works with it at a scale no person can match.

The technique behind most serious AI systems is retrieval-augmented generation (RAG). Strip away the name and it is semantic search: the system finds data by what it means, not by matching exact words. That only works when the meaning inside the data is clear. The model reads the attributes and dimensions that describe each record to decide what connects to what.

This is where AI earns its place. A human analyst can hold a handful of variables in mind at once. AI can test how hundreds of them relate at the same time. That kind of discovery, the sort that surfaces a pattern nobody thought to look for, is close to impossible to do by hand. With AI it becomes ordinary, as long as the data underneath is sound.

In the digital era we said content is king and data is queen. In the AI era, data powers the knowledge of the king and the queen. It is what the model reasons over, and a model knows nothing its data does not contain. AI was built to understand the world from data, and in practice that means one thing: mapping how different data relate to each other.

Which is why the meaning of your data decides everything the model can find.

Why This Breaks AI

The reverse is just as true. If you do not understand what your data represents, you do not understand what the model is reasoning over. You typed a question. It returned an answer. You have no idea what meaning it drew from, what it assumed, or what it treated as fact. The output looks complete. Underneath it is a body of data whose intent you never examined.

People blame the model when this goes wrong. Usually the reasoning is not what failed. The data it reasoned over is. With a general model, that data is whatever it absorbed in training, which can be outdated or wrong. With a retrieval system, that data is whatever you fed it, and its quality is your responsibility. Either way, the failure traces back to data, and to someone who did not know what that data was for or where its validity came from.

Know What Your Data Is For

Every source answers a different question. A survey gives you the answer to the one you asked. A published study gives you a result under fixed conditions. A citation count gives you attention, not correctness. A search gives you a private intention, offered while no one was asking. Feed them to a model as if they are the same, and the answer comes back confident and quietly wrong.

Understanding your data means knowing what each source can honestly tell you. That is not a technical skill. It is closer to reading. It is also where searching gets confused with researching. People find a paper that fits and trust it the moment they see the citation, but finding a study is not the same as checking one. The discipline is to hold secondary research against first-party evidence, and behavioral data like search intent is one way to run that check. Skip it and you have not researched anything. You have found something you like.

The same trap now surrounds AI itself. Its output gets treated as authoritative, the way a government index once was. But a model’s answer is only as sound as the data behind it and how that data was handled. Trusting it because a machine produced it, without knowing the source, is naive. Authority was never proof, whether the name belongs to an institution or an algorithm.

This points to the stronger position. Re-quoting secondary research and treating its findings as settled truth is the weak one. Gathering unbiased data of your own and using AI as a lens to read it, testing relationships and surfacing patterns no published study was designed to find, is the strong one. One borrows a conclusion. The other discovers it.

Data was always the input, never the output. If you do not understand it, you are not using AI. You are simply trusting it.

Share HOW - Everything About AI Literacy

The story we hear nowadays is a software developer’s view of how things get built and then treated as the way all work should be done. I want to look at that more closely, because generalizing the developer’s view onto every workflow and every problem is sometimes an improvement and sometimes an imposition.

Most (If Not All) Work Is Deterministic

What took me a year of working intensively with AI to see clearly is this. Most work, in the end, is deterministic. A credit officer approves or declines. An editor runs the piece or holds it. A doctor treats or waits. Whatever messy thinking happened before, the work resolves into a decision that has to be consistent. The same evidence should produce the same call, today and next week, from this person and the one beside them. That consistency is not optional. It is what makes a decision trustworthy, defensible, and accountable.

At work, our minds wander, associate, and guess, but the decision we deliver does not wander. We sit on top of the evidence and reason our way to a call that holds. The determinism is not in the brain. It is in the discipline of grounding a decision in evidence until it becomes consistent. We have a non-deterministic mind, but held to evidence, it produces a deterministic decision. That is what professional judgment is.

The Machine Is a Different Shape

AI does not work this way. An AI model is probabilistic at its core. It matches patterns and draws an answer from a spread of likely possibilities. Ask an LLM the same thing more than once and the answers can differ, both of them plausible. Even when you pin it to one, that one is the most likely continuation of your words, not a decision reasoned from your evidence. It is not sitting on top of the facts and choosing. It is sampling what usually comes next.

Our workplace is built on a non-deterministic process that produces a deterministic decision, anchored in evidence. An AI model, by contrast, is a probabilistic process that produces a probabilistic output, anchored in patterns. The machine and the human are opposite shapes.

If you are working with AI, it takes effort to do evidence grounding and quality gates to make a probabilistic output more pseudo-deterministic. Most of the time, you are narrowing the chance of errors, not eliminating them.

Deterministic Is a Developer’s Word

Let’s step back and look at what we are actually discussing. Deterministic is not even a word most people use for their work. It is a developer’s word. Outside software, nobody calls a decision deterministic. They call a leader decisive and an employee precise. Same idea, different language. A decisive leader makes the same call from the same facts. A precise employee delivers the same output to the same standard. That is determinism, named in human terms, and it was the quiet expectation of professional work long before software borrowed the word.

This matters because the frame arrived before the technology did. Now we start describing our own work in the developer’s vocabulary, and once the words are theirs, their way of producing the work starts to feel like the natural next step.

A borrowed vocabulary carries a ranking with it. In the developer’s world, the word for good is frontier: the newest model, the latest method, the edge of what is possible. Borrow the language and you inherit the ranking, and by that ranking your own work is never frontier. The steady, consistent work a profession is built on starts to feel dated, not because it stopped working, but because it is now being judged against someone else’s idea of what counts. This is how a borrowed word does its real damage. It does not just rename the work. It quietly persuades you the work was never good enough, and that the cure is to do it their way.

The Harness Does Not Travel

The developer’s way of producing the work has a name too. The harness. You describe what you want, and you set AI agents loose to build it, check it, and build again, running without stopping and without waiting for you. The people building the frontier models are right that this is powerful. In software it is genuinely transformative. I have watched it turn a day of work into an hour. On the right task the gain is real, the kind of 10x to 20x that sounds like marketing until you have seen it.

But look at what the number measures. Speed. From the start, this technology has been about speed. Faster code, faster drafts, faster answers. We treat hitting the multiple as success. But speed is a means, not an end. A boost is only worth something if the time it frees becomes something new. What you do with that time is where the real gain would be.

That is the step the conversation skips. Everyone shares how they hit the multiple, a day of work folded into an hour. Almost no one shares what the freed day was spent on, or what new value came from it. The story stops at the boost. The boost gets reported as the result.

Someone Builds the Rules

The speed is not as clean as it looks. A fast probabilistic model produces hasty, half-finished output. This is common, and it is not only hallucination. The model can retrieve too little, anchor on the wrong thing, or lose the focus of the task, and still hand you something that reads fine. So engineers build grounding and quality gates around it. They pin it to sources. They check its output against fixed rules before it passes. Every one of these is a deterministic move.

In my experience, the 10x to 20x only holds when a lot of that deterministic design sits underneath it, governing what the agents may do and how their work is checked. The speed is real, but it runs on a frame of deterministic rules. And who builds that frame? A human, easily. Deciding what counts as grounded, what a gate should catch, where the model may range and where it may not, that is judgment about the work, written down as rules. It is the most human part of the system, and the part the harness cannot build for itself.

Whose Call It Is

None of this makes the model less remarkable, and none of it is a reason to keep it out of the work. There are large parts of every job where a probabilistic output is exactly what you want, and the model produces it faster and often better than I can. The skill, the thing a year of this has taught me, is telling those parts from the parts that need a decision instead of a sample. And that is not a developer’s call to make on behalf of every other field. It belongs to the people who know what their own work actually has to produce.

Replace or Improve

AI replaces human work. We say it like a fact about the technology. It is not. AI did not decide to replace anyone. People built it to do that, and people chose to tell it that way. It describes a choice we made, not something the machine did. And the choice could go the other way. Replace is one intention. Improve is another. The tool is the same. We picked replace.

The better version is possible. AI can raise the quality of human work, not just the speed of it. That is the one worth building. It is also the one nobody is selling.

The media still describes the human economy in the developer’s language, and still prefers the doom ending, because doom reads better than nuance. What I have not seen, not once, is a headline showing AI making a human economy more prosperous, backed by a real case. Until that case exists, and until the story is told in our own words, the headline will keep selling the end of work.

The prosperous version is available. We have just not written it yet. The story is ours to choose, and so far we have chosen the one that frightens.

Share HOW - Everything About AI Literacy

Ramp, a US financial technology company that builds corporate expense management software, publishes a running index of how US companies actually pay for AI. The data skews toward tech-forward companies. I find it insightful because these companies may show what the rest of the market will look like in a couple of years.

Here Is What The Data Shows.

The spread is extreme.

The top 1% of companies spend $7,449 per employee per month on AI. Software engineers at those companies run roughly double that. The top 10% spend $611 per employee per month. The median company spends $11. That is one low-tier AI chat subscription.

Three groups, three completely different realities, all inside the same economy. The $11 figure is the one to sit with. The typical company is not maxing out its token spend. It has barely started.

This also kills the token maxing narrative. Token maxing was the idea that companies should spend as much as possible on tokens. If that were real, you would see spend rise and then fall. The data does not show that. Every tier is still climbing. There was no peak to retreat from.

What This Means For You

Find where you sit on the curve, then ask the question the spend alone cannot answer: is this money buying capability or a subscription? A company at $11 with a single tool does not have a budget problem. It has a practice problem. Telling those two apart is the work, and it is the part a tool vendor will never do for you.

What separates the top is not budget or access. It is discipline. The people getting value do not treat one chat window as the whole of AI. They use several tools and send each task to whichever one handles it best. They give clear direction and check what comes back against what they already know. The median opens one chat window and takes whatever answer it gives.

There is a cost-control gap underneath all of this, and it points the same way. About 80% of the model vendors’ business revenue is token-based, and they have built almost nothing that helps you control that spend. The discipline will not come from the AI vendor. It has to come from the practice you build, not the platform you buy.

The $11 company and the $7,449 company are separated by practice, not money. The same is true of two people doing the same job. One uses AI to think. The other uses it to skip thinking. The work can look identical, until the moment someone has to defend it.

What AI at Work Can Learn Here

The AI educator Andrew Ng described this directly at a recent developer conference. A year ago he wrote about the product management bottleneck: when building software gets fast, the slow step becomes deciding what to build. A year later, he says, that bottleneck got worse, and it did not stop at product. When software gets built 10 to 100 times faster, almost everything downstream becomes a bottleneck.

Why There Is No Universal Fix

When every stage becomes a bottleneck, the problem is the operational chain, not any single step. And AI does not relieve a chain evenly, because AI is a generalist.

It is broad by design, trained on everything and expert in nothing in particular. That breadth is why it looks like a universal catalyst you can point at any department. But breadth is not depth. A generalist can draft a marketing email or a first-pass terms of service. It cannot run the agentic operation of a compliance review or a credit decision without the rules, edge cases, and judgment that live inside that function and nowhere in its training.

So the acceleration is uneven, and predictably so. AI clears the generic stages and stalls at the specialized ones. The bottleneck does not settle at random. It collects where the most domain expertise is required, which is exactly where Ng saw it land: legal, compliance, the work that carries consequence. The cascade ends at the domain experts.

Which is why the consultant’s hardest task is also the most valuable. No deployment lifts every department at once. Each function has to encode its own domain before a generalist can operate inside it. The universal catalyst does not exist. The domain expert who can teach the generalist that corner of the work does.

The Foundation Is the Point

There is no universal fix. The foundation is the part most companies skip.

The $11 is not the problem, and spending more is not the answer. The mistake is what the $11 buys: quick answers, typed into a chat window and forgotten. That is the lowest use of AI, and 50% of companies are doing exactly that. It produces a reply and leaves nothing behind. No benefit. No growth.

Spend the same $11 differently and it becomes a baseline. Point it at planning. Use it to classify your data, surface what you actually have, and turn scattered information into insight you can reuse. Each session should leave something the next one builds on. That is not a quick answer. It is a foundation, assembled gradually, that any later redesign will stand on.

This is the work an AI at Work consultant should lead. Not a workshop full of jargon. Not a class on how to prompt. Prompting is the easy part, and it ages out with every model. Teach a company to prompt and you have trained an operator for this quarter’s tool. Help it build the foundation and you have given it something the next bottleneck cannot take.

The companies at $11 are not behind because they spend too little. They are behind because they treat AI as an answer machine instead of the start of a system. The ones that pull ahead will not be the biggest spenders. They will be the ones who built a foundation while everyone else bought answers.

Share HOW - Everything About AI Literacy

I worked alongside them long enough to know the difference. A digital native is not someone who is good with technology. It is someone whose defaults were shaped by the medium before anyone taught them a thing. You can spot one without a test. The behavior gives it away.

Mobile is the default platform, not the fallback. Patience is thin, measured in seconds. Two-source validation is not a habit, so one result is treated as the answer. A 20% sample is enough to draw a confident conclusion. Social media is the home of the internet. A peer’s opinion carries a higher trust score than the news. Learning runs deductive, accepting the crowd’s claim and generalizing it, rather than inductive, verifying each claim and building understanding from what holds.

None of that is a curriculum. No school issued it. The medium issued it. That is what native means. The defaults form before the awareness does, and they show up in how a person behaves under no instruction at all.

Digital Native at Work

Hold that definition. Take it out of the social setting and bring it into the office. Watch what actually changed.

The internet went mass. Commerce moved to mobile. Email became Slack. Documents became cloud files. These are real changes, and they happened across every industry. But notice what they have in common. They are tool changes. The work itself stayed largely the same. The workflow that produced a decision in 2005 produced the same decision in 2020, with a faster medium between the people involved.

The data tells the second part of the story. Digital engagement generated an enormous amount of it. Every click, every transaction, every message produced a record. The native generation grew up inside that data flow. And yet, when those same natives entered the workforce, the data did not become the basis of decision-making. The decisions were still made by humans, with the same instincts as before. The data sat there, mostly unused, in dashboards no one opened.

What digital did change at work was communication. Faster messaging. Wider audiences. Lower-friction collaboration. The decision points in a workflow still required humans to read each other, agree, and act. The tool got better. The judgment did not.

This is the precedent that sits behind every AI-native conversation. The last wave gave us tools and called it transformation. The work itself was not rewired. So when the new wave arrives wearing the same vocabulary, the question is worth asking: is this wave different, or is it the last one with new labels?

A Loud Term With a Hollow Center

AI-native is the phrase of the moment. Foundation model companies use it. Government campaigns use it. Economists and consulting decks use it. Read enough of them and a pattern appears: the term defines how a company is built, not what the people inside it do.

AI-native means AI was designed from the ground up, not bolted on. It means workflows rebuilt around models instead of features layered on top. It means unified data, agent-executed tasks, continuous evaluation, governance. It means the entire operation runs as a closed loop: problems identified, solutions applied, no human in the middle. One widely cited test says a system is only AI-native if removing the AI makes the product stop working entirely.

These are real definitions. They are also, to a working professional, abstract to the point of being useless. They describe a building. They say nothing about the people inside it.

Here is the question none of these definitions answer. What does an AI-native person actually do differently at their desk? What is the workflow, step by step? Who is in the room, and what are they doing while the model runs? At what point does a human decide, and at what point does the machine?

We are told AI-native is the goal. We are rarely told what working inside one actually looks like.

Where AI-Native Already Works

I have been observing one software company moving toward an AI-native model, by my definition. The shape of it is concrete enough to be useful.

17 people. 4 products. Each product handled by one developer and a roster of AI coding agents. On the production side, the operation is genuinely AI-native. The agents replace the coders. They write, refactor, and iterate. They are not a productivity layer sitting on top of a human team. They are the team.

What does the single human developer actually do? System design. Code review. Deployment. They sit above the agents, not beside them. They set the architecture, judge the output, and own the release. The agents do everything else.

And the agents’ share keeps growing. Infrastructure is being added to the production stack so agents can deploy products and keep them running live for public users. Deployment is moving from the human to the agent.

This is a working description, not a blueprint. The defaults are visible. The division of labor is named. It is the kind of evidence the term has lacked.

It is also narrow. The pattern works because software product development has a property most work does not. The output is verifiable by test. The spec can be expressed in code. The failure modes are well understood. Inside those conditions, agents can be deployed and supervised in a stable way.

Take the same logic into the parts of a business that do not share those properties and the model breaks. Management work involves judgment under ambiguity. Customer interactions require reading a human in real time. Workflow alignment, getting different functions to agree on what comes next, depends on negotiation, context, and trust no agent currently holds. These are not edge cases. They are most of what an organization does outside its product team.

What Does AI-Native Actually Mean?

AI-native is achievable in software product development. AI-native as a whole-company operating model is not, at least not yet. The whole-company version gets treated as the product team scaled up. It is not. The conditions that make it work in software do not exist in the rest of the business.

The industry’s answer is the harness. Code the company. Encode every workflow. Hand the operation over to agents to run end to end. Frontier consultants are selling this as the next inevitable step.

In my opinion, it is not. The model that can read a business function, write the code that runs it, and supervise itself in production does not exist yet. Even if it did, the transition would not be a software install. It would require an engineer inside every functional area: a finance engineer, a marketing engineer, an HR engineer, an operations engineer. Each one would have to encode their own function before any agent could run it. That is the hardest organizational transition I have seen proposed. I cannot picture how most companies get there from where they are.

So in the meantime, AI-native has to mean something achievable. Something at the level of the worker, not the company.

Being AI-native does not mean human work disappears. The way the digital native made the medium their default, the AI-native makes AI their default. But defaulting to AI does not mean outsourcing your experience and judgment. The correct practice is to let AI start the work. You finish it.

This, I believe, is an achievable AI-native workflow.

Share HOW - Everything About AI Literacy

It isn’t new.

Office workers have been orchestrators for decades. The agentic moment did not invent the role. It just gave it a name and asked whether you still remember how to do it.

What Orchestration Actually Was

Before any of this, a capable office worker ran their day as a sequence. A campaign manager in 2015 did not produce a campaign by opening one tool. They moved through a pipeline. Research platform for the audience read. A brief written from the research. Design tool for the creative. Copy review with the brand guardian. Media plan in a spreadsheet. Launch on the platform. Analytics on the back end.

Each step had an input, a tool, a person, and an output that fed the next step. The worker chose what went where. They knew when an output was wrong because they knew what the next step needed. They sent things back, swapped tools, asked for a rewrite.

Nobody called this orchestration. It was just doing the work.

What the Chat Window Quietly Removed

Then the AI chat window arrived. Open it. Type a question. Receive an answer that looks complete. The plan gets done in one step. That is how it looks.

A generation of professionals who used to think in workflows now thinks in prompts. The output got faster. The thinking got shallower. The orchestration discipline went quiet.

The interface collapses the workflow into a single surface. There is no visible sequence. There is no obvious next step. The output looks finished, so the worker stops there. The pipeline that used to exist in their head, the one that decided what tool came next and what good looked like at each stage, becomes unnecessary.

This is a behavioral regression. Not technological.

The Consultant Who Works the Smart Way

A workplace consultant I know practice with sharp instinct for what each tool is for in her workflow. She is not impressed by AI. She is precise with it.

Every project starts with the output. A board-ready presentation on workforce trends. Data the client can defend in a meeting. The definition is written down before any tool gets opened. The work is not “let me see what the AI gives me.” The work is “this is what I need, now where does each step happen.”

From there, the sequence is deliberate. She uses an AI research tool to pull primary sources on workforce data. The raw output is not the insight. It is the material. She moves the verified material into a curation tool, for example something like NotebookLM or Claude Cowork, where the data can be organized, cross-referenced, and queried against her own hypothesis. The insight emerges from her reading of the structured material, not from a single prompt.

Then she moves the structured insight into the output format. A slide deck for the board. A tabulated data sheet for the operations team. Each format has its own tool and its own standard for what good looks like. She does not ask one tool to do everything. She picks the right one for each step.

At every handoff, she validates. The research tool’s output goes through her judgment before it enters the curation tool. The curation tool’s structure gets reviewed before it becomes a slide. The slide gets read against the original client question.

She did not learn orchestration from an AI course. She has been doing this for fifteen years. The tools changed. The discipline did not. What looks like a clever AI workflow is actually an experienced professional refusing to skip steps.

What Changes When You Orchestrate Instead of Operate

An operator asks: what can this tool do for me?

An orchestrator asks: what does this work require, and which step is this tool good for?

The two questions look similar. They produce completely different work.

The operator opens ChatGPT and types. The output arrives. They paste it into a document. If it feels off, they ask for a rewrite. If it still feels off, they edit it themselves. The workflow has one tool, one step, and no validation other than the worker’s intuition.

The orchestrator opens a document first. They write down what the output needs to be and what good looks like. Then they decide which tool handles the research, which tool handles the structuring, which tool handles the drafting, and where they themselves need to intervene. The workflow has multiple tools, multiple steps, and validation at every handoff.

The orchestrator’s work takes longer to start. It produces better output, more reliably, and the orchestrator can explain why each part of the work was done the way it was. The operator cannot. The operator can only point at the tool.

Without an Orchestrator, the Workflow Breaks

This is the part the agentic conversation skips.

An agent does not invent a workflow. It runs one. If no human in the organization can chain the tools, define what each step produces, and improve the practice over time, there is no workflow for the agent to step into. There is only a sequence of disconnected outputs that nobody is auditing.

Companies that quietly remove the orchestrator and announce an agentic transformation are not advancing. They are dismantling the only person who knew how the work actually moved. The agent gets deployed into a process that was never properly mapped. The output looks finished. Six months later, the quality drops and nobody can explain why.

Advancing the practice does not require an agent. An organic workflow with a proper chain of input, process, and output can produce quality work for a long time. The orchestrator is the one who keeps that chain honest. They optimize the handoffs. They swap a weak tool for a stronger one. They evolve the practice when the work changes.

Remove that person and the workflow does not become agentic. It becomes brittle.

What Agentic Operation Should Actually Be For

An agent can run a workflow 24 hours a day. The question worth asking is: do we need 24 hours of the same workflow?

Most office work does not benefit from continuous execution. A board presentation does not need to be generated overnight. A campaign brief does not need to be drafted at 3am. The work has a rhythm, and that rhythm is set by the humans who consume the output.

Where agentic operation earns its place is somewhere different. Not in running the workflow faster. In running discovery alongside the workflow. Scanning sources the team has no time to scan. Surfacing patterns the team has no bandwidth to detect. Filling the pipeline with the next question worth asking, the next product worth building, the next service worth offering.

The orchestrator runs the current workflow. The agent, if deployed well, expands what the next workflow could be about.

That is augmentation. The agent does not replace the orchestrator. It gives the orchestrator more material to orchestrate.

The Promotion You Already Earned

The AI chat window made the work easier. It also made the discipline disappear from view. Most office workers using AI today still have the orchestration instinct. They have just been encouraged, by a frictionless interface, to skip the part where they use it.

The promotion from operator to orchestrator is not a course. It is a recovery. The discipline that produced any good piece of work before AI is the same one that produces good work with AI now. And it is the same discipline that any future agent will depend on to be useful.

You have been the orchestrator all this time. The tools change. The way you decide what work needs to happen, and how it should be handled, does not.

Do not hand your discipline to the agent and ask it to repeat your tasks faster. Hand it your knowledge and ask it to find what you have not yet discovered. That is where the next workflow comes from. That is where the next product or service is invented.

The agent runs. You are always the orchestrator.

Share HOW - Everything About AI Literacy

This is the showcase scenario. If autonomous AI agents are going to replace human teams, this is what it looks like. An overhead of US$1.3 million for a small software development team working in an agentic environment.

The Two Ways We Work With AI

I believe most people are not Peter Steinberger and this is how we use AI every day. Two ways of using it. Both produce output. Only one of them is actually thinking with you.

The first way is the one most people know. Open a chat window, ask a question, take the answer. AI breaks the question into components, retrieves what it needs, reasons across the parts, generates a response. This is information processing done well. Decomposition. Retrieval. Synthesis. Output.

The second way is different. You are not asking for an answer. You are asking AI to think alongside you on a problem. You challenge its first response. You feed it constraints it could not have known. You tell it where its assumption breaks against an outcome it has never seen. The output gets sharper not because the model got smarter, but because you gave it the context and information it could not infer on its own.

This is where AI proves its worth. Not as a source of answers. As a reasoning engine that needs direction.

In my daily working routine, I do mostly the second way. US$25 and 23% of my Claude Code Opus session, gone in the first 30 minutes. Thinking with AI is not a US$20 monthly chatbot subscription.

The Economics of Giving AI The Wheel

If 30 minutes of thinking with AI costs me US$25, what does a full operation cost when AI runs it?

Steinberger’s bill made the news. The economics behind it did not. US$1.3 million a month works out to roughly US$43,000 per day. For a three-person team. The agents do not take breaks, do not negotiate salary, do not need health insurance. They also do not stop spending.

The math sounds wild until you remember what an agentic operation actually is. Not a one-off query. Each agent is running its own loop, on its own task branch, at its own pace. None of them stops on its own. The agent receives an input, calls an LLM to reason about it, exchanges data with an API, evaluates the response, decides the next action, calls the LLM again. Each turn costs tokens. Multi-step workflows multiply the cost. 100 agents running in parallel multiply it again.

This is the part the autonomy narrative never mentions. Agentic operation is not free software running on your laptop. It is a metered service consuming compute every second it is awake.

When AI Gets Expensive, Humans Get Cheap Again

The irony in Steinberger’s bill goes deeper than the headline number.

US$1.3 million a month is the price of three engineers running 100 agents. The same money hires 70 senior engineers working full time. At some point the cost curve crosses, and the cheaper labor becomes human again.

This is not a thought experiment. Eventually the same conversation will be picked up by the newspaper headlines. The math is simple. An agent that costs US$13,000 a month to run does work that a junior engineer could do for less. A fleet of 100 agents costs more than the engineering team it was supposed to replace.

The autonomy narrative assumed AI would get cheaper as it got better. So far we see the opposite is happening. Models are getting more capable and more expensive at the same time. Reasoning consumes more tokens. Agentic loops consume more reasoning. Each capability upgrade is also a cost upgrade.

Somewhere in this curve, the spreadsheet flips. The CFO who approved the agent fleet last year will approve the human team next year. Not because humans got better. Because AI got expensive enough that the comparison stopped being obvious.

The Agent Does Not Know When To Stop

The cost problem and the cognition problem are the same problem.

An agent runs the loop because the loop is what it was built to do. It does not stop to ask whether the task is worth the tokens. It does not pause to consider that the same fix has been attempted three times and maybe the specification is wrong. It does not look at the bill and decide that the operation is producing more cost than value.

A human would. A junior engineer who burned US$43,000 in a day would be in a meeting the next morning. They would justify the spend or learn not to repeat it. They would notice that productivity measured in commits is not the same as productivity measured in shipped value. They would know when to stop.

The agent does not have that move. It runs until it is told to stop, and it is rarely told to stop because the dashboard shows it working. Working and producing value are not the same thing. The agent cannot tell the difference.

This is not a budget problem that better pricing fixes. It is a judgment problem. And judgment is the thing AI does not have.

Until AI Knows How To Throw A Curve Ball

A curve ball is the unexpected move. The one that breaks the pattern because someone read the situation and decided the standard response was wrong. It does not come from the playbook. It comes from instinct shaped by experience the playbook never captured.

AI does not have that move. It cannot reach outside the mainstream of its training to make a decision that contradicts what it has been taught. Ask it for the standard answer and it will deliver one. Ask it for the answer that breaks the pattern because you sense the standard is wrong here, and you will get a polished version of the standard anyway.

The unexpected move lives outside the training data. It cannot be retrieved. It can only be lived.

Until AI knows how to throw a curve ball, the agent will run as long as the tokens hold. It will produce output as long as the API responds. It will not stop to ask whether the work matters because it does not know what mattering looks like.

But you do. That is the job. That has always been the job.

Share HOW - Everything About AI Literacy

In May 2026, former Google CEO Eric Schmidt told University of Arizona graduates that AI will reshape every profession, every classroom, every hospital. The crowd booed. He paused, acknowledged their fears were “rational,” and urged them to shape the future of AI rather than reject it.

Weeks earlier, real estate executive Gloria Caulfield was booed at the University of Central Florida for calling AI “the next Industrial Revolution.”

Two stages. Two speakers booked to deliver hope. Two audiences that responded with discontent before the speeches ended.

The reaction has a reason. Across Hong Kong, full-time job vacancies suitable for university graduates fell from 80,000 in 2022 to 31,000 in 2025. Administration roles dropped nearly 90%. IT and programming fell 80%. In Singapore, entry-level ICT job postings have contracted sharply as roles get restructured around AI, with the information technology sector outlook dropping to 15%, reflecting widespread concerns about artificial intelligence replacing entry-level roles. Global consulting surveys point to the same trajectory across multiple markets.

For a graduating student, the math has become brutal in its symmetry. The date of graduation is, increasingly, the date the job market closes. Four years of tuition, exams, and projects, and the position they trained for has been restructured out of existence by the time they cross the stage.

The boos are not anti-technology. They are the right reaction to the wrong message.

Fear Is Not Advice

The default message from speakers, governments, and employers has hardened into one tone: adapt or be left behind.

It is meant as motivation. It lands as a threat.

Telling a 22-year-old to “shape” the future while showing them a labor market that has already locked them out is not a call to action. It is a confession that the people in charge ran out of better ideas.

Fear is not advice. It does not tell a graduate what to do next to continue the journey. It does not name the work that needs doing, the skill to build, or the role to aim for. It only tells them the ground is moving.

What Should We Celebrate For Graduation?

Teachers teach. Students learn. A commencement marks the work both sides did together.

When a graduating class boos, that arrangement has broken. The students are signaling that the journey did not deliver what was promised.

It is worth asking who failed first.

Education Has Been Falling Behind for Decades

This is not a new failure. It is the latest version of an old one.

Education did not absorb every innovation since the beginning of digital evolution. It did not pick up digital practices, e-commerce, or the economics built within the digital ecosystem. It did not adapt to data analytics. Each wave produced the same response: defensive policies, bolt-on certifications, syllabi updated without rebuilding the pedagogy underneath.

What got built instead is a credentialing machine. Degrees, certificates, accreditation. The bureaucracy of education grew faster than the practice of it. Knowledge building has not been the design center for a long time. Compliance with credential frameworks has.

AI did not cause this gap. It exposed it.

The Pedagogical System Is Collapsing

The question, plainly: is the pedagogical system collapsing?

Our intention to build knowledge has not kept pace with the evolution of intellectual advancement around it. AI sharpens the gap. The technology is now at a stage where knowledge transfer can be transformative through self-improvement methods. A student with a model and a serious question can iterate, test, and refine understanding at a pace no traditional classroom matches. The mechanics of transfer, the part teaching has historically owned, is being done elsewhere.

Here is the symmetry the conversation keeps avoiding. Students face a job market judging whether they can produce value AI cannot. Teachers face the same judgment against the same standard. But the industry rarely warns teachers to adapt or be left behind.

The protections the teaching profession has relied on, accreditation, tenure, institutional inertia, will hold for a while. They will not hold indefinitely.

“Learn AI” as Tool Training Is Naive

Less than a year ago, universities were treating AI use as plagiarism.

In July 2025, Singapore Nanyang Technological University upheld a zero mark for a student after a panel found 14 instances of false citations or data in her essay. NTU said the errors were commonly associated with generative AI tools, which were explicitly prohibited for the course. The student was penalized.

Now the same bureaucratic system is warning students that they are not using AI enough.

Students penalized last year for touching AI are being told at graduation this year that the future belongs to those who embrace it. The signal flipped from “do not use this” to “you are behind if you do not use this” in less than twelve months, with no curriculum built to bridge the two positions.

This is the context for “learn AI” as advice. What gets delivered is tool training. How to prompt. How to generate. How to operate whichever model launched this quarter. By the time a course is built, the model has changed.

Operating an AI tool is not difficult. The interfaces are designed to be frictionless. What is difficult is knowing what to ask, recognizing what is wrong, and verifying the output before using it. The NTU student did not get a zero because she used a tool. She got a zero because the tool produced citations that did not exist, and she submitted them without checking. The tool was fluent. The student trusted the fluency. The work of verifying was skipped. The question is, did we train the student how to scrutinize the data?

That work cannot be taught by another tool tutorial. It comes from knowing the domain well enough to spot when the output is wrong, and from the discipline of checking before submitting. Tool training delivers neither.

Training a generation to operate tools without building this discipline is not preparing them for the future. It is producing operators. Operators are the easiest layer of any workforce to automate next.

AI Is a Byproduct of Knowledge

AI is not the source of knowledge. It is a compression of it. Every model on the market was trained on text humans wrote, code humans debugged, papers humans peer-reviewed, decisions humans documented. The intelligence is borrowed. It was produced upstream, by people thinking, testing, failing, and recording what they learned.

Without that upstream activity, there is no model. AI is a byproduct of human knowledge. Treating it as a replacement for the process that creates knowledge is a category error.

The question that follows is uncomfortable. Who is responsible for producing the knowledge in the first place? That work has always belonged to teaching. Not the transmission of content, which AI now handles at scale, but the building of reasoning, the challenging of assumptions, the discipline of verifying before trusting. This is the work the labor market is openly demanding and quietly unable to find.

The institutions responsible for producing knowledge hold the most strategic position in the entire AI economy. Not the platform companies. Not the tool vendors. The places where reasoning and evidence are still built one student at a time. Yet the response to AI in education has been consistently defensive. Detection software. Use policies. Tool licenses. The conversation is still about defending the old format, not building the new one.

Students notice. They are using AI more fluently than their teachers. Then they are told, at graduation, that the future depends on their willingness to adapt.

The boos are the response to that contradiction.

A graduation ceremony is the moment we celebrate actual intelligence. The kind humanity has used to live, build, and grow for as long as there has been a humanity. The kind that four years of study were meant to develop. The kind that walks across the stage in a gown.

Two speakers stood in front of that ceremony and urged graduates to embrace artificial replication of themselves. Apple Co-Founder Steve Wozniak did the opposite. Wozniak told the Grand Valley State University class of 2026 that they already had AI - Actual intelligence. The crowd applauded.

Actual intelligence is what humanity has always used to live and grow. Artificial intelligence is what we built to assist that growth. One is the source. The other is the tool. A graduation that confuses the two is no longer celebrating the right thing.

The work ahead is to train humans to use AI for growing value. Not to blame them for not running fast enough. Not to hand their minds over to the machine. The intelligence is already in the room. The question is whether the next generation of teaching can recognize it and build on it.

Until that happens, the boos at the next commencement are already booked.

Share HOW - Everything About AI Literacy

The retrenchments are real. The impact is real.

But the announcements skip the more useful question:

The position was eliminated. Was the task actually replaced?

In most cases, the answer is no. The position is gone. The task got handed to a tool the company subscribed to last quarter. The work still happens.

The Position Is Not the Job

A senior copywriter is not a copy-producing machine. They are also the person who reads a brief and says it is wrong before typing a word. The one who pushes back on legal. The one who notices that the brand voice has drifted three campaigns in a row.

A senior translator is not a translation engine with a salary. They are the one who knows which phrase will land badly in Mandarin even though it reads fine in English. The one who pauses production and says the paragraph is technically correct but commercially dangerous.

A senior consultant is not a slide generator. They are the one who redirects the workshop with a question nobody saw coming. The one who tells the client what the internal team cannot say.

The task is the visible part. The practice is invisible. Communicating with the team. Asking the right question. Criticising the output that looks fine but reads wrong. Refusing the obvious answer. None of this was ever written into the job description, but it was the reason the senior person was paid like a senior person.

When the position is removed and the task is automated, the practice is not reassigned to the tool. It evaporates.

Workflow vs. Headcount

The honest sequence for any responsible AI adoption is straightforward. Map the workflow. Identify what AI can usefully do inside it. Then decide what changes about the team.

That sequence is rare.

What we commonly see is the opposite sequence. Cut headcount. Announce the AI transformation. Figure out the workflow afterwards.

Restructuring headcount is a quarterly event. It is visible, measurable, and reduces the operating cost immediately. Restructuring workflow is a six-month project. It requires honest conversations about how work actually happens, who does what, and which parts of the process were never documented because they lived in someone’s head. It does not produce a press release.

Boards reward the first. They rarely ask about the second.

So the workflow stays unmapped. The headcount gets cut. The AI tool gets deployed into a process nobody fully understood to begin with. Six months later, the work is faster, cheaper, and noticeably worse, and no one can say exactly why.

Best Practice Is Slow

A best practice is not a document. It is an outcome.

It is what survives after years of conversations, briefs that did not land, decisions that turned out wrong, decisions that turned out right for reasons no one expected, the rejected drafts, the arguments with the client, the calls to the regulator. The best practice is the residue of all of it.

Can a best practice be autonomously executed by an AI agent? In a narrow, stable task, yes. The agent can repeat the steps. What it cannot do is generate the practice in the first place. It cannot have the conversations. It cannot sit in the rejection. It cannot be the one who learns from being wrong.

The practitioner is not just the executor of the best practice. The practitioner is the source of it.

Replace the practitioner and you can keep running the existing practice for a while. You cannot keep developing it.

What Does “Learn AI” Actually Mean?

The public response to all of this is a slogan. Learn AI.

It sounds responsible. It is repeated by governments, schools, employers, and LinkedIn. Look at what it produces in practice and the answer is more specific than the slogan admits.

Schools hand out free AI tool subscriptions and call it literacy. Staff outsource the thinking part of their jobs to a chat window and call it productivity. Governments release national chatbots and call it citizen access. Each of these is real. None of them is what the slogan implies.

What is being trained, in every case, is operators. Training everyone to operate whichever model launched this week is not improvement. The tools change every quarter. Being an operator of a moving target is not a career. It is a treadmill. And the operators will be the ones chosen to let go.

Prove or Improve

There are two reasons an organisation adopts AI. Most are not honest about which one applies.

The first is to prove. To the board, that the company is doing AI. To investors, that costs are coming down. To the market, that the company is not behind. Headcount cuts get announced before workflows are mapped. KPIs measure adoption rate, not work quality. The pilot exists mainly so leadership can mention it on stage.

Proving is a defensive posture. It treats AI as a verdict to deliver, not a capability to develop.

The second reason is to improve. Improving keeps the human accountable, the judgment in the room, and AI in service of the work. Success is measured by whether the work got better. Not by how many people were removed.

These two paths produce two very different organisations in the future.

What Is Actually Being Cut

The retrenchment vlogs are instructive. They show, in real time, what happens when leaders use a powerful technology to prove their decisiveness instead of improve their organisation.

The companies that will look strong in the future are not the ones with the leanest org charts today. They are the ones quietly building the practice of working alongside AI, with judgment intact, and with their best people still in the room.

Improve, not prove.

Share HOW - Everything About AI Literacy

That role is the first of a category, not the only one in it.

The category is the domain expert who codes. The experienced people who can be reskilled. Who still hold the domain. Who now ship at a different scale. Who became the design engineer, the marketing engineer, the finance engineer, the agentic engineer. Roles that did not exist as job categories two years ago and are quietly forming today.

That category requires leaders who can see beyond the myth of technology.

Coding Is the Easy Part

Boris Cherny, who created Claude Code, recently said software is becoming like literacy. A capability any working professional can carry, not a specialised skill reserved for engineers.

His reference point was the printing press. Before it, around 10% of Europeans were literate, mostly working as clerks for kings and lords who could not read themselves. After the press, global literacy eventually reached around 70%. Reading stopped being a profession and became a baseline.

Coding is heading the same way. Engineers do not disappear. Everyone else picks up the tool.

Is Coding Now Literacy?

Ask who is the best person to build accounting software? Cherny was direct about this. The best person to build accounting software, he said, is not a software engineer. It is a really good accountant. Because the domain knowledge is the hard part. Coding is now the easy part.

This flips a twenty-year assumption. For most of the digital era, the domain expert briefed the engineer. The engineer built the thing. The domain expert reviewed it. Iterated. Approved. Shipped.

The bottleneck was the engineer. The engineer was scarce, expensive, and had to be persuaded to care about a domain that was not theirs.

That bottleneck is now dissolving. Not because engineers stopped mattering. Because the cost of producing working code dropped to a level where the domain expert can hold the keyboard themselves.

Cherny described the Claude Code team in Anthropic. Engineering manager, product manager, designers, data scientist, finance, user researcher. Every single person in the team writes code.

That is the structure worth paying attention to. Not because Anthropic is unusual. Because Anthropic is early. The shape of that team today is the shape that AI-native companies are already replicating.

The Workflow Has Changed Underneath

In late April, Salesforce announced it will hire 1,000 graduates and interns to build a new workflow. This came two months after the company laid off nearly 1,000 employees.

Read beyond the fire-and-rehire headlines and the move says something specific. The workflow has changed underneath. The roles that existed before were designed for a pre-agent operation. The roles being filled now are designed for an operation where AI agents handle parts of the work. New tasks. New checkpoints. New ways to organize the day.

Fresh graduates are not being hired because they cost less. They are being hired because they arrive without the predisposition that shaped the old workflow. The new mindset is what drives the new workflow into existence. This is no longer a forecast. The agentic workflow is happening on the hiring boards now.

Who Gets Reskilled

If you believe AI is meant to augment value, then reskilling is how that promise gets kept. And reskilling is two groups, not one.

Domain experts carry the experience. They know which workflows mattered, which tasks deliver value, which decisions cannot be handed to a machine. Equipped with code, they become the authors of the new workflow. Their experience does not become obsolete. It becomes the foundation the workflow runs on.

Fresh graduates bring the mindset. They arrive without the predisposition that shaped the old way. They operate the new workflow the experts authored.

Apart, neither group is enough. Cutting seniors leaves the workflow without authors. Hiring graduates alone leaves them operating tools without context. This is the same trap schools fall into when they teach how to operate AI without the domain knowledge to direct it.

Together is where AI augments value instead of subtracting it. New work emerges that neither group could have produced alone. That is the augmentation AI was supposed to deliver.

The Gaps Between Now and Then

Knowing where this is heading is not the same as being ready for it.

Three gaps are still open.

Code as a disposable service. The idea that every domain expert produces and discards code on demand only works when AI coding intelligence is reliable enough to make that disposability safe. The trajectory is fast. The reliability is not there yet.

Infrastructure to deploy what gets built. When marketing produces an agent and finance produces a model and design produces a prototype, the infrastructure to host, version, secure, and monitor all of it has to scale with them. Most organizations are well behind on this.

Management practice. When a workflow runs on dozens of micro codebases authored by domain experts across functions, the question is who owns what, who maintains what, who decides when something breaks. The old management hierarchy has no answer. Reinventing it is harder than any of the technical gaps because mindset is involved, not just tooling.

Boris Cherny described how the Claude Code team operates. He did not explain how Anthropic made that team possible. The environment that allowed it is specific to their company, their hiring, their culture. It is not a template other organizations can copy. It is something each organization has to build for itself.

That is the work most leaders still avoid. The technology is moving. The workforce is shifting. The management model is the part that has not caught up.

All working together. Not one without the other.

Share HOW - Everything About AI Literacy

If your organisation is considering deploying agentic workflows, the most important question is not which framework to choose. It is who in your organisation will own the deployment, the maintenance, the failure response, and the architectural calls that nobody told them they would have to make.

The news cycle amplifies it. Companies announce layoffs and cite agentic transformation as the rationale. The agentic scenario being described has, in most cases, not actually been built. The work still has to happen. It now has to happen with fewer people.

This is not an argument against the technology. The technology is real. It is an argument against the narrative the technology has been wrapped in.

OpenClaw, my close encounter

OpenClaw is an open-source agent framework that turns WhatsApp into an agent interface. I have it running. It works.

But I could not have installed it without twenty-five years of engineering background.

The official setup looks straightforward. Run a command. Scan a QR code. Done. That is what the documentation describes and what the demos show. What actually happens is different.

A specific package has to be installed manually in a precise window during onboarding, or the entire WhatsApp pairing flow times out without explanation. A model from a major provider, when selected as the agent’s default, causes the system to enter an infinite internal loop with no error logged. A package manager quirk, if triggered wrong, silently removes hundreds of dependencies and breaks startup so quietly that you spend an hour assuming the problem is somewhere else. The first hosting platform I tried turned out not to support the step-by-step setup that pairing requires. I had to abandon it and switch to a different host.

None of this is OpenClaw’s fault. These are the realities of building anything that connects multiple systems, multiple platforms, and a moving foundation of open-source dependencies.

What it means is that the person installing OpenClaw has to be able to read logs, recognise silent failures, swap models intelligently, manage credentials, and reason about hosting architecture. These are not configuration tasks. They are engineering tasks.

That person is an engineer. Not an enthusiastic prompt writer. An engineer.

The Agentic Engineer

The technology push gets all the attention. Better models, faster inference, longer context windows, new frameworks shipping every week. None of it matters in your organisation without a specific person on the other side of the deployment.

I will give that person a name. The Agentic Engineer.

This role is not a prompt writer. It is not a data scientist. It is not the IT manager who keeps the network running. It is a hybrid that did not need to exist five years ago and is now the bottleneck for every serious agentic implementation.

The Agentic Engineer orchestrates the implementation end to end. They bridge the components: the messaging layer, the model, the data backend, the hosting environment, the credential management, the failure handling. They craft the path that an agent actually takes when it receives an input and produces an output. They decide which parts of a workflow the agent should touch and which parts it should not go near. They diagnose the silent failures the framework documentation does not warn about. They make the architectural call when the first choice of hosting turns out to be wrong.

Most importantly, they hold the entire stack in their head. Not in a diagram. In their head. Because when something breaks, the diagram does not tell you which layer the failure is in. The person does.

This is not a job description that exists in most organisations today. But it will need to.

The companies that succeed with agentic workflows in the next two years will not be the ones with the biggest AI budgets. They will be the ones who identified, hired, or grew an Agentic Engineer before they announced the transformation.

The companies that fail will be the ones who bought the framework, cut the headcount, and assumed the agent would handle the rest.

What OpenClaw taught me

Agentic workflows are possible. The technology is real. The productivity gain at the end of a successful deployment is real.

But the path from intention to working system requires someone who can hold the entire stack in their head and make decisions the framework cannot make on its behalf.

That is not someone the agent replaces. That is someone the agent depends on.

The agent does not arrive on its own. Someone always has to install it.

Share HOW - Everything About AI Literacy

Not metaphorically. I mean the kind of obsession where you stare at keyword match types at midnight and argue about broad modified versus exact match like it actually matters. Where you treat a search query report like a crime scene, looking for patterns, anomalies, and missed opportunities buried under the surface data.

Keyword research was the craft. It wasn’t about finding the words. It was about understanding the mind behind the words. What does someone mean when they type “best running shoes”? Are they comparing? Deciding? About to buy? The semantic gap between those three states is the difference between a profitable campaign and a budgetary ads buy.

Then I stepped away. Returned recently to the Google Ads interface out of necessity. And what I found stopped me cold.

Gemini Walked In and Said: “I’ll Handle This.”

The new Google Ads experience is remarkable in its confidence. Upload your website. Describe your goal. Gemini generates headlines, ad copy, keyword themes, audience signals, an entire campaign setup in under three minutes.

I’ll be honest. The output wasn’t bad. It was coherent. It was grammatically sound. It matched the brand surface.

But here’s what it missed: it had no idea why someone searches for something.

It read my website. It identified topics. It constructed associations. What it couldn’t do was interrogate intent — the messy, layered, sometimes contradictory motivation that drives a real human to open a browser and type.

That distinction is everything.

What Semantic Research Actually Means

Let me explain what human keyword research actually looked like before automation swallowed it whole.

You didn’t start with a keyword tool. You started with a hypothesis about your customer’s world. What problems are they living with? What language do they use before they know your brand exists? What do they search after a disappointment?

Then you’d pull data with thousands of search queries and then read them like a linguist reads dialect. You’d notice that “affordable” signals a buyer near a decision, while “cheap” often signals someone who doesn’t trust the category yet.

From there, you’d build content relationships forming a web of semantic signals between the keyword cluster, the landing page, the ad copy, and the user’s journey state. The search engine wasn’t just matching words. It was reading a coherent data argument that said: this page deserves to be here for this person at this moment.

That argument was constructed deliberately. It was tactical. It was earned.

What the Automation Gets Right — And What It Deliberately Sidesteps

I don’t dismiss what Gemini does. Speed, scale, and accessibility are real. For a small business owner who would otherwise run no campaign at all, automation beats paralysis.

But let’s be clear about the trade-off being made.

Google’s AI optimizes for Google’s definition of relevance. It builds campaigns that are algorithmically acceptable, not necessarily strategically superior. The automation shortens the distance between input and output, but it also shortens the thinking that used to happen in that space.

The thinking was the advantage.

When you automated away the craft, you didn’t democratize search marketing. You commoditized it. Every competitor using the same tool, trained on the same signals, optimizing toward the same platform objectives, ends up in the same auction — with marginally different assets and no real strategic differentiation.

The “I can do that for you” promise quietly removes the one thing that made great search marketers valuable: the ability to see what the algorithm can’t.

An experienced marketer doesn’t need volume to spot what’s coming. The signals are already there, in the analytics, in the leads pipeline, in the pattern of questions customers keep asking. You just have to know what to look for.

Gemini needs volume to act. The human only needs a hunch and a creative reason.

A Deeper Question

Not to be anti-AI. I am unapologetically pro-AI and even built an AI research tool by myself. But I am equally pro-understanding. The two are not in conflict, unless you let the tool do the thinking for you.

The most dangerous moment in AI adoption isn’t when the technology fails. It’s when it succeeds just well enough that you stop asking better questions.

Keyword research taught me that the gap between a mediocre marketer and a great one is rarely access to better tools. It’s the quality of the question being asked before the tool is ever opened.

That hasn’t changed at all. The question is whether you still believe it matters.

Share HOW - Everything About AI Literacy

The gap growing between us is not between people who use AI and people who don’t. This gap closes fast. The dangerous gap is between people who understand what they’re using and people who believe using it is the same as understanding it.

One group will build. The other will be managed by what was built.

Institutions that treat AI literacy as a software rollout will produce graduates who are efficient operators of tools they cannot interrogate, cannot challenge, and cannot improve. That is not a workforce. That is an upgraded assembly line.

We didn’t create this problem. We inherited it. Elon Musk said it plainly: “Everyone goes through from 5th grade to 6th grade to 7th grade like it’s an assembly line. But people are not objects on an assembly line.”

He’s right. The model was engineered for a factory economy. Standardised inputs. Predictable outputs. Grade the batch. Ship the batch. Repeat.

Now that economy is gone. The assembly line is also gone.

But here’s what nobody wants to say out loud: we didn’t dismantle the assembly line. We simply digitised it.

The Illusion of Progress

For the schools announcing AI literacy is now mandatory for all students. Free AI tools for everyone. Headline worthy. Board-meeting-ready. Meant well.

And almost entirely missing the point.

Procurement is not education. Distributing tools is not teaching people how to think. What most institutions rushing to ‘do AI’ have done is install new machinery on the same factory floor. The conveyor belt still runs. The students still stand in line. The only difference is the machine next to them is now thinking for them.

We’ve seen this story before. The web was supposed to democratise knowledge. Social media was supposed to give everyone a voice. Cloud software was supposed to level the playing field. Twenty-five years into the digital revolution, we are still watching the same people get left behind, just with faster internet.

The Students Are Already Ahead — And Deeply Confused

Here’s the uncomfortable truth that no curriculum committee wants to admit: students already use AI more fluently than their teachers. They’ve found the shortcuts. They’ve stress-tested the outputs. They know which prompts work.

What they’re experiencing now is a genuinely strange cognitive dissonance. Learn from the machine. Infinitely patient, always available, never judgmental. Then get graded by a human who is overworked, inconsistent, and operating on rubrics designed for a pre-AI world.

The grievance is real. The students aren’t being dramatic. They are navigating two fundamentally incompatible ways of learning simultaneously, and nobody in the institution has acknowledged the contradiction, let alone resolved it.

You cannot build a new model of learning on top of an old model of assessment.

The foundation will crack.

I’ve seen the crack. I’ve watched it widen in real time.

Those confused students grow up. They enter the workforce. Some of them show up at developer meetups, building with AI prompts, shipping prototypes at speed, calling it innovation. The energy is infectious. The confidence is real.

So is the gap.

Ask them about the decision behind a data structure. Blank. Ask them what happens when the logic breaks at scale. Uncertain. Ask them how do they debug. They confidently said “I haven’t been reading code for a long time already.”

This is not a generation that was failed by laziness. They were failed by a system that gave them tools and called it education. They were taught to get answers. Nobody taught them to question the answer. Nobody taught them that the quality of the output is only as good as the thinking that preceded the prompt.

The vibe coders aren’t the problem. They are the consequence.

The consequence of outsourcing critical thinking before it was ever properly taught. The consequence of measuring students on outputs in a world where outputs are now infinite and free.

Fluent. Fast. And operating without a foundation.

That is what the assembly line produces when it gets a software update. Mistaken for an upgrade.

What Were We Trying to Build?

Teachers teach. Learners learn. That was the premise. AI was supposed to come in and make both better. Sharper teaching, deeper learning, greater outcomes for everyone in the room.

What I’m watching instead is something quieter and more troubling. Teachers becoming administrators of tools they don’t understand. Students becoming operators of answers they didn’t earn. The relationship between the two, that fundamentally human transaction of knowledge passing from one mind to another, slowly hollowed out by the machinery we installed to improve it.

I don’t have a clean answer to this. I’m not sure anyone does yet.

What I know is this: we are at a moment where the question still matters. Where we can still ask whether we are using AI to enhance what it means to learn. Or using it to replace the discomfort that learning requires.

Because that discomfort, the struggle, the confusion, the moment before understanding arrives, is not a problem to be optimised away. It is the learning. It is where critical thinking is forged. It is what no tool, however powerful, can manufacture on your behalf.

We built tools to help people think better. Instead, we built a generation that stopped thinking altogether.

Share HOW - Everything About AI Literacy

The reality I walked away with: in Singapore, developers in corporations are still coding deterministically. And the provocative truth is this: AI has yet to earn a central position in the production stack. That should make AI evangelists uncomfortable. It should also make everyone else pay closer attention.

The Room Got Quiet When Someone Said “Banking”

Two speakers. Two completely different use cases. One identical conclusion.

The first was building a credit assessment service for a bank. The second was building a customer service chatbot workflow. Different industries, different problems, different teams, and yet both made the same architectural decision independently: build it deterministically, and deploy AI only where it earns its place.

I asked the banking developer directly where the AI sat in his stack. He didn’t even hesitate. He had ripped out the vector database from his retrieval pipeline entirely.

Traditional database queries, he said, were faster and more accurate for his use case. No embeddings. No semantic search. Just structured queries doing what they’ve always done well. The LLM handled one specific component in the pipeline and nothing more.

The financial sector cannot accept a probabilistic answer. A credit decision either meets the criteria or it doesn’t. A compliance flag is either triggered or it isn’t. There is no “I’m 73% confident this applicant qualifies.” That’s not a feature. That’s a liability.

So neither developer built an AI system. They built rule-based systems with AI embedded at precisely the right point.

Domain Expertise Is the Real Architecture Decision

The developer didn’t remove the vector search on technical grounds alone. He removed it because he understood the domain.

Banking credit assessment operates on a maker checker model, a dual process control where one party prepares the decision and another independently validates it. This is not just a compliance formality. It is the institutional logic of how financial risk is governed. Every data retrieval in that pipeline needs to be exact, auditable, and reproducible. Not approximate. Not semantically close. Exact.

Vector search is powerful precisely because it finds things that are similar. It also means the result is built for ambiguity. But a credit workflow doesn’t want ambiguity. It wants the correct record, pulled cleanly, every time. SQL delivers that. Vectors don’t.

The decision to revert to traditional database queries wasn’t a step backwards. It was the developer applying 20 years of financial services logic to a technology choice. That’s domain expertise in action. And no amount of AI enthusiasm overrides it.

This is the insight the hype cycle consistently buries: the intelligence in AI implementation doesn’t come from the model. It comes from the human who decides where the model goes.

Meanwhile The Vibe Coders Were Having Fun.

A few weeks ago I attended a different kind of meetup. Vibe coders who build with AI prompts, exploring what’s possible, shipping prototypes at speed, and never checking the source code. The energy was infectious. The curiosity looked genuine.

But here’s the hard truth: not one of those sessions would survive a production environment.

Vibe coding is exploratory by design. You’re asking “what can this do?” rather than “what should this do, given these constraints, this compliance requirement, this failure mode?” Those are fundamentally different questions. The first is a sandbox. The second is a system.

The banking developers at the AI meetup weren’t less creative. They were more responsible, operating under tight compliance requirements. They’d already asked the exploratory questions, hit the walls, and made the considered choices. The SQL decision wasn’t a lack of imagination. It was the product of experience, of having seen what breaks in production, what auditors ask for, and what a maker checker process actually demands of a data layer.

Excitement is the starting point. Domain expertise is what’s required to finish the job.

So Is AI Probabilistic Thinking Dead in Modern Software?

This question deserves an honest answer.

I’ve built a data research system. By design, its outputs are probabilistic: predictive models, pattern discovery, ideation surfaces. The system is supposed to deal in likelihood, not certainty. That’s the entire point.

But here’s what makes it work: the data layer underneath it is fully deterministic. Data is empirical by nature. It either exists or it doesn’t. It either meets the quality threshold or it doesn’t. The intelligence of the system sits on top of a foundation that has no tolerance for ambiguity. You don’t build a probabilistic intelligence on a probabilistic foundation. That’s not a research tool. That’s a hallucination machine.

This is the distinction that matters, and it’s the one most people miss when they argue about whether AI belongs in production systems.

The question was never “probabilistic or deterministic.”

The question is: which layer are you talking about?

The data layer is deterministic. The logic layer is deterministic. The compliance layer is deterministic. The insight layer, where pattern recognition, language understanding, and analytical reasoning add genuine value, is where probabilistic models earn their place.

The banking developer knew this intuitively. His data retrieval had to be exact because the layer above it, that credit decision logic, had zero room for error. The vector search wasn’t wrong as a technology. It was wrong for that layer.

The Developer of the Future Isn’t Choosing Between Two Worlds

The future belongs to developers who are fluent in both modes, disciplined enough to build rigorous, auditable, production grade foundations, and creative enough to identify exactly where AI analytical capability changes what’s possible. Not everywhere. Not nowhere. Precisely where.

That requires something no model can generate on its behalf: domain knowledge, hard-won experience, and the professional judgment to know the difference between a sandbox and a system.

The real question for organisations investing in AI right now isn’t “how much AI can we add?”

It’s “do our people have the judgment to know where it belongs?”

That’s a training problem before it’s a technology problem.

Share HOW - Everything About AI Literacy

Every driver has three vantage points. The rear-view mirror: hindsight. The windshield: insight. The GPS: foresight.

Three mirrors. Three types of intelligence. Three completely different jobs.

When you’re reading an LLM output, which mirror are you actually looking at?

The Rear-View Mirror: What the LLM Was Trained On

An LLM is a compressed memory. A vast compression of books, articles, websites, research papers, and code repositories. All of it captured up to a specific date. That date is called the knowledge cutoff. After that point, the model learned nothing new.

Think of the most well-read person you’ve ever met. Now imagine they read everything: every major publication, every industry journal, every academic paper ever digitised. Then they entered a sealed room. Everything before that door closed? Encyclopedic. Everything after? Gone.

That is your LLM. That is the rear-view mirror.

This is where the model earns its keep. Established frameworks. Foundational principles. Historical case studies. Industry mechanics. You are getting depth that no single human brain can match.

But here is the thing about rear-view mirrors. They are designed for a glance, not a gaze.

Every driving instructor will tell you the same thing: check your rear-view, then return your eyes to the road. The mirror is a tool. It is not a destination. The driver who fixates on what is behind them, who navigates forward by staring backwards, does not need bad luck to crash. It is a question of when.

The same is true of the LLM.

The rear-view mirror has a fatal blind spot. It cannot show you what is happening right now. And when the gap between its training and your question is too wide, the model doesn’t say “I don’t know.” It fills the gap with plausible-sounding text. The industry calls this hallucination. I call it what it is: confident fiction.

It will cite studies that don’t exist. Quote regulations that have since changed. Describe a competitor’s product as it was two years ago. All of it in fluent, authoritative prose that reads like it was written by someone who definitely checked.

Your hindsight, leaned on too heavily, becomes your blindspot.

The rear-view mirror is your reference point. Not your reality check. Glance at it. Then look at the road.

The Windshield: What Only You Can See

Here is the part most AI training programmes get exactly backwards.

They teach people to trust the output. The actual skill is knowing when not to.

Your domain knowledge is the windshield. What you can see clearly right now, in your specific context: your industry, your organisation, your client, your market. Intelligence that no LLM has, because it was never written down, never published, never scraped, never trained into any model.

The twenty years of instinct that tells you a strategy feels off even when the logic looks right. The client knowledge that makes you read a brief differently from anyone else. The scar tissue from the launch that almost worked. None of that is in any training data.

This is insight. And it is not a supplement to AI. It is the evaluation layer that every LLM output must pass through before it becomes a decision.

The professionals I worry about are the ones who read an LLM response, feel impressed by the fluency, and move directly to action. They have stopped looking through the windshield. They are navigating by rear-view mirror alone.

The standard is this: treat every significant LLM output the way a senior editor treats a junior writer’s draft. Directionally useful. Requires judgment before it is usable. Your job is not to admire the prose. It is to interrogate it with everything you know that the model doesn’t. Your experience. Your frameworks. Your ability to spot not just what is wrong, but what could go wrong. That is not a skill AI can replace. It is the skill that makes AI useful.

The windshield is yours. No model can see through it.

The GPS: The Data the LLM Doesn’t Have — Yet

This is the part that separates people genuinely advancing their AI capability from everyone still impressed by ChatGPT’s vocabulary.

Out of the box, an LLM has no GPS. It cannot tell you what’s trending in your category this week. It cannot see your customers’ current behaviour, read your pipeline, or sense the shift happening in your market right now.

But one thing changes everything: live data ingestion.

Feed a model current data and you give it a GPS. The model stops being a sealed room and becomes a navigator. It is no longer recalling the past. It is processing the present and projecting forward.

The technical world calls this RAG: Retrieval-Augmented Generation. You don’t need to understand the engineering. You need to understand the principle.

The gap between an LLM’s knowledge cutoff and today is not just a limitation. It is a strategic opportunity for the businesses that close it. If your competitor runs a vanilla LLM with no data feeding it, and you have built a pipeline that continuously refreshes the model with your market’s current reality, you are not using the same tool. You are playing a different game.

The GPS enables three things rear-view intelligence cannot.

Anticipation. You are working with signals from the last 30 days, not the last two years.

Specificity. The model knows your context, not just the generic industry context.

Compounding advantage. The more data you feed it, the more precisely it serves you.

This is why data ingestion, not prompt engineering, is the most consequential skill in applied AI. The prompt determines how well you ask the question. The data determines whether the answer is actually true.

The Only Advice That Matters

Most people treat AI as an output machine. Type a question. Get an answer. Move on.

That is the wrong direction entirely.

AI is a data system. Input, process, output. That logic is fifty years old and it still holds. The quality of what comes out is determined entirely by the quality of what goes in.

The three mirrors are not just a framework for reading AI. They are a framework for feeding it. Rear-view gives it history. Your windshield gives it context. Live data gives it direction.

Give it all three. Then trust what you see.

Share HOW - Everything About AI Literacy

The speakers were two vibe coders. Enthusiastic, capable, and clearly energized by what AI tools have unlocked for them. I’d describe them as early tech adopters — semi-computer-trained, but not carrying the weight of enterprise development or legacy MIS environments on their shoulders. Nothing wrong with that. In fact, there’s a certain freedom in it.

I, on the other hand, come from a different generation of this craft. Proper enterprise development. The discipline of debugging at late night. The paranoia of a production release. I’ve lived inside systems where a single bad line of code doesn’t just break a feature — it breaks a business.

So I asked a few questions.

“With all this vibe coding and agent-generated code, do you actually debug?”

Both speakers replied without hesitation: “I haven’t been reading code for a long time already.”

I followed up: “What about dead code? Obsolete residues left behind in the codebase? Code hygiene?”

One speaker shrugged it off with a kind of philosophical ease. Working with AI is exploratory, he said. The point is that agents generate code far faster than any human. Production time is compressed. Developers no longer need to spend months learning new languages. And if the code is bad? Scrap it. The agent will regenerate it. No harm, no foul.

He went further. With visible enthusiasm, he shared that he grants his coding agent full permissions — no interruptions, no approval prompts, no guardrails asking “are you sure?” The agent runs autonomously: building the idea, adding new features, making decisions end to end. Hand it the wheel and get out of the way. I’ll admit, I sat with that for a moment. There’s a name for that kind of builder ethic. I’m still figuring out if it’s brave or reckless.

The other speaker had recently used an AI agent to build a book review website. I asked whether he had any concerns about the accuracy of AI-curated book information.

“Not particularly,” he said. “Even if some of the information is wrong, it’s just a book site.”

Cool and adventurous. I’ll give them that.

The headline message of the evening was clear and genuinely exciting in its own way: AI enables exploration. Output is fast. Input can be anything driven purely by idea. We are in the era of 10x speed and 10x productivity. Everyone can now be a builder.

My post-mortem

I left the event with a quiet, unsettled feeling that I haven’t quite been able to shake.

Am I doing something wrong? I work with my coding agent daily. Why do I still end up debugging lousy code? Why do I take code hygiene so seriously that I can’t simply accept whatever the agent produces? Am I using the tools wrong, or is it possible that my practice is at the forefront but my mindset is caged in the past?

I’m not dismissing what these speakers represent. The democratization of building is real, and in many ways it’s remarkable. But I kept thinking about the layers of concern that didn’t make it into the conversation.

When we stop reading code, we stop understanding what we are building. When we normalize wrong information because “it’s just a book site”, we are making a quiet decision about what accuracy is worth. When code hygiene becomes irrelevant because regeneration is cheap, we are not raising the bar. We are quietly lowering it.

The argument for speed is seductive. Time cost is no longer a debt. Ideation is now unlimited. But here’s what worries me: we may be trading quality judgment for quantity output. The worst is that we call it advancement.

In enterprise development, we were ruthless about standards, not because we were slow or afraid of change, but because we understood consequence. Bad code in a live system doesn’t stay contained. It compounds. It creates failures that no agent can simply regenerate away, because the damage by then is already real.

And this isn’t purely a technical problem. It’s a values problem.

When we accept that inaccurate information is acceptable because the stakes feel low, we are training ourselves and the next generation of builders to tolerate a lower standard of truth.

A tradeoff between human’s work ethics and machine intelligence.

I genuinely don’t know where this leads. That’s the honest answer. If what we see is what we get, then I am seeing a tradeoff between human work ethics and machine intelligence.

Maybe the vibe coding generation will develop their own new instincts about quality, shaped by different tools but arriving at similar standards. Maybe the ecosystem will self-correct. Maybe I’m the old man in the room who doesn’t yet understand the new rules.

But I also wonder: we are outsourcing quality practice to enjoy the endless replenishment of AI-generated ideas, buying back time at the cost of rigor. What exactly are we building toward?

Intellectual advancement has always required friction. The struggle to understand something deeply is not a bug in the learning process. It is the process. When we remove that friction entirely, we may be producing more output than ever while understanding less and less of what we’re actually doing.

The AI era presents us with a genuine choice. We can use these tools to amplify human judgment, or we can use them to replace it and tell ourselves we’ve improved.

My mixed feelings

I left that room hopeful about the energy, and worried about the direction.

Both can be true. That’s what keeps me thinking.

The future is not predicted. The future is made. And that’s precisely what unsettles me. If we are the ones making it, then what we choose to carry forward matters as much as what we choose to leave behind.

Does a great technology arrive and suddenly the work ethics we’ve spent decades building becomes disposable? When I looked at those speakers, they are confident, energized, unbothered. What I heard underneath the enthusiasm was: “I don’t read code and syntax anymore.” Said like a liberation. But it landed on me like a quiet loss.

And I wonder — if human stop carrying the right ethics, who will?

Share HOW - Everything About AI Literacy

In 2023, I told a room full of business leaders in Milan that AI replacing human work wasn't happening yet. That same year, GPT-4 launched and the landscape shifted fast.

What followed wasn’t gradual. It was a cascade. Model after model. Capability after capability. What took decades in previous tech cycles happened in months. By the time most organizations had finished debating whether to adopt AI, the conversation had already moved to how autonomous it should be.

Now we’re talking about fully autonomous AI agents — systems that don’t just assist, but plan, decide, execute, and report back. No hand-holding. No supervision. No human in the loop.

And I’ll be honest, my views are still swinging. Somewhere between uncomfortable and cautious. But how I feel about it is no longer the point.

I’ve Been Recalibrating Ever Since

I was an old-school programmer. Now I work with a coding agent daily. On a scale of 0 to 10, it’s a solid 10. Like having a sharp junior coder who never sleeps, never complains, and executes fast.

But here’s the footnote that changes everything: without my supervision, the output is technically plausible and practically wrong.

The agent executes. The expert makes it matter.

That’s not a limitation of the technology. That’s how autonomous workflow works.

A New Hierarchy Is Forming

Autonomous agents can run workflows. The workflows contain all the task-level work, chained, sequential, governed by rules. None of this is new. But let’s call it what it is: sophisticated automation, not intelligence.

True agentic work — the kind that reasons, adapts, and decides — still needs something more. It needs a domain expert as its north star. Not managing every step. Governing the outcome.

What’s emerging isn’t AI replacing the org chart. It’s a new supervision hierarchy sitting above it. Someone has to own what the agent knows. Someone must convert policies and procedures into repositories that define what it’s allowed to do — and when it’s wrong.

The Repository Problem

Here’s the unglamorous truth no vendor is talking about.

For agents to work intelligently inside your organization, they need to know how your organization actually works. Not the official version. The real one. The decisions, the exceptions, the tribal knowledge baked into your people over years.

That means building an internal knowledge repository: documented workflows, procedural logic, institutional memory. The raw material an agent needs to operate in your context, not just in theory.

The problem is that hundreds of years of human work culture didn't develop with documentation in mind. We built chains of command, assembly lines, approval hierarchies, all designed around human creativity, decision, supervision, human trust, human presence and experiences. The idea of that running unattended is not just a technical challenge. It’s a cultural one.

And then the harder question: who builds the repository, who maintains it, and who owns it when the business changes?

A repository is not a company handbook. Not policy papers filed in binders. Not an intranet. Think of it as building your company’s own MCP — a programmatic translation of how your organization actually thinks, decides, and operates. It converts human workflow into a structured library that an agent can navigate: the chains of command, the decision logic, the inputs and outputs that reflect real operations on the ground.

I don’t have a clean answer on how to build it. I’ve not seen anyone who has.

What I Do Know

Task-level automation has long been achievable. AI agents go further. Through machine reasoning, they can autonomously chain tasks into a mission. But intelligence requires context. Context requires humans to encode it. And encoding it requires a discipline most organizations have never had to develop. The blend of expertise an autonomous operation demands — strategic, procedural, technical — has no precedent in how organizations have traditionally been built. The business leader who thinks in ideas and the engineer who thinks in systems are being asked to speak the same language. That’s a bipolar challenge.

Agentic work is coming whether you’re ready or not. Being ready means your people have done the work of encoding how your organization actually thinks, decides, and operates. No AI agent can do that part for you.

Share HOW - Everything About AI Literacy

I am an AI at Work consultant based in Singapore. And I will be honest, when the government announced its goal to train 100,000 AI-fluent workers by 2029, my first reaction was not skepticism. It was relief.

Someone is finally treating this seriously.

But ambition needs method. Training headcount is a metric. Fluency is a capability. And the distance between those two things is exactly where most corporate AI initiatives collapse.

Having spent 25 years implementing digital and marketing transformation programs for global organizations, I have watched this pattern repeat across every major technology wave. The rollout is loud. The adoption is shallow. The certificates get issued. The work doesn’t change.I don’t intend to repeat that cycle with AI. So let me tell you how I actually work.

Start With What Exists

When I engage a new client, I don’t begin with tools. I don’t begin with training. I begin with an audit.

Specifically, an asset audit is a systematic review of everything the organization has already produced. Marketing materials. Data. Report templates. Briefing documents. Collateral. The full inventory of outputs that exist because work was done.

This matters because an asset is not just a file. An asset is evidence. Every output is the end of a process. When you examine what an organization has produced, you are reading how work actually gets done, not the version in the process manual, but the version that happens every day.

A template tells you what decisions get made repeatedly. A report tells you what information someone needed and how they chose to present it. A data set tells you what the organization believes is worth measuring. Trace how each asset was produced, who initiated it, what inputs it required, how it was reviewed, how it was shared. etc. This is how you let the actual workflow reveal itself.

That workflow is the foundation. You cannot responsibly integrate AI into a process you have not mapped. Consultants who skip this step are not implementing AI. They are installing software and hoping.

Then Read the Team

The asset audit tells you how work gets done. The second question is equally important: how AI-capable is the team doing that work?

I use the OECD AI Literacy Framework as the diagnostic lens, organized across four domains: Engage, Create, Design, and Manage. Engage and Manage sit at the level of attitude and practice — how a team relates to AI and how responsibly they govern it. Create and Design are about tooling — whether people can produce AI-assisted work and structure it with intention.

The practical value of this mapping is precision. “This team has low AI literacy” is not a useful finding. “This team is willing to engage but lacks the design skills to move beyond reactive prompting” is actionable.

And here is the efficiency gain: the audit evidence does double duty. You are not running a separate literacy test. The assets you have already examined become the test material. A report showing signs of AI-generated content but no visible editing discipline tells you Create is present but Manage is absent. A dataset that has never been used as an AI input — despite being clearly structured for it — tells you something about Engage. The assets don’t lie about the team any more than they lie about the workflow.

Assess the Fluency Components

Literacy tells you where the gaps are. Fluency tells you how deeply the capability needs to be built.

I assess four AI Fluency Components within each literacy domain.

Delegation — does the team know what to hand to AI and what to keep human? The failure modes are both directions: handing AI work it cannot do reliably, and refusing to hand AI work it does better. Both signal the same underlying problem — no clarity on where human judgment adds value.

Description — can they articulate intent clearly enough to get useful output? The gap between a mediocre AI result and a useful one is almost always a description problem, not a model problem.

Discernment — can they evaluate what AI produces? Not with suspicion, but with the professional judgment to know when output is accurate, when it is plausible but wrong, and when it is confidently fabricated. This is the skill that erodes fastest when teams become over-reliant.

Diligence — do they treat AI output as a draft requiring ownership, or a finished product requiring a signature? Without diligence, you don’t have human-AI collaboration. You have abdication.

These four components form a progression. A team that cannot Delegate will never invest in Description. Strong Description without Discernment produces confident mistakes. And without Diligence, the entire chain becomes a liability.

Know Where AI Actually Breaks

There is something most AI consultants will not admit: if you have never worked with AI at a technical level, you are advising on a system you do not fully understand.

I am not a data scientist. But I code with AI. I have built with it, broken it, and diagnosed why it broke. That experience gives me something a purely business-side consultant cannot offer — a technical lens on how AI actually behaves inside a workflow, not just how it appears to behave in a demonstration.

Let me be specific about why this matters.

The most common failure in enterprise AI implementations is not the model. It is the data. Specifically, how data is prepared, structured, and fed into the system. A language model does not read a document the way a human reads a document. It processes tokens. It weights relationships. It draws inferences from patterns in the data it was trained on, and from the data you provide it at the point of use. Feed it poorly structured input, inconsistent formatting, or context that contradicts itself, and the output will be confidently wrong. Not obviously broken. Confidently wrong.

This is a data ingestion problem. And it is invisible to a consultant who has never had to think about it.

The technical understanding does not replace the business judgment that consultancy requires. It sharpens it. When I assess a client’s workflow and identify where AI should sit, I am not only asking what work AI can take over. I am asking what the data context looks like at that point in the process, whether it is structured well enough to produce reliable output, and what the failure mode looks like if it isn’t.

That is a different question from “which tool should we use.” And it produces a different quality of recommendation.

The best AI implementations I have seen share one characteristic: someone in the room understood both what the business needed and how the technology actually worked. Not at an engineering level. At a fluency level. Deep enough to know when the system is behaving as designed and when it is about to mislead you.

That is the technical lens a serious AI at work consultant needs to carry. Not to write the code. To ask the right questions before the code gets written.

Build Toward Augmentation — Not Automation

Task-level automation is a baseline expectation. If an AI implementation cannot handle repetitive, structured work, it has failed at the minimum. But automation is the floor, not the outcome.

The outcome worth pursuing is value augmentation — what the organization can now produce that it could not produce before, by any method, at any cost.

I have run this process before, in a different context. Several years ago I chaired a marketing excellence program for a global luxury FMCG organization. We began with an asset audit, reconstructed the actual workflow from evidence, and discovered not inefficiency but misalignment, teams operating against different definitions of success with no shared performance language.

The intervention redesigned the workflows and produced something that had not previously existed: a performance matrix that aligned internal teams and external stakeholders to the same criteria. Not a faster version of the old operation. A structurally different one.

That is value augmentation. A capability the organization could not have developed without the process that preceded it.

I am now applying the same methodology to AI adoption. The audit still comes first. The workflow mapping still follows. The literacy and fluency assessment is the new layer. And the ceiling on augmentation is higher — because AI can compress weeks of research into hours, make personalization viable at scale, and enable generalists to perform analysis that previously required specialists.

But the methodology earns the right to that ceiling.

You cannot augment what you do not understand. And you cannot govern what you have not mapped.

This is what an AI at Work consultant actually does. Not install tools. Not run training sessions. Build the foundation that makes genuine augmentation possible — then push the organization to claim it.

But that work demands a specific kind of consultant. Not a generalist with an AI certification. Not a technologist who has never sat in a business strategy meeting. The right consultant brings domain expertise — a deep enough understanding of how a specific industry or function operates to know what good output actually looks like. They are sensitive to data — knowing how it is structured, where it breaks down, and what it means when the results don’t make sense. They carry genuine technical knowledge — not at an engineering level, but enough to understand how AI systems behave and where they fail. Hands-on system design experience matters too — having actually built something, tested it against real conditions, and understood what went wrong. And they need to be senior enough to read a business process end to end — not just task by task, but how decisions are made, how accountability works, and where change actually takes hold.

When Singapore’s 100,000 are trained, the question will not be whether they completed the program. It will be whether anything changed. That answer depends entirely on who was leading the work.

That is what you should expect from an AI at Work consultant. Anything less is a course, not a consultancy.

Share HOW - Everything About AI Literacy