Over the past few weeks I have been testing a few AI code assistants like Claude Code, OpenAI Codex and Github Copilot. I'm using to vibe engineer some personal projects but also to try out new ways of building software at Mindera.
Using AI to write most of my code makes me think that the role of a developer might evolve to more of an architect. Someone who thinks about what they need/want to build and then orchestrates AI to actually get it built. But as I do this, I am seeing two types of situations that will make a full evolution like this a bit slower than some predict, or even challenge it. Namely:
1. When I'm building something that is not as standard as most of the things I build (ie: something that isn't just CRUD pages and typical interfaces), AI tends to struggle more to deliver working solutions. Or at least takes longer to get it right than more conventional examples. I've seen this described as building things that fall off the distribution curve. The tech stack also has an influence here. AI might push for more standardisation as many of these models are much better trained on stacks like ReactJS. Tech choices will need to consider this.
2. When I'm building something that I've never built before versus something that I have built before. For example, the other day I was building user invitation system for a project, similar to the one I built for Kronflow earlier this year. So I was able to see that Claude Code wasn't building the feature in the right way, and I could intervene and ask it to adjust its approach. This means that when I'm building something that I haven't built before, there is a higher chance that it will be written poorly without me realising.
Point number one might be a bigger issue than point number two, because "poor" might still be acceptable, as long as it's not insecure and bug-ridden. But if AI doesn't build the thing properly, a human will still need to step in.
What this tells me is that to guide AI adoption we...