My Changing Relationship with Code Is Deepening My Understanding of Myself as a Builder.
A Love Affair With Code
My relationship with code began long before I had a software career. I was nine years old when my dad bought a Commodore 64. With it came a book containing programs written in BASIC. I would carefully type those programs into the computer and watch the magic of what those strange codes became. The idea that I could enter instructions into a computer and it would execute them accordingly was astounding to me.
It did not take long before I began to understand what I was typing. Once that happened, I started writing programs of my own. That was the beginning of experimentation. I would change things to see what happened, try things I did not know how to do, break things, figure out why they broke, and keep learning everything I could get my hands on about programming in BASIC. I was curious about how the computer worked, but I also loved that I could make something with it. That relationship with code has now lasted more than 40 years.
As I grew from that curious nine-year-old into a professional software engineer, the problems became more complex and the tools became more sophisticated, but I never lost that satisfaction. I love the entire process of building software. I love conceptualizing an idea, thinking through the architecture, writing the code, solving the problems that emerge along the way, and eventually seeing something that started as an idea become a workable, usable application.
There is also a satisfaction that comes specifically from the code itself. Sometimes the problem you are trying to solve does not fit neatly into a standard pattern. You have to enter unknown territory and construct some complex, nuanced, or clever way to arrive at your destination. Those are the moments that can produce elegant code, sometimes even code that feels technically poetic. Other times it produces ugly code. That is part of the love affair too. 😂
I say all of this because I do not approach the changing relationship between builders and code as someone who has decided code does not matter. I love code. I have loved it for most of my life. That is precisely why what began happening as I moved deeper into agentic software construction caused me to reflect on what code actually meant to me.
When the Relationship Changed
As I began using coding agents more heavily in my development workflows, I started getting farther away from the code. The agents were doing more of the actual coding for me, and at first that bothered me. This was taking me away from code, and I love code. I began wondering whether allowing the agents to do more of that work made me lazy or somehow made me less of an engineer.
Those were legitimate questions for me because writing code had been part of how I experienced software construction for decades. I knew how to take an idea, think through a solution, and express that solution through code. Now I could describe what I needed to an agent and watch it perform more and more of that translation itself.
Something interesting happened as I continued building this way. I realized I was getting the same satisfaction. I was still conceptualizing, solving problems, thinking through what needed to exist and how the pieces should work together. I was still watching something that began as an idea become working software. The dopamine hits were still happening. 😂
That forced me to recognize something about myself. I love writing code, but writing code is not the foundation of the love I have for building. It is one utility I have used that gives me access to building. What I actually love is creating. That does not diminish my relationship with code. It simply places that relationship inside something larger.
The Medium Moved Down a Layer
Software engineering has always been a story of changing abstractions. We have repeatedly developed ways to move farther away from lower-level implementation details so we can spend more of our attention somewhere else. Higher-level programming languages, frameworks, libraries, platforms, cloud services, and countless other tools have changed what builders have to concern themselves with directly.
AI feels like part of that evolution, but it also feels significantly different. Previous abstractions still generally left the engineer writing the code. The abstraction might change what I needed to write or how much of it I needed to write, but I was still expressing the solution through code. With the way I am increasingly building with agents, the code itself is becoming another layer I do not always have to interact with directly.
That does not mean the conceptualization has disappeared. It happens at a different layer. I find myself thinking more about architecture, behavior, boundaries, interactions, constraints, and outcomes because I am building software. I am not necessarily writing the code that implements those things. The agents can concern themselves with classes, methods, data structures, algorithms, and other implementation details. When I am conversing with an agent, I am no longer speaking in code. I am communicating what needs to be built and the boundaries within which it should be constructed.
There is something interesting about realizing that because the creative part of software construction was never limited to the time we spent sitting in front of an editor. I have conceptualized solutions while driving my car, taking a walk, eating, talking through a problem with a colleague, and even in my dreams. Sometimes you are nowhere near a keyboard when the thing you have been wrestling with suddenly makes sense.
A painter develops a relationship with paint. A musician develops a relationship with an instrument. A sculptor develops a relationship with stone. Software engineers develop a relationship with code. As our fluency with that medium grows, we learn how to express increasingly complicated ideas through it. Sometimes we become fluent enough to speak the language in technically poetic ways.
The relationship with the medium is real, and changing that relationship does mean something can be lost. If I spend less time writing code, I am naturally getting less practice writing code. There are also fewer opportunities to experience the satisfaction of personally writing a particularly elegant solution. I think that is worth acknowledging and, for some builders, worth grieving.
For me, though, moving farther away from the code did not mean moving farther away from building. After more than 40 years of a love affair with code, I can appreciate everything that relationship has given me without needing to hold onto the way I have always practiced it. I still love code. I also love where building is taking me now. It's all love, baby. 😂
What Happens to Craftsmanship?
One concern that naturally emerges from this shift is what happens to craftsmanship when the builder is no longer personally producing most of the code. I think answering that requires us to think about what software craftsmanship actually looks like before we ever get to the implementation.
When I encounter a builder who understands the craft, one of the first things I notice is how they approach a problem. What questions do they ask? What kind of conversation do they have around the problem? Do they immediately start throwing out solutions, or do they spend time trying to understand the problem at a fundamental level before deciding what the solution should be?
A builder who understands the craft also knows that building something from scratch is not automatically evidence of engineering ability. Before constructing something new, they explore whether patterns, solutions, frameworks, libraries, or other approaches already exist. Why reinvent the wheel when there is already a wheel that solves the problem?
They think about how architectural choices affect integrations and other parts of the system. They examine the tradeoffs between different approaches and consider performance opportunities and losses. They understand that a decision that looks elegant in isolation can create consequences somewhere else. Through all of this, they remember that they are building software for users, and sometimes the technically elegant approach has to take a backseat to what the user actually needs. Your ego is not that important.
None of those characteristics disappear because an agent writes the code. A builder can write very little of the resulting implementation and still practice software craftsmanship. They can understand the problem, investigate the available approaches, make architectural decisions, evaluate tradeoffs, provide context and constraints, observe how the construction is progressing, and make sure the result serves the people it was intended to serve.
AI does not automatically make craftsmanship more important, though. That depends on perspective. If the only concern is getting a result as quickly as possible, it can be very easy to ignore craftsmanship. We can ask an agent for something, get something that appears to work, and move on. If you care about building quality software, craftsmanship becomes much harder to ignore.
The ability to generate code does not eliminate the need to understand how quality software gets built. I learned this quickly as I began working more deeply with coding agents. They can code, and they can do it well, but there is a great deal of human understanding and context they simply do not have unless we provide it. I found myself introducing guardrails, giving explicit direction, providing context, watching how the agents worked, and correcting things when the construction began moving somewhere I did not intend. Smart coding agents are not enough to build quality software, and realizing that eventually moved me away from questioning my worth as an engineer. My perspective had to shift.
If I Built It, I Own It
There is another question that comes with this abstraction. If an agent writes most of the code, can I really say that I built the software? I absolutely believe I can, and I think architecture provides a useful way of understanding why.
Think about an architect who designs a skyscraper. The architect does not personally pour the concrete, install every window, run every electrical line, or weld every piece of structural steel. An entire construction team takes what was conceived and architected and turns it into the physical building. We do not therefore conclude that the architect had nothing to do with building the skyscraper.
I see the agent as a tool used to assist in constructing what I have conceived or architected. I may no longer personally produce every implementation artifact, but that does not remove me from the act of building. It also does not remove me from responsibility for what gets built.
An agent can do no more than what it has been allowed to do. If I give an agent permission to make certain decisions, then I have the responsibility to steward that authority. That means constructing the appropriate checks and balances to catch mistakes and creating a workflow and building infrastructure that reflects the amount of authority I have given the agent.
I do not think there is one universal answer for what that workflow must look like. Builders will make different decisions about how much of the generated code they inspect directly, what they automate, how they validate the work, and where they establish boundaries. That is left to the preference and interpretation of the builder.
What matters is that responsibility does not transfer to the agent simply because some of the construction does. An agent cannot own the software or be held responsible for what reaches the user. It operated within the boundaries it was given. If I claim that I built the software, then I also have to own what I built.
What Remains of the Builder?
I have heard experienced engineers ask what is going to happen to them as AI gets better. I have heard builders say that they love to code, so if AI is writing the code, what is their purpose? I have heard the question, why am I even needed? I understand the sentiment because I have wrestled with parts of it myself. I have wondered whether allowing agents to do more of the coding made me lazy or somehow less of an engineer.
I also understand the feeling that the industry itself is being diluted and the concern that these tools could potentially displace traditional engineering roles. This particular abstraction is different from the ones that came before it in at least one important way. Previous abstraction transitions still largely kept software construction in the hands of experts, professionals, industry insiders, and engineers. This one invited other people onto the construction site.
There is a much larger conversation to be had about what that means for the software industry and who gets to participate in building software. That is not really the conversation I am trying to have here. I am more interested in the experienced builder who looks at everything changing around them and wonders where they fit.
I do not think the answer is to dismiss their relationship with code. I certainly cannot. I was nine years old when I fell in love with it, and more than 40 years later I still love it. What my experience with agentic construction has caused me to reconsider is whether the thing I loved about building was ever contained entirely within the medium I used to build.
Tools have always changed, but the identity of the builder has never changed with them. Creativity, ingenuity, imagination, conceptualization, vision, curiosity, and the desire to solve problems do not originate in our tools. A new tool does not remove those qualities from the builder. If anything, new tools have the ability to give us additional ways to exercise those qualities and potentially increase what we are capable of creating with them.
Maybe that is why I can move farther away from writing the code and still recognize myself in the work. I am still conceptualizing, exploring, making architectural decisions, solving problems, and taking responsibility for what gets built. I still get that same satisfaction when something that began as an idea becomes something real and usable. The medium through which I construct software is changing, but after more than 40 years of building, I have discovered that I am no less of a builder because my tools have evolved.