AI Can Make You Faster. It Can't Make You Senior.

AI can make you faster. It cannot make you senior.

That probably sounds strange when coding agents can generate features, investigate bugs, plan architectures and chew through work that would have taken an engineer considerably longer only a few years ago.

But I think we have started confusing how quickly somebody can produce code with how experienced they are as an engineer.

Those are not the same thing.

AI has changed how quickly we can work. It has changed how quickly we can investigate unfamiliar systems. It has changed how much work one engineer can have moving at the same time.

What it has not changed is what experience actually gives you.

The Tools Are Starting to Matter Less

We have had a good couple of years now where tools such as Codex, Claude, Copilot, Cursor and the various agentic development tools around them have been evolving at a ridiculous pace.

For a while, every few months felt like another massive jump. One tool could suddenly edit multiple files. Another could run a terminal. Another could investigate a repository. Then everybody else caught up.

That gap is starting to mellow out.

There are obviously still differences between models, interfaces, pricing and how well particular agents behave, but the broad capability is becoming fairly normal: investigate the code, make a plan, change things, run tests and report back.

The more interesting difference now is not necessarily which AI tool an engineer uses.

It is how the engineer uses it.

Companies are still all over the place on this. Some organisations are actively paying for enterprise AI tooling because they want employees accelerated by it. Others leave it entirely to individual engineers. Some still want nothing to do with AI at all.

I think completely ignoring it is a mistake.

You do not have to use the jackhammer, but if everybody around you has stopped using a pickaxe, it is probably worth understanding why.

That does not mean blindly putting AI into every workflow. There are plenty of things we were promised AI would do brilliantly that it still does badly, inefficiently or with far too much confidence.

But even if you decide not to use it, I think an engineer should understand what it can do.

I treated technologies like JavaScript, .NET and C# the same way throughout my career. I did not have to be actively developing with every technology to understand where it fitted, what it was good at and what trade-offs came with it.

AI should be treated like another capability in the toolbox.

What Actually Makes Somebody Senior?

This is where titles get messy.

I know engineers who became senior within two or three years. I also spent a surprisingly large chunk of my career without the senior title despite feeling that I had been operating at that level for years.

Seniority is subjective because companies measure it differently.

Some measure technical depth. Some care about ownership. Some care about leadership. Some care about business impact. Some seem to care primarily about whether there happens to be a vacant Senior Software Engineer position on the organisation chart.

So I do not think years alone make somebody senior.

What those years can give you is experience to draw from.

My own career has thrown a fairly strange collection of technologies at me. At work I have moved through WinForms, SOAP APIs, classic ASP, ASP.NET, MVC, Razor, WCF, Xamarin Forms and .NET MAUI, along with microsites, REST APIs, GraphQL, Event Hub and other integration-heavy systems. Outside of work, the main technologies I deliberately picked up for myself were React Native and Node-based web apps and APIs.

The useful part is not that I can put a long list of frameworks on a CV.

Half of those technologies have moved on, been replaced or become something I would rather not voluntarily build a new system with.

The useful part is that after enough of them, a new technology stops being entirely new.

You start recognising the shapes.

You have seen dependency injection before. You have seen event-driven systems before. You have seen APIs designed well and APIs designed terribly. You have seen frameworks promise to solve a problem and then watched the abstraction leak all over the application six months later.

So when another technology arrives, you are not starting from zero.

You are comparing it against everything you already know.

That, to me, is one of the biggest differences between a graduate and a senior engineer.

The difference is not just what you have learned. It is what you can do with what you have learned when you encounter something new.

Graduates See the Ticket. Seniors Start Seeing the Business.

There is another part of becoming senior that has very little to do with code.

When you start working professionally, it is incredibly easy to see your job as a sequence of tasks.

Here is the ticket. Here is the acceptance criteria. Here is the application. Make the change. Raise the pull request. Move onto the next thing.

That is completely understandable because learning to work inside a real software team is already a lot to take in.

Over time, though, you start seeing what is behind the ticket.

Why does the product exist?

Who pays for it?

Why is this feature more important than the technically more interesting thing sitting next to it in the backlog?

Why does the product owner keep pushing for a particular deadline? Why is the business analyst asking that annoying question about an edge case? Why is somebody refusing the beautifully engineered solution because it costs three months of development to solve a problem worth a few thousand pounds?

Eventually you realise the software is not the business.

The software is doing a job for the business.

That changes how you engineer things.

You start temporarily putting on other hats. You think a little like a product owner. A little like a business analyst. Sometimes like QA. Sometimes like an architect. Sometimes like the poor person who will be supporting the thing at two in the morning when the clever abstraction you created decides it has had enough.

That broader context is difficult to teach from a tutorial.

It usually comes from being involved in enough projects, companies, failures, migrations, releases and slightly uncomfortable meetings to understand that the technically perfect answer is not always the correct answer.

Then AI Arrives

This is where I think things get genuinely interesting for graduate engineers.

AI can accelerate a huge amount of the journey.

It can explain an unfamiliar pattern. It can investigate a repository. It can compare two approaches. It can review your code and point out things you have missed. It can challenge an architecture. It can help you prototype something you have never built before.

That is an extraordinary learning tool if you use it that way.

It is also an extraordinary way to skip learning if you use it badly.

If every unfamiliar problem becomes a prompt followed by accepting whatever code appears, you are getting faster at producing software without necessarily getting better at engineering it.

A senior engineer can fall into exactly the same trap, by the way.

The difference is that experience gives you more things to challenge the output against.

When an agent proposes an architecture, I am not only asking whether it compiles. I am comparing it against systems I have built before, production problems I have seen, conventions in the current codebase and what the business is actually trying to achieve.

AI gives me another opinion incredibly quickly.

Experience helps me decide whether that opinion is useful.

I Use AI for Far More Than Coding

AI is probably involved in around 80% of my working process now.

That does not mean AI writes 80% of my production code.

That distinction matters.

I use it for investigations. Planning. Architecture. Questioning assumptions. Prototyping. Comparing technologies. Exploring a codebase. Working through possible causes of a bug before touching anything.

Sometimes the best thing an agent gives me is not code at all.

It gives me a better question.

This is also where I think engineers who are uncomfortable with AI can start without immediately handing production development over to an agent.

Ask it to investigate something.

Ask it to review some code and give you three theories about what is wrong.

Ask it to create a plan, then close the agent and implement that plan yourself.

You still get the acceleration without giving away the part of the process you want to practise.

Build Tools Before You Let It Build the Product

Internal tooling is another area I think gets overlooked.

A business does not only benefit from AI when an agent writes customer-facing production code.

It can create QA tools. Test-data generators. Scripts for standing up environments. Migration helpers. Validation utilities. Internal dashboards. One-off investigation tools. Automation around repetitive engineering work.

Those things can make the team faster without immediately putting generated code into the critical path of the product.

For a graduate engineer, that can be an excellent place to experiment.

You get to work with the agent, review what it produces, understand the mistakes it makes and build something genuinely useful for the team.

For a senior engineer, it is leverage. Instead of spending half a day doing a repetitive investigation, I can potentially spend that time on the part of the problem where my experience actually matters.

AI Does Not Remove the Ladder

I do not think AI makes senior engineers redundant.

I also do not think it magically turns graduates into seniors.

What it can do is compress some of the feedback loops that used to take much longer.

You can investigate more technologies. Explore more approaches. Prototype more ideas. Ask more questions. Get feedback on your thinking before you commit three days to an implementation.

That gives a graduate an opportunity to accumulate understanding faster than engineers in my generation could.

But the important word there is understanding.

The goal should not be to become the engineer who can generate the most code.

The goal is to become the engineer who understands enough about the technology, the product and the business to know what should be built in the first place.

AI can help you get there faster.

It cannot decide that you have arrived.