Anna's Articles

A Pragmatic Approach to LLMs

2026-06-08

I don't vibecode. I don't use LLMs willingly. Every line of code I write is my own or generated deterministically through a process I fully understand. Considering the world is divided over LLMs these days, I wanted to share my particular perspective on why I chose the path I have, as well as some of the places I do think LLMs are appropriate.

Why I Don't Vibecode

I have never used Claude Code, Cursor, Codex, or any other tool intended to replace or augment the software development process with LLMs. I have not used agentic coding, nor am I interested in spending the money to try it. In spite of this, I have kept up to date with the latest developments in agentic coding from academic and interpersonal perspectives. Because of this understanding, I decline to participate in vibecoding or any other use of LLMs in generating code.

There are a few reasons for this.

Enjoying the Craft

First of all, I enjoy programming. It may be frustrating to deal with the complexities of writing code, especially if you're doing it at the wrong layer of abstraction, but I don't believe automating it is the answer. The friction involved in writing code forces me to consider the approaches I'm using and take a step back. That friction is what often keeps me from writing something half-baked and developing something beautiful.

The more that our software toolchains disable thought, the more we lose of our craft. For me, that trade is never going to be worthwhile.

Surrendering Autonomy

Since programmable personal computers were accessible to people, we have been able to reprogram them according to our whims. There have been restrictions that we've had to fight back against, but we've held onto enough autonomy to create our own software without having to get a corporation's permission (though this has by no means been universal, and it's closing rapidly).

I want to be able to exercise my own skills on my own device, aided by a community of others with similar goals. I don't want to spend money on my own skills. Nor do I want to generate mountains of LLM-generated code that's impossible to review or maintain without a subscription to an OpenAI or Anthropic model, which keep increasing the price to modify your own code.

I see it as a trap. Become dependent on the tools today by atrophying your skills, becoming addicted, and creating otherwise unmaintainable codebases, and then being charged much more for it once you have no other option. Programming as a hobby should never cost $1000, $200, or even $20 per month.

Simply put, I don't want to rent my brain.

I See the Slop

These days, so much open-source software has embraced corporate LLMs. It's disheartening. I keep seeing people use LLMs to create software that barely works and publishing it to the wider Web. Sometimes it looks "professional", with its README put together. It's signal-shaped noise—made to look like a real project with real effort put into it but a simple production of an agentic slot machine.

I sometimes wonder if SDPX-style identifiers that identify LLM-involvement in a software project would be helpful. Something like LLM-assisted, LLM-generated, and LLM-free. Then developers could scan their dependencies for instances of it. I'm not sure this would work, since users of LLMs have been dishonest and will likely continue to be.

This is even worse with contributions. Any open-source project with a modicum of popularity is being inundated with LLM-generated pull requests and patches. Projects don't want to reject genuine human contributors but filtering out the noise is becoming increasingly difficult.

I believe Zig's ban of LLMs is a better approach than Ladybird's ban of external contributors. There may be some niche use-cases of LLMs, but overall they are making open source worse.

They're the Wrong Approach

Many people see LLMs as the future of human-computer interaction. They see them as the new compilers that transform natural language into computer languages. I'm not going to go into this too much because I've addressed this before, but I will say that the primary difference is determinism.

There is a deterministic pipeline from your source code to the machine code that runs on your system. You know what you are getting when you compile your code. It's a bug if the compiler misinterprets that code if you wrote it correctly. You also keep that code after you compile it. None of those are true in the case of LLMs.

I support creating a higher-level approach to programming that more closely resembles natural language. I want everyone to be able to exercise control over their computers. LLMs just aren't the model for that.

In many places, the legal status of LLM-generated code and other works is unclear. There are many ongoing lawsuits which have yet to be resolved, especially internationally. I want the code I write to be clearly copyrighted by myself, so I can license it for public use with as little legal difficulty as possible.

If I used an LLM to write code, I would be putting myself in potential legal risk, since at some point code may be found to be a derivative work of other people's code without following attribution and other license requirements.

No LLM I am aware of follows the legal requirements of any open-source license, even when its plagiarism is obvious.

The Environment

Yes, I know that using LLMs doesn't use that much energy, comparatively, but excessive usage combined with constant training of them does. Riding the hype train only makes this spiral even further out of control.

Legitimate Use-Cases

Despite my skepticism of using LLMs for programming directly, I do believe they have appropriate use-cases. There is some room for ethical LLMs. In all of these use-cases, LLMs are used for their analysis capabilities more than their ability to generate anything on their own.

I only support these usages of LLMs when they are run locally, under the control of the user, and as much information as possible regarding the training and operation of these LLMs is publicly available. Open weights are not enough, the models must be open source at all levels. Like any technology, LLMs should be used to empower people, not instill dependency.

At the moment, models that can do what most people are interested in doing with them don't run well locally, especially on hardware that most people have available. Because of this, I am unlikely to use LLMs in these capacities any time soon.

Isn't it helpful to have a tool that speaks natural language and can tell you exactly where something is in a codebase? Obviously you still need to verify it, but when learning a new codebase it can be difficult to know where to start. LLMs can make guesses at where what you're looking at may be, narrowing the scope of what you need to look at initially.

To be clear, this is mostly the case if the codebase is poorly documented. Ideally, software comes with a guide on how to use and modify every aspect of it, negating the need to use another tool as a guide. Unfortunately, many projects have sparse or non-existent documentation.

Vulnerability Research

It doesn't matter how vulnerabilities are found if they are real vulnerabilities. LLMs have proven themselves capable of finding and verifying vulnerabilities. Maybe not to the extent hyped by some companies, but certainly to an extent that's causing many new bugs to be found in otherwise conservative projects.

Unfortunately, the scale at which LLMs are currently finding vulnerabilities is causing extreme stress on the part of open-source projects, such as curl and rsync. Some of whom have turned to using LLMs in an attempt to resolve those vulnerabilities.

Because of this, I would follow Zig's policy on LLMs: refuse all contributions written by or inspired by LLMs, including vulnerability discoveries. This may seem counterintuitive at first, considering the vulnerabilities exist regardless of how they are found. But Zig is a rapidly iterating project that is still unstable. They might change their policy in the future, but for now they want to focus on existing human users and their needs rather than chasing down every possible bug an LLM could find.

Once a project has matured and has stabilized, then it may be a good idea to open it up to LLM-discovered vulnerabilities, after conventional testing and fuzzing is performed. But even then, maintainers have to take a hard look at their priorities and determine whether the treadmill of security fixes is possible to resolve, or if responsibility for those fixes needs to be pushed on the corporations which make the real money from the code.

Conclusion

That's why I don't use LLMs. I want to preserve my own craft without renting my brain. I don't want my own work to become like the countless projects whose code has never been read, much less understood. There are better answers to the problems LLMs try to solve. They're not worth the social, practical, or legal risks for me.

Meanwhile, they have limited use-cases. I can see their utility as a glorified search engine for poorly documented codebases and for vulnerability research. I'm certain there are more use-cases, both explored and not. Unfortunately, they are used far beyond the scope in which they are useful. At this point many of us are looking at futures in which we are forced to manage these machines faster and faster or risk homelessness. This is a future no one deserves. It's a future we need to push back against.