Why this project
Who I am, and why IA da Terminale exists
I have been using a computer since I was about fifteen. I am forty-five now.
My first encounter had actually come earlier, with a Commodore 64. Then came Windows 95 and 98, in the days when installing something meant accepting a certain amount of risk, and formatting a computer and reinstalling everything from scratch was almost routine.
Not long afterwards I discovered Linux.
It fascinated me for very practical reasons — you could look inside the system, change it and understand more clearly what was happening — but also because of the broader idea of openness behind free and open-source software. The feeling that a computer did not necessarily have to be a closed box.
I did not become a developer.
After all these years, I can at least tell a line of JavaScript from a line of Java or C#. But that is not my job.
I remained what Italians once called a smanettone: curious enough to want to know how things work, and reckless enough to try them, break them and put them back together.
That distinction matters when explaining why this project exists.
I have always used technology to do something else
Meanwhile, I was studying something entirely different.
I liked novels, stories, language and the way people construct and transmit meaning. I graduated in Communication Studies.
The computer, however, was always there.
My first permanent job was with a civil mediation body. I had not been hired to program, but at some point the small office needed a better way to organise cases, deadlines and documents.
I built a management system in Microsoft Access.
Then we needed a website, so I built that too. Search engine optimisation, early analytics tools and advertising campaigns followed: everything needed to make the site work, rather than merely exist online.
Looking back, the pattern was already the one that still follows me:
there is a concrete problem, there are tools, and I try to learn enough to build a solution.
Eventually I left that job and opened a small web agency with a childhood friend. There were two of us: he mainly handled clients and accounts; I worked on websites and digital campaigns.
Google Ads was still called Google AdWords. I spent my time thinking about the cost of a keyword, CPC, conversions and what happened after a click.
New tools kept arriving. WordPress became increasingly important. The web and advertising platforms changed, and we had to keep studying.
The project with my friend eventually ended. I stayed in that world.
Over the following years I worked with several marketing and communication agencies in Palermo, in the hybrid territory between technology and communication: WordPress sites, HTML and CSS when something more bespoke was needed, digital campaigns, tracking, Google Tag Manager, Analytics, and whatever allowed a strategy to talk to the tools that had to execute it.
Today I continue to work independently across digital marketing, web design and training. For several years I have also taught university-level courses in Palermo on web marketing and artificial intelligence applied to communication strategy.
In other words, I am still not a developer.
But I spend most of my days in front of a computer.
Then artificial intelligence arrived
I have always been broadly curious about technology.
And by technology I do not mean only digital technology.
Software is technology, of course. So is a well-designed object. In a broader sense, a book is technology too: a tool invented to preserve a thought and let someone else encounter it across space and time.
At the root of almost all of it is probably the most powerful technology we have invented: language.
When the first generative AI tools arrived, it was inevitable that I would end up in that world too.
I began with the early versions of GPT available in a browser. Then Claude. Meanwhile I tried to understand what sat underneath: neural networks, machine learning, deep learning and language models.
Not at the mathematical level required for research, but deeply enough at the conceptual and theoretical level to build a mental model of how they worked.
Not to become an AI researcher.
I wanted to know enough to distinguish, as far as possible, what these systems actually did from what we tended to project onto them.
I still consider that distinction important, especially in a field where someone announces a definitive revolution every week.
Alongside study, however, there was always use.
And use was what truly changed the way I worked.
Returning to the terminal
The terminal has always been one of my minor loves among interfaces.
That may sound odd, because for many people it represents the opposite of a good user experience: an almost empty screen, very few directions and no buttons suggesting what to do.
For me it has always held a different appeal: it is one of the interfaces closest to what a computer really is and what it can do.
But over the years, as I mainly used Macs and worked on things that did not require Linux or software development every day, I had fewer and fewer reasons to use it.
Then Claude Code came out.
I installed it almost immediately.
And that began a succession of:
Oh, so it can do this too.
I would ask it to produce a file and discover that it had installed a Python library to create an Excel workbook. Another time, a PDF. Then I would give it a web project and watch folders, dependencies, project structure and files appear.
Then:
Wait, so I can connect it to Google Analytics.
And immediately afterwards to Search Console. Google Ads. Campaign data.
I could ask it to retrieve and compare those data, then prepare analyses and reports for my work with clients.
The boundary kept moving.
Until there were evenings when, at two in the morning, instead of going to bed I found myself asking something like:
analyse my Music app library and, based on what I listen to, suggest some bands I probably do not know.
While in another terminal window another process was cross-referencing data and preparing analyses to optimise Google Ads campaigns.
A few rounds of reasoning, a few commands, a few files read.
Done.
That was when one thing began to become very clear.
The point was not Claude Code
The point was not that Claude Code was particularly good at programming.
The point was where it was.
A language model placed inside a well-built environment can receive access to the filesystem, shell, programs, libraries, APIs and external tools. It can take an action, read what happened and decide what to do next.
The scaffolding around the model — what is often called a harness — turns a model that produces text into something capable of operating in an environment.
And if that environment is your computer, the practical consequence is considerable.
Almost all the work we do on a computer ultimately consists of reading, transforming, moving or communicating information.
Files, spreadsheets, databases, email, websites, images, servers, APIs, browsers and online services.
If the agent has the right door to reach them, the necessary tools and permission to use them, it can work on those same things.
It is not magic.
We gave it tools.
For me, this is one of the fundamental differences between using a model in a chat and using an agent in an operational environment.
One question changed above all
Before, when a client made a request, a significant part of my work consisted of asking myself:
How do I do this?
Which tool should I use? Which steps should I follow? How do I retrieve these data? How do I transform them? How do I produce this output?
Increasingly, the question became a different one:
How should I organise the environment so that the AI can do this part of the work well?
Where should the data live? Which tools should it access? What information does it need? Which operations may it perform? Which ones should require my confirmation? How can I verify what it did?
And, above all:
which part still needs me?
Because that part has not disappeared.
Quite the opposite.
When AI retrieves hundreds of rows of data, writes code to analyse them and produces an initial interpretation in minutes, my value no longer necessarily lies in manually performing every step.
It lies in knowing whether it queried the right data, whether a change matters, what it means for that campaign, client and market, and when a formally perfect result is conceptually wrong.
It lies in judgement.
And that is not merely my impression.1
What changes, then, is not the need for expertise.
What changes is where that expertise is applied.
AI can dramatically shorten the distance between what I know and its execution on a computer. But domain knowledge still matters if I am to know what to ask, what to accept and what to correct.
Why this project, then?
At some point I realised that I was learning a way of using computers that could be useful to other people too.
People who are not developers. People who may never have written a line of Python and do not know what a shell is, but who spend a large part of every working day at a computer, using different tools and interfaces.
A marketer, teacher, researcher, accountant, consultant, designer or someone running a small ecommerce business.
Someone who takes information from one place to another, produces documents, checks numbers, sends email, edits files and uses different tools every day.
For years, simplifying somewhat, there were mainly two possibilities: learn to use applications someone else had built for us, or learn enough programming to build something ourselves.
A new space has now opened between the two.
Not everyone will become a developer, nor do I think everyone should. Designing and maintaining complex software systems will continue to require people with deep expertise in architecture, programming, security and engineering.
But between using an application and professionally building a software system lies an enormous territory.
That is where I want to work.
Recent research is beginning to study this shift explicitly: coding agents are already used for general tasks and can write, execute and correct small programs on the fly instead of depending only on a fixed list of tools. At the same time, more complex work still exposes their limits when domain understanding is missing.2
That is precisely why this project does not want to teach people to press a button and wait.
It wants to teach them to stand on the other side of the work.
Learning enough to guide
My way of teaching almost always begins with practice.
I do not care whether someone can recite the definition of a file path if they cannot tell an agent where a document is.
I do not care whether they can define an API if they cannot recognise that an API may be the door through which their agent reaches a service.
I do not care whether they know ten shell commands by heart.
I care whether they can watch what the machine is doing and know when to step in.
That is why the book begins with files and folders, moves through the terminal and reaches agents only afterwards. It is also why the exercises are done with the computer open beside you: a concept, something to do, and a criterion for knowing whether you have really understood it.
Behind this approach is a view of learning that has accompanied me for a long time: we truly understand something when we use it, when someone helps us just enough to take a step we could not yet take alone, and when that help can then gradually diminish.
Anyone looking for its roots will find a long tradition running from educational pragmatism to guided learning and scaffolding.3
But you do not need to know the theory to follow this project.
You need to open the terminal.
I do not want to teach you Claude Code
Claude Code is the tool with which all this began for me.
Today I also use Codex and other tools, often at the same time in the same project. One can work on a page while another produces images or analyses material by reading instructions kept in the same files.
Tomorrow I will probably use others.
That is deliberate.
This project aims to remain as brand-agnostic as possible.
Models, prices, limits and interfaces will change. All the parameters, if you will forgive the pun, will change.
What I want to teach is what remains: how to organise an environment, identify materials, give an agent capabilities, decide permissions, preserve context, check the output and retain the ability to go back.
The terminal itself is not the goal. Today it is simply one of the most transparent and general places in which we can watch an agent actually use a computer.4
AI can change. Your work should remain.
And I would like your files to remain too
There is another consequence of this way of working that matters deeply to me.
The cloud is enormously useful. A large part of my digital life is in the cloud, and I have no intention of giving it up.
But there is a difference between using a service and depending entirely on that service.
If the context of my project is stored in ordinary Markdown files, the data are exportable, the code is in a repository and important procedures are documented, Claude can work with them today.
Codex can read them tomorrow. Another agent can do so the day after.
That does not mean everything is perfectly interchangeable.
It means that the centre of the system can remain mine.
This idea did not begin with artificial intelligence: the local-first movement has long explored software that preserves the benefits of the cloud without giving up control and ownership of our data.5
Agents make that choice even more interesting today, because an accessible file is not merely something you own: it is also something different tools can work on.
What I would like to do here
IA da Terminale begins first of all as an educational project.
I do not rule out its eventually becoming an economically sustainable part of my work through other volumes, courses or training. I hope it will.
But the order matters to me.
Learning comes first.
I want to build something that lets a curious person begin from:
I do not even know what I am looking at when I open the terminal
and gradually arrive at:
I know what I want to achieve, which pieces I need to connect, where the agent may work and how to check what it did.
You do not need to become a developer.
You need to understand enough about the computer to work knowingly alongside an artificial intelligence.
And, above all, not to remain a passenger while that intelligence uses tools, files and services on your behalf.
If, after learning to connect Google Analytics, someone closes the page and thinks:
Wait. Then I could do the same with Search Console. Or email. Or my documents. Or the lessons I need to prepare. Or my research.
then the project is already working for me.
Because the outcome is not that they learnt a recipe.
It is that they began to see the computer differently.
Notes
These notes are not needed to read the page. They are for anyone who reaches the end and wonders where some of its claims come from.
#1. It is not merely my impression
Anthropic analysed about 400,000 Claude Code sessions between October 2025 and April 2026. Among other findings, the research reports that users’ domain expertise remains associated with successful agent work, while use extends beyond coding into data analysis and document production. During the same period OpenAI described growing use of Codex among knowledge workers for reports, spreadsheets, research, analysis and small tools. Sources: Anthropic — Agentic coding and persistent returns to expertise and OpenAI — Codex is becoming a productivity tool for everyone.
#2. Coding agents as general tools
The possibility that coding agents may become more general tools is already a subject of research. Can Coding Agents Be General Agents? examines their ability to tackle different tasks by writing, running and correcting code and scripts during the work, while also exposing their limits and failures as domain complexity grows. Source: Can Coding Agents Be General Agents?.
#3. Learning as a guided activity
The theoretical references include John Dewey, Lev Vygotsky and Jerome Bruner. The connection is not to a rigid methodology, but to a shared idea: learning as experience, guided activity and a progressive acquisition of autonomy. The term scaffolding was introduced in Wood, Bruner and Ross’s 1976 work on the tutor’s role in problem solving.
#4. The terminal is not an ideology
The research behind the project suggests that the terminal should not become an ideology. Its present value lies above all in being a general, transparent and composable operational surface. The same paradigm is appearing in desktop applications and operating systems. The more durable principle is therefore not “everything must pass through the terminal”, but the computer can become an environment controlled in natural language.
#5. Local-first
The local-first movement explicitly aims to preserve collaboration and the benefits of the cloud alongside user control, longevity and data ownership. Source: Ink & Switch — Local-first software.