At one point in my career, I was opening books in the University of Washington library to work out the mathematics for a mapping application.

I was building a globe in Silverlight, importing map tiles, and figuring out how to render them in the right places. To get it working, I had to understand how the coordinates, geometry, and imagery fit together. A quick web search wasn't turning up the answers I needed.

Today I'm building Taproot with AI coding assistants. An agent can help me investigate an unfamiliar system, propose an implementation, write tests, and review a change. That gives me a very different way to approach the work.

In between, I spent decades building desktop applications, websites, mapping systems, software that controls physical machinery, and internal business applications. I've worked at every layer of software engineering: front ends, application logic, databases, and the pipelines that get software into production.

That history shapes how I use AI. It gives me a starting point when I decide what to ask, which assumptions to question, and how to check the result.

Getting my feet wet

I earned a BS in Computer Information Systems at DeVry. The curriculum covered everything from BASIC to C++ to COBOL, with plenty in between, so moving between languages was part of learning to program from day one.

My first job was fixing Y2K bugs for a company that built hotel property management systems. I started in Delphi, working on software that already had a purpose and people depending on it.

Maintenance is a good introduction to professional software development. Before you change anything, you have to understand enough of the existing system to avoid breaking it. The code in front of you carries decisions made by people working under constraints you may not see right away.

During my five years there, .NET arrived. My manager wanted to use it for the next version of our software, so I moved from Delphi to the new platform.

That was my first taste of something that kept happening throughout my career. I was learning a technology while using it to solve a real business problem.

Building interfaces, then arguing with browsers

After that, I contracted at Microsoft on the team building Visual Studio, where I helped develop the WinForms auto-layout features.

People mostly notice layout when it goes wrong. Controls need to fit together and behave sensibly when their surroundings change. That work put me on the other side of the tools, building features other developers would use to build their own applications.

My next role took me into web development at a company building event websites for Microsoft.

This was when jQuery was the cool kid in town and Internet Explorer 6 could eat what felt like 85% of the working day.

I got to know HTML, CSS, and browser layout bugs very well. A page that looked right in one browser could fall apart in another. Fixing it took patience and a willingness to dig several layers below the feature I thought I was building.

That still matters when I work with generated code. An implementation can look reasonable and still behave badly where it actually runs, so I have to exercise the result.

Sometimes you have to learn the mathematics

At a startup building mapping software for emergency preparedness and disaster planning, the work got complicated in a different way.

The mapping application was written in WPF. It pulled together elevation data, shapefiles, collision detection, road graphs, routing algorithms like Dijkstra's, and map projections.

All of those pieces had to agree with one another. A route depends on how the roads are represented and connected. A shape has to show up in the correct location. Elevation adds another dimension to account for.

I personally built a Silverlight map viewer, including the globe and the code to import and render map tiles. That was the project that sent me to the university library.

That's a good picture of what full-stack work has meant for me. Sometimes the next layer you need to understand is geometry.

Now AI gives me another way into unfamiliar material. An assistant can explain an algorithm or help me investigate an implementation. I still have to work out whether the explanation applies to my problem and whether the implementation behaves correctly.

Experience helps me see where that checking needs to happen. It also reminds me how much I still have to learn.

Ballot sorters and business software

In another role, I built software around an OPEX Mail Matrix machine to sort voting ballot envelopes. The machine had to scan envelopes, perform OCR, validate signatures, and direct each envelope into the right bin for its voting district.

Part of that application's output was a physical envelope landing in a physical place. In the lab, I could see exactly what a software decision did.

Later, I worked for several companies building internal web applications across the full stack. Those systems tied together the user experience, business rules, data, and the processes for managing complex tasks. I was responsible for the whole process.

The tools changed along the way

Over the years, I've built software in C#, JavaScript, TypeScript, and Go. My production web work has run from jQuery and Backbone through Angular, React, Aurelia, and Vue. For Taproot, I built a zero-dependency design system from scratch using Lit, which fits my general preference to avoid third-party packages.

I've also published sites with raw HTML, WordPress, Ghost, and Hugo. That gives me several points of comparison when I think about what a publishing platform should make easy.

On the data side, I've worked with SQL Server, MongoDB, and Postgres. I've built CI/CD pipelines with everything from NAnt and Jenkins to Azure DevOps and GitHub Actions, with TeamCity and CircleCI along the way.

That range pays off at the boundaries. A slow screen may be waiting on a database query. A painful deployment may expose an assumption in the application. A framework that makes the first feature easy may get in the way of a later requirement.

Because I've worked on each side of those boundaries, I have more depth when I evaluate how to solve a problem, and more alternatives to weigh before I commit to an approach.

Bringing that experience to AI and Taproot

Taproot is where I'm applying all of that to a new way of working.

We're building a publishing platform and refining how we use AI throughout development as we go. That covers defining the work, investigating the existing code, implementing changes, reviewing them, and verifying the result.

I've already written about why we keep our backlog in Git. Keeping it there means the explanation of the work lives right alongside the implementation. An assistant picking up a task needs the intended outcome, the constraints, and the decisions that came before it.

My experience helps me supply that context and judge what comes back.

If an agent proposes an abstraction, I can ask whether it earns its maintenance cost. If a change crosses the interface, API, and database, I can follow the contract through those layers. If the tests pass, I can still ask whether they exercise the behavior that matters.

There's also room for the assistant to push back on an approach I'm comfortable with. I've used a lot of patterns for years, so I'm happy to ask an AI assistant for suggestions and weigh them against decades of experience.

I'm still working out how to make this process more effective and efficient, and part of that is how we enforce coding standards on AI-written code. Working fast only helps when it moves the project toward a dependable result.

Making more things possible

For someone getting started, AI offers another way into work that can otherwise feel out of reach. You can ask for an explanation, try an approach, and dig into what happened. I feel like I've learned more in the last six months working with AI than in the decade before.

There's a lot to learn along the way. Learning how to describe a problem, inspect a result, and recognize when you need help gives you a stronger foundation for the next project.

I wrote more about where I hope this leads after riding in Waymo robotaxis in Las Vegas: a future where AI and robotics take on the rote work and give people more time for art and creativity.

For a business owner, the same possibilities come with practical decisions: what to build first, which requirements matter, what can stay simple, and how the software will be maintained after its first release.

Those are the decisions I want to help with. I bring 26 years of experience across the stack, along with an ongoing effort to understand how AI can improve the way I work. Taproot gives me a place to put those ideas into practice and share what holds up.

If you have a product or internal tool you want to build, I'd welcome a conversation about what it would take to make it useful, reliable, and maintainable.