Computational thinking: from the problem to the step-by-step

I’ve always been a builder. Even with a degree in Computer Science, I spent a good part of my career building with low-code and no-code tools and writing, at most, a little bit of script. The old repositories on my GitHub say so in their descriptions, in all honesty: “my lazy scripts.” The reason is simple: I’ve always found programming a drag. Hunting bugs, memorizing frameworks, putting up with each language’s quirks. I wanted the product working, not the ceremony.

Today I don’t program, and I interact with code all day long. I think that’s great. The boring part went to the agent. The part that always interested me stayed with me, and that’s what this chapter is about.

You can see that shift in my own writing. For years, my biggest decision when choosing a low-code tool was what I would give up to get something ready-made. With agents that code, that math changed. Today I work on code without opening the code: I question, I document the decisions, and I ask for explanations.

What changed, and what didn’t?

What changed is who deals with the syntax. A comma in the wrong place, a library version, an unreadable error message: none of that is a barrier to entry anymore.

What didn’t change is that someone has to turn a messy problem into something a machine can execute. That has a name: computational thinking. Jeannette Wing, who popularized the term, was already arguing that it’s a skill for everyone, not just for people in computing.

In Brazil this became a guideline. The National Curriculum Guidelines for undergraduate Business Administration programs ask that graduates know how to:

formulate problems and their solutions in such a way that the solutions can be effectively carried out by an information-processing agent, involving the stages of problem decomposition, pattern identification, abstraction, and the design of a sequence of steps for the resolution. (my translation)

“An information-processing agent.” When it was written, that was an abstract expression. Today it’s literal: it’s the AI agent open on your screen, waiting for you to formulate the problem.

That’s the focus of the course I teach at FGV EPPG, a school of public policy in Brasília: understanding that you can automate with code, deterministically, and that AI has to be used in a way that builds our critical thinking instead of replacing it.

How do you think through a problem for a machine?

Take Lia’s problem as the example: teenagers who stop going to school, and a small team to go after them.

1. Decompose. “Reduce school dropout” isn’t a problem you can solve; it’s an umbrella. Broken into parts: know who is missing school; decide who to reach out to first; make the contact; record what happened; learn from the record. Each part has a different owner, different data, and a different deadline.
2. Recognize patterns. Absences on Fridays in night classes. Absences that start after the July school break. Siblings who disappear together. A pattern is what lets you move past case by case.
3. Abstract. Decide what matters and what gets left out. For the first screening, what matters is the run of absences; the name, the address, and the math grade don’t. Abstracting well also protects data, as a bonus (chapter 5).
4. Write the step-by-step. The algorithm: an unambiguous sequence that two different people — or a person and a machine — would carry out the same way.

Can you draw your process?

One way to test whether you understand a process is to try to draw it as a flow: what goes in, what repeats, where something gets decided, what comes out. If you can’t, the problem isn’t ready to be automated yet, by AI or by anything else.

Two things in this exercise are worth their weight in gold. The first: the number five. It isn’t technical, it’s a decision that someone has to make and justify. Why five absences and not three? The second: the step that belongs to a person. It’s in the flow by choice, not because the technology can’t do it.

So I don’t need to learn to code?

It’s the question that always comes up. Writing code, probably not. Understanding five concepts, yes, because they’re what let you read what the agent did and ask better. I explain them in an hour:

1. Variable: a little box with a name that holds a value. absences = 7.
2. List: several little boxes in a row. A spreadsheet column is a list. It’s the vector from chapter 2.
3. Conditional: the spreadsheet’s IF. If you know how to use =IF(A1>=5,"contact","ok"), you already program.
4. Loop: “do this for each row.” It’s what a spreadsheet doesn’t make very clear, and what gives you a superpower: six rows or six million, the code is the same.
5. API: the door one program uses to talk to another. When the agent “queries the official database” or “creates a card on the board,” it went through an API.

With these five, most of the scripts an agent writes stop looking like hieroglyphics. The tutorials I use in class are open on my GitHub, and a good exercise is to open any of them in an assistant and ask: “explain what’s happening here, line by line.”

What is a “little system” made of?

When someone says “I want a little system,” they’re asking for three things without knowing it:

Between the layers, and between your system and the rest of the world, sit the APIs.

Knowing this changes the conversation with an agent or with a tool that generates apps. “It looks ugly” is a front request. “It’s counting wrong” is a rules request. “What I entered yesterday disappeared” is a data problem. Whoever points to the right layer solves in one message what would have taken ten.

The other idea that comes along with it is modularizing: each piece does one thing only. The absence count shouldn’t know anything about the color of the button. Small, independent pieces are easier to test, easier to swap out, and easier to hand to an agent without worrying that it will break the rest. It’s the tech basics I see operations people pick up quickly: modularizing, each step doing one thing only, keys that don’t stay exposed, and versioning.

How do you ask?

In the product world, the document that describes what’s going to be built is called a PRD (product requirements document). You don’t need forty pages. You need seven lines, and in practice they are the context from the next chapter:

Problem:             teenagers stop attending and the team only finds out weeks later.
Who uses it:         3 people on the field team and 1 coordinator. Almost always on a phone.
What goes in:        each school's weekly attendance list (codes, not names).
What comes out:      the list of who has 5 or more absences in a row, from longest to shortest.
Rules:               nobody is labeled "at risk"; the list shows the situation, not the person.
                     The decision to reach out to the family always belongs to someone on the team.
What it does NOT do: doesn't send messages on its own; doesn't store addresses; doesn't cross-check social benefits.
It worked if:        the list matches 10 cases the team counted by hand.

The most important lines are the last two. Saying what the system does not do is where ethics and safety live. And saying how you’re going to check is what separates building from hoping.

What does this have to do with autonomy?

I started writing about building without depending on a development team long before generative AI. Years ago I published a guide to building MVPs without developers. What low-code tools promised, generative AI delivered on another scale: today a person who understands a problem can get to a working product.

I think that’s really cool. As I wrote back when I was still wrestling with the first tools: speed is not the differentiator, autonomy is. More people can build, because building now happens in natural language.

And I think there’s a condition. The tools democratized the doing; the thinking still belongs to each person. Someone who can’t decompose a problem asks for “a school dropout app” and gets a generic, pretty app. Someone who can asks in seven lines, and gets what they need.

Generative AI literacy and computational thinking are the two legs of the same autonomy. One without the other limps.