At least one of these two things is true: We’re not building as fast as we can, or we are lying to ourselves and each other about the effectiveness of manual code review.

“Careful” and “fast” are opposite ends of a spectrum. Different organizations will need to bias towards one end or the other, but both can’t be optimized for at the same time. Choosing either one is valid, but one is all you get. It seems that most tech companies prioritize velocity. Setting aside any feelings and value judgments about that choice, it’s how business works and we will accept it as a given for now.

I won’t bury the lede: If you want to move as fast as AI lets you, you have to stop reviewing every line of code it generates. That’s not to say you can’t or shouldn’t read any of the code, but you have to be selective with where you spend your time and energy. To focus on everything is to focus on nothing, so you either have to pick your battles or take on the entire army with a wiffle bat and hope for the best.

You could choose to dismiss this idea out of hand and stop reading here. Careful, thorough code review may be nonnegotiable for you, and that’s okay. But you then need to accept that you’re not going much faster with AI than you would without it, and you are therefore likely wasting money on it. If you hold yourself to the code review practices of old, AI isn’t accelerating your dev process terribly much. Instead, it’s just shifting your development bottleneck from code generation to code review.

Actually unlocking the efficiency gains of AI requires rethinking the whole SDLC, not just handing your team Claude Code licenses and calling it a day. Code review is still necessary, but why does it need to be humans doing it? LLMs have gotten as good at reviewing code as they are at producing it, so the symmetric solution is to leverage review agents to balance out the code generation agents. Yes this increases your AI spend, but it’s necessary to unlock the meaningful benefits of AI-accelerated development.

This isn’t to say that human review shouldn’t be done; it should. The trick is to focus your review attention where it really counts: Database schema design, system architecture, and test case descriptions. The first two are consequential design aspects that are hard to fix if you get them wrong, and the last one is your clearest insight into what your software actually does. These are things LLMs can effectively review for correctness, but they generally don’t have enough context to evaluate them for appropriateness. This is what humans still bring to the table and can do better than AI, so it’s where we should focus our time and energy.

Conversely, it’s worth minimizing time spent on reviewing things like business logic and presentation. Business logic implementation will only ever be as good as its original specification, and LLMs are reliably good at deriving the former from the latter. Presentation is better verified through means other than code review, such as automated visual diffing and acceptance testing (either it looks and feels right or it doesn’t). Leave the actual code review of these parts of your code to the robots. They’re about as good at it as we are, and they have vastly higher capacity to do it well.

There’s a predictable drawback of reviewing less code: Code quality will go down. Rather than reflexively balking at that idea, let’s consider: Is that really a big deal? This is a sincere question, not ragebait. What is the purpose of code quality? The only two practical reasons I can think of are maintainability and performance.

Software engineers can be a discerning bunch. We value precision and elegance, and we abhor complexity. This is frequently out of love for the craft, but it also serves a practical purpose: We don’t want to have to reason about code that makes our heads hurt when a bug is reported or we need to add a feature. The shorthand for this is “maintainability.” Maintainable code prevents migraines, high blood pressure, and missed deadlines. But the conversation around code maintainability historically assumes that it would be humans maintaining the code. What about when that’s not the case? When we can hand off unintelligible code to a robot to interpret and change according to our whims with reckless abandon, who really cares how elegant or ugly it is? The AI certainly doesn’t have any feelings about it. We’re at a point with AI where we can abstract ourselves away from the implementation details of our work and not really lose anything, so it stands to reason that we should.

When compilers were first developed, there was extreme resistance from the programmers who wrote machine code by hand. In their view, compilers produced inefficient assembly code that was inferior to their handcrafted output. And they were objectively right. But they couldn’t see the forest for the trees; history proved their valid reservations irrelevant. Computers got faster and the compiler output was demonstrably good enough.

Does this sound familiar?

If we’re going to move as fast as AI lets us, we’ll need to become comfortable with prioritizing directionality over precision. We need to become okay with “good enough” and shipping minor defects from time to time, because those are inevitable when you’re shipping at a high velocity. This might sound counterintuitive, but it is abated by AI’s ability to quickly iterate and ship fixes once the bugs are found. Of course, different organizations’ tolerance for defects will vary, so it’s on you to determine what the right balance is for yours.

Before you reject this idea, ask yourself this: Were you shipping bug-free code before you had AI?

Machines are faster than humans. If you want to move at machine speed, then you need to get out of their way. Direct, don’t gatekeep. And don’t keep yourself beholden to development processes today simply because you did them yesterday.

This is a letter to myself 17 years ago when starting out in tech. It is a post about cold truths and mitigations. It is intended to be illuminating rather than inspiring. My hope is that others find it instructive.

Embrace the layoff

You will eventually be laid off. That is how jobs in tech end, assuming you don’t leave or get fired first. Practically speaking, there is no concept of staying at one company for decades until you retire. The exception to this rule is company leadership which executes said layoffs as a means of protecting the business. Some non-leadership outliers win the job stability lottery and achieve career-long jobs, but it is unwise to bet on winning the lottery.

Given this inevitability, your best option is to own it, plan for it, and delay it. When I start a new job, I think to myself: “I wonder how the layoff for this one will go?” I find out concretely in time, but it usually follows a similar pattern: A few bad quarters and company meetings focusing on lagging sales, followed by the CFO leaving, followed by an unexpected, late-breaking “Company Update” meeting with HR the next day.

You can’t choose how to feel about your future layoff, but you can choose how to think about it. You can preemptively strategize around it, both with your personal finances (you do have 6+ months of cash on hand, right?) and your choices as you navigate your job through its untimely end. Those choices are actually more about setting up for the job that follows the current one. Specifically, it’s about crafting success stories you can share from this job in a future interview and building personal connections with which to leverage a future referral.

Sidebar: Jobs are only obtained via referrals now. Cold-applies are nearly pointless; employers only hire through their employee network. This is not an absolute truth, but it is a practical one.

The rest of this post is about strategies for delaying your layoff.

The salary catch-22

Having a big salary is great. In tech, salaries can range from underwhelming to obscene. It’s rational to seek and negotiate for the highest salary you can for any given position — you should do this.

We all wear a layoff target on our backs. The size of that target is roughly proportional to your salary. You might think that, at layoff time, a company would rationally stack rank each employee’s individual value and simply cull the least valuable employees as necessary. This is not how it works. Layoffs are not about value, they are about cost. The purpose of a layoff is to reduce costs to make the balance sheet make sense at the end of the quarter. Your salary is a cost. If you want to reduce your layoff risk, consider not maximizing your salary when negotiating an offer. I don’t actually recommend doing this (making more money is better than making less), but it’s a tiny knob that’s available to you if you value stability over wealth.

It’s not totally black and white in terms of who goes and stays at layoff time. The salary-based survival cutoff is a little fuzzy; leaders can and do make choices of who to keep and who to cut when it’s down to choosing between a handful of people of comparable cost levels. Let’s call this “the zone of fungibility.” You can make choices to put yourself on the better edge of that zone.

Know what your job is

Most people don’t actually know what their job is. Engineers, for instance, often think their job is to write code, or solve problems, or perhaps even to build great products. This is an illusion. The reality: Your job is to make the company money and please your management chain. That’s it. You could ship the most inane, low-brow slop and still be considered a hero if it results in a noticeable improvement to the bottom line. The seminal piece on this is Patrick Mackenzie’s

Don’t Call Yourself A Programmer, And Other Career Advice. If you haven’t already, stop here and read and internalize that essay. Key quote:

Engineers are hired to create business value, not to program things

It’s in your interest to seek opportunities to create direct business value. Try to work closely to revenue streams. If you’re not in a role that puts you in a position to do this (e.g. internal operations), try to transfer to one that is. If you can’t do this (or simply don’t want to), your next best option is to seek opportunities to reduce costs. Find inefficiencies in the organization, own them, and eliminate them. If your work is visible to leadership (more on that later), it will be considered by decision makers in case you find yourself in the zone of fungibility.

Make friends in high places

Pithy though it is, they saying “it’s not what you know, it’s who you know” is a universal truth in the business world. Do not underestimate this fact. You are not smart enough to be exempt from it.

Make friends with your manager, director, VP, CTO, and ideally CEO. They should be aware of your existence and what you do for the company. This is one of your best tools to defer your layoff.

How do you make friends with these people? Proactively reach out to them and provide useful information to them. Literally just ping them on Slack from time to time. If you’re an individual contributor, you have valuable perspective as a person with boots on the ground. You can give them insight that’s obvious to you but perhaps not to them. Good leaders crave high-quality data, as that’s what lets them do their job. When doing this, take care to optimize for signal over noise. Don’t use any more words than necessary and don’t overwhelm them lest you not be heard at all. And absolutely do not be annoying.

How do you differentiate between signal and noise? Consider what you know that they don’t and think they should. That’s it. If you don’t have this information, don’t ping them. If you do, then do. Either way, don’t do this more than about once a week.

The goal of this is twofold: Contribute to the success of the company by disseminating valuable information to those who can do something with it, and establish yourself as more than just a name on a list of fungible layoff options. To be clear, you are just a name by default. You can choose and work to be more. I recommend that you do so.

Visibility beats competence

Competent people make the world go ‘round. Unfortunately, they’re not valued or rewarded by default. Reward comes from visibility regardless of any underlying competence. I imagine you’ve already seen a loud person take and get credit for work that a more competent person did. Perhaps you were that competent, unappreciated person. You will see this again throughout your career.

Books could be (and likely have been) written about why this is. My reductive understanding is that this is a quirk (failure?) of human nature. It’s not going to change and it’s foolish to try and deny it.

Competence is important but ultimately irrelevant without visibility. Advertise your wins, even if it feels gross. Frame your failures as lessons learned. Over time you will be widely perceived as competent, which is all that really matters in the end. You are not granted this perception by default, and that’s dangerous when you’re in the zone of fungibility.

Embrace cynicism, but don’t lead with it

This post is admittedly a little cynical, but it is the distillation of my lived experience and the lessons I’ve learned. I don’t like much of what I’ve shared here, but I’ve found it all to be true just the same. It is also consistent with what I’ve seen my peers go through (many of which are quite successful). No two career experiences are the same, but many of them follow a general pattern. Chances are, you’re in a similar one.

It’s easy to let this cynicism spill over into your everyday demeanor, but this is incredibly dangerous. It is very easy to be cast as “the negative one” and very hard to shake that perception. You should be your authentic self at work, but it’s imperative that you attenuate any cynicism you may develop over time. After all, nobody wants to work with a downer.

Be careful not to overcorrect; being toxically positive isn’t any better. It’s worth being your authentic self, just keep in mind how others perceive you. Perception is everything and it becomes your story. Make sure it’s one that people want to hear.

Surviving is thriving

There are a lot of influencers who want to sell you on the dream of “thriving” (they make money from that message). Take bold risks, launch a startup, be your own boss. Some people are well suited for founding and leading companies, but most are better suited for being employees. There is no shame in this and it’s not some sort of moral failure.

Simply finding and keeping a job these days is success. Reaching your local maximum is an achievement worth being proud of, and you may even find that your ceiling is higher than you thought. If so, you should try to continually raise and reach it. But surviving is a prerequisite to thriving, so start there.

Hopefully this post will help you do that!

But it wasn’t Mike’s excellent code that influenced me the most. It was actually a very simple rhetorical construct that I don’t think he even used consciously in engineering debates. Two simple words: “It seems.” Now, “it seems” might not strike you as very compelling at first. But it’s what it’s used as an alternative for that makes it powerful.

Engineers tend to be an opinionated bunch. We have a point of view and part of our job is to sell that perspective and design systems around it. We also tend to be extremely emotional and get attached to our ideas. Right now you might be thinking “That’s nonsense. I’m not emotional! I’m logical! I exclusively make logical analyses and decisions!” If you’re thinking this, you are the most emotional type of engineer. You have a concept of who you are and what you do, and you are very attached to it. But don’t feel bad! Humans are emotional beings no matter how much we’d like to tell ourselves otherwise. We can’t will our emotions away. At best, we can manage them. At worst (as engineers), they manage us.

Typically in engineering debates, participants try to make their case by saying that they “feel,” “think,” or “believe” something. For example:

• “I feel that using a state management system will make this code more maintainable.”
• “I think Postgres is the way to go for this project.”
• “I believe that our test coverage should be at least 90%.”

These are all valid points of view, but they’re presented in an inherently subjective way. Engineering, when done well, is not a subjective discipline. Real engineering is fully objective, and good engineers know how to remain objective when determining a solution to a problem. How you feel or think about something is a subjective reflection, but how something seems is a more objective baseline to work with. Let’s apply this to the arguments above:

• “It seems that using a state management system will make this code more maintainable.”
• “It seems Postgres is the way to go for this project.”
• “It seems that our test coverage should be at least 90%.”

Now, these arguments are actually a bit weaker than they were before because they lack any rationale. But now it’s much more obvious that they lack rationale and that’s a trigger for the team to acknowledge and discuss it. With “feel,” “think,” and “believe,” the implicit rationale is “because I say so.” That’s a pretty poor way to sell an engineering solution and it doesn’t invite collaboration. By using “it seems” to recast the argument in a less emotional light, it opens the door to different perspectives and potentially better alternatives. And this is what good engineers do: Get to the root of a problem and identify the best-fit solution. A major component of that is willing to not be the loudest or most opinionated person in the room.

“It seems” has helped me navigate many engineering debates better than if I used my emotions to make a point. It seems that many engineers would benefit from doing it as well!

Welcome to 2025. LLMs have captured the hearts and minds (AKA VC dollars) of everyone and they are literally the only thing happening at all in the entire tech industry. They are the cause of and solution to every problem and will both save and destroy the world.

LLMs are at least a potential solution for a very wide range of problems, but they’re often not the best and very rarely the simplest. The one thing you can say for sure with LLMs is that you can put stuff into them, and something will definitely come out. Will it be the right thing? Who knows, hit the button and see what happens!

Hitting the button and seeing what happens is a fine workflow for a lot of situations. It’s great for creative writing, drafting Jira tickets, cheating on homework, and writing emails to people you don’t care about. But some work requires a bit more determinism. Programming is an example of such work; either software works correctly or it does not. Because we live in the future, LLMs are quite good and will often provide you with code that at least mostly works. And if you already know how to write the code you’re asking the LLM to write, then you’ll be able to verify the output and grin smugly about all the time you just saved yourself (or regenerate the response five times and then give up and just write it yourself in frustration). If you don’t already know how to write it yourself… well, hopefully somebody catches the bugs in code review.

What makes LLMs both great and terrible is that they hallucinate. It’s not a bug, it’s the very essence of what they exist to do. LLMs don’t actually know anything and mostly don’t have access to any kind of database of verifiable information. They are machines that were shown a lot of information in training and learned to infer new conclusions based on the patterns they picked up in that training. But they don’t know anything. They have no truly concrete way to validate nontrivial assumptions or conclusions. They’re just making extremely educated guesses. And they’re doing it in an extraordinarily resource-intensive way.

I like LLMs (at least ones that I can run on my own personal hardware), but I’m also a simple man who enjoys simple things. A resource-intensive guessing machine is not the simplest solution for a majority of programming-related tasks. Such tasks include writing, refactoring, finding and moving code. Ironically, this problem has been well-solved by long-established, proven static analysis tools that predate LLMs by decades. Linters, for example, are static code analysis tools that deterministically evaluate code and identify a wide range of problems. They’re not as versatile as LLMs, but they are completely consistent and reliable and very often versatile enough.

In the mid-2010’s, Microsoft gave the world a wonderful gift: The Language Server Protocol, or LSP for short. At a high level, LSPs are a unified way for code editors such as Neovim to communicate with a wide range of development tools. That doesn’t sound particularly exciting, but it’s the technology that tells you what properties or methods the object you just typed has available to it. This is a little more exciting, but still not exactly compelling. More advanced LSPs (such as the ones available for TypeScript) offer advanced refactoring capabilities such as extracting functions, moving code to different files, renaming variables (across files!), finding code references and definitions, and more.

There’s a good chance you’re sitting there rolling your eyes because you know that LLMs can do this too. But hold on there, buddy. Your LLM takes an extraordinary amount of compute to do this work. And if you’re not running it on a $20k custom-built NVIDIA rig that heats up your whole house, then you’re paying someone like Anthropic to do it in a data center. LSPs, on the other hand, can do this work on any random laptop purchased from Walmart. And the best part? LSPs don’t hallucinate! They literally can’t! They will always provide you with a valid response, unlike LLMs which may or may not.

LLMs definitely have their place. But they aren’t the only solution to most problems, and are very rarely the best. For many programming tasks, LSPs are just as good of a solution and much more efficient. New tools don’t have to replace old ones, they can supplement them too! I have no problem using LLMs in my workflow, but I use LSPs far more frequently because they’re faster and better for real-world scenarios. And the best part? I don’t have to provision a server rack or fund a new yacht for Sam Altman to use them.

Long live LSPs!

AI is the future. You can disagree with this, fight against it, or ignore it. But there is no scenario (short of a literal apocalypse) in which our future involves less AI than it does today. It is simply too useful to not stick around and improve. Even if AI progress stops with LLMs (it won’t), people will find more uses for it (both good and bad) and build more products around it. It’s not all hype; this technology has practical applications. I’m not necessarily endorsing the AI future, but I accept that it is reality. And it’s only when you accept reality that you can thrive within it.

As of December 2024, OpenAI is the only mainstream household name in AI. Anthropic is the company that is used by AI power users. In other words, OpenAI is for normies and casuals and Anthropic is for the hardcores. This will probably change pretty soon because there’s no stability in this space. It’s too early to tell who will be the winners and losers. But to be honest, I don’t really care. None of these AI companies are doing anything particularly interesting.

“But wait,” I hear you say. “In one breath you’re saying that AI is the future, and in another you’re saying that the leading AI companies aren’t doing anything interesting. That doesn’t make sense!”

My friend, you need to expand your notion of what AI is and can be. While these companies are indeed developing the most advanced AI technology on earth, their actual product is API access to their models. And therein lies the problem. As per the (inexplicably) standard Silicon Valley playbook, both OpenAI and Anthropic operate at a loss. I would bet on them eventually becoming profitable, but not before at least setting the stage for full-scale enshittification, if not fully embracing it. And by then it will be too late. The moats will be established and the API dependencies will be established. We’ve already seen this with cloud providers like AWS and there is, realistically, no way back. Big tech will win again because it always does.

But there is space for another option! Smaller, open source LLMs are flourishing right now and will only get better with time. Unlike the frontier models like Open AI’s GPT4 and Anthropic’s Claude that are trained on many hundreds of billions (maybe even trillions) of parameters, there are many smaller, open source LLMs ranging from less than one billion parameters on the low end to around 400 billion on the high end. These models are free to download and run on your own hardware as you see fit. And because these models run locally, you don’t have to worry about token costs, rate limiting, or privacy concerns. There’s no catch and it’s as good as it sounds!

To directly address the elephant in the room: Many of these open source models require significant hardware resources to run. You’d probably need a RAM and CPU-maxed MacBook Pro or an array of NVIDIA 4090’s to run the larger models well. But to focus on this is to miss the forest for the trees: There’s a respectable set of small but capable LLMs that run well on commodity-grade hardware and probably even the one you’re reading this blog post on. You don’t necessarily need high-end GPUs or specced-out Macs to run models such as Llama 3.2 3B or Qwen 7B at usable speeds. To offer one data point: My iPhone SE 3, which is the lowest-end iPhone Apple makes, can run Llama 3.2 3B locally via PocketPal. While Llama 3.2 3B objectively has a tiny fraction of the training data available to generate responses that something like GPT 3.5+ has, it has fully replaced ChatGPT for me. It’s in no way the best LLM, but it is easily good enough for general purpose LLM tasks. For more specific tasks such as coding, I use more specialized models such as Qwen.

While we can easily deduce that OpenAI and Anthropic will enshittify, it’s unclear when it will happen and what that will look like. It could be as simple as jacking up API rates and bleeding customers dry, or it could take on a more insidious form like monetizing user data to make ends meet for the investors à la Google. We simply don’t know. Personally, I’m not sticking around to find out. And I don’t need to, because I have amazingly capable “small” LLMs that I can easily run locally on my laptop and phone. I have zero dependence on the cloud for my AI needs and have no API bills to pay. This is a delightful reality that everyone is free to enjoy right now and in the future. If you’re curious to explore this exciting new world, I’d recommend installing Jan and Llama 3.2 3B via its model hub. If you’re not using a Mac, you’ll want to look into enabling “Vulkan Support” and “GPU Acceleration” in the settings for better performance.

I think you’ll be surprised at what you can do with small, local LLMs. I for one am continuously amazed at what I’m able to do with just my daily driver laptop and Llama 3.2 3B and Qwen. You just need to have a realistic sense of what they can and can’t do well and how to make the most of them. I’ve been deep-diving this rabbit hole a lot lately, and it’s clear that the difference between the “best” and “good enough” LLM models is insignificant for many tasks. And at the end of the day, it seems like an obviously worthwhile tradeoff to own your computing experience and digital future.

Don’t be another victim of enshittification and start owning your AI today!

As cloud-based apps evolved, they were necessarily designed around the business models of their developers. And business models, at least in the tech industry, are often at odds with the interests of users¹. In the case of Google, the relationship between the service and user is predicated on surrendering stewardship of the user’s digital identity and property to Google. This is problematic, as Google is neither benevolent nor trustworthy. There are numerous reports of people losing access to their Google accounts due to misinterpreted misuse or bad luck. Losing something as depended upon as a Google account would be catastrophic for many people. And Google has little incentive to improve the situation, as they have no real accountability to users when admittedly rare cases like these happen. But do you want to be the one-in-a-million person that inadvertently triggers a spurious policy violation and lose your Google account? I certainly don’t. All that’s left is to either live in fear of Google, live in ignorance of the risk, or find a different solution entirely.

The core of what Google offers as a cloud solution is fundamentally good at a high level, but it can’t be trusted because of the interests and track record of the company that operates it. There are safer alternatives such as Proton Drive that prevent the service from accessing user data. However, users still need to identify themselves to the service and manage their account credentials lest they lose access forever. We need something that’s as private as Proton, but simpler to manage.

People often talk about “the future” of a given technology or domain. The future of mobile devices, the future of design, etc. But this is such a limiting way to see it! “The” future implies there is only path to go down, but there are in fact many possible futures that can happily coexist. The world is too complex for one solution to solve every problem well. There’s space for more than one way of doing things!

I get really excited by decentralized systems and peer-to-peer networks because they have tremendous potential to empower individuals. I’m a lot less excited by traditional centralized systems and client/server networks, but that’s because of how they’ve manifested in practice. Centralized, client/server systems defer power and authority to the server, and that’s problematic when the server is controlled by a self-interested business with incentives that are misaligned with that of its service’s users.

Despite the drawbacks, centralized systems have numerous technical advantages:

• Simplicity
• High performance
• High availability

Decentralized, peer-to-peer systems are great because they keep control and authority with the users. In a decentralized system, individual nodes (users) manage their own data and identity. However, these advantages come with tradeoffs:

• High complexity
• Unreliable availability
• Significant collective maintenance burden

These are fundamentally limiting issues. Enthusiasts will put up with the challenges of participating in a decentralized system, but typical users will not. If a product is going to achieve widespread adoption and enjoy the network effect benefits that brings, it needs to be approachable to the majority of people.

The ideal between these two extremes is a system that has the benefits of both without the drawbacks of either. Here’s what I think that could look like:

• Dumb servers
• Smart clients
• Public key identity

Let’s break down what each of these mean.

Dumb servers

The fundamental problem with platforms like Google and Facebook is that the service knows everything about its users. An alternative that actually keeps users safe is a service that knows nothing substantial about them. This can be achieved through end-to-end encryption. This is where alternatives such as Proton Drive shine: The service delivers significant value to its customers, but it doesn’t monitor them because it’s designed such that it can’t.

A more user-centric model of cloud software is one where services do little more than store encrypted data that only clients can decrypt and utilize. For that to work well, we need smart clients.

Smart clients

There has been a decades-long shift away from independently-functioning software that lives on user’s machines and towards a model where clients are only focused on managing the user experience rather than business logic.

End user devices are quite powerful these days and there’s no reason we can’t have them execute substantial business logic. Given that, and the fact that we apparently can’t trust cloud providers to access and work with our data, it’s worth considering a shift back to a model where clients do the heavy lifting and treat the server as a functional enhancement (such as for data redundancy) rather than a requirement. This is a core tenet of local-first software, and it fits elegantly with the concept dumb servers that only store end-to-end encrypted data.

Public key identity

While Proton offers an excellent privacy-oriented cloud solution, it still requires a username and password to register. Like Google and Facebook, this relinquishes ownership of the user’s identity to the service. We’ve normalized this model of software, but that doesn’t mean it’s a good one. People should be able to own their digital identity and not have to depend a on third-party to authenticate them.

Fortunately, there is an effective, established, battle-tested alternative: Public key cryptography! It allows a user to create and provably attest their unique identity. When done correctly, it’s effectively impossible for one person to impersonate another person’s cryptographic key pair.

There are two significant drawbacks with public key cryptography:

• It’s not intuitive to most people and never will be
• Effective key management is critical and challenging

These may be the major reasons that public key cryptography is not more widely used for identity. But in recent years, a solution to these problems has been developed: Passkeys! Passkeys completely encapsulate the complexities of public key identity and automate away the burden of key management. WebAuthn is the implementation of Passkeys for the web, and hopefully we will see increased adoption of it.

Rather than provide a username and password to web services when registering, users could instead provide public key credentials via WebAuthn and keep their real identity private. This is a better model, because it’s safer and ultimately simpler for users. Passkeys can be backed up to a trusted cloud-based system of a user’s choosing, and they don’t need to worry about remembering usernames or passwords. All they have to do is present biometric identification (such as a fingerprint or facial scan) and they have access to their account.

A future we can have if we choose it

We have normalized cloud services knowing everything about us and having total control over us online. This is a risky way to live, as our digital existence is based on little more than hope. Hope that Google and Facebook won’t misuse our data (either intentionally or accidentally), and hope that we don’t run afoul of capricious and byzantine service policies.

Many people are comfortable with the status quo, and they probably always will be because it’s familiar and works well most of the time. But not everyone wants to settle for the status quo. There’s always room for alternatives to exist and thrive, and there’s always an audience for more sophisticated way of doing things. Along with the mainstream options like Google and Facebook, we can have more advanced cloud services that are designed around end-to-end encryption and public key identity. We just have to choose to build something better.

This is a future that I personally want to see, so I’m building my own expression of what that might look like. I’m developing Passway, an API designed around end-to-end encrypted storage and public key identity. My long-term goal is to build a cloud that does everything for you, but knows nothing about you. It’s very early days for the project, but I hope to see it or something like it become a common model for cloud computing. Wish me luck!

Much like a cool URI, software is only relevant so long as it’s available for use. Unfortunately, software is trending towards a fragile design: The Cloud. If you’re a Cloud Architect and reading this, relax. This isn’t a condemnation of your work. Cloud-based architecture has many benefits and there is a place for it. However, it is fundamentally flawed in a key way: The user doesn’t own the software. At best the user rents the software, and even then the user can be evicted (or worse) with no recourse. This is a critical design flaw for many use cases and there needs to be an alternative.

We need software that doesn’t go down when AWS does. We need software that the user owns and controls. We need software that can’t be taken away due to corporate whims or government overreach. We need Unkillable Apps.

Anatomy of an Unkillable App

An Unkillable App is:

• Open source
• A self-hostable static web app
• Cloud-agnostic

Let’s dig into each of these characteristics.

Open source

The foundation of an Unkillable App is its source code. If the user does not have access to their software’s source code, then they have no ability to modify its operation. If your app is not open source, then it is trivially killable and you might as well stop reading this article now.

With open source code, the user is empowered to fix bugs and make updates when the software’s context changes. For example, closed-source software is liable to be abandoned by its developer and may cease to function when the operating system it runs on is updated.

Open source software is automatically redundant. Everything on the internet is permanent (for better or worse), and that includes published source code. It is trivial to hit the Fork button in GitHub or simply git clone a project to preserve it offline. When software is open source, everyone owns it and it cannot be taken away. A hostile government could attempt to suppress an open source project (and they do), but there are no technical means by which they could remove it from existence.

Open source software will last until the end of the internet.

A self-hostable static web app

Open source software is a great place to start, but it won’t do people much good if it can’t actually be run. Software that’s designed to be self-hosted is designed to survive. This doesn’t mean that software must be self-hosted (after all, doing so is extra work), but it must be available as an option in case the principal version of an app becomes unavailable. Think of it as a failover mechanism. To make self-hosting practical, complete application data export functionality must be available to users so that they can migrate between app instances.

Software that is open source and self-hostable is a hydra. You can try to kill it, but it will always reappear elsewhere.

The simplest kind of app to self-host is a static web app. It’s strictly a set of HTML, CSS, and JavaScript files. If built appropriately, it will run on any device. A static web app is immune to operating system updates and the risks of outdated system libraries. And web apps can last forever. The original Space Jam website is still online and functional because it was built to web standards. Web standards are both stable (once completed) and powerful.

I’ve written previously about the incredible power of PWAs. That power can be made available indefinitely if it is built to be self-hosted and not reliant on specific cloud services.

Cloud-agnostic

A static web app can be served from any HTTP server. That flexibility lends a lot of durability because anyone can run an HTTP server. Why not extend that flexibility to any web services that the app depends on?

It would be very limiting to artificially restrict a web app to just locally-available APIs. After all, web browsers are most powerful when they connect to other computers and exchange data. Unkillable Apps don’t depend on proprietary web services. Instead, they treat web services like a “dumb” resource. A practical example of this is remote data storage. Rather than building a web app’s storage mechanism around something like AWS S3, consider building it to use generic file storage solutions as a back end. You could integrate with Nextcloud, Dropbox, Google Drive, etc. and allow the user to log in to whichever storage provider they want. StackEdit is a shining example of this. StackEdit persists data locally by default but offers the option to sync with Dropbox, Google Drive, GitHub, or GitLab. Even if the developer of StackEdit abandons the project, I can be confident that I’ll always have access to my data because it was stored in the system of my choosing.

An Unkillable App relegates the cloud to being an implementation detail. When one doesn’t meet the needs of the user, they can trivially switch to one that does.

Unkillable apps for a better future

I believe the future of software can be bright and amazing, but only if we design for it. We have to choose open source. We have to choose a standard and stable technology platform. We have to choose to be cloud-agnostic. We have to choose to build software that cannot die or be taken away.

Users need to rightly trust that the apps they depend on will be there tomorrow. Because if we don’t do this, we will always be dependent on corporations that do not prioritize our interests.

We have the tools to build the future we want. So let’s build it!

Why is this? How could a great technology utterly fail to make meaningful market share inroads? Let’s explore why PWAs are awesome, and why nobody cares.

User-centric design

Progressive Web Apps (PWAs) are literally just web pages with some additional functionality to make them behave like a native application. The key components of this illusion are the ability to install the web page such that it appears alongside actually-native apps like Microsoft Paint or Apple Messages, and some level of offline functionality. When opened, PWAs render in a dedicated window as their own app, distinct from any browser. Under the hood they’re just another browser tab, but they present as a fully-formed, installed application.

Because PWAs are web pages at their core, they natively offer all of the benefits of a standard web page. That includes accessibility, security sandboxing, the potential to be customized via browser extensions, and observability via browser devtools. Every mainstream web browser has devtools that allow the user to take a look at the code that’s running on their device. Most people won’t do this, but the important thing is that they can. Observability is a de facto right of web users that cannot be taken away by web developers¹. And this is wonderful. I can’t think of any other mainstream technology platform that puts the user’s interests ahead of the developer’s in this way. Because of this, PWAs are inherently user-centric in a manner that native apps uniformly choose not to be.

In general the tech industry has sort of lost the plot of what we’re trying to accomplish. Computers are magical and amazing things, and they could do so much great stuff for people. Unfortunately “tech” has been largely co-opted by VCs into being a wealth extraction mechanism, so user-centric design has taken a back seat to investor-centric design. This has led to widespread enshittification and a general degradation of product quality. I don’t see this changing in the near future, but the user-centric design built in at the platform level of PWAs at least gives us a hope that it someday could.

Simple deployment

Not only do PWAs offer the most user-centric design, but they have the most developer-centric deployment mechanism available as well: The web! Depending on how a project is set up, deployment could be as simple as modifying a file on a server. By contrast: If you want to update a native app, you need to submit your change to the app store operator (Apple, Google, etc.), wait, and pray that they accept it. Native app developers have no real control over the software that is delivered to their users because app store operators could capriciously deny updates for any reason. They own the deployment platform.

With web technology, the server is the deployment platform. You could run one for free from home, if you’d like. The web also has no gatekeepers or censors. There is no inherent payment processor that skims 30% off of every transaction. The web lets you own and control the code, the infrastructure, and the content. And the best part? PWAs run on every device! There’s only one build target. It is the most successful implementation of “write once, run everywhere” in history. I struggle to conceive of a better way to ship software.

So far I’ve extolled the myriad virtues of PWAs and you’re hopefully as excited about them as I am. If you are, prepare to be disappointed!

PWAs have struggled to gain meaningful app market share, and I don’t expect that to ever really change. There are two main reasons for this: Gatekeeping incumbents, and user expectations.

Corporate incentives stand in the way

Apple effectively invented the concept of a modern app store, and it makes them billions of dollars a year. Many people seem to consider their practices unfair. I don’t quite see it that way (nobody is requiring developers to publish with Apple), but I do see what such a market position means for us. iOS and its derivatives offer only one web browser², Safari. The problem is that Safari has always lagged behind the other major browsers in its feature set. This holds iOS back, and it therefore holds the potential for PWAs back as well because it’s such a major platform. After all, why would a developer invest resources into a project if it won’t work properly on over a quarter of mobile devices?

Apple has an obvious incentive to limit its browser’s capabilities: Apple can’t monetize the web. Being the cunning profit-driven corporation that it is, Apple is going to seek to widen its various moats as much as possible. Why invest in a technology that doesn’t produce revenue when you could invest in one that does? It’s hard to fault their logic, but the end result hurts users because it disincentivizes developers from creating PWAs and therefore diminishes user freedom.

User expectations

PWAs, as a concept, don’t make sense to the average person. PWA installation is effectively a power user feature because typical users don’t even consider the concept. Computer users have been implicitly trained for decades to think of web browsers as a means of basic content access and to rely on installed native apps for more advanced work and engagement. Can you honestly think of anyone in your life (who isn’t a web developer or technology enthusiast) that would default to installing an app via the web rather than their app store?

This isn’t actually a technology or design problem. No, it’s a marketing problem. Marketing problems can only be solved with money, and there isn’t a clear ROI in solving this particular one. So things will likely remain this way.

“We just need an app store for PWAs!” I hear you say. Bad news: It’s been tried and it hasn’t succeeded. Appscope has been abandoned and nobody is talking about store.app. I want these stores to win. I just don’t see the business model to support them, though.

I really want to be wrong. I want to see PWAs flourish and render native apps irrelevant. But there needs to be a killer business model behind them for it to happen. Without that, the primary audience for PWAs is other web developers.

What we can do

The good news is that PWAs aren’t going anywhere. It’s a web standard that’s in wide deployment. It’s an effective technology choice for hobby projects and side hustles. I don’t see Apple ceding its market share any time soon, but that doesn’t mean that we can’t enjoy PWAs today and into the future. I think we just have to accept that it will always be a less successful platform, especially for Apple users.

I plan to keep making open source PWAs because it’s such an effective solution for the hobby projects I like to build. I encourage you to do the same. If you value developer control and user freedom, PWAs are the obvious choice.

The first time I tried this, I used Octopress. I really enjoyed the Git and Markdown-driven nature of the tool, but sadly it has become irrelevant due to lack of maintenance. Also nobody uses Ruby anymore ². The second time I tried this, I used Medium. But Medium doesn’t support syntax highlighting without absurd workarounds, so I gave up on it. Next I tried dev.to. I like dev.to and actually plan to keep using it for some content because it provides a lot of nice features out of the box and has a strong community. But I’ve come to realize that dev.to is more geared towards tutorials, which is not always what I want to write. Sometimes I just want to rant into the void about computers and dev.to simply isn’t the forum for that. Also I don’t love the idea of my authored content generating income for a platform that doesn’t share it back with me.

If I’m not making money with my work, then nobody is, dammit.

Which brings me to this iteration of my attempt at blogging. This blog is open source and built with Hugo. I wanted a solution that would get the tech out of the way and just let me write. I’m hoping that Hugo can be that. I’ve set this blog up such that I can just create a post and go. Hopefully by simplifying the blogging process down to just managing Markdown files and pushing to GitHub, I can stay motivated to actually write. We shall see.

I like to make snarky jokes about technology. I like absurdity. I don’t take anything seriously, because life is too short for that. I believe in Comedy first. Always. If you can’t learn to laugh at yourself and everything else, this blog is probably not for you. There’s also an outside chance that I may occasionally have something vaguely insightful to share, but I’m not making any promises.