The current state of play with AI

AI has changed engineering forever

AI is no longer autocomplete. It's gone so far beyond that in such a short space of time that I consider my AI agents more like a team of very eager and enthusiastic junior to mid-level developers who deliver extremely quickly.

A single experienced engineer can now direct the output of multiple AI "team mates" simultaneously, but that output still depends very heavily on the judgement of the engineer steering it if you don't want to produce "AI slop".

AI team mates are real but they still need senior engineers

In my humble opinion, modern AI agents (Claude Opus 4.7, GPT 5.5) are enthusiastic developers. They are capable, productive, and fast, but require a decent amount of guidance to stay on track and maintain engineering standards.

Without oversight they devolve into generating AI slop - subtle architectural mistakes, shortcut-driven implementations, and code that slowly descends into spaghetti. Without an experienced hand to guide and steer them AI can generate locally plausible code without necessarily understanding the wider system or goals.

Sometimes even on non-technical decisions, it'll deviate from what we're asking. Just the other day I was working through a feature on the doorstep family app, quite involved, a specification that's well over 1000 lines of markdown, with a clear plan. GPT 5.5 decided it would descope part of that plan "for version 1", I had to remind it what the definition of done was and ask it to finish the job. Those are the easy catches.

I've also caught both Claude (Opus 4.7) and GPT (5.5) implementing "good enough" shortcuts that aren't actually good enough. It can range from throwing a quick 20 line helper function in a weird file somewhere rather than considering where it lives properly, through to naïve implementations of queries which introduce hidden N^N+1 query patterns that would go un-noticed until it hit scale.

I've lost count of the number of times I've had to steer both models away from, frankly, quite shoddy practices. But honestly, that's no different from leading a human engineering team. We review code, guide people back onto better paths, and help less experienced developers avoid mistakes. AI team mates aren't fundamentally different, they're just faster.

Experience Is Becoming More Valuable, Not Less

I feel like a broken record repeating this daily, but AI isn't a silver bullet - it's excellent at generating code, but it still struggles with some skills:

• General overall application architecture and strategy unless very clearly documented.
• Coding with scalability front of mind
• Source tree structure and discipline
• Human readable code
• Long term maintainability - especially for us meat bags.
• When NOT to do something and when to ask for help.

A really great example of the last point there, was standing up a brand new project with Claude (4.6 at the time), where I wanted to use TanStack Start for a statically generated site.

It started based on the knowledge it had, but, TanStack is a fast moving project and its knowledge was out of date. After adding the latest npm package, and trying to apply it's knowledge, Claude realised things weren't working so then tried some other avenues. After a couple of iterations of that, it went to search for and fetch the documentation but for some reason, it was unable to get at the content it needed.

When it got to that point, it made some assumptions about how it might work, failed, tried again, failed, went back to the original way, failed, tried to get the docs again, failed.

It did this for about an hour, and as I was AFK, I wasn't aware it had got itself stuck in a loop. Instead of stopping and asking for help, it kept retrying outdated assumptions, and didn't recognise that each iteration was just a repeated failure.

When I returned I found it in this loop, stopped it and asked what it needed - it asked for the latest documentation from the docs site, I copy/pasted it into the context and the problem was solved 30 seconds later.

Claude in this case lacked judgement. It was more than capable of doing the task, provided it had some input from me, but instead of realising that and asking me what it should do next, it didn't seem to recognise that it was failing. It also burned through a significant amount of inference £££'s before I intervened!

A human, I'd hope, would raise their hands earlier there, or, if not, just like I intervened with Claude, I'd realise they are struggling and intervene - so again, it's not entirely different from working with a human team.

AI makes mistakes, it gets stuck, it tries to shortcut it's way through things for efficiency, and for that, it still needs a skilled engineer driving it. As we deliver more, faster, those senior skills, the earned stripes, the hard earned battle scars, the sting from the bite of inefficient code in production at scale, become more and more valuable, not less.

Which brings us to the point of this post - the tension between AI assisted development making things easy Vs Juniors being able to develop their own senior skills and judgement.

The AI Skills paradox

Skills from traditional battle scars

Up to now, engineers gained hard won experience at the coal face. Through a thousand small cuts from debugging painful issues, building manually, living through outages, learning from mistakes and accumulating those battle scars over the years, an engineer becomes more and more competent from those learnings, gaining important judgement skills they then reapply in future.

AI is increasingly removing that struggle. If AI removes the difficult path that created experienced engineers, how will the next generation develop those same skills when we retire?

Just last week, a friend of mine was showing something he'd created that's illustrative of this point.

He'd created a solution that leans on Claude to triage and deal with support tickets before a human gets involved.

The ticket comes in via Zendesk, Claude picks it up and reviews the problem and, provided it has enough context, it reads all the related product and technical documentation, cross references the log files for the customer in question, looks at all the telemetry, inspects all the appropriate areas of the source code and correlates everything together to arrive at a suggestion for how to proceed - relayed to the support person on the ticket.

Awesome! But it gets so much better - if it identifies a code issue, it's able to take all that information and hone in on the exact lines of code causing the problem, change it, and open a PR for review to get a fix out!

The impressive part is, on one particular ticket, it uncovered a significant performance issue that would have taken days for a human to get to the bottom of.

That's truly impressive, but also reinforces my point - the AI in that instance completely removed the learning opportunity that would have been gained by a human spending 2 days tracking it down. It's awesome it resolved it, got the PR opened etc and just needed some human review to get a patch out, but conversely it's arguable that no engineer actually gained the hard-won understanding that normally comes from spending two days tracing a production performance issue.

AI pushes toward consensus not experimentation

Beyond battle scars, intermediate engineers become senior, become staff, become principal, through judicious use of experimentation - trying new things and expanding their body of knowledge. One of the things I've noticed with both Claude and GPT is they tend to stick to the status quo - the things they know about already.

That's inevitable, they're trained to a certain point in time, so they'll lean heavily on that knowledge, but it lacks innovation and forward momentum. Using what works, being "boring" is good - but stagnation isn't.

To give a very basic example, I'm a big fan of TanStack Start. I use it for small projects like this site/blog, to create static sites, to create documentation portals and things like that. Unless I'm explicit when starting from an empty source directory, the models lean towards what they already know for this purpose - next.js - every single time.

Technology moves so fast that the most popular solution of the day is not always the correct solution for your problem. Experienced engineers experiment, learn, they understand context and trade-offs, whilst AI, I think it's fair to say, optimises towards consensus and popularity.

Seniors hold a respect for the status quo, boring is safe, boring is proven, but they also have a willingness to challenge it. Curiosity and experimentation are traits we need our juniors to develop to avoid stagnation - otherwise, every new project will start with Claude/GPT standing up a repo with next.js boilerplate and newer approaches largely going unnoticed.

Unwinding the paradox

What Juniors Should Do Now

I'd encourage any juniors out there to still continue to learn fundamentals properly. To read every line the AI generates, debug things manually, understand databases/networking/performance to a deeper level, ask "why" not just "what", and occasionally build things without AI assistance.

Experiment regularly, try out new tools, new frameworks - perhaps do that without the AI, so you develop a foundational breadth of knowledge first. Breadth is as important as depth.

Use AI to accelerate your development for sure - it's a mandatory skill now, so develop your driving skills, but try to allow yourself the extra time to deeply understand what it's doing and question it. Where a particularly gnarly problem crops up, get involved, understand the problem, the cause and resolution.

Whilst still embracing AI, you can open yourself up to opportunities to learn more, to gain those foundational skills and judgement expected of a senior. Simply put, AI should accelerate your learning, not replace understanding.

What leadership needs to do

If senior leaders want to bring through the next generation of engineers to have the same skills they themselves have, they need to provide the opportunities and they need to be intentional about it. Today it's too easy to request a feature be implemented, assign to a more junior team, have them build with AI and deliver it, not fully understanding the code and its implications.

By allowing extra time to implement with understanding, to create mentoring opportunities, to teach reasoning rather than syntax and to expose juniors to debugging, system design, and architecture discussions, is perhaps the only way to ensure they're getting exposure to solving complex problems themselves and gaining a few war wounds of their own.

We need to optimise for learning and understanding, not just throughput and in this AI era, mentoring may become more important than ever.

Does this still matter in 12 months?

At this moment in time, deep engineering knowledge clearly still matters. Models still make naïve mistakes and systems still need humans with judgement. With AI, we worry about how that creates a tension with juniors coming up behind us who may not have the opportunity to earn their stripes, gain the scars, and develop the skills and judgement that comes with the senior badge.

Whilst I worry about that somewhat, I also wonder if we'll need to care in 12 months.

AI augmented engineering is already more about steering, reviewing, understanding intent and architecture than the implementation of the code itself, but the steer and review is very important. In 12 months, as new frontier models release, as they become dramatically more capable, will we even need to worry about this?

Nobody really knows yet. In the meantime, there are things juniors can do and that leadership can do to try to preserve the body of knowledge, and necessary senior skills.

Final words

Claude and GPT are awesome - we can deliver 3-10x what we used to when working individually. That velocity doesn't need to trade off against quality either - that also remains high, provided the model is being steered by an engineer with the right skills and judgement. The paradox is - how will more junior members develop their skills and judgement - assuming we still need to care in 12 months.

The question isn't whether AI can write code, it clearly can - the real question is whether future engineers will still develop enough understanding to know when the AI is wrong.