나는 단 한 줄의 코드도 작성하지 않고 완전한 제품을 배송했다. 실제로는 다음과 같습니다.

I’ve been a JS/TS/Java developer for years. A few weeks ago I shipped a production proxy in Go — with a Vue dashboard, Redis counters, Postgres, security hardening, a CI pipeline, a multi-arch Docker image, and 32 headless UI tests — without writing a single line of code myself.

I want to be precise about what that means, because the framing matters.

What I built

ProxAI is a transparent reverse proxy that sits between your apps and LLM APIs (OpenAI, Anthropic, Mistral, and 6 others) and enforces hard hourly/daily spending caps per client. You change one base_url; it meters costs in real time and returns 429 the moment a budget is exceeded. The upstream is never called once you’re over cap.

I built it after reading one too many postmortems of agent loops and leaked keys torching API budgets overnight — while provider billing alerts are monthly and org-wide.

Repo: https://github.com/mat-chartier/proxai (AGPL)

What “no hand-written line” actually means

It doesn’t mean I sat back and watched an AI build software. It means I directed Claude Code for every task: writing the spec, reviewing the output, testing it manually, deciding when it was good enough, and moving to the next thing.

The workflow is closer to being a very hands-on tech lead than to pressing a button. The difference is that the person implementing your specs never gets tired, never pushes back on scope, and will rewrite anything you ask — but won’t catch its own blind spots.

First drafts were almost always unusable

This is the part that tends to get glossed over in “I built X with AI” posts.

Almost every first draft — backend handlers, frontend views, you name it — landed in a state I couldn’t ship. Not broken in obvious ways, but wrong in subtle ones: structure that didn’t fit the rest of the codebase, UI that worked but felt off, logic that handled the happy path and ignored edge cases I cared about.

What made it work wasn’t accepting those drafts. It was knowing precisely how to direct the corrections. “The modal closes too early” or “the error state isn’t handled” or “this endpoint needs to validate X before doing Y.” Each correction required me to identify what was wrong and articulate it clearly.

That’s a skill. It’s not passive.

Two things I had to impose that Claude never spontaneously suggested

A security review. The product proxies API keys in transit and stores client tokens. Security wasn’t going to handle itself. I had to explicitly stop feature development, commission a structured audit pass, and work through the findings one by one. Ten findings, all resolved — including encrypted tokens at rest, hashed magic links, fail-closed budget checks, constant-time comparisons. None of that happened organically.

Responsive design. The dashboard worked on desktop. On mobile, it was broken. I had to stop and explicitly direct a responsive pass: grid rewrites, scrollable tables, stacked forms, viewport testing at 390px. Left alone, Claude builds for whatever viewport the problem description implies — which is usually desktop.

The pattern: Claude handles what you spec. The things you don’t think to spec don’t exist.

How I reviewed the output

I didn’t do code review. That’s the point of the experiment — I’m a JS/TS dev, not a Go expert, and I wanted to find out whether I could ship a correct Go backend by testing rather than reading it.

I tested manually. I ran the test suite (Go tests + headless UI checks in CI). I read error messages. I traced flows end to end. When something was wrong, I described the symptom to Claude and we fixed it.

The codebase went through a real security audit, not just vibes. The tests are real tests, not mocks of mocks. The CI catches regressions. I’m not claiming the code is perfect — I’m claiming it’s been validated by something other than “it looks right to me.”

What surprised me

I expected to hit a wall. A moment where the AI’s context window would collapse, or the accumulated complexity would make further progress impossible, or I’d need to understand Go deeply enough to debug something it couldn’t.

I haven’t hit it yet. Whether that’s a property of the project size, my directing style, or Claude Code specifically, I can’t say. What I can say is that the limiting factor throughout wasn’t the AI’s ability to write code — it was my ability to specify clearly what I wanted.

Is it worth it?

For me, for this project: yes. I could not have shipped a production Go proxy on my own timeline. The experiment forced me to get very good at specification and very honest about what I actually wanted, which turned out to be useful skills independent of the AI.

Whether the output is trustworthy is a question you’ll have to answer yourself — which is exactly why ProxAI is AGPL and small enough to audit. The process is disclosed in every commit message. Judge the code, not the process.

ProxAI is live at proxai.eu (free beta, no credit card) and fully self-hostable via docker compose. Happy to discuss the workflow or the proxy in the comments.