The first time I took ChatGPT seriously, I was not the one using it.
By then, I had already been working in software for years. I started in 2015 with HTML and CSS inside Ruby on Rails applications. From 2019 onward, React, Django, and REST APIs became the core of my work. I had moved from implementing features to onboarding customers and leading a team.
I was not looking for a tool that would teach me how to code.
I had ignored ChatGPT on purpose. I stay away from whatever the internet has decided is important this week, and my days were already full. Work continued after the code was written: customer calls, delivery decisions, reviews, and helping a team move. Then I went home to my family and a small child. Another tool asking for my attention was not something I was looking for.
So for about a year, I did not open it once.
Then I gave a junior developer a Django project.
It was ordinary work. User authentication: login, password reset, password change, and the screens around them. He was early in his career. I knew the work involved because I had built and reviewed similar flows before. I expected it to take him a while, and I had planned the week around that estimate.
He came back with the first part in fifteen minutes.
An hour or two later, most of the flow was working.
I asked him how.
“I used ChatGPT.”
I asked whether he had used it to write the code.
“Yes.”
The code was basic. I would not have accepted it into production without reading and correcting every line. Authentication is the last place to be relaxed about validation, permissions, error handling, and security.
But the code was not what surprised me.
The speed was.
Someone still learning had gone from an empty project to something he could run, read, and improve in a fraction of the time I had allowed for it.
My experience made both sides visible. I could see where the code was weak, but I could also see that the way developers reached a first working attempt had changed.
I did not change how I worked that afternoon. I am not going to pretend I did. It took a while before I could say what had actually moved.
It was not that the machine could replace an experienced developer. It could not make the architectural decisions, understand the customer, or take responsibility for what went into production.
It had shortened the distance between a requirement and a first attempt. Not the distance to something finished. That still required review, testing, judgment, and ownership. But it gave a developer something concrete to run, read, question, and improve much earlier.
That is a much smaller claim than the ones being made everywhere at the time.
It is also the one that turned out to matter.
From May 2023 to November 2024, I worked as a freelancer.
It was not a career break. I was still building, speaking with clients, estimating work, implementing features, debugging failures, and delivering projects. The difference was that every decision eventually came back to me.
Freelancing also came with health problems, unpredictable income, and stretches where I did not know what the next month would look like. It was not a clean or comfortable period, but it gave me room to change how I worked.
That was when I started using AI seriously.
I had used GPT-3.5 and Turbo by then. GPT-4 was the one that changed the relationship.
Before it, investigating something unfamiliar meant searching documentation, reading several articles, building a small experiment, and joining the pieces into something useful for the project in front of me. A difficult problem could take a day. Sometimes it could take a week.
After it, I could start immediately.
I could compare two approaches before committing to one. I could ask for a different explanation when documentation was unclear. I could paste an error, challenge the answer, test the suggestion, return with what actually happened, and continue the investigation. It became a fast second pair of eyes, available at the exact moment a problem appeared.
It was also confidently wrong, often.
I lost real time to answers that were fluent, well organised, and false. The failure mode is worth naming precisely: how well an answer is written carries no information about whether it is true. A wrong answer arrives in the same calm prose as a right one. There is no tell. You find out by checking, or you find out later in front of someone else.
Years of development experience helped me reject many bad answers, but experience was not protection against every confident mistake. I learned to verify anything I would have to defend. That habit is the only reason the speed was worth having.
But the real problem that year was not hallucination.
It was that I could learn anything.
I would pick a subject, work on it for a month or two, become productive enough to see what was possible, and then find something else that looked important. Then again. Then again. I spent too much of that first year researching what I should learn instead of choosing a direction and staying with it.
AI had lowered the cost of curiosity. It had not taught me how to decide what deserved my attention.
What eventually fixed that was not a better model.
I stopped treating it as a path to learning everything and started treating it as one tool inside an engineering process I was still responsible for. I still had to test the code, read the documentation, understand the system I was changing, and recognise when an answer only sounded right.
The fundamentals did not become less important. They became more important, because I was now producing far more work that I had to be able to judge.
That is roughly when the direction settled. I moved toward AI development and deeper system design. My previous work did not disappear when I changed direction. React, Django, APIs, customer onboarding, and team leadership became the foundation I brought into AI work.
I was not restarting from zero. I was changing direction with nearly a decade of software work behind me.
A demo that works and a system people depend on are different problems. AI can help produce the first one quickly. The second still requires engineering.
Three years on, there is no Netflix. Almost no YouTube. Still very little social media. I do not think of that as discipline. The work simply became more interesting than the alternatives, and my attention went where it wanted to go.
Most of my day now runs through Codex: building, reading, testing, and arguing with it. Not because I have forgotten how to code, but because the tool lets me move across more of the work without giving up responsibility for the result.
The tools are unrecognisable from the ones that produced that first authentication flow. What I learned that afternoon has not changed at all.
Starting became cheap. Deciding what to start did not.
Codex it is.
That is the next entry.
— H.