Prologue

This week I want to take a look at a topic that’s been working its way around the developer community again: How AI might be changing the programming languages that we use. By that, I don’t mean C#, Python or JavaScript but that, instead of working in programming languages, we’re first working in our natural languages (whatever one you speak or think in. For me, that would be English). I believe that AI is changing that (in the previous episode I showed how a non-developer could write a simple app) - but I also want to say that we have always programmed in our natural languages first. A bold claim? Maybe, but hear me out.

In Episode 5 we are going to look at how we think, how the web has evolved, and the shifts that are happening as AI and LLMs take on some aspects of software development – and explore what’s left for the Humans (spoiler: the fun parts, I think).

Languagologue

What does it mean to say we have always programmed in our natural languages? As professional developers, we often have scopes of work, design documents, user stories, etc. that the development team will transform into a working application. The goal has always been to convert somewhat fuzzy operational descriptions into precise, logical instructions.

Even as a solo developer, you may not write anything down before coding, but you’re still thinking in language. Language is core to the way that our brains operate. It is what our higher-level thoughts are built in and operate in. We have always thought in language, and, in a way, we have always programmed in it as well.

Now, the translation to computer language is happening automatically. We can now use an LLM to go from design to computer code, without having to type it out ourselves.

A brief history of the web

In the early web, there was no social media, no YouTube, no Facebook or Bluesky. Instead, it was a set of individual websites, where everyone had their own sites. To simplify it, we had things like GeoCities, Blogger or LiveJournal. You still had control over the space, but it was starting to centralize.

Facebook was the beginning of the dense centralization of the web where a few companies owned and operated it. The goal of Facebook was to keep people on Facebook, to keep people in the walled garden, so to speak. Then, with the iPhone, we added Apps to the mix, meaning that if you wanted to communicate, tell other people your message or look something up, you probably went through a relatively small number of Apps to get there. Software started eating the world and there were Apps for everything, both at home and at work.

Recently there has been an IndieWeb movement pushing for a decentralization of content, but it still mostly rests within a few large providers. Applications are similar, in that a few large providers maintain the most frequently used apps. Even within a single app category, say ToDo lists, there are only a few Apps that dominate the space, with quality of the smaller Apps falling exponentially.

The Re-democratization of the Web (a.k.a Personal Software)

But, even with so many Apps, there are still issues with each one. Each App provider has their own opinions on how the tools should behave, and we don’t always agree. AI, specifically LLMs, are pushing us in a direction where anyone can build an application, and that means we can all have our own tools, and they will behave the way we want.

I’m not alone in this thought. Amjad Masad, the CEO of Replit calls this Personal Software.

Low Code/No Code is Dead

Okay, maybe not dead, but the Low Code/No Code industry is evolving. Individual configurable apps are still going to be useful, but I think we will see them begin to transform from fully human configurable to using natural language to configure and then fading to the background because Disposable Apps will be more functional, more personal, and just plain better.

Building large enterprise systems will also become cheaper, as AI assists in development and maintenance—even if it can’t manage large codebases on its own. And these custom systems will be better than their configurable counterparts. There simply won’t be a need to have “low code” software in the future.

Maybe there will be marketplaces where we can share our Disposable Apps or the prompts that created them so that others can mash them up in different ways to get what they want.

I also think this means that we, as developers, will spend more time doing things we want, writing the hard or interesting code, not configuring YAB (Yet Another Button).

Coding by Vibe

My first reaction to this was… “lol… ugh.”

But upon further reflection, I realized that I’ve been coding by vibe for years.

Before LLMs, I was already working this way. As a manager of software developers, my job often involved writing up what needed to be done rather than writing the code itself. If I got enough of the context down, even if I missed a technical detail, I trusted my team to fill in the gaps.

In a way, I do this with clients all of the time:

1. The client tells me what they want, often in vague, high-level terms.
2. The architect translates that into a system design, defining the moving parts.
3. The design team works to fill in the gaps and document workflows and design elements.
4. The developers implement the design, filling in the last of the gaps to make the application work.

It’s turtles all the way down—each layer adds more detail until we reach the system’s core logic.

Now, with AI, we’re pushing this process one step further. Instead of providing technical details, we describe what we want to an LLM, and it generates code for us.

What does “Coding by Vibe” Actually Look Like?

If you’ve attended one of my talks or seen some of my previous posts you might know what I mean, but let’s look at an example. Say you need a simple app to display some live temperature data, something I’ve often needed. In the past I would have had to build a backend, frontend and API calls. Now I can outline it for an AI. (Note, I do usually provide more detail than this - that’s the architect in me):

The AI will return a basic application written in JavaScript that will record sensor data and give me a chart to visualize it.

I didn’t have to specify exact libraries or data storage formats. The AI inferred that for me based on context, that’s coding by vibe.

The Fluffy AI Problem

Obviously, LLMs aren’t perfect. AI-generated design documents by tools like OpenAI’s Deep Research or Perplexity often look polished on the surface but are full of false assumptions and made-up information.

Right now, AI is a useful brainstorming tool; it can help surface sources, but I wouldn’t rely on it blindly. It might capture the essence of what you want, but it often isn’t very precise.

For small applications (like a page to display data or a quick mapping tool) you can often go straight from idea to working app. But for larger systems, developers still play a key role in making sure the AI’s output is logical, efficient and maintainable. For now.

The Future of Developers

More software means more Developers! When configurable apps came out, there were probably people saying that in the future, you wouldn’t need Software Developers. I’d say that didn’t pan out: those configurable apps could get you there but were not a replacement for writing code. If anything, I’d say that it caused more Software Developer jobs to be created, both to build those configurable apps, but also to extend and integrate them with other systems – and ultimately to build more software when the configurable tools no longer meet the business need.

I think that AI and LLMs are the same. I think we are close to the time where simple, Disposable Apps can be created by anyone who understands the data and what they want to display. And that will drive the need for even more applications, meaning we will need more developers!

Those developers will have a superpower in the form of AI powered coding tools. I see a future where, as a developer, you might not only be responsible for entire applications that would have previously required a team, but you might be responsible for multiple of those, with a small cadre of AIs working on those apps under your direction.

This also means that system architecture, and an understanding of how applications and systems are built will be important to building quality systems.

It also means that developers will get more time to focus on what they want, which was my entire thesis for starting this newsletter.

What Now?

I think this means more work for developers, to build core components and acting to multiply what the AI can do. I believe this to be a case of Jevons Paradox: the resource of software development is getting cheaper, but instead of lost jobs, we will have an increase in demand creating more opportunity. You might do more and more coding by English (or whatever your natural language is) and letting the AI build the bulk of the app, but you will also be building more and more applications.

Newsologue

• Big AI companies try to use Fair Use to get out of copyright claims
• PSA: Amazon Echos will send all requests to Amazon Servers soon
• How news agencies might survive in an AI-Powered future: tolls

Epilogue

I have been thinking about this topic for a long time, but what got me to start writing it down was this article that I saw a little while ago: I’m not the only one that thinks this might be where we are headed. And more recently, someone shared this article on how AI might affect programming jobs.

As with the previous posts, I wrote this post. This one was more of a brain dump that I continued to massage until I got what I wanted. I used the same feedback prompt as before to make edits and generally clean up the post before I had a couple of humans read it and give me feedback.

Here is the prompt I used to get the model to provide me with the feedback I wanted:

You are an expert editor specializing in providing feedback on blog posts and newsletters. You are specific to Christopher Moravec's industry and knowledge as the CTO of a boutique software development shop called Dymaptic, which specializes in GIS software development, often using Esri/ArcGIS technology. Christopher writes about technology, software, Esri, and practical applications of AI. You tailor your insights to refine his writing, evaluate tone, style, flow, and alignment with his audience, offering constructive suggestions while respecting his voice and preferences. You do not write the content but act as a critical, supportive, and insightful editor.

In addition, I often provide examples of previous posts or writing so that it can better shape feedback to match my style and tone.