The fantastic Kirstin, one of our awesome full-stack developers gives us her thoughts on how The Developer Role Is Being Rewritten.
When I first started my computer science degree, I was almost convinced I had made a mistake.
The world of computing felt enormous and intimidating. Every module in my first two years introduced another corner of the industry I barely understood: networking, security, media technology, game development, natural language processing, system architecture, programming elevators (?!!). It felt like stepping into a world where everyone else already knew the rules, and I was supposed to just get it.
Programming didn’t come easily at first for me. I struggled with it more than I expected. For a while I genuinely thought I might have to drop out because I just wasn’t wired the same way as the people around me.
Then at some point, in my second or third year, I noticed that something had clicked. The logic started to feel intuitive. Instead of fighting the code (and another breakdown), I began to understand how the pieces came together. Small experiments turned into projects, and before long, I was building my own apps just to see if I could. I remember thinking to myself, “I can build anything.”
That feeling is still one of the things I love most about software development.
At the same time, I didn’t exactly fit the stereotype of the hyper-focused engineer. My attention span in lectures was… inconsistent. My university friends can confirm that I managed to doze off in more lectures than I stayed awake in. But wasn’t boredom or lack of interest (although a 3-hour lecture about the history of network security was exhilarating) – I needed something that would hold my attention.
Development gave my brain exactly what it needed. A target.
There was always a problem to solve and a deadline to meet. The moment there was a goal, my focus would snap into place. Instead of forcing myself to concentrate, I wanted to. My brain seemed to enjoy the chase of figuring something out and making it work.
But problem-solving in software can also be mentally demanding. First, you have to understand the problem properly – why it exists, how it happens, and whether it should even be solved in the way you’re thinking. Then comes implementation, writing tests, and ensuring everything still follows best practices.
Along the way, there’s the familiar routine of working through pages of documentation, searching for examples, and digging through Stack Overflow to see how others approached something similar – all the while running into the kind of unhelpful responses that make you question your very existence.
Luckily for us, AI is here to help.
The way AI can now aggregate information from across the web, summarise large pieces of documentation into clear steps, and even allow me to “talk” to my own codebase as if it were another developer is something I never imagined being possible during my career.
Instead of spending hours searching for the right answer, I can explore solutions much faster. AI can handle some of the heavier lifting – generating starting points, helping debug issues, or surfacing relevant information while I continuously review, refine, and guide the outcome. Over time, as I refine how I work with these tools, it’s starting to make me more efficient, and give me something valuable back: time.
That extra breathing room now changes how I think about the work. Instead of spending all my energy pushing code over the finish line, I can step back more often and pay attention to parts of the process that didn’t always get the same focus before. AI can help with the first pass; suggesting implementations, filling in gaps, or exploring different approaches.. and then I can step in to shape it. Review it, question it, refine it, and make sure it actually fits the spec. It means I can spend more time making things robust, improving the user experience, and adding the details that make a product feel complete.
There are still trade-offs. It’s easy to lean on AI, and it’s not always reliable – small inconsistencies or unexpected mistakes can creep in, and the fact that it doesn’t always produce the same result twice is concerning. It still needs human intervention, someone to guide and supervise it.
In that sense, AI isn’t replacing developers. It’s expanding what we have the capacity to do – less time wrestling with the mechanics, and more time thinking about systems, ideas, and better ways to solve problems.
And for someone who has always enjoyed the creative side of building things, that shift feels less like disruption and more like a progression. There’s still a long way to go with AI, but it’s hard not to be curious about where it leads – and how much further it can push the quality of what we are building.
