You sit down in front of Claude, Copilot, Lovable, or any similar tool in the field; you describe what you want, and... there it goes: a new, shiny website, an app, an essay, maybe a song. And if you're tired of typing in all those words and sentences, you can use your voice and tell the computer what you want. Feels good, for many reasons.
One particular benefit of this is the ability to describe what's in my mind with my own words, and hand it over to the computer. It feels more natural than learning sometimes awkward artificial languages and interfaces.

AI tools - LLMs - have become quite powerful. Their abilities include image and video generation, software code generation, and drafting documents and presentations—even songs and books.

But how did this become so easy in just a few years?

We needed a lot of things for this to happen. First, the core technology itself was already available 10-20 years ago. Then, sufficient computing power became a reality in the last few years. Then, data is needed to train the models. We already had a lot in the form of books, but with the explosion of internet usage, a whole new world of data sources was born. Agents - LLMs that can act - also need tools. Specialized software tools that can perform specific tasks very well. Search engines, compilers, image and text editors are all tools. Let’s focus on the knowledge part here.

2. How we got here

An important part of developing these models is training, which requires feeding them large amounts of existing data. Data someone produced.

We already have a lot of data, including shared experiences, working and not-working examples, descriptions of how to work, patterns, and guides. These accumulated over years and decades. Strangely, LLMs were the lamps that shed light on this pile of knowledge.

Now let's turn our attention to what has happened over the past decades in software engineering and explore the many factors that have contributed to the current state.

3. Building the knowledge infrastructure

5, 10, or 20 years ago, very different problems were considered challenging than the ones today.

For example, in software engineering, there were fewer standards and mature techniques. From a web development perspective, it was still a pioneering era. Web 2.0 was still in its infancy; the technology stacks were more like islands than they are today.
A decade later, with the rise of the cloud and the tools born in that era, deployment, infrastructure management, and many other topics matured as well. We started to see more and more “boring” technologies: battle-tested and it working reliably.
In recent years, even more parts of the software stack got democratized and commoditized. To have a working authentication system earlier usually required at least some custom development; today there are plenty of ready-to-use options like Auth0, BetterAuth, and so on.

I remember the time when creating a calendar component for a web application required a lot of engineering effort. It seems easy at first, but it turns out to be challenging: handling different languages, date formats, screen sizes, and layouts. One layout is nice and easy to use on a mobile - by the way, which phone, model, size? - but maybe unpleasant, or wrong-sized on a tablet. Or the very dreaded thing is to handle dates: there are many, many time zones, many weird cases, for example when a country is in multiple time zones, but the time zone differences are different. There are several other engineering challenges in the software field.

Problem spaces

The foremost challenge was, in such cases, to explore the problem space itself: what typical and edge cases are there, are there recurring patterns, and, in general, how hard is it to explore and navigate it? In other words, discovering the nature of the problem(s) and their potential solutions.

In recent decades, many similar problems were discovered and mapped out. We understand the challenges we needed to overcome. Based on this knowledge, we built increasingly effective solutions until we had ready-to-use strategies, patterns, and libraries.
Such a problem space was no longer uncharted territory, and we had the tools to travel through it faster and more safely.

In recent years, creating a new application could be done with little to no coding using templates, project generators, and example projects. Sure, putting everything together so it all works could be painful.

Still, in most cases, it was plumbing.

4. A spectacular gap AI could fill

We already had good maps and tools, but it was not that comfortable. One could spend a lot of time connecting the tools and frameworks. To use a car analogy: we charted the territory and built the infrastructure, like roads and gas stations, but still traveled in age-old automobiles. Then came newer models built on the existing infrastructure, drawing on decades of engineering experience and unlocking new possibilities. Still a car, but now with a much more comfortable interior and capable of much higher speeds. Although it is still possible to travel by foot - or horse- the car is much faster now in the known space.

We now know a lot about what to build, how to build, what to prepare for in terms of common failures, issues, and fallacies. We have developed useful theorems, best practices, and tools to aid us. It is way easier to create a working web application now, even without having deep knowledge of the tools. It has become common to have ready-to-use template apps for all major frameworks. Connecting ready-to-use authentication solutions, logging, and databases has become much easier. And so this becomes the least interesting part of web development, but it could consume disproportionate time to make it work. This was the case before coding agents. Now with agents, it can be much faster to assemble a working app from scratch, connect all the required tools, and use it. There are a lot of written materials, documentation, articles, and an agent is just faster at consuming all this information and finding the required configuration and settings to make my code work.

5. A note on knowledge externalization

There could be many reasons to externalize a skill or knowledge about something:

• Not that important,

• I don’t have enough time or capacity,

• another actor is more capable and/or faster,

• or I can use my energy and time more wisely by spending them on higher-reward tasks. That is all good.

Two possible consequences take more time to be visible.
The first is that a single skill or set of skills decaying might affect others. People who rely more on navigation tools not only lose their ability to navigate without them but also experience weakened memory.
As with all human abilities, our cognitive ones must be exercised and trained. If not by manually writing code, we'll need to find another approach.

The other consequence is becoming increasingly dependent on external actors. That can be a company, tool, other person, etc. The real threat here is losing sole ownership and governance over our abilities if we externalize too much.

Now, this is not new; we have been doing this for a long time.

With LLMs, it becomes way easier to materialize our inner thinking, logic, and our own brain's algorithms as data and software. If I lean too much on these tools, I might find myself in trouble when I lose access to my externalized memory, skills, and knowledge, especially if that knowledge is not internalized. I will write on this more in an upcoming article.

Conclusion

I will leave here three questions to think about for now.

1. How does their speed affect quality? - Are we at the point where they can produce high-quality outputs (granted to have good inputs and a good guidance system), or do we just not see the drop in quality in the high-speed noise?

2. Are the problem spaces where AI tools are very effective (like web app or website development) fully explored with the current technology?

3. Can today’s AI tools explore new problem spaces on their own? - It would effectively mean that they are capable of something similar to human intuition. Or just being very effective at using brute force.

In upcoming articles, I will explore these topics in more detail.

Subscribe now