AI Made Me a More Productive Developer. I’m Still Figuring Out Whether It Made Me a Better One.

I spent around five years working with WordPress before I landed my first proper software development role at InSky Solutions. At the time, I thought I knew quite a lot about web development. I’d worked on countless websites, dealt with plugins, hosting, databases, custom functionality and all the usual problems that come with maintaining websites for real businesses.

I was fairly confident in what I knew, and then I started working with .NET and Microsoft Dynamics 365.

That was quite an eye-opener.

Suddenly, I was working with enterprise applications, integrations, APIs, business processes and systems that needed to communicate reliably with one another. There was a whole world of software engineering that I hadn’t really experienced through WordPress, and I loved discovering it.

I remember working on an integration between Dynamics 365 and a hotel reservation system that exposed an XML-based SOAP API. We had to consider customer records, reservations, synchronisation, existing data, error handling and the limitations of the third-party provider. We built an IIS-hosted integration service, with a Windows Service running the synchronisation every five minutes because the external system couldn’t provide reliable event notifications.

It was the sort of project where you had to understand the problem, work through the limitations and figure out how to make everything fit together. I learnt an enormous amount from that experience, and there was always something else I wanted to understand.

I felt like I’d moved from being comfortable with websites into a much bigger field, and I was still finding my feet.

Then AI changed how I worked

Over the last couple of years, AI-assisted development has become a central part of my everyday workflow.

These days, when I receive a project specification, I’ll often start by discussing it with ChatGPT. I’ll go through the requirements, consider different approaches, raise ideas of my own and ask questions about the technologies or architecture we might use.

Sometimes I’ll bring Grok or Gemini into the discussion as well, particularly when I want another perspective on a decision.

I’ve also become quite conscious of how agreeable these tools can be. If I suggest an approach and receive a very convincing explanation of why it’s a good idea, I still have to ask myself whether the reasoning is sound or whether the model is simply following my lead.

Once I’ve settled on an approach, I’ll work on the implementation instructions and context for Cursor. Depending on the project, that might include setting up a GitHub repository, configuring GitHub Actions and arranging automated deployment to a test or staging environment.

Sometimes that’s a relatively simple FTP deployment. Other times it’s a Docker-based application hosted on something like Fly.io. The technology varies, but I like having a workflow where changes can be committed, tested and deployed consistently.

Cursor then handles a substantial amount of the implementation, often including tests, fixes and subsequent iterations.

The amount of software I can build this way is remarkable.

I’ve worked on custom BigCommerce applications, integrations with business systems, WordPress plugins and native Android applications. I’ve been able to explore technologies that I probably wouldn’t have had the time or confidence to tackle independently a few years ago.

Building an Android application over a weekend can feel like taking part in a game jam or hackathon with considerably more resources available to you.

I’ve always joked that if you can think of something, we can probably build it. We just have to figure out how.

AI has made that attitude feel more realistic than ever.

But something else changed along the way

As AI took on more of the implementation work, I gradually became less involved in writing the code myself.

At first, that seemed like a natural progression. If a tool could implement a feature, run tests and help resolve issues faster than I could manually, it made sense to use it.

And I still believe it does.

The difficulty is that writing code was also how I learnt.

When you’re working through an unfamiliar language, debugging a problem or trying to understand why a particular implementation isn’t behaving as expected, you gradually build knowledge that stays with you. You learn the syntax, recognise patterns and become more familiar with the decisions that experienced developers make almost instinctively.

When an AI agent handles much of that process, you can reach a working result without necessarily going through the same learning experience.

I’ve noticed that in myself.

I can plan an application, work through its requirements, coordinate implementation and test the finished functionality, but I don’t always have the same familiarity with the internal code that I would have had if I’d written it myself.

And while I’ve gained experience across a much wider range of projects, there are areas of software architecture that I still want to understand much more deeply.

For example, I understand the general differences between a monolithic application, a modular monolith and microservices, but I haven’t always had the opportunity to make those decisions in a professional environment and experience their consequences over time.

That sort of judgement comes from more than reading definitions. It comes from building systems, maintaining them, seeing where decisions cause problems and understanding why another approach might have worked better. It’s closer to the habits I’m learning to value in senior engineering than to the speed of a first green pass.

I sometimes feel as though AI arrived while I was still progressing from junior towards senior-level engineering, and suddenly the way I was learning changed.

My productivity continued improving, but I wasn’t always sure my technical understanding was progressing at the same rate.

How much should a developer understand?

This is the question I’ve been thinking about most recently.

If I use Cursor to build an application, what exactly am I expected to understand about the result?

I certainly need to understand the business requirements, how the application behaves, what data it processes, how it integrates with other systems and whether it does what it’s supposed to do.

But how deeply should I know every class, function, dependency and implementation detail?

Nobody realistically reads thousands of lines of generated code like a novel and remembers every part of it. Equally, I don’t think it’s reasonable to accept an application’s behaviour simply because an AI agent says everything is working. I’ve already watched a control pass its tests and still do nothing when clicked.

When I work with something unfamiliar, I already ask Cursor to produce two forms of documentation.

One is written for me, explaining the architecture, important components, dependencies and how the application works. The other is more technical context that I can give to ChatGPT for further discussion or use when planning future changes.

I often approach this by imagining that I might have to defend the application in a technical review. If somebody asked why it was designed a particular way, how it handles failures or what would happen under different conditions, could I explain it?

That has helped, although I still think the industry is working out where the boundaries of responsibility should sit when agents are generating substantial portions of our software.

I don’t believe developers need to memorise every line of code. We never did, really. There was a reason Stack Overflow became such a familiar part of development, and I’m fairly sure the joke about experienced developers searching for how to centre a div will never completely disappear.

But being able to find an answer and being able to evaluate whether that answer is appropriate are two different skills.

The same applies to AI-generated code, only now the tool can implement the entire solution before you’ve had much opportunity to question it.

Finding a better balance

I have no intention of giving up AI-assisted development.

It’s become too useful, and I genuinely enjoy working this way. The variety of applications I’ve been able to develop and the speed at which I can explore new ideas have made software development exciting in ways I wouldn’t have imagined a few years ago.

What I want to change is how deliberately I learn from that work.

I’m spending more time understanding the architecture behind the applications I build, the reasoning behind technical decisions and the verification needed before something should be considered complete.

I want to be more confident discussing reliability, data consistency, security, testing, deployment and the trade-offs between different approaches.

I also want to become better at challenging the recommendations I receive from AI tools rather than accepting a well-written explanation as evidence that a decision is correct.

Longer term, I’d love to help other development teams adopt AI-assisted workflows effectively. There’s a lot of potential in combining experienced engineering teams with tools that can accelerate implementation, documentation, testing and experimentation.

But to help other developers use those tools responsibly, I need to keep improving my own understanding of the software they’re helping me produce.

I still have plenty to learn, and perhaps that’s the part of my earlier development experience that I most want to recover.

I used to enjoy spending hours figuring out how something worked, why it failed and how to improve it. AI has made reaching the finished result much faster, but I don’t want to lose the curiosity and understanding that made the process enjoyable in the first place.

I’m building more software than I ever have before. Now I want to make sure I’m growing as an engineer alongside it.