The Hands I Never Had

The builder was already there

I spent most of my technical career below the visible surface.

Networks. Servers. Storage arrays. NAS appliances. Firewalls. Hypervisors. Operating systems. Backup systems. Endpoint platforms. Security controls.

I knew how to make those things work together. More importantly, I knew what happened when they stopped working together.

Infrastructure teaches lessons that demonstrations tend to avoid. Systems need to be patched. Certificates expire. Networks become unreachable. Vendors discontinue products. Backups that have never been restored are mostly expressions of optimism.

A system can be technically impressive and still be impossible to operate. It can pass every demonstration and fail the first time somebody needs to recover it at two in the morning.

That background matters now that I am building software with AI.

I may not remember the syntax required to produce every component, but I understand dependencies, failure conditions, access boundaries, recoverability, and operational cost. I know that the application is not finished because the screen rendered correctly once.

I know what comes after the demo.

The part people touch

Given my background, I might have expected to enjoy backend development most.

I respect it. The backend carries the system. Without it, the interface is decorative optimism.

But the work I enjoy most is on the frontend.

I like the part that touches the user.

I care about how information is arranged, whether the hierarchy makes sense, whether the page feels coherent, and whether the artifact helps someone understand what they are looking at.

I like building things that are visually strong and useful enough to share.

That is not separate from engineering. The interface is where the architecture finally has to keep its promises.

Users do not experience the database, firewall, network path, storage tier, deployment pipeline, and security model as independent components. They experience whether the thing in front of them works and whether they can understand it.

For much of my career, I could see the gap between what the technology was capable of and what the user actually received.

I could describe that gap. I could troubleshoot it. I could sometimes automate around it.

I could not always build the experience that closed it.

Now I can get much closer.

Slides or a movie?

I recognized this instinct long before AI-assisted development existed.

About twelve years ago, I attended a large regional meeting for the Americas. I was responsible for North America. The leader responsible for Latin America and Central America was also there with her team, and both of us were introducing our organizations.

She gave a polished PowerPoint presentation.

It was a good presentation, and in retrospect, I am glad she went first.

When it was my turn, I stood in front of the room and asked:

“Folks, do you want me to spin through some slides, or would you rather watch a movie?”

I had produced a fifteen-minute video.

It used Google Earth to move across the North American sites we supported. Each location had music selected for that place. The transitions were choreographed. Humor appeared throughout it. People could see the geography, the teams, and the scope of the organization rather than reading the information from a sequence of rectangles.

People kept talking about it after the meeting.

The point was not that video was inherently superior to PowerPoint. The point was that the medium fit what I wanted the audience to experience.

The organization became visible.

The introduction became memorable.

The same instinct showed up in our support work. We were producing how-to videos while many organizations were still trying to convert every piece of knowledge into a ServiceNow article.

Sometimes an article was the right format.

Sometimes the fastest way to teach someone was to show them.

The medium was part of the solution. I was already thinking about the user experience, even though I was not calling it frontend development.

What AI actually changed

AI did not create my interest in building.

It exposed how much of that interest had been waiting behind an implementation barrier.

I can now describe what a system needs to do. I can define the audience, workflow, states, constraints, failure conditions, and visual intent. I can ask the model to produce an implementation, inspect the result, test it, reject what is wrong, and refine what remains.

I can move between the interface and the machinery supporting it.

That does not mean I possess the same knowledge as an experienced software engineer who has spent years writing and maintaining production code. Pretending those differences have disappeared would be disrespectful to the discipline and dangerous to the software.

But those differences no longer prevent me from building useful things.

The change is not merely that I can complete an old task faster.

I can attempt work that was previously outside my reachable range.

That is a larger shift than productivity.

It is expanded agency.

The industry is feeling it too

My experience is personal, but it is not isolated.

Stack Overflow’s 2025 Developer Survey found that 84 percent of respondents were using or planning to use AI tools in development. Among professional developers, 50.6 percent reported using them daily.

The trust numbers tell the more honest story. Forty-six percent actively distrusted the accuracy of AI output, compared with 33 percent who trusted it. Adoption is growing faster than confidence, which is probably the correct relationship for a tool that can produce both working software and beautifully formatted nonsense. (survey.stackoverflow.co)

DORA’s 2025 research describes AI primarily as an amplifier of the strengths and weaknesses already present in the surrounding organization. The largest returns do not come from the tool alone. They come from the technical and organizational system around it. (dora.dev)

That fits my experience.

AI is useful to me partly because I am not approaching it empty-handed. I already understand infrastructure, operations, security, recovery, service ownership, and users. The model gives those forms of judgment another way to become tangible.

A GitHub survey of 2,000 software-team respondents found that people commonly reported reinvesting time saved with AI into collaboration, learning, and system design. Many also expected AI tools to help them meet customer requirements more effectively. That is vendor-sponsored perception data, not neutral proof of productivity, but the direction is relevant. People are using implementation leverage to move closer to higher-level design and user value. (github.blog)

Research on AI-assisted end-user development is beginning to find the same opening from another direction. In one 2025 case study, most participating non-programmers successfully created a basic web application through interaction with AI assistants.

That does not prove they produced secure, maintainable, production-ready systems. It does show that the old boundary between someone who can describe an application and someone who can create one is moving. (arxiv.org)

The verification gap

The excitement needs a boundary.

AI can allow someone to produce work beyond what they could previously implement.

It can also allow them to produce beyond what they are capable of verifying.

Those are not the same achievement.

A separate study of business users evaluating AI-generated data analyses found that participants frequently failed to identify consequential flaws, even after being warned that the AI could make mistakes and being explicitly asked to inspect the work critically. (arxiv.org)

That is the risk underneath easy generation.

A person can receive something that looks finished without knowing whether it is correct. The better the presentation becomes, the easier it is to confuse confidence with quality.

The answer is not to preserve syntax as an artificial barrier around creation. It is to strengthen the disciplines around what gets created.

Source control matters.

Testing matters.

Code review matters.

Security review matters.

Bounded permissions matter.

Recovery matters.

Knowing when the model is operating outside the evidence matters.

The easier code becomes to generate, the more important judgment becomes. We should not measure progress by how many lines the machine produced. Lines of code have always been a questionable unit of value. AI merely found a way to make the problem industrial.

Knowing the whole stack matters

My advantage is not that AI suddenly made me an expert in every layer of application development.

My advantage is that I understand what sits behind the screen and what happens in front of it.

I know that a beautiful interface can hide a fragile system.

I know that a reliable backend can still produce a miserable user experience.

I know that security can be implemented so poorly that people work around it, and convenience can be implemented so carelessly that nobody should trust it.

I know that systems live much longer than the presentation that got them approved.

I have also spent years close to users. I have watched people struggle with tools designed by teams who understood the technology better than they understood the work.

That combination gives me a useful perspective when working with AI.

I can think about the full path from infrastructure to interaction.

The frontend is not a decorative layer sitting above the real engineering. It is the point where every technical and operational decision becomes visible to another human being.

That is probably why I enjoy it so much.

It closes the circuit.

The third chapter

The first chapter of my technical life was about making machines and infrastructure work.

The second was about making services work across organizations and for the people depending on them.

This third chapter may be about building the experiences directly.

I am not abandoning the backend. I am bringing everything it taught me into the part people can see.

The industry will continue arguing about whether AI makes people more productive, whether it weakens fundamental skills, whether it eliminates jobs, and where all of this eventually lands. Those arguments are legitimate. I have opinions about several of them.

They belong in other artifacts.

This one is about something that has already changed for me.

A boundary that shaped most of my technical career is no longer where it used to be.

I still do not know all the syntax.

I know what a good system looks like. I know what failure costs. I know when an interface is fighting the user. I know when an artifact communicates and when it merely occupies space.

AI did not invent the builder in me.

It gave me the hands to finish the work.

Below the glass: infrastructure, dependencies, failure modes.

Above the glass: the experience another person actually receives.