Back to the apps

2026-05-25 · 8 min read

It was sometime during the back half of 2025 that I really felt it: LLMs were now capable of writing real software.

I've surprised myself by how quickly this has become part of my core workflow for almost every day to day task as a professional software engineer. A few examples:

LLMs write most of the code I need to ship with every day, implementing specs, helping with ideas. My focus is directed to higher level concepts, technical designs and strategy behind these implementations instead.
MCP/CLI integrations (🌶️ - CLI is always better) mean I mostly use my agentic tool of choice to interact with most of the core external systems I work with so I don't have to deal with their web-based interfaces (e.g. JIRA)
It's the ultimate code review aide: by pointing me to the areas of diffs that actually matter, I can focus on giving substantive reviews rather than getting bogged down in nits

But the most profound thing I've really felt is that it's made the bad parts of software engineering bareable. Rewrite a legacy monolithic view controller in SwiftUI with a modern concurrency-based action handling system? Awful to write, but enjoyable on some intrinsic level to plan this out, and an unmatched feeling of excitment to view a diff where all the programming is completed in a matter of minutes. By generating source code a couple of orders of magnitude faster than my meaty human fingers, a difference in amount has really become a difference in kind. Despite what some detractors may think, we're never really going back to the "good old days" and it's time to fully embrace this workflow (or, at the very least, to get started) if you haven't yet, because you will be left behind.

Tool apps and side projects

The reason I got into software engineering in the first place was for the apps. Writing dumb, tiny apps and games is the reason I'm so passionate about creating anything these days.

Like most professional software engineers, I have side projects in various states of completion. OK you got me: they are almost all incomplete and I just wish I had more time to round these off and ship them. It feels amazing to ship anything, but getting software into this state usually has a few annoying hurdles to clear before it's shippable. The ship fast/break things methodology doesn't work so well when you want to feel good about software that you're actually shipping, especially when it's not necessarily for-profit and especially for stuff that you're just using yourself. I don't want to use slop if I can help it!

Using LLMs for side projects is an absolute game changer: even more so than in large established projects. A legitimately abandonded side project can become shippable in an afternoon. An idea can become a working prototype even faster. Heck, you can even do both at the same time.

Don't get me wrong: there's a level of statisfaction when you've just written the perfect algorithm by hand to solve some novel issue. But I would argue the satisfaction of shipping beats that every time.

The rise of LLMs has also created a whole new class of software engineers, which was unimagingable just a few years ago: vibe coders. It's now possible to create complete apps without any real understanding the underlying technology, via the LLM choosing sensible defaults and responding to purely semantic prompts. The realities of this are that the world of software is growing at an unprecedented rate now that the cost of entry is only a subscription to any half-decent LLM.

I don't want to dive too deep into the world of vibe coding, but having an understanding of the level of complexity that LLMs are able to deal is necessary to understand what you're able to do with them. This isn't the early days of ChatGPT any more: with the right prompts and contexts, you can do more than you might think. And regarding vibe coders: experienced software engineers have a very clear advantage over non-engineers. We understand the importance of the underlying technologies that we choose, their tradeoffs, and a general sense of what's the correct way to "do stuff" with software. This is absolutely critical when it comes to the long term evolution of larger projects and their continued maintenance; LLMs have finite context windows, so unless the vibe coder to very careful to create sensible abstractions and manage this context carefully, entering the realm of "context rot" can doom vibe coded projects.

In the context of my small apps I fully understand the technical choices I'm making, the direction I want to go, and how I would do the next task "by hand". The LLM is a force multiplier in that it's doing exactly what I would otherwise be doing, just faster. That slump between being mostly done and actually done is a big one and this closes that gap in a big way. My small apps are seeing the light of day and it feels so good!

I'm also still staying familar with code that I'm generating. LLM's finite context windows force me to make sure my source code remains sufficiently abstracted such that it's still human (and LLM) readable.

Speaking of which...

Let's talk about Vault.

I'm so glad that these tools have empowered me to polish and ship this, because it's exactly the app I've always wanted to for secret management and backups.

The TL;DR is: it's a more secure version of a paper backup for anything. Write your secrets (or OTP codes) into the app, create an encrypted backup and then delete the digital copy. The project is fully open source, and it's got some really cool data protection features.

To address the elephant in the room: how do you know this is safe if you had an LLM write it?

This project was started "by hand" back in 2024. I wrote a majority of the core logic and design by hand based on best-practice security principals. This gave an LLM a solid foundation to build off, rather than going from scratch completely. I say this not to detract from projects which were started with LLM help, but more to make clear that I have carefully considered the design and abstractions at play. This project was designed from the start to be maintainable, backwards compatible, and human readable at it's core.
All code changes are reviewed by a human, to verify the design principals are followed. LLM generated code without a human in the loop is a liability given the current state of LLMs.
All behavioural changes must be tested, and the tests human reviewed. Tests keep LLMs on track and set clear expectations about existing behaviours, as well as providing good precedant to continuously test. LLM workflows without tight feedback loops are liable to go off track in subtle ways.
It's open source, so others are free to review the source to identify any issues so they can be fixed. As an aside, it pains me to see similar secret-keeping apps on the app store which are not open source. Unless they are from a large, trusted company (e.g. Google Authenticator), I would strongly encourage people to not use vault apps, OTP apps, or other software which is closed source from small companies for storing this highly senstive data. Even for Vault, I would encourge you to build the app yourself from source rather than using the App Store distribution so you know exactly what code is running on your device.

Where are we heading?

The general consensus at the moment is that software engineers should be worried given the rapid pace of advancement of these tools. If LLMs are building everything, what's left for the humans?

I would argue that for engineers with some amount of product sense, integrity, and an appreciation for the underlying implementation details for what they are building: that is not the case. I'm not currently getting the feeling that my livelihood is in jeopardy, but rather that these tools are game changing enablers for people with a passion and drive to use them to build things faster.

Having said that, I'm not going to claim I know where software engineering or the industry as a whole is heading but it sure is an {exciting,scary} (pick one) time to be in the world of software.

But for now, if you're also a programmer (or are interested in becoming one), get stuck into something and see how it goes. Maybe pick up one of your old side projects that you thought was dead, who knows where it will go. Just don't lose yourself in the process.

Disclaimer: this blog post was written entirely by me, a human. Any typos are my own.