The Gate Has Opened
When generative AI first started entering the broader technology conversation, I wasn't paying much attention to it. I had heard about ChatGPT, of course, but like a lot of people at the time, I didn't really understand what it was or what it would eventually mean for the work I had been doing for years. I was a software engineer with software to build, and AI wasn't yet something I saw as particularly relevant to how I did that work.
What I did begin to notice were some subtle changes happening inside the tools I was already using. Autocomplete in my IDE seemed to be getting a little smarter. Instead of simply completing the word or variable I was typing, it would sometimes anticipate where I was going and suggest larger portions of code. Eventually, I started seeing it propose complete methods based on the patterns and context around what I was working on. I found that intriguing. I wasn't ready to go down the AI rabbit hole, but I was paying attention now because something about the interaction between me and the development environment was beginning to change.
Not long after that, I attended a technology conference where I sat through several sessions focused on AI. By then I had become curious enough to want to understand more of what was happening, and some of what I heard in those sessions pushed that curiosity further. I was beginning to see that there might be more here than a smarter version of autocomplete or another productivity feature being added to the developer toolbox. I still hadn't reached the point of changing how I built software, but I had reached the point where I wanted to experiment for myself.
Shortly after returning to work, I had an idea for a VS Code extension based on a need I had encountered. It wasn't something I needed another engineer to build for me. I knew how to build it. The issue was the same issue that often determines whether small ideas ever become anything more than ideas: time. I already had other things I was working on, and this was the kind of useful little tool that could easily remain on the mental backlog because finding enough time to sit down and build it would always be competing with something more important.
This time, though, I had another option available to me. I decided that instead of putting the idea aside, I would use it as an opportunity to experiment with what I had been seeing and hearing about AI-assisted development. I began describing what I wanted and working through the construction with AI using natural language prompts. Before long, the idea that would ordinarily have been waiting for me to find enough spare development time had become working software.
That experience began changing my perspective because what interested me wasn't simply that I had been able to build the extension faster. I've been building software long enough to have seen plenty of tools, frameworks, languages, and abstractions make some part of software development easier or more productive. What felt different was how much distance had been removed between the thought in my head and my ability to turn that thought into something I could actually use. The technical ability to build the extension had never been my barrier. The amount of time and attention required to do it had been, and AI had changed that equation enough for an idea that might have remained on my mental backlog to become software.
As I continued experimenting, I started thinking about what that same change could mean for someone whose barrier wasn't time, but technical ability. There are people who spend years becoming experts in fields that have nothing to do with software engineering. Through that experience, they often recognize problems that others overlook. They see inefficient processes that everyone around them has simply learned to live with, or they imagine a better way of doing something because they understand the problem from the inside. Sometimes they have an idea for an entirely new product or experience. The problem is that when the solution requires software, what they can clearly imagine may still feel out of reach because they don't know how to build it.
That separation between understanding the problem and possessing the technical ability to construct the solution has shaped software creation for a long time. It is one of the reasons domain experts and software engineers work together. There is nothing inherently wrong with that relationship, and I don't believe AI makes it unnecessary. What is changing is that it is no longer the only way someone with an idea can begin exploring whether that idea can become software. Natural language is becoming a new layer of abstraction over software construction, allowing someone to describe what they want to create without first knowing how to translate every part of that description into code.
The code hasn't disappeared, and neither has the complexity underneath it. What has changed is the entry point. Knowing how to manually write code is no longer the only way someone can begin participating in the construction of software. For the domain expert who has spent years looking at a problem and thinking about what a better solution could look like, AI can bring something that once seemed out of reach into arm's length. They can begin experimenting with the idea themselves, and I think there is something significant about what can happen once a person crosses that threshold.
Sometimes the first thing they build may simply solve a problem they have. Then, after seeing an idea that once existed only in their head become something they can actually interact with, they begin to wonder what else might be possible. Another idea comes. They experiment again. They learn how to communicate with the AI more effectively, they discover things that don't work the way they expected, and somewhere in that process the creative juices begin to flow. A person who never thought of themselves as someone who builds software may begin to discover the builder within themselves.
When I look at what is happening from that perspective, I see some similarities with other technologies that changed participation by changing the vehicle available to people. The automobile changed who could travel and how far they could reasonably go. The internet changed who could publish and distribute ideas without needing access to traditional publishing or broadcasting infrastructure. Mobile technology changed where and how people could participate in the digital world. None of those technologies created the underlying desire to travel, communicate, create, or participate. What they changed was what people could do with a desire that was already there.
I believe AI is beginning to do something similar with software creation. It is changing how experienced builders like me work, but it is also changing who has an opportunity to participate in building software in the first place. That is why I have a difficult time seeing this moment as simply another increase in developer productivity. We are still discovering what AI makes possible, how we should work with it, where it performs well, where it falls short, and what entirely new ways of creating may emerge from it. There is still a great deal of territory we haven't explored.
That is what I mean when I say AI has opened a new frontier for building software. I see an expanding landscape of possibility where more people can take ideas that previously felt beyond their reach and begin exploring what it would take to make them real. For those of us who already build software, there are new ways of practicing our craft that we are only beginning to understand. For those who have never considered themselves builders, there is now an entry point that did not exist in quite the same way before. All of that gives us good reason to be curious about where this leads.
The part we have to be careful about is confusing greater access with the idea that the journey itself has become simple. If we are going to describe this moment as a frontier, then we also have to acknowledge what a frontier actually is. It is full of possibility precisely because so much remains unexplored, but unexplored territory also means we do not know everything we are going to encounter along the way. The gate may be wider, but getting through the gate is only the beginning.
Beyond the Gate
One of the things that makes building with AI so compelling is how quickly an idea can begin taking shape. You can sit down with a thought, explain what you want to an agent, and watch it begin constructing something that resembles what you had in mind. When you first experience that, especially when the result actually works, it is difficult not to start thinking about everything else you might be able to build. I experienced that myself. The more I experimented, the more ideas I had, and the more I wanted to explore what was possible.
That experience is real, and I don't want to diminish it by immediately responding with a list of warnings about everything that can go wrong. Part of what makes this moment interesting is that we don't know the boundaries of what is possible yet. We are still experimenting with the technology, learning how to interact with it, developing new workflows, and discovering things we didn't know to ask for a year ago. When I use the word frontier, that sense of possibility and discovery is a large part of what I mean.
The problem comes when we begin treating the ability to make something work as evidence that we understand everything required to build it well. Those are two different things. An application can look complete while containing security vulnerabilities that haven't revealed themselves yet. It can work perfectly for the handful of people using it today while being completely unprepared for what happens when that number becomes a few thousand. It can handle the path we expected users to take while failing badly when they do something we didn't anticipate. There are questions around error handling, data integrity, maintainability, performance, privacy, future features, and a long list of other concerns that may not become obvious simply because the software appears to work.
None of this is unique to AI-generated software. Experienced software engineers have been dealing with these problems for as long as we have been building software. We make architectural decisions that eventually need to be reconsidered. We introduce bugs. We misunderstand requirements. We discover that users behave differently from what we expected. We design something for today's needs and later discover that tomorrow's requirements don't fit comfortably into what we created. Experience and engineering discipline have never given us the ability to predict everything that will happen inside a software system.
What experience does give us is a collection of principles and practices for dealing with that uncertainty. We test because we know our assumptions can be wrong. We think about architecture because today's implementation decisions can affect what becomes possible later. We consider security because software operates in environments where people and systems will interact with it in ways we may not intend. We pay attention to what happens after software is released because the system and its users will often tell us things we could not have known while we were constructing it. Over time, those practices become part of how an experienced builder learns to navigate software construction.
AI doesn't make those principles unnecessary simply because it can generate the implementation for us. If anything, the speed at which we can now move from an idea to something that looks like working software makes understanding those principles even more important. When construction becomes easier, it becomes easier to move quickly past questions we don't yet know we should be asking. Someone who is new to building software may not know that a particular architectural decision will become painful later, or that the authentication flow the AI produced has a security problem, or that the way data is being stored will create difficulties once the application grows. The AI may produce something that works well enough to keep the builder moving without making those concerns obvious.
This is where I think we have to resist treating AI like a magic wand. The story cannot simply be that someone can sit down with an idea, prompt back and forth with an agent for a while, and come out the other side with market-ready software. We can celebrate the fact that someone now has the ability to create something they could not have created before while still being honest about everything involved in turning that creation into software people can depend on. Those positions don't contradict each other.
For me, building well means establishing a workflow that supports responsible construction rather than simply pursuing output. That workflow needs enough flexibility to allow the builder to pivot when the software reveals that an assumption was wrong or when the direction needs to change. It requires paying attention to what the system may be telling us as it develops, maintaining some awareness of the people who will eventually use it, and thinking beyond whether the feature immediately in front of us works. Security, code quality, future features, maintainability, and the possibility of needing to scale are all part of that larger responsibility.
This is also why I don't believe AI changes the definition of expertise as much as it changes where and how expertise gets applied. Someone who has spent years learning how to design systems, reason about tradeoffs, recognize failure modes, understand security concerns, or maintain complex software hasn't suddenly lost that expertise because an AI agent can generate code. The implementation of some of those practices may change as our construction methods change, and I expect we will continue discovering new practices that are better suited to agentic development. The underlying need for sound judgment and responsible construction remains.
So when I picture this expanding gate into a new frontier, I don't imagine a gate opening onto a highway where someone has already mapped the shortest route and placed signs telling us exactly how to get where we're going. I imagine something much larger and less predictable, with different paths worth exploring and destinations we may not even know exist yet. The fact that more people can enter that landscape is exciting to me, but entering it doesn't guarantee that every path leads where we thought it would.
The gate provides access to the journey. What we learn about navigating the frontier will determine what we are able to build once we're inside.
How We Respond
Whenever a technology changes the way people participate in something that previously required specialized knowledge, there are going to be different reactions from the people already there. Software construction is no different. As I've spent more time building with AI and paying attention to the conversations happening around it, I've noticed several responses to this widening gate. I understand some of the concerns behind those responses because I share many of them. Where I sometimes differ is in what I believe we should do about those concerns.
There are experienced software engineers who look at people building applications through prompts without understanding much of what is happening underneath and become concerned about where all of this is headed. I understand that reaction because I share many of those concerns. There is more to building software than blindly prompting an AI agent back and forth, what has become commonly known as vibe coding, until something appears on the screen that can be packaged and sold. When you've spent years dealing with production systems, security vulnerabilities, architectural decisions, performance problems, failed deployments, strange edge cases, and all of the other things that come with maintaining software after the excitement of building it has passed, it can be frustrating to hear software construction reduced to a conversation about how quickly someone can generate an application.
The concern itself isn't the problem. I think we should be concerned about the quality of what we build, regardless of whether the person constructing it has twenty years of experience or started experimenting with AI six months ago. The problem begins when we decide that someone who didn't come through a traditional education or gain practical experience in the way we did should not be taken seriously as a builder. It also happens when we refuse to recognize AI as a legitimate tool for software construction because it changes a process that has been familiar to us for a long time.
There is a difference between protecting the integrity of the craft and protecting access to it. I believe the integrity of software construction deserves to be protected. The widening of access should not be accompanied by a story that diminishes the complexity of building quality software or suggests that those concerns are artifacts of an older way of working. Security still matters. Architecture still matters. Code quality still matters. Understanding how a system behaves beyond the happy path still matters. The fact that someone can now begin building without first spending years learning how to write code doesn't make any of those things less important. It means we need better ways of helping people understand why they matter.
If someone showed me an application they had built entirely by prompting AI, without understanding much of the code underneath it, my first response would not be to tell them they had no business building software. I would congratulate them. They took an idea and created something that works, and that is an accomplishment. After that, I would start talking with them about the things they may not have considered yet. Depending on what they built, that conversation might involve security, code quality, scalability, testing, data integrity, or whatever else applies to the system. I might point them toward resources that could help fill some of those gaps, mentor them through some of what they are learning, or, if the situation called for it, offer professional services to help them take the software further.
That response is very different from gatekeeping, but there is another response to this frontier that has been almost the opposite. Instead of seeing the widening gate as something that threatens the craft, some people see a rapidly expanding market of people who want to build. The opportunity itself is legitimate. More people building software means more demand for tools, education, consulting, platforms, and services that help them do it. I don't have a problem with anyone building a business around that demand.
What I do have a problem with is selling the dream instead of providing the value. We've all seen some version of the advertisement promising ten prompts that will take you from zero to a $10,000-a-month SaaS business, or the webinar where someone with no experience is supposed to arrive on Friday and leave the weekend with a market-ready application. That kind of messaging takes something true about this moment and stretches it until it becomes something I consider snake oil. Yes, AI has lowered the barrier to building software. No, lowering that barrier does not mean everything required to build, launch, operate, and grow quality software has become trivial.
There is a significant difference between someone who uses their experience to guide another builder through territory they may not understand yet and someone who sells them the dream that the difficult territory no longer exists. One offers knowledge, time, experience, and quality service. The other offers the dream. Whether they genuinely believe the dream they're selling doesn't make much difference to me. The person entering the frontier is still being given the impression that access to the gate means someone has already cleared the terrain on the other side.
There is another group, though, whose response I think deserves a different kind of consideration because their concern isn't really about the new builders coming through the gate at all. These are experienced builders who are trying to understand what this change means for them. They have spent years, sometimes decades, learning how to construct software. They know their languages, their tools, their patterns, and the development process through which they have practiced their craft. Now they are watching AI alter parts of that process, and what they love about building is beginning to look different.
For some of them, the questions are deeply personal. If I spend less time writing the code myself, what does that make me? If AI becomes increasingly capable of doing something I spent years learning how to do, where does my experience fit? Will the role I've built my professional identity around still exist? Do I have to re-identify myself in order to remain part of this field? I don't think those questions should be dismissed as fear of change. When something you have invested a significant part of your life learning begins changing rapidly, it is reasonable to stop and consider what that change means for you.
At the same time, I don't think refusing to explore AI is a good long-term answer. Technology has a long history of moving forward while people are still deciding whether they want to participate in the transition. There were programmers who became deeply invested in languages and development environments that eventually stopped being the center of the industry. Some adapted their experience to newer ways of building, while others continued practicing the familiar way until the opportunities available to them became narrower. I think experienced builders who refuse even to experiment with AI-assisted or agentic development run a similar risk of allowing the industry to move around them.
This is probably a good time for some reflection about why we build software in the first place. If the way we have practiced the craft begins to change, then it may be worth digging beneath the tools and processes we have grown attached to and asking what actually drew us to building. Is it truly the act of writing code itself, or is there something deeper about solving problems and creating things that has kept us here? I think there is a larger conversation to be had around that question, but for this frontier the important point is that a change in how we build does not necessarily mean the builder has lost their place.
There is another response available, and this is the one I find myself increasingly drawn toward because it reflects much of my own journey with AI. An experienced builder can enter the frontier with curiosity, bring what they already know about software construction with them, and begin experimenting with how that knowledge applies in this new environment. They don't have to pretend that every old practice transfers perfectly, and they don't have to pretend that AI has solved problems it clearly hasn't solved. They can research, experiment, practice, learn where the technology performs well, discover where it falls short, and begin developing workflows that combine what they already know with what they are learning.
I think of the builders taking this approach as guides, although not because they are standing at the entrance with a complete map of territory everyone else needs to follow. We are too early for anyone to honestly claim they possess that map. They are out in the frontier as well, learning through practice and experimentation while bringing enough experience to recognize some of the terrain. Sometimes guidance may mean teaching someone a principle that software engineers have understood for years. Other times it may mean sitting beside another builder and saying, "I don't know the answer to that either. Let's find out."
Experienced software engineers aren't the only people who can eventually occupy that role. Someone may enter software construction through AI as a novice, discover that they love building, and then become serious about learning what they don't know. They can spend countless hours experimenting, reading books and documentation, following technical discussions, watching experienced builders, and studying the areas where their knowledge is thin. Over time, they develop experience of their own. Their path into the craft may look different from mine, but the willingness to learn, practice, and take responsibility for what they build matters far more to me than whether their starting point looked like mine.
This is where I believe stewardship becomes important. If this really is a new frontier, then our responsibility is not to close the gate, pretend there are no dangers beyond it, or claim we already know every path through it. Our responsibility is to take what we know, remain willing to discover what we don't, and begin figuring out how the principles of responsible software construction should be translated into this new era.
Stewarding the Frontier
When I talk about stewardship in this new era, I'm not suggesting that experienced software engineers have been handed the responsibility of standing at the gate and teaching everyone else the proper way to build. That would simply create another version of the hierarchy I've already argued against. We are still too early in this transition, and the ways we build with AI are still being formed. Experienced engineers have an enormous amount of knowledge to contribute to that process, but we are learning too.
That means the responsibility for shaping this frontier belongs to everyone who chooses to participate in it. Each of us enters with a different perspective and eventually develops experience based on the path we take. Someone who has spent twenty years building enterprise software will recognize problems and patterns that a new builder probably won't see. At the same time, someone who entered software construction through AI may discover a way of interacting with an agent that the experienced engineer never considered because they aren't carrying the same assumptions about how software is supposed to be built. One person's experience doesn't invalidate the other. Both can contribute something useful to a field that is still figuring itself out.
I think this is especially important for experienced engineers to understand because stewardship isn't simply the preservation of everything we already know. It requires translation. Many of the principles we've learned through years of software construction are not suddenly obsolete because AI has entered the process. The reason we think about architecture, testing, security, maintainability, observability, and the needs of users hasn't disappeared. What may change is how those principles are implemented when more of the construction is being performed through collaboration with AI agents.
That translation requires experimentation. There will be practices we've used for years that transfer naturally into agentic development, others that need to be modified, and probably some that no longer make sense in the form we've known them. The important question isn't whether we can force the new way of building to look exactly like the old one. We need to understand what a principle was protecting or enabling in the first place, then determine how to preserve that value within a different construction model. Sometimes we'll already know the answer. Other times we'll have to build something, observe what happens, get something wrong, adjust the workflow, and try again.
That process is part of what building well means to me. I don't think responsible software construction can be reduced to a checklist that we run after an AI agent finishes generating an application. It starts with establishing a workflow that gives us room to think, observe, evaluate, and change direction when necessary. Software has a way of telling us things while we're building it. An architectural decision may begin creating friction. A feature may expose an assumption we didn't realize we were making. The way people actually use something may tell us that we misunderstood part of their need. A responsible workflow has to leave enough room for us to hear those signals instead of becoming so focused on generating the next feature that we move past them.
There are also responsibilities that don't change simply because the construction process becomes faster. We still need to think about security and the quality of the code being produced. We still need to consider what happens when the software grows, when new features are added, or when the number of users changes. We still need to understand enough about what we've built to recognize when something isn't behaving the way it should. AI can participate in all of those activities, and in some cases it can help us perform them better, but using AI to help carry the responsibility doesn't remove the responsibility from the builder.
For someone entering software construction through AI, stewardship may begin with something as simple as being willing to learn what you don't know. You don't need to become a twenty-year software engineer before you're allowed to build something useful, but you should remain curious about the gaps in your understanding. If you encounter a concept you don't understand, learn about it. If someone with more experience points out a concern you hadn't considered, don't treat that as evidence that you don't belong. Treat it as another part of learning how to navigate the terrain.
For the experienced builder, the responsibility looks somewhat different. We have years of accumulated knowledge that can help shape how responsible AI-assisted construction develops, but contributing that knowledge requires us to participate. We have to experiment enough to understand where our existing principles fit, where their implementation needs to change, and where the new construction model introduces concerns we haven't dealt with before. Stewarding our experience means more than repeating the practices that worked for us in the past. It means doing the work required to translate the wisdom behind those practices into the environment that is forming now.
Those of us who find ourselves becoming guides have another responsibility as well. We need to keep experimenting, keep learning, and share what we discover. Sometimes that will happen through mentoring or coaching. Sometimes it will happen through writing, speaking, teaching, building in public, or simply helping another builder work through a problem. I think there is room for more voices in that conversation, not fewer, because no single person or group has enough experience with this new way of building to tell the rest of us exactly what it will become.
That is ultimately why I remain excited about this frontier even while taking the risks seriously. More people being able to build means more ideas have an opportunity to become something real. People who understand problems deeply can participate more directly in creating solutions to them. Experienced builders have new ways to practice the craft we've spent years developing, and people who never imagined themselves building software can discover abilities they didn't know they had. At the same time, all of us have an opportunity to participate in figuring out what responsible construction should look like as the tools continue to evolve.
I don't think our job is to close the gate because the terrain beyond it can be difficult, and I don't think we should stand outside selling people the promise that the journey will be easy. The gate is already open, and the frontier beyond it is still being discovered. Our responsibility is to enter it with curiosity, bring whatever experience we have with us, remain willing to learn from people whose experience is different from ours, and help each other figure out how to build well in a landscape none of us has completely mapped yet.