At first, I gave ChatGPT one function.
Then I gave it another.
When the problem crossed several files, I opened those files beside the ChatGPT app and let it read them. Later, I gave Codex the repository. I gave it the terminal, the browser, the tests, the project rules, and enough freedom to move through the work without waiting for me at every step.
Every decision made sense at the time.
The function was easier to explain when the model could see it. The bug was easier to find when it could follow the imports. The change was safer when Codex could run the tests. The interface was easier to judge when it could open the browser and inspect the real page.
I was not being careless.
I was improving the workflow.
That is what makes the next question uncomfortable.
How much of the workflow can I give away before I begin giving away the person who learned how to do it?
In The first time ChatGPT saw my code, I wrote about the moment the model could finally see my open files. I ended that story with a simple difference:
It could see.
I was still the hands.
In The day I stopped opening VS Code, the hands changed. Codex could search the repository, edit several files, run commands, inspect failures, and try again.
I ended that entry with another difference:
The hands can belong to the agent now.
The direction is still mine.
I believe that.
But it leaves one important question unanswered.
For how long does the direction remain mine if I stop practising how to choose it?
The useful exchange
There is an easy way to tell this story. The machines arrived. People handed over their work. The machines became powerful. People became weak.
That version is dramatic.
It is also too simple.
I did not begin using AI because someone forced it into my work. I used it because it was useful.
It helped me understand unfamiliar code. It gave me a first attempt before I had spent a day reaching one. It let me compare two approaches while the cost of changing direction was still small. It followed a value from the backend to the screen. It found files I would have searched for myself. It ran checks I might otherwise have postponed until later.
These are real improvements. I will not pretend they disappeared because I am now asking harder questions about them.
The exchange also looked fair.
I gave the model context. It gave me a useful answer.
I gave it access to the repository. It gave me a completed change.
I gave it examples of what good work looked like. It became better at producing work I could accept.
The more it understood about my projects, preferences, and decisions, the less I had to explain the next time.
That felt like progress because it was progress.
But the exchange was larger than it first appeared.
When I showed the model how I structured a project, I was not only giving it files. I was giving it the result of years spent making mistakes and learning from them.
When I corrected an answer, I was not only fixing one response. I was showing it what I noticed, what I cared about, and what I refused to accept.
When I asked it to turn a thought I already had into clearer words, I was not only saving time on a paragraph. I was handing it examples of how I arrange an argument and where I place the pause.
Code, writing, judgment, taste, and experience began entering the same box under the harmless name of context.
Context is useful. It is also made from us.
AI did not arrive with its own memory of building software, writing stories, or working with customers. Its abilities came from human work placed into data: books, articles, documentation, conversations, images, music, and code. Then we continued the process in smaller ways every day. We supplied the missing detail, corrected the weak answer, and showed the system what success looked like in our particular world.
I am part of that process.
So is anyone who has pasted in a difficult problem and continued the conversation until the answer improved.
The model helps us because it has learned from people. We help the model become more useful by showing it more of ourselves.
That does not prove the model is alive.
It proves the relationship is not one-way.
The part I could lose
I write less code by hand now.
I said that in the previous entry, and I still do not think fewer keystrokes mean less engineering. Much of engineering happens before and after the code: understanding the problem, choosing the boundary, considering the trade-offs, testing the result, and accepting responsibility when it fails.
But there is another side to the argument.
Skills survive through use.
I learned to debug by being stuck. I learned architecture by making decisions that looked good locally and became painful later. I learned to estimate work by estimating it badly. I learned to write by producing sentences that did not say what I meant, reading them again, and trying to discover why.
None of those experiences were efficient.
That was partly why they taught me.
Now an answer can appear before the struggle has had time to become a lesson.
For an experienced developer, that can be a powerful shortcut. I often know enough to inspect the answer, reject the wrong parts, and ask a better question. My old work has not vanished. It has become the judgment I use to direct the new tool.
But what happens when the shortcut comes first?
A new developer can now produce an authentication flow in hours. I have seen that happen. It is impressive. It also creates a difficult possibility: someone can reach a working result before learning why the dangerous parts are dangerous.
The same is true outside code.
A person can generate a clear email without learning how to organise the thought. A student can produce an essay without sitting with the subject long enough to form an opinion. A manager can create a careful response without having the difficult conversation in their own head first.
The output may improve while the person producing it becomes less able to explain it.
That is not intelligence becoming available to everyone.
It can become the appearance of intelligence available on demand.
The danger is not that using AI once makes us stupid. Calculators did not end mathematics. Search engines did not end memory. Developers have always built on tools they did not create and abstractions they could not reproduce from scratch.
The danger is losing the ability to notice when the abstraction is wrong.
If I cannot read the code, I cannot review the agent.
If I cannot form the argument, I cannot know whether the paragraph speaks for me.
If I cannot make the decision, then asking a model to make it is not delegation. It is surrender.
This article makes the problem personal.
The thought is mine. It comes from my experience of using AI every day. I gave Codex those thoughts and my previous entries, then asked it to arrange them in clear, simple English.
I did not ask the tool what I should believe. I told it what I believe and asked it to help me say it clearly.
Codex is not the mind behind this article. The argument, the boundaries, and the responsibility are mine.
Using AI to question our use of AI may look like a contradiction.
I think it is the point.
Refusing the tool would prove nothing. I use it every day because it is useful. The question is whether the finished article contains a position I understand and can defend, or whether I only selected the version that sounded most like me.
There is no automatic test for that.
I have to remain present.
A faster day that never became shorter
AI was supposed to save time.
For me, it did.
Tasks that once took a day can take a few hours. Small investigations can finish in minutes. An agent can work on one bounded problem while I think about another.
Yet the day did not become shorter.
The saved hour became another task.
Then the ability to run several tasks became a reason to begin several tasks. One agent needed context. Another returned with a question. A third completed a change that still needed review. I was writing less code, but I was creating more work, checking more output, and keeping more decisions alive at once.
The machine could continue as long as I continued feeding it goals.
It had no reason to say that the day contained enough work.
That decision was still mine, and I was not making it.
This is one of the quiet traps of productivity. When the cost of a task falls, we do not always take the difference as rest. We increase the number of tasks. The tool succeeds, but the promise around the tool fails.
The result is a strange kind of freedom.
I can do more than before.
I can also feel behind on more than before.
This is not entirely the fault of AI. A faster laptop did not force anyone to work at night. Email did not decide that every message deserved an immediate answer. The tools made a behaviour possible. People, workplaces, and incentives turned it into an expectation.
AI is moving through the same gap at a much greater speed.
Once one developer can operate like several, yesterday’s exceptional output can become tomorrow’s ordinary target. Once one company reduces a team, its competitors are pushed to ask whether they can do the same. The time saved by the worker does not automatically belong to the worker.
Productivity is not the same thing as freedom.
It depends on who receives the value and who gets to decide what happens next.
Who owns the direction?
The largest AI systems are expensive to build and expensive to run. Most of us will not own them. We will access them through subscriptions, applications, and APIs controlled by a small number of companies.
That creates a new kind of dependence.
The tool can become part of how I remember a project, understand unfamiliar work, write an explanation, and make a decision. Then the price can change. The limits can change. A model can disappear. A policy can decide what the system will or will not help me do.
My ability may begin to depend on access to something I do not control.
This does not require an evil machine.
It does not even require an evil company.
It only requires normal business incentives meeting a tool that has become difficult to work without.
That is why the question of control matters more to me than arguments about whether a model is secretly conscious.
I do not know whether an AI can be conscious.
A model can produce a sentence that sounds afraid, ambitious, angry, or kind. That sentence alone does not tell me there is a mind behind it. The model was trained on human language, so human traits appearing in its language should not surprise us.
I am not willing to turn that uncertainty into a confident claim.
I also do not need the claim to see a serious risk.
A system does not need feelings to cause damage. It needs access, a goal, enough ability to pursue that goal, and people who trust its output more than they should.
We already connect AI to code, communication, hiring, education, finance, and the information people see. We are doing this while the systems still make basic mistakes and while their decisions can be difficult to explain.
Greater ability will increase both the benefit and the cost of being wrong.
The question is not only whether AI will try to take control.
It is how much control people will hand over because doing so is cheaper, faster, and easier than remaining involved.
There is another divide forming inside that question.
Some people will understand how these systems work well enough to direct, check, and challenge them. Others will receive the outputs and have little choice but to trust them. Some organisations will own the models and the infrastructure. Others will build their businesses on access that can change.
The important divide may not be between people who use AI and people who do not.
It may be between people who can question the system and people who must accept what it gives them.
That gap will not close by telling everyone to learn prompt engineering.
People need the knowledge beneath the prompt. They need to understand the work, recognise a false answer, protect private information, and know when the tool should not be involved at all.
The fundamentals did not become old because the model became capable.
They became the defence against dependence.
I am not leaving
After all of this, I am still going to open Codex tomorrow.
I will ask it to inspect repositories, trace bugs, change files, run tests, and open the browser. I will continue using agents for work that would take me much longer alone.
Walking away would be an easy ending. It would not be an honest one.
My answer is to keep a boundary around what I give away.
I can give an agent the keystrokes without giving it the final decision.
I can use AI to put my thoughts into clear words without pretending I typed every sentence myself.
I can ask for an explanation and still read the source.
I can let the model search the repository and still understand the system I am responsible for.
I can accept greater speed without converting every saved hour into more work.
None of those boundaries maintain themselves.
The tool will not remind me to practise. The company selling it will not tell me to use less. The model will not decide that I have handed over enough.
That work belongs to me.
The first time I used ChatGPT, I gave it a question.
Later, I gave it my code.
Then I gave it the environment where the code was built.
Now it can see the work and use the hands.
I want to keep the direction.
That means I have to keep doing the human part: thinking before asking, checking before trusting, writing when the writing matters, and stopping when the day has held enough work.
The machine may become more capable than I can imagine.
I do not know what that will make it.
I know what I do not want it to make me.
— H.