DEV Community: Antonio Di Pinto

Stop Running

Antonio Di Pinto — Fri, 07 Aug 2026 11:06:30 +0000

I am 35 and I just caught myself forgetting what software development actually is.

Not the job title. Not the stack. The thing itself. For about ten years I lived inside the usual noise: monolith versus microservices, this language versus that one, this framework versus the next rewrite. Useful debates sometimes. Mostly theater.

Then AI arrived, and the theater got louder.

From CryptoBros to AIBros

We watched the CryptoBros rebrand almost overnight. Same energy, new vocabulary. Suddenly everyone was a software expert, a marketing expert, an AI expert. The feed filled with launches, screenshots, and urgency.

I felt the pressure even when nobody asked me to. Create the new SaaS. Create the new game. Create the new whatever. Fast. Come on. Rapidly. You are already late. Make it faster.

That pressure does not look like a manager standing over your desk. It looks like a timeline where everyone else appears to be shipping while you are still thinking. Indirect force is still force.

Thanks to that, I lost interest in programming. In solving problems. In the small joy of discovering a new language and feeling my brain stretch around a different model of the world.

What is left when the LLM writes it

What is the real difference between PHP and C++ when your job shrinks to explaining what you want to a language model?

I do not ask that as a joke. I ask it because for a while the answer felt uncomfortably close to “not much, if you only care about output.” And if that is true, then the craft collapses into prompt quality and shipping speed. That is a thin life for anyone who once loved building software.

So I had to dig back to something older than the current wave.

Solving problems, not performing solutions

I rediscovered that I need to focus on solving problems. Not AIBros-type problems. Not “build a website for the tyre shop, cold call the owner, show a demo, get paid.” That story is lame. It is not true in the way it gets sold. Only people without enough real-world scars believe it that easily. The same people who, four years ago, fell for the pump and dump.

The wrong mindset is creating something in order to sell it.

Nothing is sellable by default. Need makes something sellable. And how do you understand a need? You experience it. You live inside the friction long enough that the missing piece becomes obvious. Inventing a product first and hunting for buyers later is backwards. It turns software into inventory.

Software is the tool

Of course we can talk about software philosophy. Data structures. Performance. The quiet satisfaction of ordering fields in a class so the shape of the system feels honest. We can write books about that, and sometimes we should.

But that is not the center for me anymore.

My main interest is solving problems. Software is the tool. Sometimes the right tool is a small script. Sometimes it is a careful system. Sometimes it is not software at all. The moment the tool becomes the identity, you start optimizing for looking busy in public instead of removing pain in private.

Years of SaaS mythology

Years of SaaS bros trained a lot of people to believe that “having a solution” is the whole game. Ship the wrapper. Add the landing page. Announce the waitlist. Call it a company.

That is not the truth.

A solution without a real need is cosplay. A need without the patience to understand it is guessing. The hard part was never generating another product idea under artificial urgency. The hard part was always noticing what actually hurts, staying with it, and building the smallest honest response.

Stop running

So this is the motto I am keeping: stop running.

Stop running after the next launch narrative. Stop running after every model release as if missing a weekend means missing a decade. Stop running after the feeling that everyone else already built the thing you were vaguely thinking about.

Slow down enough to remember why you opened an editor in the first place.

I still use AI. I still ship. I still care about languages, architecture, and craft. I just refuse to let the pace of strangers redefine what my work is for.

If there is no need I have felt, I am not building a product to prove I am still in the race.

I am stopping. On purpose.

The Lost Art of Reading Documentation

Antonio Di Pinto — Wed, 05 Feb 2025 16:11:08 +0000

I’ve been a web developer for over 10 years, primarily working on backend systems, APIs, and databases. I’m not an “anti-AI” guy, I use AI every day for coding, and even for things like fixing grammar in this article. I wanted to write this article for nearly six months or so, but for some reason, I kept putting it off. Today, I finally sat down to do it.

I’ve always enjoyed reading documentation. In Vim-like editors, a simple gd (go to definition) is often all it takes to dive into the heart of a function. That, in my opinion, is the best way to truly understand how a framework or software works. It also allows you to see how another developer approached a particular problem. This article is about my experience and perhaps it won’t resonate with everyone, but if it does, maybe it’s time to reconsider how we interact with code.

The AI Revolution

In 2020, OpenAI launched something that felt like science fiction to most of us, an LLM capable of mimicking human conversation. It was WOW!. Developers rushed to build wrappers, integrate ChatGPT into their applications, and enhance their software with AI-powered features. AI became the new SEO buzzword and a magnet for VC funding.

This era brought a surge of AI-powered development tools. GitHub introduced Copilot, and alternatives like Cursor, a fork of VSCode, emerged and many more. It felt like a new industrial revolution. An era where you could ask a virtual developer to fix a bug or simply start typing and have the code complete itself, as if by magic.

At first, everything seemed great. That is, until I noticed something strange happening in my own workflow.

The “TAB TAB TAB” Syndrome

One day, as I was writing code, I realized something off. Instead of thinking through my logic, my workflow had shifted from actual problem-solving to compulsively pressing TAB TAB TAB TAB. I wasn’t actively coding anymore, I was just letting the AI generate everything for me.

That moment was a wake-up call. I realized I was no longer enjoying the process of coding. The thinking, debugging, and problem-solving. The creative, intellectual challenge that made programming exciting had started to disappear.

So I decided to conduct an experiment: I turned off AI-assisted coding for two weeks.

Rediscovering the Joy of Coding

The first day was tough. Breaking the habit of waiting for AI suggestions was harder than I expected. By the second or third day, I found myself reaching for Google again, checking documentation, and manually implementing solutions.

Then came another revelation, I wrote the same feature twice, but this time, I understood why I wrote it that way. I grasped the underlying logic, the reasoning behind the decisions. It felt like my brain was waking up, neurons and synapses firing in a way they hadn’t in months.

I started enjoying coding again. I found inspiration in content from developers like @DevAsLife, whose videos not only have stunning visuals but also showcase deep dives into code. Unlike the flood of “Build a SaaS in 2 Days While Sleeping!” content, his approach resonated with me.

Another creator, @Tsoding, his content reminded me that true understanding comes from engaging with code, not just consuming AI-generated snippets, this guy uses Emacs, no Intellisense, just pure skill. And then there’s @HusseinNasser, who explains the inner workings of databases like PostgreSQL, dissecting why a SELECT statement behaves a certain way. These are the creators we need, people who champion understanding over shortcuts. And last but not least, @ThePrimeagen, whose hilarious content makes learning fun while showcasing his mastery various programming languages, all thanks to his rock-solid grasp of the fundamentals. I can’t thank Salvatore Sanfilippo (@antirez), the creator of Redis, enough for his contributions to open source and his deep critical thinking about the software industry.

A Look Back: When Documentation Was King

I remember being 15 (18 years ago 🥲) and learning PHP. Stack Overflow wasn’t as big yet, and finding answers often meant digging through forums filled with half-baked solutions, each dependent on specific hosting configurations. There was no universal standard, some hosts supported certain php.ini settings while others didn’t. The only reliable resource? The official PHP documentation: php.net.

Finding Balance

I still use AI in my editor, but I’ve redefined how I interact with it. When I need to build something quickly, I’ll let AI assist me. But for at least 50% of my projects, I now choose to enjoy the process of coding.

If I’m hacking together an MVP for a quick experiment, sure, I’ll “TAB” my way through it. But if I want to grow as a developer and truly understand my craft, I turn back to the fundamentals: documentation, debugging, and deep thinking.

Because in the end, if all you do is press TAB, you’re just another operator, not a developer. And that’s not why I fell in love with coding.