Liking what we are becoming
I feel like these past few months I've been going from thinking the craft I once loved was dead, to thinking about what's next, to liking what we are becoming. I've juggled between these feelings, it wasn't a clean journey or anything.
I've been in software engineering professionally for 10 years and I've always really loved the creation part, especially creating for fellow developers. Thinking about an API surface, making it convenient and ultimately seeing people get to success with it. Minimal APIs, good performance... one of the things folks praised me for throughout my career was my fast execution.
With agents we got that fast execution for free and developer tools were being created by anyone. As long as the tools worked the developers were happy, a lot of the time it was about replacing them and not paying for them.
This fast execution being my strength was one of the reasons why I feared becoming increasingly irrelevant in our field, which was moving at breakneck speed.
What turned it around for me was pracht and drydock. Both were ideas I'd been sitting on for a while, the kind I'd shelve because I knew how many evenings they'd cost me. With agents they came together in days to weeks, while I spent my time on the parts I actually cared about: what the routing API should feel like for pracht, what a maintainer needs to see before approving a staged publish for drydock. Neither would exist otherwise. That's when it clicked that the fast execution I was so proud of was never the point. It was what stood between my ideas and reality.
That's why I've landed on this being the absolute best time to be a software engineer. Typing code was the time consuming part, we are free of those shackles and can now
- Try any new idea at the speed of thought
- Maintain codebases of vast sizes on our own
- Build a rapid understanding of systems
I used to be fast at coding, now that part is even faster thanks to agents; now I am good at managing multiple work streams and seeing my agents drive my vision towards a reality. There are so many things I would never have built without them, some public and some sitting in private repositories waiting for me to have the confidence to release.
Everyone becoming a software engineer is also a positive thing in my eyes, we are going to get an influx of ideas in our field thanks to all the new perspectives of folks who weren't raised in our lingo.
There's still a gap though. It used to be that you needed a wizard who spoke code to get a system up and running. Now folks can try their ideas without these expensive wizards and hire one when they get revenue. Just like in (E)Sport, the gap between a professional and a really good player is small but decisive.
Agents are good at code. Where they fall short isn't skill, it's sameness: give them a certain problem and they'll converge on the same solution every time. That isn't inherently bad, the common answer is often the right one, but alternatives don't get considered unless someone asks for them. We can push agents to implement those alternatives, but knowing when to push is on us.
That raises the obvious question: if agents write the code, how do juniors ever build up the experience? I don't think experience is their edge, creativity is. Newcomers don't carry our assumptions about how things are supposed to be built, and with agents they can test their wackiest ideas before anyone tells them it won't work. Seniors bring the experience: how the pieces fit together, how distributed systems behave over time, and which of those ideas is worth pursuing. The best teams will have both.
Our profession evolved and I would encourage anyone to try this new flavour of software engineering, it's so much fun! Try that wacky idea, create a game, the possibilities are... endless... and that brings me to my next point.
Loops
We can't keep giving people a blank chat box and expect them to know the endless possibilities, that's a power user move. Part of what our profession is evolving into is building feedback loops and there are currently (as I see it) two types of them: internal and customer.
Internal loops are what replaced my fast execution. Running those work streams well isn't about prompting faster, it's about designing the loop: now that time has collapsed into the LLM working, the process became design heavy. We will collaborate on discussing how a feature looks, how it's architected, how it fits in with the rest, how it needs to be QA'd, how bugs and customer feedback feed back into the loop and how we validate success. We ensure that this whole loop is well-designed and fast so features can grow independently.
Customer loops are essentially a feature built through the above. As customers interact with the product, the interfaces they leverage should evolve on their own to fit their needs better. If I always visit some page that is x links deep the UI can evolve to show that link earlier, if I execute a certain query a lot the MCP server can evolve to serve that as a built-in tool to save tokens...
The power user will always be there but we have a whole other non AI-pilled audience to cater to and it's still our job to make their life better and enable them to not waste time on trivial things.
Let's stop arguing amongst ourselves whether we like or dislike what we're growing towards, we won't stop evolution here. We should embrace change and figure all of this out together. Just like during the framework wars, we'll get through this, as an industry.