Remember when you first started at your last company? Beyond the first day nerves, or the confusion about where to go - commonly in software there was a large, unfamiliar beast in the room.
The code.
This beast is to be understood, to be known, and to be eventually a partner in your work. Great programmers can teach it new tricks. It is well studied, this beast, there'll be documentation (hopefully) somewhere teaching you the ways to get started, how to get something running.. Exciting.
Dance beast, dance.
Next step is familiarity, this comes with time, and effort. Time to know the ins and outs, what's hard and what's easy. Cherish this time, the novelty of strangeness disappears quickly. I commonly ask new starters to my team to point out what smells - for those who have been around a while are used to it and forget that things can be better, faster, easier. There are better looking beasts out there depending on your preferences.
After familiarity comes execution. This beast no longer looks strange to you, it may be haggard and burdened by many years of activity - but in it you see shared experiences - and sometimes you see a little of yourself. Ideas that you're proud of, things that never took off, things that took off and frankly surprised you. Even the ideas that aren't there anymore, having been replaced, renewed, rejected, are nestled in the wrinkles of the beast. You and this beast are in tune, you as its next steward. This is not a one way responsibility, but a shared expectation for you. You care for the beast - as it does for you, running every day. Writing individual features, code, was never the goal. It was simply the journey we took to know the beast.
Enter AI, and code has never been easier to write. Every prompt, pops out a new beast, or a new appendage to an existing one. For many a project, this is an immaterial addition - after all, one does not require becoming intimately familiar with every stranger they meet. But for those that live long term, there's a set of hidden decisions that were made. Historically, those were explicit, and from you. You may make note of it, and it might guide your thinking later. Now, they're implied. Even in the most explicit AI prompt, those small iterative features introduce history with no one to advocate for why that choice was made. It simply was.
In our craft though, we care about those decisions that make up the whole. Rather than individual features, or files of code, our craft is a symphony of collaboration. In a team, you might notice that your beast has started looking... more strange?
At its worst, we're taking steps back. Trading the win of the short term uber-prompt for a fading memory of the beasts face. We can lose the desire to know intimately how everything pulls together, after all, maybe it doesn't matter any more?
The beast gets a new tooth...
Our responsibility is to be able to reason about our code, we may not have the same requirement to know each line, or to recall precisely how some SQL pulls together. I do think it's reasonable to argue that the lines between the function signature and the final brace are less important than they perhaps once were. Authors of functions have always had an individual flair, and they're highly likely to change relatively consistently. So at what abstraction does it matter now to know and be able to tame the beast?
Many of us, the key task that we fulfil is to collaborate, and build, with others, we build platforms that long lived features rely on. In that level, you serve to guide those around you in the "right way" that the system should be used. You rely on your experience, and the historical decisions that have shaped the beast so that newcomers can continue to shape it in a way that continues to tame it. Just like you didn't know the most effective way years ago when you first started, the less you tend to your relationship with the beast, the less you know the best way today.
I've heard from senior engineers that "code doesn't matter any more" - i'd argue it's never mattered more. It matters that you build your system purposefully. I care little for the idiosyncrasies of a style guide that worries about naming of methods. That truly has never been easier to standardise or change. But I worry about our continual "and then"-ification that comes from the act of adding code. It adds an arm, a leg, and a strange new growth to our beast that may surprise a team member who used to understand the system. It may struggle to find re-use, having been stitched on only to do one thing. Simple addition only serves to make a scarier beast.
It means our craft has changed. We appear to have walked one step up the logical stack. But peer, be wary of walking so far up the stack you forget what you aim to bring. Building purposefully has never been more important. A high agency owner, with a good relationship with their beast can take on outsized impact with the help of AI writing code in the way that continues to take advantage of the history & desired future of the system.
You should have strong opinions about the entities, domains, and general purpose of your system. You should have firm invariants that you're unwilling to let go of. You should have clear relationships & boundaries between other systems and collaborators. You should build a system that is dependable. This fundamentally is your job. For your collaborators do not know your beast like you do, you serve them well to not add a new sharp spike to it. A failure to interrogate, and understand your system means that increasingly, there are spikes that you might not know about too.
AI writing code is here to stay, our jobs are changing. But don't let your beast become a stranger, your relationship with it will define your success.
Dance beast, with me.