What 50,000 Lines of AI-Assisted Code Actually Looks Like

Six months ago I wrote about shipping products without knowing how to code. That post resonated because the idea was new. Since then I have written over 50,000 lines of production code with Claude Code. Every day. Real systems, real users, real revenue. The novelty is gone. What remains is a very specific, very honest picture of what this work actually looks like.

This is not a tutorial. It is not a hype piece. It is a practitioner's field report from the other side of "vibe coding," where you stop marvelling that AI can write code and start dealing with the consequences of deploying it.

The Portfolio

Let me be specific about what I have built. Not in theory. In production, right now.

Kern OS is an AI operating system that runs on Railway. It manages my calendar, email, memory, project context, and agent orchestration across every tool I use. It has persistent memory backed by pgvector, cron-scheduled routines, and a multi-agent architecture where specialist sub-agents get spawned for specific tasks. It is the backbone of how I work.

BookerBot is an AI phone agent. It handles inbound calls, books appointments, and manages conversational flows with real humans who do not know they are talking to software. Voice synthesis, real-time transcription, state management across multi-turn conversations.

Resuite is a consumer app that takes a photo of a room and generates AI-powered redesigns. Image processing pipeline, style transfer, user accounts, payment integration. Production users paying real money.

Net Positive is an editorial site with AI-generated illustrations. Every article gets custom artwork produced by an image generation pipeline that understands editorial context. Content management, automated publishing, illustration workflows.

The Levity content engine sits at 42,000+ lines alone. Blog generation, SEO optimization, automated publishing, analytics integration. It powers the site you are reading right now.

None of these are side projects gathering dust. They run. They serve users. They make money or save time that converts to money. I maintain all of them, and I still cannot tell you what a useEffect hook does without looking it up.

What a Tuesday Looks Like

People ask about the workflow and expect something magical. It is not magical. It is a lot of talking to a very fast, very literal colleague who has perfect recall and zero common sense.

A typical morning: I open Claude Code. I have context about what I was working on yesterday because Kern's memory system persists it. I describe what I want to build next. Not in code. In outcomes. "The webhook handler needs to retry failed deliveries with exponential backoff, max three attempts, and log each failure to the monitoring table."

Claude writes it. I read what it wrote. Not the syntax. I cannot evaluate syntax. I read the logic. Does it make three attempts? Does the delay increase? Does it log the right fields? I run it. Something breaks. I paste the error. It fixes it. Something else breaks. I describe the symptom. It fixes that too.

This loop takes five to fifteen minutes for a feature that would have taken a developer a few hours. Not because the AI is faster at typing. Because the feedback loop is instant. There is no Slack message, no standup, no context switching. The person who understands the business problem is sitting next to the thing that writes the code.

I do this eight to twelve times a day. By evening I have shipped more features than most small teams ship in a sprint.

What AI Gets Right Every Time

Boilerplate. Dear god, the boilerplate. Every web application is 60% wiring. API routes, database schemas, form validation, error handling, pagination, auth middleware. The stuff that is not intellectually interesting but takes forever to write correctly. AI eliminates this entirely. You describe the shape of the thing and it wires up everything.

Pattern replication. Once I have established how something works in one part of the codebase, I can say "do the same thing for this new entity" and get a perfect copy with the right names changed. No copy-paste errors. No forgotten edge cases that existed in the original.

Documentation. I never write docs. I describe what the system does and Claude writes documentation that is better than anything I would produce because it actually reads the code instead of guessing from memory.

Refactoring. "This file is 800 lines and does too many things. Break it into logical modules." It does. Correctly. With the import paths updated everywhere. A task that would take a human developer an afternoon of careful, tedious work happens in ninety seconds.

What AI Gets Wrong Every Time

This is the part the hype pieces skip.

It over-engineers. Ask for a simple function and you will get an abstract factory pattern with three layers of indirection. Every time. You have to actively fight the instinct toward complexity. "Simpler. Just do the thing. No abstraction layer. No config object. Just the function." You will say this ten times a day.

It loses the plot on long sessions. After two hours of back-and-forth in the same context, the AI starts making changes that contradict things it did thirty minutes ago. It forgets constraints you established early in the conversation. You learn to start fresh sessions frequently and front-load the important context every time.

It cannot hold system-level architecture in its head. It is brilliant at the file level. It can write a perfect API route. But ask it to reason about how twelve services interact across a distributed system and it will confidently produce something that works in isolation and breaks everything else. Architecture is still a human job.

It hallucinates APIs. It will import a library method that does not exist, call a function with the wrong signature, or reference a database column you never created. Not occasionally. Regularly. You learn to never trust an import statement without verifying it. This is why "non-technical people can build software now" is only half true. You need enough technical literacy to spot when the AI is lying to you with complete confidence.

It writes tests that test the implementation instead of the behaviour. Every time. The tests pass because they are tautological. They verify that the code does what the code does, not that the code does what the user needs. Writing good tests still requires a human who understands what "correct" means in context.

The Architecture Decisions That Matter

After six months I have a clear mental model of what to delegate and what to own.

Delegate implementation. Own architecture. Let the AI write every function, every component, every query. But decide yourself how the system is structured. Which services exist. How data flows between them. What the boundaries are. If you let AI make architectural decisions, you end up with a codebase that works today and becomes unmaintainable next month.

Delegate CRUD. Own state management. Creating, reading, updating, and deleting records is mechanical work. AI does it perfectly. But the rules about when state changes, what triggers what, and how concurrent operations interact: that is where bugs hide and AI does not have the judgment to get it right.

Delegate styling. Own information hierarchy. AI can write beautiful CSS. It cannot decide what the user should see first, what the primary action is, or how the page should flow. Design judgment is human judgment. Let AI handle the pixels once you have decided the structure.

Delegate error handling. Own error strategy. AI will write try-catch blocks all day. But deciding which errors should retry, which should alert, which should fail silently, and which should halt the whole pipeline: that requires understanding what your users will tolerate and what your system can recover from.

The Numbers

People love asking about cost and velocity, so here are real numbers.

Claude Code costs me roughly $200 to $300 per month. That is the Pro plan plus the API usage from Kern's agent orchestration. For context, a mid-level developer in my timezone costs $4,000 to $6,000 per month. I am not replacing a developer. I am augmenting myself to the point where the output is comparable.

I ship between three and eight features per day. Not all are big. Some are bug fixes, some are small improvements. But the volume is real. In a traditional team this would require multiple developers coordinating through tickets and pull requests.

Time from idea to production averages two to four hours for a new feature. That includes the conversation with Claude, testing, deployment, and verification. For a completely new product, from zero to deployed, I budget one to two weeks. Kern OS took about three weeks of active development to reach its current state. BookerBot was built in ten days.

About 15% of AI-generated code gets rewritten within a week. Not because it was wrong. Because once you use the feature in production, you realize the approach needs to change. This is normal in software development. The difference is that rewriting is also fast.

The Gap Between "Vibe Coding" and Reality

The term "vibe coding" markets this as easy. It is not easy. It is easier than traditional development, yes. But it requires a specific and non-trivial set of skills that nobody talks about.

Prompting is a real skill. Not in the "learn these five prompt templates" sense. In the sense that you need to learn how to decompose a complex problem into chunks the AI can execute without losing context. You need to know when to be specific and when to be vague. You need to develop an instinct for when the AI is about to go off the rails and intervene before it wastes twenty minutes down a dead end.

Quality control is the actual job. The AI writes code fast. Your job is to make sure it is the right code. This means reading everything it produces, understanding the logic even if you cannot write it yourself, testing edge cases it did not think of, and maintaining a mental model of the system that the AI does not have. If you skip this step, you ship bugs. Lots of bugs.

Debugging without stack trace literacy is a learned art. When something breaks and you cannot read the error message, you develop a different debugging methodology. You describe symptoms. You ask the AI to add logging. You narrow the problem by toggling features on and off. It works, but it is a skill you build over months, not something you pick up on day one.

Architectural debt accumulates faster. Because shipping is so fast, you can build a tangled mess in days instead of months. Discipline matters more when velocity is high. I have learned to force myself to refactor before adding features, even when the AI makes it tempting to just keep stacking.

Why This Matters for Levity

I run a consulting and development agency. Every client engagement benefits from the fact that I build production software with AI every single day. Not as a demo. Not as a proof of concept. As my actual workflow.

When a client asks "can AI do this?" I do not have to guess. I have probably built something similar in the last month. When they worry about quality, I can show them production systems with real users. When they want to move fast, I can move fast, because the toolchain I use daily is the same one I deploy for them.

Most agencies that offer AI services have a sales team that read a white paper and an engineering team that attended a workshop. We have a founder who writes production AI-assisted code before breakfast and uses an AI operating system to manage the agency itself. That gap in practitioner experience is the entire competitive advantage.

The agencies that survive the next two years will be the ones that build with AI, not just sell it. Everyone else is reselling access to tools their clients will learn to use themselves.

Where This Goes

Six months from now the tools will be better. The models will be smarter. The failure modes I described above will partially disappear and be replaced by new ones.

But the fundamental insight will not change. The people who build the best software with AI will not be the best prompters or the best coders. They will be the people with the clearest understanding of the problem they are solving, the best taste for what good looks like, and the discipline to maintain quality when the tooling makes it easy to ship garbage at high speed.

The skill is not coding. It was never coding. It is thinking clearly about what needs to exist in the world and then making it exist. AI just removed the last barrier between the thinking and the making.

Fifty thousand lines in. Still learning. Still shipping.