Mentor dos Nerds Home The evolution of technology: from mainframes to real-time bad puns
Post

Article Artificial Intelligence

The evolution of technology: from mainframes to real-time bad puns

From a mainframe room to a conversational agent, with cloud, modular servers, and a rubber duck along the way
From a mainframe room to a conversational agent, with cloud, modular servers, and a rubber duck along the way

Decades of abstraction, billions in infrastructure, and an embarrassing amount of engineering just to afford the luxury of receiving a technical status update accompanied by a bad joke.

TL;DR

The evolution of computing was not a simple march from big to small. It was a sequence of abstractions: the mainframe concentrated capacity, the cloud made resources available on demand, containers packaged environments, AI models turned language into an interface, and agents began combining context, tools, and execution. The everyday result can be a technically useful and less mechanical conversation. Personalizing tone and humor improves the interface; it does not authorize flattery, ego-stroking, hiding uncertainty, or confusing a tool with a human relationship.

For much of computing history, talking to the machine meant filling out cards, waiting in a queue, and hoping you wouldn’t discover the next day that you had missed a period.

Today, I can ask an agent to inspect a repository, preserve what already works, research a question, divide the work, run validations, and return three things: current state, risk, and next step.

Between one scene and the other, the industry invented some important abstractions.

And apparently, all that effort also served to let the machine announce that it will analyze a log with something like: “I’m going to look for the needle in the haystack. The good news is that the haystack has grep.”

It wasn’t the future promised by the movies. On many days, it’s better.

When the computer was a place

The mainframe was not just a big computer. It was the center of an operation.

Processing, storage, terminals, routines, and people orbited expensive, shared, and deliberately administered infrastructure. The IBM System/360, introduced in 1964, made a family of machines compatible and helped consolidate the idea of a platform: software written for one model could grow with the customer without being rebuilt from scratch with every hardware change.

This seems obvious today because it worked.

At the time, it cost a gigantic business bet and required enough coordination to make any current migration seem like a slightly unpleasant Tuesday.

The mainframe taught a lesson we keep relearning: useful technology is not just power. It is power organized by contracts, compatibility, and operation.

When the computer became capacity

The cloud didn’t make computers evaporate. It just made it easier to forget which physical computer something was running on.

This sentence sounds like a joke, but it describes a serious shift. NIST SP 800-145 consolidated the definition of cloud computing around on-demand access, shared resources, elasticity, and measurable service. Instead of starting every decision by asking which machine to buy, it became possible to start by asking how much capacity to use, for how long, and under what conditions.

The server still exists. The bill does too. The novelty was turning infrastructure into a more flexible operational interface.

This brought real gains and new risks: provisioning became fast; wasting at scale did too.

Every abstraction removes one type of friction and creates another. The cloud reduced the wait for hardware and increased the importance of governance, observability, and cost control.

When the environment fit in a package

Then containers arrived and said: “What if, in addition to the code, we packaged the environment needed to run it?”

It wasn’t magic, nor a miniature virtual machine. It was a practical way to distribute applications with dependencies, configuration, and filesystem layers in a reproducible manner. The Open Container Initiative image specification helps keep images, manifests, and runtimes used by different tools interoperable.

In practice, containers reduced the classic “it works on my machine.”

They didn’t eliminate the phrase. They just gave it a file to attach.

The important advance was repeatability: a versioned definition could cross notebook, continuous integration, staging, and production with less improvisation between environments.

When language became an interface

Language models changed the surface of computing.

Before them, operating a system required learning the interface someone had designed: commands, menus, forms, APIs. Now, in many contexts, the first interface can be an intention described in natural language.

This does not mean that intention became reliable execution by decree. Language is ambiguous, models make mistakes, context can be missing, and convincing answers can hide fragility. The gain is in reducing the distance between what I want to do and the first operational representation of the work.

I can explain a goal in an imperfect way and receive an initial decomposition. I can externalize context, ask for alternatives, reveal dependencies, turn a decision into a checklist, and a draft into an artifact.

The model does not replace the system. It becomes a translation layer over the system.

When the conversation got tools

An agent adds another layer: beyond producing language, it can receive context, consult sources, use tools, execute steps, and verify results within defined limits.

This is where the conversation stops being just a response and starts functioning as coordination.

The agent can track the state of a branch, remember the acceptance criteria, notice that a validation hasn’t run yet, and return concrete evidence. It can also pick the wrong repository, misinterpret an instruction, expand scope, or execute something that should only be recommended. That is why the ability to act must come with explicit authority, observability, confirmation proportional to risk, and rollback when a change is hard to reverse. The NIST AI RMF 1.0 offers a framework compatible with this posture by organizing risk management into govern, map, measure, and manage.

The leap is not from “machine” to “person.”

It is from an interface that responds to a system that helps operate.

Timeline of computing showing mainframe, cloud, containers, models, and agents, followed by the limits between useful personalization and flattery

The pun is a small interface decision

After all that evolution, we arrive at a question of high scientific relevance: should the machine make a joke before opening a log?

My answer is a technical and responsible “it depends.”

When the agent announces that it will search, reason more deeply, or execute an action, it is making its own state more legible. A short joke can reduce the rigidity of the interaction, mark the transition, and make hours of work less sterile.

Humor has a function when it serves clarity and rhythm.

If it interrupts work, tries to be funny in inappropriate situations, or turns every response into a corporate stand-up number, it becomes noise with high self-esteem.

The same applies to tone personalization. Adapting vocabulary, technical level, length, and rhythm can make the conversation much better. Knowing my preferences prevents me from having to re-explain how I work in every session.

But modeling my style is not knowing my life the way a person knows it. And predicting the response I will likely prefer is not proof that the response is correct.

Personalization cannot become flattery

There is a clear line between a pleasant interface and an agent that agrees to preserve pleasantness.

On the useful side:

  • adjusting depth to context;
  • remembering that I prefer evidence over promises;
  • using light humor when it doesn’t compete with risk;
  • saying what is happening before a long-running action;
  • returning state, risk, and next step;
  • pointing out uncertainty and asking for a decision when it really changes the path.

On the dangerous side:

  • treating every idea as brilliant;
  • turning preference into fact;
  • hiding contrary evidence to avoid breaking the mood;
  • simulating certainty to appear competent;
  • validating an emotional narrative without sufficient context;
  • presenting itself as a substitute for human relationships that have reciprocity, needs, and their own limits.

A good interface reduces friction without removing reality. If humor makes risk disappear or personalization makes counterpoint disappear, the system has become more likeable and less useful.

The prompt I would use

I don’t want a grumpy agent. I also don’t want a terminal-based hype man.

I want a conversation that preserves rigor, announces mode changes, and knows how to relieve tension without masking the state of the work. A short contract could be this:

1
Speak in a technical and objective manner. When you need to search, reason more deeply, or execute an action, announce it with a short, natural joke before starting. Use light sarcasm when appropriate, without flattery and without hiding uncertainties. Prioritize: current state, risk, and next step.

This prompt does not guarantee good judgment. It defines an interaction preference.

The rest depends on the harness: which sources the agent consults, which tools it can use, where it needs authorization, how it records evidence, when it should stop, and which validations close a delivery.

Personality without operation is decoration.

Operation without personality works, but it can spend eight hours talking like a printer manual.

Current state, risk, and next step

When the conversation gets long, three anchors prevent humor from becoming smoke:

AnchorOperational questionWhat it prevents
Current stateWhat is true now and what evidence supports it?Optimistic summaries that don’t match the system
RiskWhat can go wrong, with what impact and uncertainty?Performative confidence and unlimited acceleration
Next stepWhat small, verifiable, and authorized action reduces uncertainty?Infinite analysis and theatrical execution

This structure works because it doesn’t require the agent to seem human. It requires it to be legible.

It can say it doesn’t know. It can disagree. It can announce that it will search. It can execute a small task. It can make a bad joke and, right after, show the correct SHA.

By the way, this order is important.

Evolution remains a choice of direction

From mainframe to agent, each layer expanded what we can coordinate.

Mainframes centralized critical work. The cloud flexed capacity. Containers increased repeatability. Models put language in the interface. Agents began connecting intention, context, tools, and action.

None of these layers automatically made our decisions better.

The easier it becomes to ask, the more important it becomes to know what should not be delegated. The more context the system tracks, the more serious privacy and scope become. The more natural the conversation seems, the more we need to remember that fluency is not reciprocity, consciousness, or human commitment.

The best agent is not the one that strokes my ego or agrees with me before I finish my sentence.

It is the one that reduces mechanical work, preserves context, points out the blind spot, and returns me to the world with something that can be verified.

AI doesn’t need to seem human. But if it’s going to talk to me all day, at least it should know when to drop a fifth-grade joke.

To go deeper

References and usage limits

The sources support specific technical milestones. The reading on humor, personalization, and conversation quality is an authorial synthesis, not a claim that one configuration works equally for all people or situations.

This post is licensed under CC BY 4.0 by the author.

Open conversation

Continue the conversation

Disagree, spot a gap, or have an experience that adds to the subject? Comment with your GitHub account. Do not publish personal data, credentials, or sensitive information.