“A thousand reais for a bloody chatbot?”

That’s the startled reaction I get when I tell people how much I pay to use artificial intelligence. I understand it. In Brazil, a dollar subscription can turn a conversation about tools into a conversation about bills pretty quickly.

I used to joke that I wanted to be like Piccolo from Dragon Ball: multiply myself to multiply my ability to get things done. I had ideas and the ability to execute. I needed more hands to make it all happen.

Today, I call my agents “clones” in that same playful sense. I explain what I want, distribute workstreams, and then assess what they did. The reaction to the price gets more interesting when you look at that use.

When I say “around a thousand reais,” I’m describing the expense approximately. I’m not quoting an exchange rate calculation or the exact amount on my bill.

The reference price here is US$200 a month. When checked on October 18, 2026, OpenAI’s official documentation listed that amount for ChatGPT Pro 200, one of its subscription tiers. That sets the context; it isn’t a recommendation or an account of every cost in my operation.

If I paid that just to exchange messages and get a pleasant piece of writing back, I’d have plenty to question too.

But in my daily routine, the conversation is the starting point for work that continues afterward.

I love working with AI because I’m having fun with the work. I see an idea take shape, direction turn into execution, a task move forward. What excites me is participating in that movement.

TL;DR

I love working with AI because I’m enjoying the work more and seeing my ideas gain traction. Delegating manual execution leaves me more involved in direction, rules and validation. The joke of having “clones,” like Piccolo, has become a way to work on parallel fronts. I evaluate the expense by delivered work and the load it takes off me, including supervision, errors and rework. The subscription offers capabilities; integrations and automations need building and governing. This is my experience, without a promise of saved hours or returns for somebody else.

What happens after I press Enter

A chat interface, or chatbot, receives messages and returns answers. An AI agent, as I use the term here, can also choose next steps and use tools to pursue a goal within limits. I explained that distinction in “If you think AI is just a chatbot”.

In my daily use, several agents take part in different workstreams. The joke can evoke a corporate version of The Sims — a little town of characters, like the game where players follow their daily lives. The image is only a comparison. I’m still talking about systems that receive context, execute steps and need to leave verifiable results.

In software development, that includes writing code changes and reviewing them: examining what changed, looking for faults and testing whether the solution meets the request. I used to do all that reviewing manually, line by line. It took time, concentration and mental effort; bugs — errors in how software behaves — and security flaws could still slip through. Nobody is tireless.

Today, in the workflow I use, every change I submit, whether written by me or by an agent, goes through another agent’s review. That adds a layer of verification without guaranteeing perfection: the reviewer can be wrong too. I reach my own assessment with part of the investigation already underway and can focus more attention on the solution’s direction, readability and my quality criteria. I remain responsible for understanding and accepting the result; when the risk calls for it, the technical analysis needs to go deeper.

In infrastructure and integrations — the environment systems run in and the connections between them — I use agents to investigate failures, check configurations and establish what remains unresolved. An investigation that identifies a blocker can be useful. It doesn’t become a working integration because the report ends confidently.

Less cinematic tasks matter too. In document organization, I’ve delegated checking duplicate files and moving redundant copies to recoverable trash while preserving the copies that should remain in use. The deliverable was the organized folder and evidence of what was preserved, instead of instructions for me to do the cleanup.

I also have reply follow-ups and configured routines spanning email, documents and tracking systems. The rules say what deserves an alert, what has already been handled and when a discrepancy needs to come back to me. Spreadsheets and organized record collections, such as Notion databases, take part through authorized connections. Configuration is a real deliverable; each routine’s execution needs checking in its own context. I want to receive what needs a decision with enough context to act, without reconstructing the follow-up myself. I also want to know where to find each piece of information, easily and accessibly. The organization needs to work for me and for the agents. I don’t lose my autonomy; I gain strength.

In content work, I’ve turned an idea into a complete, reviewed chapter recorded in a version I could assess. I also use AI to prepare documents and define products. That speaks directly to a business owner’s work when they have knowledge but need to turn it into usable material and clear decisions.

This work doesn’t come with a technological revolution soundtrack. It still takes time when nobody does it.

Preparing an email doesn’t mean sending it. Following up on an outstanding item requires access to the channel, continuity and a way to record its status. When a piece is missing, the result needs to show that gap.

I have used agents to find nearby businesses, check their locations and contact details, and open WhatsApp conversations. For the pharmacies, the work included sending questions and following the back-and-forth to confirm stock, availability, price and purchase conditions for a medicine. We obtained stock and price confirmation from one store. Requests for oil and filter change quotes were also sent to local businesses; I don’t yet have a confirmed final comparison establishing who offered the lowest price.

The benefit was delegating that chain of small tasks: search the map, find the contact, open the conversation, ask, follow up on the reply, and organize price, distance and availability so I could decide. The agents kept track of who had replied, what was confirmed and what was still missing. I watched out of curiosity, without having to manage each conversation or interrupt my work to answer every message. That control of the follow-up is what I want alongside the options and the next step; I don’t have a measurement of money or hours saved.

The comic moment came from an automated service: it asked for a shorter message, then sent me a novel. I chose to step in to challenge the inconsistency I perceived; the task didn’t need my intervention to move forward.

The report arrived. The work stayed with me.

That’s the bottleneck I want to solve.

I request a task. I get a detailed report explaining everything that could be done. Now I need to extract the actions, choose their order, copy information, open systems and execute.

I’ve gained some reading. The queue is still mine.

Sometimes an assessment is precisely the right deliverable: before a consequential decision, when authorization is missing or when risk calls for investigation. The problem is an executable task coming back as advice and requiring me to do all the work of turning it into reality.

So the result I want is more concrete: the organized file; the prepared change with checks; the email ready for review; the recorded outstanding item; or a clearly framed decision explaining why execution stopped.

A useful agent can say what it completed, where the evidence is and what depends on me. If it couldn’t act, it needs to bring back the target, the blocker and the decision required to continue.

“Here are fifteen suggestions” can be a good answer. For some tasks, it’s also a beautifully formatted way of handing the job back.

The subscription buys access. The operation needs building.

The official Pro page describes access to models, Codex — the tool for working with code —, deep research, image creation, memory and file uploads. That’s the foundation the provider offers.

The platform also has scheduled tasks and connected apps, subject to availability, permissions and limits. A routine spanning email, a spreadsheet and a database still needs authorized connections and its own rules. There are also automations I built with AI’s help and services I integrated into my infrastructure. That whole setup can’t be presented as something the subscription delivers ready-made.

This use depends on a structure of context, tools, procedures, checks and limits. That’s what I call a harness.

In my case, part of the work is formalizing procedures in that system. Changes are recorded in versions and pass through reviewable change proposals, or pull requests, before being incorporated. That lets me inspect what’s changing instead of relying only on the memory of a conversation.

That structure takes work too. Writing rules, organizing access, correcting contradictory instructions, reviewing changes and maintaining integrations don’t come courtesy of the monthly fee.

And having access to a capability is different from authorizing its use. Finding a Send button doesn’t grant permission to send a message. Being able to edit a file doesn’t authorize publishing any content. The greater the consequence, the clearer the limit needs to be.

I want autonomy for work that’s authorized and sufficiently defined. I want to be called in when there’s a real decision, missing information or a risk that justifies my involvement. I explore that boundary in “Does your agent know when to stop?”.

If I need to supervise every click in a simple task, autonomy falls short. If the system crosses a decision that still belongs to me, it has gone too far.

What changed in my head before it changed in a spreadsheet

The window runs from October 15, 2026 at midnight through October 17 at 21:08:09, São Paulo time: three calendar days, with the third still incomplete.

In that period, I worked on evolving two libraries — collections of code other systems can reuse —, 29 stable versions were published across three projects, and 23,179 changed lines of code, tests and configuration were incorporated. The survey found 135 pull requests opened across six repositories; 123 had been merged by the cutoff. Versions include capabilities, fixes and maintenance; the lines come from comparing the start and end of the period without adding overlapping PR diffs, and don’t measure manual typing or productivity.

During the three days that prompted this conversation, I moved software development and infrastructure workstreams forward in parallel, with changes prepared for review. My estimate is that this work would probably have taken me three to six months two or three years ago, before directing agents became this accessible. That’s a personal comparison with how I used to work, not a productivity measurement. Later in the article, I show some verifiable deliverables from that period.

The work took more effort and time. Mental exhaustion also reduced how much I could produce. Just anticipating the cost and difficulty of implementing an idea could tire me out before I started. As I worked on one, others appeared; the anxious urge to execute the new ones made me lose traction on the earlier ones.

The stream of ideas has always been there. Each feature opened paths to several others, and I could get lost in deeper explorations before finishing what I had started. That still happens. What changed is that I can now hand those new workstreams to agents without stopping the previous one’s execution.

I then assess whether the result matches what I wanted. Rules we’ve already agreed on leave some deliveries nearly ready for approval. It isn’t always right; I still need to examine what was done and decide what I accept.

There’s a sentence that sums up what’s happening to me:

I’m more committed to the process because I’m less involved in the process.

Less involved in manually executing every step. More involved in saying what I want, specifying how it should be fulfilled, building the working agreements and validating the result. That’s work too. And it’s a part of the work I enjoy participating in.

That’s why the promise I keep seeing in AI offers irritates me: “you won’t need to work anymore because AI will work for you.” I consider that promise a lie. And it takes the fun out of the process. What I’m experiencing is a stronger desire to participate and see the work happen. The tool expanded what I can set in motion; it didn’t turn my interest into a wish to disappear from the operation.

The gain I perceive is that shorter distance between thinking of something and having concrete work to assess. It’s more than finishing more things. I can get ideas out of my head without personally executing every step of each one.

I could already switch those stages to automatic: create a task and connect implementation, review, publication and follow-up. I choose not to enable everything yet. What I’m building is confidence that the workflow respects my criteria, maintains my rules throughout execution and knows when to call me in. I want agents to incorporate that way of working more fully so I can reduce the manual checks I still need to make.

A teacher of mine had a phrase: “Just because it works doesn’t mean it’s right.” It took me years to understand. It fits perfectly here: a workflow running doesn’t prove it meets the criteria, has the necessary quality or is ready for my trust. I won’t sell as finished what I still want to build. That promise of validated work merely because something ran is what I criticize. Automating more doesn’t release me from responsibility for the result or guarantee that everything will always be right.

I explored that distinction in “AI made an elephant. The expert sold it as a rabbit.”: fulfilling an ambiguous request is not enough to meet the intent; specifying and checking remain my responsibility.

The soul of the text isn’t a setting to automate

This conversation illustrates what I mean. The article began with the startled reaction to a thousand reais. Then I kept bringing in what was missing: the Piccolo joke, the exhaustion of anticipating all the execution, the desire to work and the choice to stay involved. I’m directing the text as it takes shape.

I could configure a workflow to generate posts, Instagram publications and texts for X at set intervals. What matters to me is whether I’d be true to myself and my authorship if I let it run without reading, without knowing what was being written in my name. Scaling output is one thing. Recognizing myself in what I sign requires a different kind of involvement.

Even if it made money, I don’t want to monetize what, for me, would be a lie: presenting something as my thinking when I’d removed myself from it. That’s a personal choice about what I put my name to. Content automation can serve many legitimate purposes; the problem here would be pretending to have an authorial involvement I didn’t have.

In Portuguese, I call that abandonment “delargar em vez de delegar”: a play on delegating versus letting go of responsibility. Delegation requires direction, limits and assessment of the deliverable. Abandonment is giving those up and still selling the result as though that responsibility had been fulfilled.

I also don’t want to use AI to exploit people’s psychological triggers in ways I wouldn’t want used on me. There are people and legitimate offers earning money legitimately. My choice is to explain what I deliver and its limits, without manufacturing fear, guilt or scarcity to push a purchase.

I explored this in “Writing with AI hasn’t made me less of an author”. When I think about a book, the idea, direction and what I call its soul are mine. AI can help make the prose understandable, organize paragraphs, correct wording and grammar, and reduce the burden of mechanical editing. I still need to assess whether the result preserves what I wanted to say.

The concerns I don’t need to have, I don’t need to have. The concerns I do need to have are my responsibility to have, and I think everyone should take that responsibility.

I don’t need to rebuild every sentence alone to be truly involved. I need to recognize the idea, check the claims, reject what doesn’t represent me and answer for what I publish. That’s where I want to put my attention. The tool can lighten the execution; responsibility for putting my name to it still belongs to someone.

I checked what came out of that activity

The numbers show the scale. What interests me is the work that came with them.

I asked the agents to scan for bugs and security flaws. They brought back problems to investigate and fix. Some discoveries surprised me. That use makes a difference to me: examining what already exists, finding things that slipped through and moving fixes forward, alongside building new things.

For the two libraries, the result was reusable code better prepared for use. error-handler gained improvements in handling failures and separating what users see from information intended for technical diagnosis. Fixes also preserved content produced by the application. php-cs-fixer improved shared code-formatting rules and the checks that help keep them consistent.

Another workstream prepared an environment to run tests and check changes automatically. It also brought operating commands, documentation and procedures for using and maintaining what was built. A delivery spans several changes; published versions record stages of that work.

I saw processes I once imagined would take months happen in a few hours. That’s my perception of this way of working, not a timed comparison or a delivery forecast for somebody else. What I can show are deliverables, fixes and published versions available to inspect.

Finding a problem also creates work: I need to assess the finding, decide on a fix and check the result. A scan doesn’t certify that a system is free of flaws. A published version establishes that something was made available; it doesn’t establish customer adoption or production results.

The bill includes the time AI demands from me

I don’t have an audited spreadsheet of recovered hours. Nor do I have a financial return figure that turns my experience into a promise to somebody else.

I have a way to evaluate it: choose a recurring task and follow it through to an accepted deliverable.

How much did I need to explain? How much did I need to check? Was the result usable? Were there errors? Did I have to redo it? Did the task leave the queue or merely change format?

Time spent supervising counts. Reviews and rework count too. Beyond the subscription, other spending on tools, infrastructure and maintenance needs to appear when it exists. A plan’s price isn’t the total cost of operating with AI.

I also need to consider what was delivered. A correct file, an investigation that reduces uncertainty and a tested change have different effects. A task can become faster and remain bad. It can require more review now and create a reusable procedure later. That needs observing, not assuming.

Agent counts, messages, changed lines or code proposals don’t settle that evaluation. One result can span several pull requests; a single pull request can mix fixes, documentation and features. Raw volume shows activity. We still need to check the deliverable.

It’s the same care I described in “Not every bottleneck deserves AI”: sometimes the best saving comes from removing a useless step. Assigning an agent to maintain it only makes the absurdity more sophisticated.

What if it isn’t worth it for you?

It might not be.

An occasional user may get what they need from a cheaper plan, a specific tool or a good automation rule. I don’t need everyone to buy the same subscription to justify mine.

I also don’t need to turn this calculation into a comparison with somebody’s salary. A collection of assisted tasks doesn’t equal replacing a person, their context, responsibility and judgment.

For me, it’s worthwhile because I can turn more ideas into work and I’m more interested in participating in it. That’s my assessment of my routine, open to revision as cost, quality and needs change.

I want to keep recording that experience here, including for posterity: how I’m working, what works and what still depends on me. Without having to announce a revolution in every post.

If you’re evaluating this kind of expense, start with a task that’s currently stuck in your hands. Define the deliverable, the limits on action and how you’ll check it. Observe the result and count the effort the tool demanded from you too.

The Piccolo joke has found a practical version in my routine: I can set more workstreams in motion without having to provide the hands for all of them. I still direct the work and decide whether to accept, correct or discard the result.

In the end, the question I care about is far less impressive than “how many agents do you use?”:

After that conversation, what stopped depending on me doing everything?

Further reading

• From chatbot to operation: the difference between answering and participating in work.
• The harness around the model: the structure needed beyond a subscription.
• About pull requests: how changes can be discussed and reviewed before incorporation.

References and limits of use

• OpenAI — ChatGPT Pro tiers: checked on October 18, 2026; supports the US$200 monthly reference for Pro 200. It doesn’t establish my bill, availability of every integration, total cost or returns. Prices and limits can change.
• GitHub — about pull requests: supports the explanation of the proposal and review mechanism; it doesn’t establish the effectiveness of my procedures.

• The routine examples are my account, without private third-party data. They aren’t a comparative productivity study. “Around a thousand reais” is my approximate description of the expense, without an exchange rate calculation or inferred taxes and fees.

• Libraries and published versions: the package definition files for error-handler and php-cs-fixer classify both packages as libraries. The public lists of error-handler releases and php-cs-fixer releases support 21 and two stable versions in the window respectively. Six further stable versions were verified in the private command-line tool. Filtering by publication date and excluding drafts and prereleases gives 29 in total. Release notes for 2.4.0, 2.5.0, 2.5.2 and 3.0.0 support the improvements and fixes described; publication doesn’t establish third-party adoption.

• Lines and incorporation: 23,179 is the sum of per-file changes in the comparison between the recorded states of each repository’s main version immediately before the start and at the final cutoff. It covers 296 selected code, test and configuration files; documentation, plans, examples, dependencies, generated files and dependency-version lock records are excluded. Each repository is compared once, without repeating changes present in more than one proposal or adding up every intermediate edit. The error-handler comparison and php-cs-fixer comparison are public; other comparisons, filters and the inventory remain in private review support. The total includes tests and configuration; it doesn’t measure manual authorship or every intermediate edit. Of the 135 PRs opened in the window, 123 had a recorded merge by the cutoff and 12 had not; later merges weren’t counted as deliveries for that period.

• Own GitHub activity survey: queries for owners coisa, mentordosnerds and I-9-AI, deduplicated by URL and checked individually. UTC window: October 15, 2026 at 03:00 through October 18 at 00:08:09. The review inventory is preserved outside the public repository because it contains private metadata. It doesn’t certify complete coverage, manual contribution, deployment, recovered hours or returns.

• OpenAI — scheduled tasks and connected apps: support the distinction between platform features and conditional access to services. They don’t establish my particular executions or that every integration is included in the plan.
• The personal comparisons between three days now and three to six months of past work, and between processes taking months and a few hours, are my estimates. They aren’t a controlled experiment, measured hours or a return calculation. Connecting stages automatically is a technical possibility the author chooses not to enable fully; the maturity sought is reliability and adherence to his criteria, without absolute guarantees or transferred responsibility.