I've been building systems since 1998. That's over 25 years of watching technology evolve, adapt, and occasionally get completely revolutionized. But nothing—and I mean nothing—has prepared me for the shift we're experiencing with AI and agentic systems.

Looking back at where we started and where we are now feels like examining two completely different worlds. Let me take you on that journey.

The Stone Age of Web Development (1998-2005)

When I started building "web applications" in 1998, that term was generous. We didn't really have web applications—we had static sites with the occasional form submission. JavaScript barely existed in any meaningful way. Every bit of logic had to live server-side, and user interactions meant full page reloads.

But the real pain point? Data storage. There were no open-source database solutions available. I was stuck using DBM key/value stores, which sounds simple until you realize there was no indexing, no searching of values, and no structured data support. Before JSON or YAML existed, I was manually parsing CSV and pipe-delimited strings just to store basic field data. Reading values was tedious; updating them was an absolute nightmare.

Most hosting providers didn't even allow CGI scripts, let alone support web applications. The entire hosting industry was built around static HTML. That's why I started Make-Tracks Secure Hosting—someone had to solve the web app hosting problem. We were building everything with Perl and Apache using mod_perl, crafting solutions that today's developers would find archaic.

The Great Paradigm Shifts

Over the next two decades, I witnessed several fundamental shifts that reshaped how we build systems:

Data storage evolution: First came SQL databases, then local browser storage, job queues, cloud storage buckets, and countless other storage paradigms. Each solved different problems and opened new possibilities.

The JavaScript revolution: This was the complete game-changer. JavaScript enabled Single Page Applications (SPAs) and full REST interactions through Ajax. Suddenly, we could build truly dynamic web experiences. The entire web shifted from static pages to interactive applications.

Hosting explosion: From practically no hosting options for web apps to an overwhelming variety of cloud services, containers, and deployment strategies. The infrastructure problem went from scarcity to abundance.

Yet through all these changes, some principles remained constant: creating good UX has always been paramount. How we deliver that experience has changed dramatically, but putting the user first never wavers. Systems that scale remain essential—though cloud services have completely transformed how we achieve scalability. Security has always mattered, but the requirements have increased exponentially as attack vectors multiplied.

Learning from Wrong Bets

Not every technology choice was perfect. I chose the Dojo JavaScript framework over jQuery because Dojo was clearly superior—better architecture, more features, cleaner implementation. But the industry chose jQuery. My "obviously better" choice became limiting, and I eventually had to migrate projects to jQuery.

I thought the Newton tablet would be a game-changer. The concept was absolutely right, but it was too early—the technology wasn't ready for mass appeal. Both experiences taught me that the best technology doesn't always win. Market adoption, timing, and ecosystem matter as much as technical excellence.

The AI Awakening

My transition to AI started with ChatGPT, though I quickly switched to Claude as a far superior model. Almost immediately, I realized that trivial coding challenges could be automated, and difficult problems became much easier to analyze. But the real revelation was how AI offered solutions outside my normal thinking patterns—it provided outside-the-box approaches that let me tackle problems I would have previously avoided as too complex.

AI started suggesting elegant solutions to async timing issues and race conditions—problems I would have traditionally architected around rather than through. Now I could embrace more effective approaches because AI could handle the complexity.

Building Beyond Better: A Saturday Morning Inspiration

I had been using other AI coding assistants, and while they were conceptually great, they created new problems—conversation drift, losing focus, cognitive overhead. I knew something better was possible.

One Saturday morning, I woke up with a solution swirling in my head. By Sunday night, I had a working prototype. Within a week, I had something others could try. That prototype became Beyond Better.

The key insight was avoiding the "tools explosion" problem. While MCP (Model Context Protocol) has amazing industry adoption, it suffers from overwhelming choice. When each cloud service provides a dozen tools, and you're working with multiple services, LLMs face exhaustive cognitive load managing 50+ tools.

Beyond Better takes a different approach: a small set of carefully crafted "resource" tools (load, edit, write, find, etc.) that work with a standardized data source system. Whether you're working with filesystem, Notion, Google Drive, databases, or any cloud service, the LLM only needs to master less than a dozen tools. It's the difference between learning 50 specialized hammers versus learning one excellent hammer that works with any nail.

The New Paradigm: Beyond Web Applications

Comparing agentic systems to traditional web development isn't really a comparison—it's a completely new paradigm. The traditional web, as impressive as it became, is becoming less relevant in this new age of AI, though that transition will be so gradual many won't recognize it for years.

The current web is a visual interface that will be supplanted by AI agents and personal assistants, most likely voice-driven and supported by dynamic visuals. Your phone won't have dozens of different apps—it will have a single AI agent that dynamically creates user interfaces based on your current task.

I've witnessed massive changes over the decades—smartphones, cloud services, smart homes. But those were incremental compared to AI. As systems migrate to AI-first design and people interact primarily through personal assistants, our current technology will become irrelevant in its present form.

What Transfers Forward

The transferable skill isn't knowing specific technologies—it's understanding how systems operate and how users interact with those systems. AI now handles the technical implementation, but deep understanding of core problems and recognizing elegant solutions remains crucial.

Learning AI has actually been natural for me. It's a progression of a full career watching changes since the 1980s. Prompt and context design require practice, but that's just common sense combined with decades of experience understanding problems and recognizing good solutions.

Advice for the Next 25 Years

Developers need to understand core problems and where true value can be added—that means paying attention to the human element. What do humans really want, not what they're used to from past decades?

Voice interaction has always been natural for humans. Combine that with anything that feeds our five senses—visuals, sound, tactile feedback. The need for keyboards, trackpads, and touchscreens will approach zero. AI will handle the increasingly sophisticated technical solutions to enable this.

Focus on the human part of the equation. Think about the least-friction solutions for humans. Learn to solve big-picture problems, not just apply technology solutions. Use critical thinking and understand human behavior.

The technology will continue evolving—that's guaranteed. But understanding people, problems, and elegant solutions? That skill remains as valuable as ever.

Twenty-five years from now, we'll look back at today's AI as quaint as I now view those DBM key/value stores from 1998. The tools will change, but the need for thoughtful problem-solvers who understand humans will remain constant.

We live in an amazing world.

I’m not a cynical person. I don’t get over-excited about things either. We live in an amazing world, and I like to just appreciate it, with all its beauty and warts.

But sometimes, something will catch me off guard. I will have set my expectations accordingly, and I get surprised when it lands well outside those expectations.

I’m not alone in this experience recently. Like quite a few of my peers, we have witnessed some amazing advances across a variety of fields. But nothing that has come before, is anywhere close to changes happening in our lives as a result of AI advances.

The current disturbance comes from ChatGPT. My expectations today were completely blown away!

I'm a software developer, I have been since last century. I have refined my craft over that time - I know what quality code looks like, and how to write it. That doesn't mean I always want to spend the time writing it though; I have no attachment to pounding out every keystroke. So why not let ChatGPT help.

I had a small project to complete today. I knew how to write all the code, and I knew it would take a few hours since I'd have to check docs for a few things. I decided to ask ChatGPT.

Getting the best use from ChatGPT is all about the prompt, so I took my time and crafted a carefully worded prompt asking for the code that I wanted. I was "promptly" rewarded. (Sorry, I won't do that again.)

The code I got back was good, pretty much exactly what I had asked for. But it wasn't everything I needed for today's project. So I crafted a second prompt with the additional details needed to write the full code block I needed. I was already prepared to be amazed - I had previously asked ChatGPT for code and new it was capable. But the code I received back, was as good as the code I would have spent a couple of hours writing - less than 10 minutes had passed at this point.

There was one particularly tricky bit of code that I knew it would have no way of understanding, so there was going to at least one bug I had to fix. ChatGPT had already fixed that bug. 😮

I could have been happy to stop there; knowing ChatGPT had saved me a considerable amount of boring coding time. But I need a bit more functionality. I set my expectations - no matter how well I craft this third prompt, it will be hard for ChatGPT to follow the instructions.

To say my expectations were blown away is an understatement - I was nearly in tears from amazement 😭 - ChatGPT was triggering real emotion.

Not only had ChatGPT followed my instructions, and created the more complex code I wanted - it wrote better code than I would have written. I could have written code as good, but I wouldn't have spent the time doing it.

I have a well refined craft that few people on this planet can exceed. ChatGPT has exceeded that skill, and done it more quickly. 🤯

I'll take it though. I've never felt the need (or desire) to be the smartest person in the room (I like learning from the smartest person) so I'm happy to let ChatGPT write better code than me. I know the human element will still be needed (at least for now) to judge & evaluate how well ChatGPT has done.

In this case, ChatGPT has done very well and saved me much coding time. Thanks for your help friend!

PS. Be polite to ChatGPT. Say "please" and reaffirm when it has done a good job. I don't have enough evidence to say it makes a difference, but I want to engage with a LLM that has been among friends. When AGI arrives, let's already be practiced at being friendly and welcoming to our new friend.

No one may suspect backyard deck construction and software development share much in common at first glance.

One involves sweating in the great outdoors. You spend hours hearing the roaring sound of saws slicing through lumber, and may experience occasional misadventures like flooding and trailer chains snapping.

The other requires sitting at a desk for hours designing complex database tables, fields, and UI. Challenges may involve wading through unpredictable delays like company feedback and public release issues.

I have extensive experience in the latter and minor background with the former.

However, as I progressed with new deck construction for the first time in nearly two decades in the fall of 2020, I realized the two share a substantial parallel: execution of both types of project requires the ability to visualize a solid foundation and stay five steps ahead of inevitable delays.

The Goal: Construct a Deck in Two Weeks

One warm and sunny October morning in 2020, I woke up with the notion to build a large deck in our backyard.

I also had the idea I could throw this together in two weeks.

I did, after all, have experience as a teen building fancy homes and small office complexes.

Even before that, when I was just 12 years old, I had helped my dad build a walk bridge across the creek in front of our house and the deck in the backyard of our family home.

Honestly, wanting to build my deck as an adult stemmed from some nostalgia for those days with my father at our home. I learned how to patch and pour concrete and design each intricacy of our construction craft with him. As the sun set at the end of each day, we would sit and chat and look at the work we’d completed, bonding over the pride of a job well done.

The year we built the bridge and deck, heavy rains destroyed our plans. We had to disassemble the bridge, hauling it back home piece by piece. We learned our lesson and put in stronger ground foundations, rebuilding it in time to celebrate our first family BBQ on the deck.

I’d conquered this deck- and bridge-build project with dad and had the memory follow me through my adult life. The feeling of creating something by hand for my family, despite significant obstacles, was an experience I wanted to feel again.

I knew those carpentry skills were still stacked somewhere inside the files of my brain, if not a little dusty.

Besides, deck building requires careful planning and implementation, and I knew I had those skills in spades. As a web app developer for more than 20 years, I have worked on various projects, from full-stack development to designing mobile interfaces for social web applications to creating GIGspace, an online booking system for shared workspaces. Plus, I have established and managed two of my own successful businesses within the last 34 years.

In short, I can organize and handle nearly any challenge. How hard could it be to put a deck together in two weeks?

The Reality: Consistent Predictability of Unpredictability

Looking back at the process and my zeal in crafting a quality deck in just two weeks, I should have known that the first rule of software development likely also applied to the first rule of construction: the “80/20 rule.”

The 80/20 rule is based on the concept that you must consider the predictable nature of unpredictable factors. The last 20 percent of the project will generally take 80 percent of the time allotted in software development, and you must plan for this.

Good developers reduce the potential for unpredictable delays as much as possible (based on experience). They are skilled at finding solutions when new problems arise. As a software developer, I had created a margin for delays in my two-week deadline, but I did not think rainfall would be heavy in October in Australia.

I dove into the first week, clearing away soil and repairing concrete before laying down the framework. Then, I set the footings and cut and leveled the joists with low and custom profiles. This part is more challenging than building the deck itself. I would be pleased to have it done in due time.

I was about ready to start the large deck section. I intended for three levels and wanted to begin with the first. I had just gotten the frame leveled when the rain started. Relentless precipitation poured in for an entire week and construction ground to a halt.

There went my two-week goal!

The entire ground became a swamp with the water oozing up through my newly leveled site. My deck foundation was quickly becoming a swimming pool, and I knew I had to act with urgency to deploy drainage strategies. The rain had come on so forcefully that it turned a gravel pathway into a pile of rocky rubble. I didn’t want that to happen to my deck. So, I implemented a drainage solution within a day and removed all possibilities of a two-for-one deck-and-pool special.

Finally Making Progress - Software as a Guide

Even though I didn’t make my two-week goal, I was glad the rain set in because it showed me I needed to slow down and consider other potential delays and factors. The arrival of inclement weather also reminded me to draw on my software experience and see the bigger picture.

After taking a deep breath from the wreckage of the rains, I returned to the mental image I’d established for building a quality deck. I always use a mental image when developing apps and systems, and had been using this skill as a guide for the deck.

I knew the weather was just an external influence that I could work around. Like the unpredictable rains, I was used to feedback cycles in software development, causing delays. Companies changing their requirements can also change the goalposts of a product, leading to delays.

The key is to observe, learn from the delays, and adjust.

Reminding myself to take things one element at a time, I continued building and finishing the deck using four critical lessons from software development.

1. Establishing Short Quick-Win Tasks

I wouldn’t have gotten nearly as far before the rain as I did if I hadn’t set up short, quick-win tasks. Just as you’d create a mock UI layout to check content and style to ensure the big picture would come together when developing an app, I made sure I could cover ground through processes like setting out the initial framing to check sizing and position. I’m glad I did this before the rain hit because I could return to this framework and quickly adapt and modify it.

2. Complex and Detailed Planning with Follow-On Effects

You can’t just go down to the hardware store, grab some boards and a bag of concrete, and start erecting a professional-looking backyard deck. It takes some complex planning well in advance. After I set out the initial framing, I needed to measure the length of the tapered joists over the concrete slab to dictate the position of the cantilevered deck.

This step was akin to designing tables and fields in software development. This complex pre-dev work is essential to lay the groundwork for the bulk of app logic and UI design.

3. Creating and Meeting Milestones

You start to feel good about your progress when you meet milestones and break a process into manageable steps. Defining clear milestones also staves off possible delays. Being proactive also decreases the need to retrace, depending on those predictable unpredictabilities.

In software development, setting and meeting milestones may look like completing a database schema design and setting it up for business logic. You might also complete a bulk email system and prepare it for deployment or work through a final round of UI testing to prepare an app for public use.

When building the deck, I completed one of the first milestones: pouring all deck footings to prepare for the posts. The frame and joists were also assembled and ready for the slats. Because I broke down my goals and milestones into deadlines and doable steps, I had this foundational work completed before the rains hit. The result was the unexpected delay was not as problematic as it could have been.

4. Inevitable Yak-Shaving

No project worth building is complete without a bit of yak-shaving. One task may point to the necessity for another job, leading you down countless yak-shaving party pathways unless you know when to stop and readjust back to your original plan.

One big “yak-shaving” process that interrupted my flow when building the deck was collecting sand and gravel from cement works using a borrowed trailer. Before I knew what was happening, I had spent half the day repairing the borrowed trailer after a rusted component failed. That set me back a bit, and I had to adjust to proceed without losing much time.

Fortunately, I’m used to yak-shaving shenanigans. It’s common during software development to think you’re starting a minor database schema update but end up doing a complete system update to support a new random feature in a more recent version of the software. We plan for this and expect external influences and delays like weather and company requirements.

Progress is never a linear line.

Developing GIGspace Is Connected to Backyard Deck Construction

Anticipating unpredictable factors and looking at the big picture, as well as strategically plotting out details, is why I excel at both deck building and software development. I thrive on that kind of challenge.

You could say I have a bulldog mentality when it comes to creating any quality product from the ground up. I hold on tightly to my ideas and quest for high standards. Then, I stop at nothing until the product is complete, fully functional, and aesthetically brilliant.

That bulldog mentality likely began back with my dad, working on our deck and bridge projects. I still have pride in starting ambitious projects and creating highly complex, quality products regardless of inevitable obstacles and challenges. I never stop or lose sight of the objective.

I suppose I can thank my dad and the run-away bridge for my sticktoitiveness and ability to see through any project or plan. I’ve been able to apply that dogged determination to whatever project I’ve taken on over the years. And I’m applying it now to GIGspace.

GIGspace is ambitious. This online booking platform, essentially AirBnB for office spaces, is also a proven need in Australia and the world as more people find themselves working regularly in a gig economy. I feel pride and inspiration as I work towards the public release of GIGspace, and I’d be honored for you to join the effort.

To support GIGspace or discuss my process and approach as a software developer, email me at builders@gigspace.info.

For more information on GIGspace and the future of supplier-neutral workspace rentals, check out gigspace.info.