Jon Hilton

Going round in circles. Anyone else feeling it? As software developers we're very susceptible to the silver bullet, shiny new thing that's going to make building stuff easier. Queue the fail loop: see shiny thing, adopt shiny thing, run into problems, see new shiny thing.

AI doesn't feel so different. Where it gets interesting is when you work through all the noise and realise being effective with AI depends on exactly the same fundamentals as being effective without AI. Short feedback loops, small batch sizes, optimising for early user feedback etc.

The more I use AI for coding the more it becomes apparent - AI generating realms of code isn't speeding us up. If the goal is to solve problems, deliver value, meaningfully impact our users, then AI generating more code, more quickly doesn't cut it.

An old boss of mine loved nothing more than to come to the dev team armed with a 'mockup' for a screen they wanted building. The mockup was, in fact, an Excel sheet, where they'd used the border tool to make it look like the picture in their head.

In an AI world we can spend countless hours trying to automate everything, but let's not forget the step before that.

An old boss of mine loved nothing more than to come to the dev team armed with a 'mockup' for a screen they wanted building. The mockup was, in fact, an Excel sheet, where they'd used the border tool to make it look like the picture in their head.

At the time we probably dismissed this as 'the boss being the boss'. But, with a bit more experience under my belt, I see it differently now. They found a way to think through what they were asking for, and bring it to us.

Team struggling to ship? Identify the bottleneck - the one part of the system where work backs up. It might be obvious (you're swamped in code reviews because... AI). Or less obvious (devs waiting for clarification on requirements from a PM or designer).

Imagine you're a junior developer and your boss asks you to "build a car finance calculator" You, the junior, don't know the rules, moving parts, how to calculate finance based on deposits, depreciation, interest rates etc. But, keen to impress, you give it a go.

You know (because they kept moaning about it) that they had to make the rules up as they went, because no-one took the time to help them think through the details, the edge cases, the legal implications of mis-selling...

Imagine you're a junior developer and your boss asks you to "build a car finance calculator" You, the junior, don't know the rules, moving parts, how to calculate finance based on deposits, depreciation, interest rates etc. But, keen to impress, you give it a go.

For the engineering team leaders out there - how are you tackling the adoption of AI within your team? Maybe you've thrown some Claude/Copilot licenses at them and are hoping they can figure it out.

Let's be honest, as developers we've known the value of tests for a long time, doesn't mean we've always written them. But in the last few weeks I've made sure to get AI to write tests first, before implementing, and in most cases it's been much better in two key regards.

Give the AI examples like this, have it write them up as unit tests (ideally first, without assuming any knowledge of the implementation details) and I'm finding AI is much more dependable as a coding partner.

Let's be honest, as developers we've known the value of tests for a long time, doesn't mean we've always written them. But in the last few weeks I've made sure to get AI to write tests first, before implementing, and in most cases it's been much better in two key regards.

1) writing code that meets the requirement in the first place 2) catching regressions as the LLM later goes on to make further changes But there's a third, subtle benefit to.

Everyone knows AI can generate code, but what if that isn't even its best party trick? I've found the most useful and productive sessions I've had are those where I get AI to help me do the work.

Most recently asking it to walk me through a 'messy component' and help me figure out which parts to refactor (and why). As a learning tool, which can adapt to your specific scenario, I don't think it can be beat.

There's a notable fail mode I see being amplified by AI right now. Especially for developers. We decide we want to build something, because we have a problem and feel like building something will help us fix it.

Here's a more effective approach. Spend time reflecting on the problem, your goals, and coming up with theories on how you could address those problems to meet your goals. I've started doing this of late, and every time I've tried it, the answer wasn't to build software.

There's a notable fail mode I see being amplified by AI right now. Especially for developers. We decide we want to build something, because we have a problem and feel like building something will help us fix it.

The more I use AI for coding the more I realise feedback loops are vital now. (side note, they always were) Linters, compile checks, tests, extensions to test the UI in the browser, code quality reviews.

Anything that gives AI a way to check, and course-correct, just after it's made changes, seems to yield much better results. I've found that effective feedback loops go a long way to balancing out the differences between the various models too.