Craft in the Time of Agents

Good morning, everyone. I hope you're having a really great time. I know I sure am. Alright. Let's get started. So, in 1843, before there was even a working computer in the world, Ada Lovelace said this, we may say most aptly that the analytical engine weaves algebraic patterns just as the jacquard loom weaves flowers and leaves. Now, besides being a bit of a tongue twister, doesn't that just evoke really beautiful imagery for you?

And ever since then, we've been reaching for that sort of language beyond the technical to explain what it is that we do as software engineers. Software engineering has often been described as a craft and compared to things like gardening and poetry, novel writing, or building complex beautiful structures like castles and cathedrals.

But if we take a step back, what do we even mean by craft? So at its heart, a craft is about skilled making. Right? It requires specialized knowledge and expertise blended with creativity to create something of value. And we tend to think of more sort of manual hand working, say, woodworking or shoe making, watchmaking when we think of craft, but actually applies to any highly developed practice, physical or digital. So, software included.

But all crafts share these similar dimensions. Right? So, we've got skill, judgment, quality or care, and knowing. But the two that I think about the most are pride and joy. And what do I mean by pride? You know, knowing that you did the best you could and being proud of what you've done, putting your name to it.

Right? And joy, well, the reason we do it at all, when the hours pass like minutes. But mastering a craft isn't something you just accomplish tomorrow. Right? There's a whole journey behind it. It takes a long time and a lot of hard work. You start off as an apprentice, learning the patterns and the principles, and if you stick with it, you might become a journeyman, where you become more capable and contributing.

And then if you stick with it for like ten years with a lot of hard work put in, you might master that craft. Then you get to function from a sense of intuition, and that feels great. But you don't just absorb that knowledge. Right? That knowledge, you have to grind it into your fingers, your eyes, and your gut, as Uncle Bob would tell us.

But for all that's universal about craft, I think there's something really personal about it as well. Right? Because if I were to ask each and every one of you what you mean by craft, what it means to you, I bet you'd all say something different. I think it's because it all comes down to where you find your reward, your pride, and your joy.

So speaking of joy, a friend of mine called David Kerr Lewis, he recently wrote this lovely blog post that touched on this very topic. He thinks that there's two kinds of engineers, those who get their reward from the results, seeing the outcome. They're more result oriented.

And then there are others who are more journey oriented. They get their joy and reward from the figuring out, the experimentation. Now, don't think this is a binary choice. Right? I think this is more of a spectrum, and we all sit along it somewhere. I know personally, I get a lot of satisfaction out of the journey itself. Right? I love the figuring it out, I love understanding a problem deeply, teasing out the complexities, modeling it in my head, and coming up with the simplest solution I can for that problem.

But I'm sure not gonna walk away from a half done thing either. I need to see it working and done as well. So ask yourselves, where do you sit along that line? Because it might be more than just a personal preference. It may also help explain how you are feeling about this AI moment. Right? Because for some of you, if you're more results oriented, you might actually be feeling like AI is a real superpower.

It's allowing you to reach further, accomplish more, build things faster, more. But if you're more journey oriented, you might actually be feeling a bit of a sense of loss or grief because it's now being sort of done for you. Right? Now, it's the same technology, but we're having different reactions to it, both valid and real.

And some of us might even be feeling both. It's a bit confusing. And no matter what you might be feeling, I think we can all agree that AI is having a really big impact on our field. Right? I I normally talk about software engineering being a bit of a canary in the AI coal mine because we applied it there very early and it's very applicable to software engineering.

But, you know, it's all still changing, and we don't really know where it's all going yet. We certainly have more questions than we have answers, which is why we're all here to share and learn from one another. But I'd love a show of hands actually. Who in the room thinks that it's just another evolution, another step change in the long history of computing?

A few hands. Okay. And who thinks it's more of a revolution, something that's genuinely new? Okay. I I think I see more revolution has, but, you know, it's actually pretty mixed. Well, I think we're all still trying to work that out. Nobody really knows where this is all going. And it's those very questions that took me back to university at the beginning of twenty twenty four, because I really wanted to understand this more deeply. So I I did a masters of engineering, took me two years part time, and, I designed a longitudinal study with two questionnaires based six months apart that I ran at the end of twenty twenty four, beginning of twenty twenty five, to look at the lived experience of professional software engineers who are using AI, either at work or at home.

I got participants from 28 countries, and today I'm gonna share four of the findings from that research for you to contemplate, take away with you. So one of the things I was really interested in understanding was whether AI coding assistance shift our perceived focus across these common development tasks that we all do. And most engineers felt that they spend less time on all but one. Reviewing code was the only one that was slightly above neutral at both time points.

But what was more interesting was what happened between those two time points. Because over that six month period, we saw a statistically significant shift from the more creation focused tasks to the more verification focused ones. And what that tells us is that the very nature of the work we do, or the craft of software engineering, is changing.

And it also got me wondering though, so we're spending less time on all but one of those common tasks. Does that mean that we've got a whole bunch of free time on our hands now, and we're all going home at midday, and we're going to the beach and relaxing? I don't think that's what we're feeling at all.

I know that it's not what I'm feeling. I'm busier than I ever have been. So when I dug into the qualitative data, I found that there was this new type of work that was emerging that people were describing. And it was different enough to the other standards or software development tasks I just mentioned. So I've given it a new name, supervisory engineering work.

It's made up of directing AI, evaluating its output, and correcting it when it's wrong. And I don't think it fits into either the inner loop or the outer loop of software development. I think it sits right in the middle in a new loop, I've called the middle loop. But note that the dimensions of craft, they don't disappear.

We're now just applying them to a new type of work. So this one's one that I really want you to pay attention to. Alright? So the research over many years now has shown that productivity and developer experience travel together. They're correlated. And leaders have been told, if you want to improve the productivity of your team, focus on improve improving the developer experience of your engineers and productivity will follow.

So I asked engineers in my study, did they feel more productive with AI? And of course, most said yes. 84% did at both time points, very stable. But those same engineers were starting to report a decline in their developer experience. And by that, I mean one of three dimensions, cognitive load, flow state, or feedback loops. At the first time point, 14% said that at least one of those three had declined or gotten worse.

And by the second time point six months later, that number had almost doubled to 27%. And it was flow state that was the most negatively affected, followed by cognitive load that was increasing. Feedback loops was improving though. And if you think about it, maybe the mere fact that we're getting more feedback more frequently is actually interrupting our flow.

Correlation there. Side effects, right? But note what's happening. We feel more productive, but the very things that made the work feel like a craft are starting to erode. So if you're feeling a version of this, know that you're not imagining it. The research is starting to show it, and our industry is certainly talking about it. Right? Giving it names like AI burnout.

If you haven't read it yet, Steve Yeghi has a really great blog post called the AI vampire on which he talks about this as well. And for the leaders in the room, please make sure that you're taking note of this as well. It's not sufficient to try and measure productivity alone because you'll miss half of the equation.

Right? So, anyway, this is all sounding pretty grim, so I hope that the next and last finding that I'll share with you will give you as much hope as it gave me. So of all the research questions that I had to answer, I figured that demographics would play a big part, that they would matter. So things like your seniority, or the tools you're using, the size of the company you're working for, that sort of thing.

But as it turns out, the strongest predictor of productivity and those three dimensions of developer experience was something called self efficacy. So self efficacy is your own belief and your own ability to accomplish something. So engineers who felt more confident when using AI to build software were over 10 times more likely to report higher productivity gains. That's a really big effect.

And I'll tell you why it matters. Because self efficacy is a belief, and you can change your belief much more easily than you can change your demographics or your work situation. Right? So you're not stuck where you are, you don't have to wait for the perfect title or the perfect tool to come along. You can actually get going right now.

And self efficacy is built up through mastery experiences, which you can gain through experimentation. The more you experiment, the more you learn. The more you learn, the more confidence you gain. The more confidence you gain, the more that you can adapt. And the virtuous cycle builds from there. Alright? So you're far more in control of how you react to this moment than you might have thought.

Alright. So the very nature of our work is changing. The craft is relocating. What does the future even look like for us? I'm not an oracle, don't have a crystal ball, but I was inspired by a paper that I read recently. It was written by the same some of the same researchers that created the space framework, if you're familiar with that.

And they described these three possible futures. Now, I've given them slightly different names, but I was inspired by their work here. So, on the one hand, you've got the artisanal developer. That's, you know, think hand built, high prestige, possibly restricted to the more safety domains or heavily regulated environments. Now, I think this type of there there will be a demand for this type of work, but it might be quite rare.

On the other hand, you've got the clerical coder. Now, this is the one to watch out for because I think it's the one that's probably got the least amount of joy built in. Think agents doing a lot of work overnight. You come in in the morning and you just accept those PRs uncritically. Where's the creativity in that?

Right? So that's the one to avoid. And in the middle, we've got the orchestrator or the code conductor. I mean, we're gonna give these things funny names. But that's probably the center of gravity. Right? Where most of us will land. Think building software with agents at scale. Now, depending on where you find your joy, you might find yourself leaning towards one of at least two different directions.

If you're more interested in really understanding the problem, the domain, then you might lean towards being more domain focused, capturing the what and the why in in intents, in well written specs. And you're feeding that to the agents. On the other hand, if you're more interested in building the machine that builds the machine, then you might be more, you know, leaning towards that harness, making the harness by building skills and tools and all the things that we heard about yesterday.

Importantly, creating those deterministic constraints as well that build the rigor in so that your agents create the right thing. Now note that I don't think you need to choose between these two. Most engineers I know are doing a bit of both depending on the day, so the line between those certainly blurs. Okay. So as we look forward, I have a couple of calls to action for you.

If you're an engineer in the room, please be curious and experiment. Now is the time. Right? Go deep, find the thing that lights your fire and go deep on that. AI can really help you with that. But then, go deep in many directions because narrow specialization has far less room than it used to.

And take control of your craft. Right? Don't wait for permission, don't wait for the perfect tool. The dimensions of the craft are still yours to own, no matter where it's applied. Alright? And if you're a leader in the room, please name what's possible. Get the conversation going about what the future of work looks like at your organization. Be aware that there are some engineers in your teams who are looking over their shoulder, mourning the loss of something they used to love doing by hand.

Help them turn around by painting a picture of what the future of work looks like, and then create the pathways by opening up the opportunities, blurring the lines, and encouraging them to move towards it. And remember that pride and joy, they don't just happen by accident, they're outcomes that you can design into your system.

So that, my friends, is the leadership work for you. Alright, to wrap this up, nobody has this all figured out yet. Right? Literally nobody, not the top practitioners, not the tech leaders, and not the academics. Trust me, I know I have been in rooms with all of these people just this year, and they all have more questions than they have answers.

We've all been rebooted, we're all just explorers now, and we're writing the path as we walk along it together. The future is yours to imagine, so take the opportunity to design the craft that brings you the most pride and joy in your work. Because as engineers, we've always designed for the future, And now, we get to design our own.

And that's all.