Just fix the thing

A weird thing has happened to my brain recently.

When software annoys me, my first reaction isn't "the devs need to fix this" anymore.

It is "Well, I guess I can just throw something together real quick."

I saw Sam Altman's "you can just do things" tweet a while ago and mostly shrugged it off. It sounded like a marketing slogan, a great one, but just fluff coming from the dealer selling you the tokens. But annoyingly, it has kind of become true for me.

Over the last few months I have been adopting that mindset almost by accident, and it has changed how I look at software. I do not really see software as this fixed product or service anymore. Now granted a lot of OSS contributors just cringed there, but that was just my mindset. Recently, it feels like clay. Something you can wrap, patch, automate, replace, route around, or make a worse-but-perfect-for-you version of.

I'm not one of those people who are saying that I can get an agent to throw together Stripe in an afternoon.

What I am saying is that we can use agents to build or fix tools for your personal use. The barrier has moved. You no longer need to understand the entire stack before you start. You need enough software fundamentals to aim the agent, inspect what it gives you, and know where to look when something breaks.

These are a few examples which will hopefully help you adopt the mindset instead of just dismissing this as ramblings of a vibe coder.

The paid button I built for myself

Someone at work recommended GoFullPage to me. It is a Chrome extension that takes a screenshot of an entire webpage, not just the visible part. Very useful. I used it a lot, especially considering the fact that I worked in Web App QA.

But I kept running into paywalls. I wanted to crop the screenshots, annotate them, and sometimes compress them to the exact image size Discord would allow so I could send them to OpenClaw. The old me would have looked up what it takes to build a Chrome extension, realized I would need to learn TypeScript and extension APIs, and decided the juice was not worth the squeeze. I would have kept downloading screenshots, cropping them manually, and throwing them into random image compressors from Google.

Instead, I sent an agent at the problem. A few hours later, I had a working Chrome extension living on my machine. It takes the screenshots I need, lets me crop and annotate them, and gets the image into the shape I need for my actual workflow.

Does it work perfectly? No.

It does not play super well with animations. But honestly, GoFullPage did not always love animations either. And more importantly, I do not need this thing to be perfect in the abstract. I need it to work for me.

That gap creates an opportunity which agents can fill super well. This extension is not published. It does not have onboarding. It does not have a landing page. It does not have pricing tiers, analytics, customer support, or a roadmap. It just lives on my PC and solves my problem.

Would I be comfortable releasing this extension as it is right now? Absolutely not. I have not given a single ounce of thought to security or how it works on other platforms. Hell, I haven't even tested it in Chrome, even though it's a Chrome extension, it works on my Mac in Perplexity Comet and I haven't had any issues. The total addressable market is one, and for that market, it's complete.

The renderer I made because chat UIs are bad at artifacts

Another example: my OpenClaw agent kept sending me long-form outputs through interfaces that were absolutely not designed for long-form outputs.

Discord and WhatsApp are fine for messages. They are not great for big markdown files, diffs, structured output, or anything that wants to be read like an artifact instead of a chat bubble.

So I made agent-render.com, GitHub.

The idea is pretty simple. An agent just spits out a URL with the data in a url fragment, which I click and a static page serves the renderer to actually render the data in a way that makes sense.

I have mostly used it for diffs and markdown files, because that is a lot of what agents like OpenClaw end up producing. A chat interface can technically show that stuff, sure. The same way you can technically eat soup with a fork if you hate yourself. The failure mode is also extremely boring. If it fails, I ask the agent to send me the file directly as markdown and I open it in a viewer. Which, while not as bad as eating soup with a fork, is still pretty annoying.

That brings me to the point, the cost of failure is just doing it the old way, so the barrier for entry has to be low. And when it works, which it basically has for me, it is much better than the workflow I had before. Would I have been able to build this without AI? Yeah, probably. This is not some revolutionary app. This is just a glorified pastebin. But the hurdle is the fact that I am far from competent at front-end design and development and this has stopped me from building a bunch of stuff in the past.

And then Claude walks in and hits that hurdle with a sledgehammer. The wall of being good enough at frontend to make something which looks good just completely got shattered by me just taking a skill and asking Claude to make it look good and attaching a few reference images.

The Swift wall stopped being a wall

I use CodexBar, a macOS menu bar app by Peter Steinberger. I get a lot of value out of it, but it did not support a couple of AI inference providers I was using.

I just recently started using a Mac, and honestly, I've never been interested in learning Swift. And that's not because Swift is bad—it's just not on my priority list, and I don't feel like it will ever be at this point. So me of a few months ago would have run into this and been annoyed, but you know, been understanding because these are niche AI providers which I use for very specific use cases.

So again, I sent an agent at it. That turned a problem into a couple of PRs: one to support Synthetic's V3 rate limits, and another to add Crof as a provider.

This was not magical, I don't think a person with zero technical knowledge could have done this. Codex did not nail this the first try. It needed some iteration, The agent was not able to wrap its head around the fact that the quota for Synthetic regenerates a certain percentage every few minutes instead of just resetting from 0 to 100 every 5 hours.

But it turned the barrier from "I don't know Swift and I have no idea how to even develop a macOS app" to "can I figure out what it could be doing wrong and how to guide it onto the right path."

Watching someone else realize it

The thing which compelled me to write this blog was one of my friends essentially catching the bug as well. We were just sitting on a Discord call, either chatting or playing a game of overwatch. And he mentioned an idea for a VS Code extension, and I said something like, "Yeah, that sounds like a two or three hour project."

He was shocked by me even suggesting that this might take less than a week or two of learning how to write a VS Code extension and then actually getting it to work. So I got him set up using OpenCode and a good open source model, not even a frontier model.
He looked at that estimate like I had suggested we casually rebuild Kubernetes after dinner.

A couple of hours later he had a working VS Code extension, and the agent had also walked him through the annoying Azure DevOps / marketplace publishing stuff too. Again, this does not mean the extension was some perfect production artifact. It means he had a problem, tried to build around it, and found out the wall was much shorter than he thought.

That is the thing I keep coming back to. You do not learn what agents can do by reading takes about them(including this one). You learn by throwing a real annoyance at them and watching where they fail. Ideally, something where, if it catastrophically breaks, it's not gonna cause you too much issues. If it breaks, you know that you were being too ambitious, and if it works flawlessly, you know that next time you can probably push it harder.

What I am not saying

I am not saying AI can make reliable production apps from scratch without someone who knows the underlying tech.

I am not saying you should replace every coder or engineer with an agent.

I am not saying maintainability, security, taste, testing, and boring engineering judgment suddenly stopped mattering.

If your software handles money, medical records, auth, customer data, infrastructure, or anything where failure hurts other people, then yes, please use actual engineering standards. Review the code. Write tests. Threat model. Do the boring stuff.

What I am saying is the barrier to entry has never been lower. If you have a problem and the entire user base for the solution is just you, that is enough now. You do not need to justify it as a startup. You do not need to pretend there is a market. You do not need to convince yourself that the idea is worth a weekend because thousands of people might use it someday.

You are not going to cause some software-as-a-service apocalypse because you made a shitty little tool that fails outside your exact use case. Just be honest about what it is. Do not sell it as reliable if it is not reliable. Do not put other people's data through it if you have not earned that trust. But if it works for you, and the failure mode is safe, you can call it done.

The total addressable market can be one

"You can just do things" does not mean "you can stop thinking."

The agent can write code, but it cannot care about your problem for you. That part is still yours. You need to know what is annoying, what good enough looks like, which corners can be cut, and which ones absolutely cannot.

The advantage of building for yourself is that the feedback loop is immediate. You are not guessing what users want. You are the user. You know when the tool made your life less annoying.

So the test is simple:

• Does this thing solve my problem?
• Does it fail safely?
• Would I rather use it than what I was using before?

If the answer is yes, congratulations. You shipped. To your total addressable market of one.