28 September 2026
The Byproduct Nobody Put On the Roadmap
As a developer, I’ve watched AI change the way I work in ways I couldn’t have imagined a few years ago.
I can generate code in seconds, get help debugging a stubborn issue, explore an unfamiliar framework, or build a working prototype without spending hours searching through documentation. Things that once took me an entire afternoon can sometimes be done in minutes.
And honestly, I love that.
I enjoy spending less time on repetitive work and having more room to focus on solving problems. I like being able to explore ideas quickly, learn about technologies I haven’t used before, and get past the parts of development that used to slow me down.
But there’s something about this shift that makes me pause.
Am I becoming a better developer, or am I simply becoming better at getting code written?
It’s a question I think more of us should ask ourselves. Because while AI is helping us get things done faster, I wonder whether we’re paying enough attention to what happens to our skills along the way.
If you’ve watched Suits, you probably remember Mike Ross. He has an incredible memory and can absorb information almost instantly. But knowing so much doesn’t automatically give him the experience and judgment that come from years of practising law.
Donna Paulsen brings something different to the table. She understands people, reads situations, and notices details others miss. Her strength isn’t just what she knows. It’s how she applies that knowledge.
I see a similar distinction in software development.
AI can generate a function, build an API endpoint, or suggest a fix for a bug in seconds. Sometimes, the solution is better than what I would have written myself. Other times, it looks right but hides a problem I might not notice until much later.
The important question isn’t just whether the code works. It’s whether I understand why it works, where it might fail, and whether it’s the right solution for the problem I’m trying to solve.
I’ve come to appreciate that writing code and understanding code are two different things.
Understanding comes from more than reading a solution. It comes from debugging, experimenting, making mistakes, reading documentation, and spending enough time with a problem to recognise patterns you wouldn't have noticed before.
The challenge with AI is that it makes it incredibly easy to skip parts of that process.
When a solution appears almost instantly and looks convincing, it’s tempting to accept it, move on, and enjoy the progress. With deadlines to meet and features to ship, I can understand why.
But if I keep taking that shortcut, I have to ask myself what I’m missing along the way.
One related concept is automation bias: our tendency to trust recommendations from automated systems, sometimes even when we have reasons to question them.
In development, that might mean accepting an AI-generated solution because it looks familiar, passes a basic test, or saves me from investigating an issue myself.
The danger isn’t that AI is always wrong. It’s that I might become less practiced at recognising when it is.
When I use AI to speed up development, the benefits are easy to see.
I can complete tasks faster, explore more approaches, and spend less time on repetitive implementation. If I’m working with a team, that efficiency can help us deliver more without constantly increasing the workload.
But there’s another side to the equation that’s harder to measure.
What happens to the skills I would have developed if I had worked through the problem myself?
Imagine I ask AI to build an authentication system. It generates the code, the interface looks right, and the basic tests pass. I integrate it, close the task, and move on to the next feature.
From a delivery perspective, everything looks good.
But can I explain how the authentication flow works? Do I understand how sessions are managed, how tokens are handled, and where security vulnerabilities might appear? If the implementation fails under an unexpected condition, can I investigate and fix it without asking AI to generate another solution?
If I can, AI may have helped me work more efficiently.
If I can’t, I may have delivered something I’m not fully equipped to maintain.
And that gap might not become obvious today. It could appear months later when the requirements change, a security issue emerges, or a production bug sends me back to code I barely remember reviewing.
That’s the cost I worry about: not necessarily a mistake in the code, but a gap in my own understanding.
There’s no ticket for a skill I didn’t develop. No metric tells me I’ve become less comfortable solving a particular class of problems independently. And no warning appears when I start depending on a tool for things I used to understand myself.
I’m not saying every line of code deserves to be written manually. That would defeat much of the value AI brings.
I’m saying that when I save time by letting AI do the work, I should be conscious of whether I’m also giving up an opportunity to learn something important.
I think about this most when it comes to junior developers and people entering the profession.
When I was learning to code, understanding a concept often meant struggling with it for a while. I would write something that didn’t work, search for an explanation, try a different approach, and sometimes discover that I had misunderstood the problem entirely.
It could be frustrating. Sometimes, I wanted someone to give me the answer and let me move on.
But those moments taught me things that went beyond the immediate task. They helped me understand how different parts of an application fit together, how to approach unfamiliar problems, and how to recognise mistakes before they became bigger issues.
That experience is part of learning the craft.
Today, a junior developer can ask AI to generate a component, explain a framework, or solve an assignment in a matter of seconds. That can be incredibly useful, especially when there isn’t an experienced developer nearby to help.
But there’s a difference between using AI to understand a solution and using it to avoid understanding the problem altogether.
If I ask AI to explain a piece of code, challenge its approach, and then try to implement the solution myself, I’m using it to learn.
If I simply copy the code because it works, I might finish sooner without developing the skills that task was supposed to build.
Both approaches can produce the same result on the screen. They don’t necessarily produce the same developer.
And this isn’t only a concern for beginners. Even experienced developers can fall into the habit of accepting convincing answers, particularly when deadlines are tight or the technology is unfamiliar.
Experience helps me recognise problems, but it doesn’t make me immune to taking shortcuts.
The good news is that AI can be an excellent learning partner. I can ask it to explain unfamiliar concepts, compare alternative approaches, identify weaknesses in my implementation, or help me understand why a particular bug occurs.
I can also ask it questions I might otherwise spend hours researching.
The difference is in what I do with the answers.
Instead of asking AI to solve every problem, I can ask it to help me reason through one. Instead of accepting the first solution, I can ask what alternatives exist and what trade-offs each one introduces. And after receiving help, I can challenge myself to explain the solution without relying on the generated response.
That extra effort might feel slower in the moment, but it can make me more capable the next time I face a similar problem.
For me, that’s the distinction worth protecting.
I don't want to become a developer who knows how to prompt a tool but struggles to explain the code it produces. I want to become a developer who uses the tool to deepen my understanding and expand what I can do.
Do I think developers should use AI for more of their work?
Absolutely.
I don't believe being a good developer means writing every line from scratch, memorising every API, or refusing help when it’s available. Software development has always involved tools, abstractions, libraries, and the work of other people.
AI is another tool, and pretending otherwise won’t help us.
It can generate boilerplate, suggest tests, help investigate bugs, explain unfamiliar codebases, and make it easier to explore different solutions. Used well, it gives me more time to think about the parts of development that actually require my attention.
The distinction I keep coming back to is this: I can delegate the execution of a task without delegating responsibility for its outcome.
If AI generates code, I’m still responsible for understanding what I ship. If it suggests an architectural decision, I need to consider whether that decision fits the product, the team, and the system we’re building. If it proposes a quick fix, I need to think about whether that fix solves the underlying problem or simply hides it.
The same principle applies beyond writing code.
As developers, we’re not just producing files that compile. We’re helping build products that people depend on. Those products have users, business requirements, security considerations, operational constraints, and consequences when things go wrong.
AI can help me navigate those challenges, but it cannot remove my responsibility to consider them.
I think teams have a role to play here, too. We should create an environment where developers can question generated code, discuss their decisions, and learn from mistakes without feeling that speed is the only thing being measured.
At Awesomity, building useful digital products involves more than delivering code. It means understanding the problem, making sound technical decisions, and building software that works reliably in the real world.
AI can help us do that better. It can help us explore more options, challenge assumptions, and move through implementation faster.
But the quality of what we build still depends on the judgment of the people guiding the process.
And I don't want us to lose sight of that just because the tools keep getting better.
There’s a question I think is worth asking whenever I reach for AI:
Am I just trying to finish this task, or is there something here I should learn?
Sometimes, I simply need to finish the task. Not every routine
