What Is Computational Thinking?

Computational thinking (CT) is the process of formulating problems and their solutions in a form that can be carried out by an information-processing agent — a computer, a team, an AI model, or even a well-organized human. It is a way of thinking, not a way of typing.

A working definition

The most durable formulation comes from Jeannette Wing’s 2006 essay in Communications of the ACM: computational thinking means solving problems, designing systems, and understanding behavior by drawing on concepts fundamental to computer science. In her later refinement, CT is the thought process involved in formulating a problem and expressing its solution so that a computer — human or machine — can effectively carry it out.

Three properties make this definition useful in practice:

It is agent-agnostic. The “computer” executing your solution can be silicon, a colleague following a checklist, or an LLM following a prompt. The thinking is the same.
It is about formulation, not execution. The hard intellectual work happens before any code exists: deciding what the problem actually is, what can be ignored, and what “solved” means.
It is a spectrum, not a credential. A nurse designing a triage protocol and a kernel engineer optimizing a scheduler are both doing CT at different depths.

The Wing lineage

Wing did not invent the ideas — Seymour Papert used the phrase in 1980 while arguing that programming reshapes how children think — but her 2006 paper turned CT into a movement. Its central provocations were that CT is “a fundamental skill for everyone,” that it means “conceptualizing, not programming,” and that it is “a way that humans, not computers, think.” The paper triggered two decades of debate, curriculum reform (CS for All, national computing curricula in England, Korea, and elsewhere), and assessment frameworks such as PISA’s inclusion of CT from 2021 onward.

Along the way, the community converged on the now-canonical four pillars:

Decomposition — breaking a problem into manageable parts
Pattern recognition — spotting regularities and reusable structure
Abstraction — deciding what to keep and what to hide
Algorithm design — expressing a solution as precise, ordered steps

Most modern treatments, including this knowledge base, add a fifth: evaluation and debugging, because a solution you cannot test or trust is not a solution.

Evolution to 2026

The concept has shifted with each era of computing:

2006–2012: Advocacy. CT as a literacy argument — everyone should learn it, like reading or arithmetic.
2012–2018: Curriculum. Block languages, CS-in-schools mandates, and operational definitions for assessment.
2018–2022: Data and systems. CT expanded to include data thinking and modeling, as machine learning entered mainstream practice.
2023–2026: The AI inflection. Large language models decoupled CT from hand-written code. When a model can generate a working program from a paragraph of English, the scarce skills become problem formulation, specification, and verification — CT’s front and back ends, rather than its middle. Recent ACM commentary frames this as the “commoditization” of routine computational work, with the human contribution concentrating in exactly the pillars that were always hardest to teach.

The pillars survived every shift because they describe cognition, not tooling.

Why CT is not just coding

Conflating CT with programming is the most common and most damaging misunderstanding.

Coding is one expression of computational thinking, the way writing is one expression of literacy. You can be literate and never publish a novel; you can think computationally and never open an editor.

Concretely:

CT happens before code. Choosing what to model, what to ignore, and how to measure success is CT; the resulting Python is a transcript of decisions already made.
CT applies where no code exists. Designing a hospital shift-handover protocol, structuring a legal argument, or planning a warehouse layout all use decomposition, abstraction, and algorithmic steps.
Code can exist without CT. Copy-pasting or prompt-spamming until something runs produces artifacts, not understanding — and fails the moment requirements shift.
The AI era proves the separation. LLMs now write competent code, yet projects still fail for the classic reasons: wrong problem, missing edge cases, unverified assumptions. Those are CT failures, and no code generator fixes them.

The CT process

CT in practice is a loop, not a pipeline. You will revisit this diagram throughout the Foundations section:

    flowchart TD
    P[Real world problem] --> D[Decompose into parts]
    D --> R[Recognize patterns]
    R --> A[Abstract the essentials]
    A --> G[Design an algorithm]
    G --> I[Implement or delegate]
    I --> E[Evaluate and debug]
    E -->|works| S[Solution in use]
    E -->|fails| D
    S -->|requirements change| P

Two arrows deserve attention. The failure edge from evaluation back to decomposition is where most real learning happens — a failed test usually means you decomposed or abstracted wrongly, not that you typed wrongly. And the edge from “solution in use” back to the problem reflects that deployed solutions change the world they operate in, generating the next problem.

How to use the rest of this section

Each of the following five pages takes one pillar, explains the core techniques, and works a concrete example. Read them as parts of the single loop above: decomposition feeds pattern recognition, patterns justify abstractions, abstractions make algorithms expressible, and evaluation closes the loop. When you reach CT in the AI Era, you will see the same loop again — with an LLM sitting inside the “implement or delegate” box and the human owning everything else.

References

Decomposition