I know how to build things. I know how to write code, understand systems, learn unfamiliar tools, and turn an idea into something that works. For a long time, that was enough for me.
I did not need every project to become a product. I did not need every experiment to attract users or prove something about my career. Sometimes I would spend months, even years, working on the same idea. I would rewrite it in different frameworks, change the architecture, abandon it, return to it, and start again.
From the outside, that might look slow or unproductive. But I was learning.
I was learning how different tools behaved, where they failed, which abstractions held up, and which decisions I would make differently the next time. The project did not have to succeed. It did not even have to reach the point where anyone else could use it. I was doing it because I loved the craft.
Since AI became part of software development, that relationship with the work has become harder to maintain.
The problem is not simply that AI makes it easier to build things. That part is useful. The problem is that once everything becomes faster, speed stops feeling like an advantage and starts becoming an expectation.
An idea is no longer something you might slowly explore. It is something you are expected to build immediately. If you have an idea, you can build it. If you think of a product, you can launch it. And if you want to move forward in your career, you are expected to have a portfolio filled with finished applications, public demos, users, stars, revenue, recognition, and other forms of external validation.
Everyone suddenly has access to abilities that once required years of experience, several people, or a significant amount of time. People are building products they could not have built before. That is exciting, but it has also created an enormous rush. Everyone wants to be part of everything, and everyone appears to be moving at once.
It creates a strange pressure to keep producing proof that you are moving forward.
A lot of meaningful engineering work does not naturally produce that kind of proof. You might spend years solving difficult problems inside a company, improving systems that outsiders will never see. You might make software more stable, reduce infrastructure costs, simplify an architecture, or prevent failures before they happen. None of that necessarily becomes a public trophy.
Unless you work somewhere that gives you room to experiment, take ownership, and pursue ideas carefully, you are expected to create those opportunities yourself. Side projects become portfolio entries. Experiments become products. Learning becomes content. Curiosity becomes another career strategy.
Something that once belonged to you begins to feel like another obligation.
I have always believed that tools are secondary. A good developer can learn a new framework, language, or platform when the work requires it. Tools matter, but they are not the foundation of the craft.
The deeper skill is knowing how to approach a problem. It is the intuition to recognise what might work, the judgment to choose between several possible approaches, and the experience to notice when something feels wrong before the failure becomes obvious.
It is knowing what already exists, understanding the trade-offs behind different decisions, and recognising when a familiar solution does not fit the current problem.
A tool can make the work faster. It can generate code, suggest an architecture, explain an unfamiliar library, or complete a repetitive task. But it does not automatically give someone the judgment that comes from building, breaking, debugging, rewriting, and maintaining real systems.
That judgment is difficult to display.
What people can see is the output. They can see how many applications someone has built, how quickly they built them, and how confidently they present the results. It is much harder to see whether the person understands what was produced, whether they could maintain it, or whether they could continue when the tool gives them the wrong answer.
As the tool becomes more visible, the craft behind it becomes less visible.
This will be especially difficult for people who are still learning. New developers need room to be slow. They need opportunities to make unnecessary things, choose the wrong framework, write poor abstractions, and later understand why those choices were wrong.
They need to struggle with problems that a tool could solve instantly because the struggle itself develops intuition.
When every project is measured by delivery, there is less space for that kind of learning. Even side projects begin to carry the pressure of production. They need to look complete. They need documentation, a launch page, users, analytics, and a story that can be shared with employers.
But a side project does not always need to become anything.
Sometimes I want to build something simply to understand how it works. I might rewrite the same feature several times using different frameworks because I am curious about the differences. I might stop halfway through because I have already learned what I wanted to learn. I might spend far too much time on something that nobody else will ever see.
That is not wasted work. That is part of how I became a developer.
People come into software for different reasons. Some genuinely enjoy the craft. Others primarily see it as a good career, and there is nothing wrong with that. Most of us need our jobs to pay for our lives, no matter how much we enjoy the work.
But those motivations used to feel more distinct.
Someone could love building things, experiment quietly, and allow a career to emerge from that interest. The job was a way to make a living from something they already enjoyed doing.
Now those paths appear to be collapsing into one. Even people who love the work are expected to present themselves as relentless builders, founders, creators, and hustlers. Everything must move towards delivery, growth, visibility, or money.
The industry increasingly rewards the appearance of constant movement.
That is where my conflict with AI begins.
I use AI. I understand why it is useful. It can help me explore ideas, automate repetitive work, move through unfamiliar parts of a system, and sometimes build things that would otherwise take much longer.
I am not trying to reject the tool.
But I still want to write code.
I want to build some things by hand. I want to sit with a problem, understand it, try an approach, realise it was wrong, and try again. I want to experience the part of the work that made me love software in the first place.
The uncomfortable part is that choosing to work that way can now feel like a liability.
When someone else can produce something similar in a fraction of the time, taking the slower path looks inefficient. Even when the slower path helps me understand the problem more deeply, that understanding is not always visible in the finished result.
So the choice is no longer simply between using AI and not using AI. It often feels more like keeping up or falling behind.
That pressure follows the work everywhere. It enters personal projects, experiments, learning, and the quiet time that used to belong to curiosity. It makes it difficult to tell whether I am building something because I care about it or because I am afraid that everyone else is moving ahead.
Perhaps the real problem is not that AI allows us to move faster. It is that we have started treating maximum speed as the only reasonable way to move.
I do not want to spend years on every project. I do not want to ignore useful tools or pretend that software development should remain unchanged. But I also do not want every unfinished idea to feel like a failure or every slow experiment to feel like time lost.
I want there to be room to build something without having to turn it into a trophy. I want to learn without immediately converting that learning into proof that I am moving forward.
Most of all, I do not want the part of software development that I love to become the very thing that makes me feel as though I am falling behind.
