A Year of Vibe Coding in Production. Observations from a Solo Developer

Format: Opinion Context: 2026, production projects, AI agents as part of the process Topic: what has actually changed in a developer’s work, without hype and without hype-mongering

Preamble

This is not another article about "AI will replace programmers" or "AI is just hype". I’m tired of both of those takes. This is an attempt to calmly look at what has happened to my work over the past year — after agentic AI tools became genuinely usable, rather than just being the focus of demos.

I’ll start by outlining my context upfront, so you understand the perspective I’m writing from.

I am a solo developer. I have several products running in production at the same time: a messenger built with React Native + Electron + FastAPI, an AI platform with its own backend, a marketing automation tool, and a desktop application for a manufacturing company built with Rust + Tauri. I am not a startup co-founder with a funding round and five junior developers on my team. I am a single person building multiple products and earning a living from them.

I use Claude Code in agent mode on a Max subscription. That’s $200 a month — not cheap, but for my cost structure, it costs less than I would pay a single junior developer for two days of work. By my rough estimate, around 70% of the code that ends up in my projects’ repositories is written with active AI involvement. That doesn’t mean "Claude took my task and coded it for me" — it means Claude and I work together, and the final code is the product of that joint work.

Below is what I think about this after a year of working this way.

Core thesis: my role has changed, but it hasn’t disappeared

A year ago, my work consisted of two large parts: figuring out how to build something and building it. Now, almost only the first part remains.

That doesn’t mean I don’t write code by hand anymore. I do — just different code. Tasks that used to take hours (writing a CRUD endpoint, laying out a form, implementing a standard pattern) now take minutes. Not because I type faster, but because for these tasks, I don’t type the code myself. I outline what I need, check the result, and make adjustments.

What hasn’t gone away is all the architectural decision-making. Why three levels of cache instead of two. Which indexes to add to SQLite, and why those specific columns. When it’s worth building a custom protocol implementation, and when to use a ready-made library. These are decisions AI doesn’t make for me — it can suggest options, but I’m the one who chooses.

Compilable logical errors. The most insidious type of error. The code looks well-written, passes linting, passes the tests that the AI itself wrote for it. But in production, in some edge case it doesn't work as intended. This category of errors is the main reason why I read every line generated by AI, even if it ends up in the code almost unchanged.

Suboptimal algorithms. AI tends to use O(N²) where O(N) would work, loves creating intermediate data structures, and loves mapping, filtering, and reducing when a single pass would suffice. For most tasks this doesn't matter — even poorly written code runs in milliseconds. But when we're talking about hot paths or working with large datasets, a profiler shows that AI-generated code can be sped up 10-50 times with simple rewrites.

What I don't trust AI with

There are several categories of tasks where I either don't use AI at all, or use it with extra care, checking every single line.

Security-critical code. Cryptography, authentication, user input handling, everything related to access permissions. AI doesn't "write incorrect code" here — it often writes code that is formally correct, but may miss a nuance that is critical in the given context. The cost of a mistake far outweighs the time saved, so for these tasks I work more slowly and manually.

Architectural decisions. This isn't about "write class X", but "how do we build service N so it can scale". AI is good at generating code based on a clear set of requirements. It's worse at coming up with the requirements itself. Architecture is mostly about tradeoffs between competing requirements. AI tends to choose the most standard path, which isn't always the right choice.

Migrating data to production databases. Any code that has irreversible consequences for production. The "I tested it locally, let's deploy it" approach does not work here — here you need to understand what will happen to all the data currently in the database. This is the area where I would rather pay more to do it manually.

What's changing in my habits

There are a few things I've noticed in my work that surprised me a little.

I've started thinking more before writing. It's a paradox — before, I often wrote, tested, and rewrote code because that was faster than working it through in my head. Now, before formulating a prompt, I think the task through more thoroughly. A poorly formulated prompt produces bad code, and reworking it sometimes takes longer than writing it from scratch. It's similar to the situation if I had a junior developer — I'd spend time explaining the task properly, because otherwise the junior would waste a whole day for nothing.

I am less afraid to start complex tasks. Before, a task marked "need to do X" with an estimate of "a week of work" would get put off, because it's psychologically hard to start a week-long task. Now the same task takes two or three days, and it's easier to get started on it. This means I complete more tasks overall.

I read more other people's code. It sounds strange, but AI-generated code is still other people's code that I need to understand before adding it to my repository. I do more of this kind of reading than I did a year ago. It's a useful muscle — I've gotten better at navigating unfamiliar code overall.

I write less boilerplate code manually. Buttons, forms, wrappers, standard helpers — all of this is generated now. This means I'm gradually losing the skill of writing this kind of code quickly by hand. I'm not sure if that's a problem, but it's objectively happening. If AI tools disappear tomorrow, it will be physically uncomfortable for me to go back to writing template code manually.

Why I'm not afraid that AI will replace me

This is the question I get asked most often, and I'm tired of both standard answers — "AI will replace everyone soon" and "AI will never replace a real developer". Both answers are ideological positions, not observations.

My stance: AI has already replaced a certain portion of my work — the routine, template-based, repetitive tasks. And that's perfectly fine. This part of the work was not interesting, did not make me a better engineer, and did not add value to the product. The machine does it faster. That's good.

What AI has not replaced is decision-making. Not "what code to write", but "what system to build, for which users, with what trade-offs, in what sequence". These decisions require knowledge of the product, market, users, and business context. AI does not have this context — and it will not have it until the solo developer provides it themselves. And as long as the developer is doing this, they remain an irreplaceable link.

Can this change? Possibly. Can AI become capable of independently designing a product from idea to release? Technically — probably, someday. Practically — I definitely don't see this happening within the next year or two. And if it happens in five years, I will have five years to adapt to the new reality, just like all of us.

Adaptation is the only reasonable response. Not "don't use AI because it will kill my profession" and not "use AI blindly because otherwise I'll fall behind". Use it where it is useful, don't use it where it is harmful, and constantly check your assumptions about where the line between these two cases lies.

Can I do what I do on my own — without AI?

I have asked myself this question several times. The honest answer is yes, it is possible. Without AI, I would do the same work, it would just take significantly more time — likely two to three times more. Instead of working on multiple products in parallel, I would focus on just one.

In other words, AI does not make the impossible possible for me. It makes slow work fast. That's an important distinction. If I can't figure out a task from an architectural standpoint — AI won't help me. If I know what needs to be done, but it would take a month to complete alone — with AI it will take a week. That's the full effect of it.

Conclusion

A year of vibe coding in production is a year of getting used to a new way of working. No euphoria, no disaster. Just a different way to do the same work.

In my view, the core question for solo developers in 2026 is not "whether to use AI" (the answer to that is obvious), and not "how to use AI better than anyone else" (there are plenty of guides for that, pick one that suits you). The core question is what you will do with the time you free up.

You can do more of the same work. You can start working on things you didn't have time for before. You can work fewer hours a day and spend the freed-up time on your personal life. This is no longer a technical choice, it's a personal one.

Personally, I'm currently working on multiple products at the same time. It's possible that in a year I'll realize that was a mistake and focus on just one. But that's my choice — not a forced position because one person can't handle everything all at once.

This is the fifth article in my software development series. The previous entries covered concrete project case studies: three-tier message cache, Double Ratchet E2E, WebRTC calls, vanilla Electron desktop. This one is a different genre, consisting of general observations. If you're reading this and thinking "my experience is different" — share it in the comments. I'm curious to find out how typical my experience is, or if it's not.