Less Coding, More Big Dreaming
Less Coding, More Big Dreaming Earlier this week I read I Can Fix the Bug. I Can't Fix the Fear of Becoming Irrelevant by Abhijit Rana, and it's stuck with me ever since. As developers, we're used to adjusting. New fr
Less Coding, More Big Dreaming
Earlier this week I read I Can Fix the Bug. I Can't Fix the Fear of Becoming Irrelevant by Abhijit Rana, and it's stuck with me ever since.
As developers, we're used to adjusting. New frameworks, new tools, new ways of working. It's pretty much constant. But what happens when the adjustment means you don't actually write code any more?
Remember that thrill when you finally got something working? No more errors. You spin it up and it just works. Where's that gone?
The thrill has moved
I've been thinking about this a lot, and I reckon the thrill hasn't gone. It's moved.
I've hardly written any code recently. I've reviewed thousands of lines of it, but none of it was written by me. Claude does the heavy lifting.
So what do I actually do now?
I learn how to make Claude the best fit for whatever I'm trying to do. I look for ways to make it faster and better, to get the most out of it, and I chat to other folks who are trying to do exactly the same thing.
Finding the right tools
I'm also trying out different tools to see what works for me and the team I work in.
I started off with the Claude CLI and a load of tabs. Now I'm swapping between Claude Desktop and Kepler from GitKraken. Both are really good at what I need, which is a way to organise my worktrees and keep track of what the heck I'm actually doing. I just haven't settled on a favourite yet.
Making life easier for the team
On top of the tools, I'm trying to make life easier for myself and my team.
I've now got Jira and GitHub connected to Claude. Claude reads my tickets and moves them across the board as the work gets done. It writes test scripts for QA, so they've got detailed manual tests that tell them exactly how to test that specific new feature. PRs get created automatically too, and the descriptions are kept up to date so whoever is reviewing hopefully understands the changes better.
Sounds great, right? It is. But there's a lot of work going into making it all genuinely useful while keeping it feeling human, if that makes sense.
The PR descriptions are kept human readable. I'm putting things in place so there's consistency across the team in how Claude writes and reads our spec documentation. Harrie and I have put a load of work into the initial spec files, and that's turning out to make a massive difference to how Claude works on the project.
So, should I be scared?
Maybe being a developer isn't about the code we write any more. Maybe it's about building better solutions, ones we could only have dreamt of in the past, in half the time.
Does the future scare me? Possibly, a bit. But I'm also excited to see what's possible. I think I just need to change how I see my job.
Less coding. More big dreaming.
The point
If you're feeling that same fear Abhijit wrote about, here's what I'd say. The skill hasn't disappeared, it's moved. The code matters less. What matters now is everything around it: the specs, the context, the conventions, making sure what comes out the other end is something a human actually wants to read.
The single biggest improvement I've seen didn't come from a clever prompt or a new tool. It came from Harrie and me sitting down and writing decent spec files. That's still developer work. It's just a different kind.
So don't fight it. Learn it, shape it, and make it work the way your team works.
And it's been a lot of fun. I recently built two new projects that I'd never have dreamt of taking on before. Both of them, combined, in less than a week.
I'll write about them both soon.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.