Coding May Be Solved. Engineering Moves Up the Stack.

When an engineer hears GPT, they probably think Generative Pre-trained Transformer, the GPT in ChatGPT.

Economists have used the same initials for something larger: General Purpose Technology. In their foundational work on GPTs, Timothy Bresnahan and Manuel Trajtenberg described technologies with three important qualities: they spread across many sectors, continue improving over time, and make new inventions and processes possible elsewhere.

Steam power. Electricity. The internal combustion engine. Computers. The internet.

These technologies did not merely make an existing task faster. They became foundations on which economies, industries, institutions, and everyday life reorganized themselves.

AI is beginning to show the same pattern. It is appearing in software, medicine, education, science, law, finance, design, manufacturing, and ordinary office work. The underlying models keep improving. More importantly, every improvement creates room for complementary innovations that could not have been justified or imagined before.

That is why it is a mistake to treat AI as a feature, a chatbot, or a more convenient way to search. Those are applications of the technology, not the full technology.

Electricity was not a better candle. The internet was not faster mail. AI is not autocomplete with better marketing.

It is a new layer of capability beneath almost every kind of knowledge work. As it spreads, it will change not only what we do, but how we organize people, how we define expertise, what we teach, what we fund, and what becomes possible for one person to attempt.

I will return to the broader GPT argument in a future note. Here, I want to follow one part of it that I can already see clearly: what happens to software engineering when implementation stops being scarce.

I sometimes describe myself as a time traveler. Not in the science-fiction sense, but because one lifetime has allowed me to inhabit very different technological worlds.

That experience has taught me the value of temporal awareness: the ability to step outside the present and ask what was normal before, what feels normal now, and what might become normal sooner than we expect. Without that habit, we mistake the current arrangement of the world for something permanent.

I grew up in Kolong village in Kamobo, Nandi County, without electricity, running water, or access to technology. I had questions about radios and digital watches before I had the words to explain what I wanted to know. I had never used a computer when I arrived at Tulane University in 1998 to study computer engineering.

My first technological life was defined by absence. Tools were scarce, answers were difficult to reach, and geography set hard limits around what a curious child could see.

My second began in a university engineering lab. I learned to type while learning Unix and Solaris because those were the machines available through the night. I used Pine for email and worked through terminals before a graphical browser could define the internet for me.

Then I encountered the young web.

I arrived in time to watch the first browser wars unfold. Netscape Navigator and Microsoft Internet Explorer were fighting to define the doorway into a medium that still felt unfinished. Netscape's story, including the engineers racing to release its source code as Mozilla, was captured up close in the documentary Code Rush. To me, the browser did not feel like just another application. It felt like a passage into a world that was still being invented.

The web collapsed distance. Code written in one room could be downloaded in another country. Two developers who had never met could combine their work. An organization I would never visit could install software I had built. A young engineer outside the usual centers of technology could create something that traveled farther than he could.

Curiosity kept pulling me deeper into the web. In 2003, it led me to help launch osTicket. Ancient by software standards, it is still used by organizations around the world more than two decades later. I have written more about that unlikely beginning in The First Build and about the responsibility of sustaining useful software in Useful Work Outlives the Announcement.

But reach was not enough. Building software still meant finding servers, configuring them, predicting capacity, and paying for infrastructure before knowing whether an idea would work. Cloud computing changed that. Infrastructure became available on demand. A small team could deploy, learn, and scale without first becoming a data center operator. The cloud did for computing capacity what the web had done for distribution: it turned a fixed barrier into something a builder could consume as needed.

Now I find myself in a third technological life, defined not by absence or access, but by agency.

AI does more than make knowledge available. It acts on knowledge. It drafts, renders, tests, explains, explores, compares, and implements. The web gave us global access to information and distribution. AI is adding execution.

The change feels less like adopting another tool and more like time travel.

Over the years, I have accumulated ideas I believed were worth exploring: ways to route questions to the right experts, preserve collective knowledge, connect people in real time, and make help easier to find. Some of those ideas were good. Some were probably overcomplicated. None were short of ambition.

What I often lacked was not imagination. I lacked time, a team, funding, and a practical path from the full idea in my head to something real enough to test.

Many builders have an archive like this: domain names we bought, sketches we saved, prototypes we abandoned, and ideas that arrived before we had the resources to give them a fair chance.

AI changes the economics of that archive.

An idea that once required a designer, product manager, frontend engineer, backend engineer, infrastructure support, and months of coordination can now be explored by one capable person in days. Not finished. Not made reliable, secure, and durable. But made visible enough to confront reality.

That is a form of time shifting. AI reaches into the years we thought a project would require and pulls part of that work into the present. It reaches into a builder's past and makes old ideas newly testable. It lets a small team borrow execution capacity that previously belonged only to a much larger organization.

This compression of time is one expression of AI as a general-purpose technology. Its effect is not limited to a task called “coding.” Like the web, it changes the cost of coordination, the shape of companies, and the boundary between what a person can imagine and what they can attempt.

The web made geography porous. The cloud made infrastructure elastic. AI is making time, team size, and accumulated knowledge porous too.

When a general-purpose technology changes the cost of doing work, it eventually changes the organization of the work itself.

General-purpose technologies do not transform the world on the day they arrive. They move through a diffusion lag: a period when the capability exists, but people, companies, institutions, and complementary technologies are still learning how to reorganize around it. Economists have studied this diffusion of general-purpose technologies because adoption is not a switch. It is a long process of invention around the invention.

That lag can look like disappointment. The early technology is awkward. The hype gets ahead of reality. Incumbents bolt the new capability onto old workflows and wonder why productivity has not immediately changed. Skeptics point to the friction as proof that the entire thing is a fad.

But the lag is not empty time. It is the opportunity.

It is where entrepreneurs discover use cases, teams redesign workflows, business models emerge, and norms begin to shift. The first-order effect is usually obvious: the new technology performs an existing task faster or more cheaply. The more consequential effects arrive later, when people redesign the surrounding system around what the technology now makes possible.

Code generation is a first-order effect of AI.

The reorganization of software work is a second-order effect.

Software teams divided themselves into roles for good reasons.

A product manager clarified needs and priorities. A designer translated them into journeys and interfaces. A frontend engineer turned the interface into behavior. A backend engineer built the systems, rules, and data beneath it. Work moved from one function to the next because each stage required specialized tools, knowledge, and time.

Those disciplines still matter. The handoffs are what are collapsing.

AI makes it possible for a backend engineer to sketch and test an interface before committing to an API. It allows a frontend engineer to inspect data models, trace a request through the server, and propose a coherent contract. It gives a product-minded engineer enough visual capability to make a workflow tangible. It allows someone close to a customer problem to turn context into a prototype without waiting for a chain of translation.

The result is not that design, frontend, backend, and product management vanish. It is that their essential skills escape the job titles that contained them.

• Design becomes the responsibility to understand people, workflows, interaction, clarity, accessibility, and taste.
• Product management becomes the responsibility to frame the problem, choose what matters, sequence the work, and define the outcome.
• Frontend engineering becomes the responsibility to make the system understandable and useful at the point where a person experiences it.
• Backend engineering becomes the responsibility to preserve rules, integrity, security, performance, and the consequences hidden beneath the interface.

These are no longer stations on an assembly line. They are perspectives that must coexist inside the act of building.

That does not mean good software abandons boundaries. The opposite may be true. Backend and frontend contracts can become more explicit even as the people responsible for the product understand both sides. Human ownership can expand across the system while the architecture preserves disciplined separation of concerns. The roles converge around the outcome; the system remains coherent through clear boundaries.

The collapse of role boundaries does not mean every engineer becomes equally skilled at everything. Deep specialization will continue to matter, especially where the consequences are serious. It means no engineer can declare the product someone else's responsibility simply because the problem crossed a familiar boundary.

The future does not belong to the person who is mediocre at every layer. It belongs to the person who is deep somewhere, fluent across the system, and capable of integrating what the whole product requires.

Making one part of a system faster does not make the entire system equally fast. It reveals the next bottleneck.

AI is accelerating a growing share of repeatable software work: generating routine implementation, explaining unfamiliar code, producing test cases, scaffolding interfaces, summarizing documentation, and exploring common patterns.

As that layer becomes cheaper, the unresolved work becomes more important, not less.

That remainder includes:

• Choosing a problem worth solving.
• Understanding what the customer is actually trying to accomplish.
• Seeing second- and third-order consequences across a system.
• Making tradeoffs when every option has a cost.
• Exercising taste when several answers are technically valid.
• Designing architecture that will remain coherent after the prototype.
• Knowing when the generated answer is confidently wrong.
• Taking responsibility for what happens after the software meets reality.

AI can generate implementation, propose an architecture, critique a workflow, and help us see tradeoffs we might have missed. It will do more and more of the work we currently call engineering. We can delegate choices to AI. We cannot delegate responsibility for their consequences.

When answers become abundant, judgment becomes expensive.

This is the part of the current conversation I think we risk missing. We keep measuring AI by how much code it writes, as if code were the final output. Code is an intermediate artifact. The output is a change in the world: a person completes a task, a team coordinates better, a business keeps a promise, or a customer no longer experiences a particular frustration.

As generated code becomes less impressive, engineering moves up the stack.

For years, “full-stack” usually meant someone who could work on both the client and the server. That definition is now too narrow.

The engineer required by this moment must work across the whole problem.

They need enough customer understanding to know why the work exists. Enough product judgment to distinguish the essential outcome from a pile of requested features. Enough design thinking to make a workflow clear. Enough technical depth to build a sound system. Enough operational maturity to consider security, reliability, maintenance, and cost. Enough humility to ask where their understanding is weak.

Most importantly, they must be willing to own a decision.

Ownership is not doing every task alone. It is ensuring that the problem does not become orphaned between functions. It is pulling in deeper expertise when the work requires it, while remaining responsible for the coherence of the outcome.

That changes what is expected of an engineer:

• Do not begin with the ticket. Begin with the problem.
• Do not wait for a perfect specification. Find and resolve the ambiguity.
• Do not treat the first generated answer as a decision. Expose its assumptions and tradeoffs.
• Do not keep the model in your head. Write the RFD, draw the workflow, build the prototype, and let others challenge it while change is still cheap.
• Do not measure yourself by code produced. Measure whether the system became more useful, coherent, and trustworthy.
• Do not compete with AI at remembering syntax. Upgrade your judgment faster than the tools upgrade around you.

I have called this person a design engineer, a product thinker, a cross-functional polyglot, and sometimes simply a strong engineer. The title matters less than the direction.

The engineer must interpret the customer, the system, the constraints, the evidence, and the consequences; they must then turn that understanding into something that works.

There is an exhilarating side to this change.

For most of software history, ambition was constrained by headcount and capital. A small team had to narrow not only its product, but often its imagination. Many ideas were not disproven. They were never attempted because the cost of learning was too high.

AI lowers that cost.

Small teams can now explore more, test earlier, and operate with the leverage of organizations many times their size. People in places far from established technology centers can use the same models and development capabilities as people inside them. A builder in Eldoret can work at the edge of a global technical shift without waiting for the shift to be packaged and imported later.

But greater leverage also raises the standard. When everyone can produce more, volume stops being an advantage. Speed becomes the baseline. More software will be built, not less, because every improvement in efficiency expands what people attempt.

The advantage moves to the team that knows what not to build. The team with the clearest customer understanding. The team that protects architecture while moving quickly. The team that can tell the difference between output and progress.

Capacity is becoming purchasable. Clarity is not.

I began in a village where modern technology was largely absent. I met the computer late, then arrived in time to experience the web while it was still being imagined. I watched the web turn distance from a hard boundary into a design constraint. I built software in one place that found users around the world.

Now I am watching the boundary move again.

The web made it possible to sit in a room and reach the world. The cloud made it possible to build and operate without owning the infrastructure. AI makes it possible to sit in that same room and attempt work that once required years, funding, and a much larger team. For someone whose life has crossed from no technology, to the early web, to cloud computing, to this moment, it can feel like living in different centuries without leaving one lifetime.

Yet the most important abilities have a familiar shape.

The village taught me to observe closely, work with constraints, improvise with what was available, and care whether a solution held up in real life. The web gave those instincts reach. The cloud gave them scale. AI gives them leverage.

None of the tools removes the responsibility to think.

But they radically expand who can get far enough to exercise that responsibility.

Work that was once prohibitively difficult is becoming accessible. An idea that once required a department can now be explored by one curious person. A concept that might have died for lack of funding can become a working prototype before the first funding conversation. A problem that once demanded months of coordination can be tested while the insight is still fresh.

The impossible has not become automatic. It has become attemptable.

That may be the most consequential change of all. For much of my early life, technology was not simply a tool I lacked. It was a barrier between curiosity and the ability to act on it. Today, people beginning in places like Kolong can reach capabilities that were once concentrated inside wealthy companies, well-funded laboratories, and established centers of technology.

This may be the best time in history to be an innovator, not because success is guaranteed or the difficult parts have disappeared, but because the cost of a serious first attempt is collapsing. You no longer need a large team, substantial funding, the right geography, or permission from an institution simply to discover whether an idea might work.

AI can propose tradeoffs, critique designs, and even help us develop better taste. What it cannot do on our behalf is establish the values and context by which a choice should be judged or accept responsibility for the consequences. But it can give far more people the leverage to turn curiosity and courage into something real.

So yes, coding is solved, or near enough that the phrase forces the right conversation.

AI will do more and more of the work we currently call engineering. That is precisely the point. As implementation becomes abundant, the engineer’s value moves from producing every artifact to choosing, composing, verifying, and taking responsibility for the whole.

The scarce layer is engineering taste. It means recognizing which of many plausible answers is right for this user, this system, and this moment; it also means knowing what should not be built at all.

Taste without consequences is preference. Engineering taste is judgment trained by experience, informed by evidence, disciplined by constraints, and revised when reality disagrees. It is the work of making sure our expanding ability to build is matched by an equally serious ability to choose.

The code is becoming the easy part. The first build is within reach of more people than ever.

What we do with that freedom will define the engineer, and it may allow the next important technology to be built by someone technology once excluded.