How To Keep Up With AI Coding Technology
I think a lot of developers are quietly afraid right now. Not because AI is going to replace them tomorrow. Most experienced developers don’t actually believe that.
The fear is more subtle than that. They’re afraid of getting left behind.
Afraid they’re learning the wrong tools.
Afraid they’re building the wrong way.
Afraid that younger developers are adapting faster.
Afraid that everyone else secretly understands all of this already.
I feel that pressure too.
I use Claude Code CLI constantly. Every day. At this point I can’t imagine building software without it. I’m dramatically faster than I was a year ago, and the amount of experimentation I can do now is honestly kind of incredible. I can build things in an afternoon that I wouldn’t have even tried a few years ago. Just look at my GitHub commit history over the last 9 months.
Talkin’ ‘Bout Practice
When I open Reddit, LinkedIn, BlueSky, Twitter, YouTube, even TikTok, suddenly I’m hearing about:
• new coding agents
• orchestration systems
• autonomous workflows
• MCP setups
• self-healing applications
• AI IDEs
• AI browsers
• AI terminals
• AI everything.
And every one of them is apparently “the future.” After a while, it starts to feel like keeping up with AI means continuously rebuilding your workflow forever.
I don’t think that’s true.
I think the developers who are adapting well right now are not the ones consuming the most AI content. They’re the ones building with AI consistently. That’s the entire game.
Not reading. Not watching demos. Not arguing online.
Reps. You need reps. The same way you learn almost anything else. You do not become a better golfer by watching YouTube videos about golf swings. At some point you need to stand over the ball and embarrass yourself for a while.
AI coding is the same thing. You need to build things. Not startup ideas. Not the next billion-dollar SaaS. Not some massive architecture astronaut project.
Solve a problem in your own house.
Maybe your family needs a better way to plan meals.
Maybe you want to track something like the number of times you turn off light switches.
Maybe you want a better view into your finances.
Those are the best projects right now because you already understand what success looks like.
That part matters more than people realize. A lot of developers are trying to learn AI by cloning products or following tutorials, but those approaches hide one of the hardest parts of software development: knowing whether the solution is actually good. When you solve a problem for yourself, you already have the validation layer built in.
You know whether the app is useful, whether the workflow makes sense, whether the UI feels frustrating, or whether the software is actually helpful, or just more work. That feedback loop is incredibly important when learning to work with AI.
Because AI can absolutely generate solutions. Sometimes surprisingly good ones. But somebody still needs judgment. Somebody still needs taste. Somebody still needs to know when the generated output is elegant versus fragile, maintainable versus dangerous, useful versus impressive-looking.
Ironically, this is why I think senior developers are undervaluing themselves right now.
I see a lot of experienced engineers looking at AI and quietly wondering whether their years of experience are becoming less relevant. I think the opposite is happening. Your experience is the thing making these tools valuable.
You know what questions to ask.
You know when requirements are incomplete.
You know when something is overengineered.
You know when the AI misunderstood the intent.
Someone with deep engineering experience can use AI to move incredibly fast because they already understand the shape of good software. Someone without that experience can generate an astonishing amount of slop very quickly.
And honestly, I think we’re already seeing that happen.
Delivering Value
Right now, there’s a lot of confusion around productivity in AI conversations.
People equate productivity with:
• more generated code,
• faster feature completion,
• one-shot demos,
• or “look what I built in six minutes.”
But none of that necessarily creates value.
I can generate a giant pull request full of AI code this afternoon. That doesn’t mean it survives:
• integration tests,
• production data,
• scale,
• security review,
• observability requirements,
• or real users doing unpredictable human things.
Real productivity is delivering value to users more quickly. AI absolutely helps with that. But nothing AI built in six minutes should go directly to production without expecting failure.
Failure is still where learning happens, though. One of the most valuable AI lessons I’ve learned came from trying to move too fast. At one point, it felt easier to give AI direct access to my development database instead of having it generate migrations that I would review and apply myself. That worked great right up until the database schema and the ORM became slightly mismatched. The AI decided the cleanest solution was to simply drop the database completely.
Thankfully, I had backups.
But watching your development database suddenly disappear definitely teaches you something about convenience versus control. That experience didn’t make me anti-AI. It made me more thoughtful about where humans still need to stay deeply involved. Because someone still needs to understand how the system works.
When a product owner asks: “Can users upload videos in addition to images?”, someone still needs architectural awareness.
Where does upload handling happen?
How does storage work?
What are the performance implications?
What changes in the API?
What breaks?
What scales poorly?
What affects cost?
AI can help implement the solution, but humans are still accountable for the outcome. That’s not a weakness of AI. Humans are always the ones to be accountable. It’s also one of the reasons that observability has become so important to my development workflow. I can identify those hidden issues that show up in latency before they’re in production. So when something fails, and it will, the fingers hopefully aren’t pointed in my direction.
Hype vs. Value
I also think developers waste enormous amounts of time chasing hype right now. Good marketing does not automatically equal good value. I’ve seen tools receive massive amounts of attention that, once I dug deeper, simply didn’t improve my workflow in any meaningful way.
The tools that matter are the ones that genuinely make you more productive while still allowing you to maintain understanding and control over what you’re building. That balance matters to me. I don’t want to become disconnected from the software itself.
And honestly, I think developers should absolutely pay attention to what other people are doing. Part of being a software engineer has always been committing yourself to continuous learning. You should read Reddit. You should follow developers on social media. You should pay attention to emerging workflows and ideas.
But you also need to learn how to distinguish hype from value. Look for the people that are actually building things in public. Look for the people sharing process instead of certainty.
Ask yourself: “Was this content created to share knowledge, or to drive engagement?”
Those are very different things.
The people I trust most right now are usually the ones showing unfinished work, explaining tradeoffs, discussing failures, and sharing lessons learned from actual implementation. Not the people pretending they’ve solved software development permanently because they chained six agents together in a demo video.
Back To The Future
I think AI tooling is going to mature dramatically over the next few years. A lot of capabilities that currently feel experimental will eventually become invisible defaults.
Self-healing systems. Automatic issue remediation. Generated pull requests. Observability-driven fixes. Architecture-aware tooling.
Much of that will simply become part of the normal development lifecycle.
I also think we’re going to see software UIs start looking increasingly similar to one another. AI-generated UI is often “good enough,” and many developers will stop investing deeply in thoughtful design because acceptable interfaces are now incredibly easy to generate.
I think that’s a mistake, but I think it’s going to happen anyway. And honestly, I suspect the next major shift after all of this is going to involve APIs and data access. As software becomes easier and easier to create, useful data becomes the bottleneck. The world is full of walled gardens right now.
But if everybody suddenly gains the ability to rapidly create custom software experiences, pressure will increase dramatically for systems and platforms to expose their data in more useful ways. That might end up being more transformative than the models themselves.
At the same time, I absolutely think developers will become dependent on AI tools. But humans become dependent on useful abstractions constantly.
Carpenters became dependent on power tools. Drivers became dependent on GPS. Pilots became dependent on guidance systems. The world became dependent on computers.
That’s progress! Not something to be avoided!
As long as these tools remain accessible and affordable, dependence is probably expected. And honestly, someday developers are going to look back at writing software without AI assistance the same way carpenters look back at building entire houses with only hand tools.
Not with shame. Just with disbelief.
“How did we ever do our jobs without this?”