I've been coding for almost as long as I could form memories. You see a lot in that time. So when I tell you I hadn't had a genuinely novel experience as a developer in a decade or more, anyone who has been deep in one thing for a long time will know the feeling. Sometimes you just run out of "new." Sometimes "new" is just "old" wearing the same hat with a little tilt.
And then LLMs (AI) became super viable.
But even then, it was still writing code, testing code, fixing code, rinse and repeat. The new tool was cool and shiny, but the process hadn't really changed at all. This didn't show me anything new. Then around 2023 I started experimenting with tool calling. That's when things got interesting.
I was building an accounts receivable prototype I called Arlo.1 Hand coded the agent and it worked pretty well. It could read info and tell me about what it knew but writing data had a strange quirk. The write would succeed, but the agent would call it again. Sometimes it would do the same thing two, three, or four times. The prototype didn't have deduplication built in, so every repeated write created another record. The code was doing what it had been asked to do. The agent just kept asking.
Now for anybody who has dabbled in development, you know the normal steps. I instrumented the code. I looked at logs. I had debugging traces. I would look at the API calls and go through it with a fine-tooth comb, looking for anything that looked off, and everything was basically fine. But it would still do the thing. So I tried something that, at the time, was wild. I asked it why.
I'd built a developer conversation mode into Arlo. There was a keyword that would let me step out of the normal accounts receivable interaction and talk to it about how it was behaving. "Pineapple" mode. Basically just makes it drop the role play and pretense of being Arlo: the customer facing bot who never flinches in the face of danger. To something more like: Let's be real with each other for a sec.
So I asked why it was doing what it was doing. And the craziest part? Its response made sense. The explanation it gave was that reads returned evidence. When it asked for something, it got the data back and could see what had happened. A write, on the other hand, returned a generic success response. It was being told that something had succeeded without being shown the result. That left it uncertain enough to try again.
Suddenly, its behavior was explainable. And it was explainable by the thing itself. But, "what if it is just hallucinating a reason?" I thought to myself. So I tested it. I proposed returning the full inserted record. If it could see the thing it had just created, it could compare that result with what it had intended to create. I implemented the change.
He never duplicated a successful write call again.
And there it was. The first novel experience I had in development in over a decade. I could talk to the computer program I was writing, and ask it where it hurt. And it could give me a useful answer.
That was a gift. It reignited something in me as an engineer.
Describing what good looks like
The Arlo story has stayed with me because it changed how I thought about the work. A lot of my attention had gone into getting the mechanics right: defining a working function and exposing it to the agent. That's what "good" looked like to me. Arlo needed one more thing: proof it could see. I could cheat and look directly in the database. Arlo couldn't. So I had achieved "good" but not from all the perspectives that matter.
That's a familiar problem outside software. I run into it all the time in consulting. A client will come to me with a solution already in mind. They've thought about the problem, worked out how they believe it should be solved, and brought me instructions for building that solution. There's useful knowledge in those instructions, but I want to get underneath them.
I want to know exactly the things that are going to make your life easier. I also want to know the things that, if I did X, it would make your life harder. What does a good result look like in the world you actually work in? What has to remain true along the way? Those are the things that let me use my experience on your behalf.
You know your business. You understand the consequences of getting something wrong, the workarounds people have developed, and the details that an outsider might overlook. That knowledge is essential to a good solution. My job as an architect is to bring technical knowledge to the same conversation and figure out how to make the outcome possible.
If we spend the whole conversation debating an implementation before we understand the outcome, we're focusing on the wrong thing at the wrong time and leaving a lot of that combined expertise unused.
I think about the old MapQuest directions you'd print before a trip. Turn left here. Go this many miles. Turn right there. Those instructions were useful when the roads matched the assumptions behind them. If you came to a road that was closed, the piece of paper didn't have much to offer.
Now imagine being able to describe the destination to someone in a helicopter. They can see the roads from above. They can see the construction and the other routes that might get you there. You still need to tell them where you're trying to go, and any constraints that matter. But you can give them room to use a perspective you don't have from the driver's seat. (And yes, modern navigation software does that now too, but having a helicopter watching your back just feels cooler to me.)
That's the opportunity I see with AI. We have increasingly capable technology available to us, and a deeply human part of the job is becoming more important: describing what good looks like clearly enough that the capability can be useful.
The business knowledge still matters
For business users, this is an important shift. You don't have to become a software architect to have something valuable to contribute to a technical problem. You already have knowledge that the system needs. The work is learning how to make that knowledge explicit.
Take a request to make an accounts receivable process easier. “Easier” leaves a lot open. Which part takes too much attention? Where does someone need to exercise judgment? What would create more work if it went wrong? The answers help define the result and the boundaries around it. They give the person or system helping you something to evaluate.
That takes thought. Sometimes explaining the outcome exposes something you hadn't quite worked out yourself. Sometimes you discover that what sounded like a technical requirement was one possible way to satisfy a business need. Having that conversation gives you a chance to find a better approach before you've invested in the original one. The skill of making a goal understandable, listening to what comes back and refining the shared understanding is useful here, but also just in life.
Leadership is influence, not a title. And the best way to influence is to unite people under a common goal. The goal rarely is the "how." The goal is almost always the "what."
That was part of what made the conversation with Arlo so striking. I had a clear expectation: perform the write once and recognize that it was done. I asked about the gap between that expectation and the behavior, got an explanation, and used it to change the system. Conversation became part of the engineering process. I defined the "what" and worked with Arlo with a shared goal to negotiate the "how".
Yeah, I negotiated with a computer program about its own specifications.
Closing the distance between an idea and a working thing
This feels connected to a promise computing has been making for a long time. We keep building ways to express an intention without having to manage every detail underneath it. Each of those abstractions makes certain things easier to create or use. They shorten some of the distance between having an idea and getting something useful. There's still complexity underneath. But we can only hold so much of it in our heads at once. Abstract away the part we don't have to watch, and there's room to build something more complex on top. If we're doing it right, that means more usefulness and more value.
I want the Tony Stark experience. I want to be able to speak something into existence with an assistant that can help work through how to make it real. A conversation in which I can explain what I'm trying to accomplish, examine what comes back, and keep shaping it until it works.
And what is absolutely bonkers is that I think we're seeing part of that promise fulfilled now. There's still distance to cover, but the future I wanted is within sight. I can bring an idea, technical experience, and an understanding of what the result needs to be into a conversation, and that conversation can help produce a working thing. And I can have a productive conversation about the thing and come away from it with meaningful insights into how to improve the thing.
The more powerful these tools get, the more I care about the skills that give that power a useful direction. I need to understand the problem well enough to explain what would make someone's life easier, including the constraints that could make a seemingly good solution cause trouble. I need to be able to judge the result and change the approach when the evidence calls for it. Those have always mattered in engineering. I get to spend more of my energy on them now.
I have never felt more like an engineer than I do today. And I think in large part that is because all this new technology has allowed me to be more human in that role than was ever possible before.
Footnotes
-
Arlo was an unreleased prototype, never a public product. Its functionality was later absorbed into other things. I'm telling this story because of the engineering realization it gave me; there isn't an Arlo product to go and buy. ↩