"[Person who is financially incentivized to make unverifiable claims about the utility of the tool they helped build] said [tool] [did an unverified and unverifiable thing] last month"

Is anyone with or without AI approaching anywhere near that speed of delivery?

I don’t think my whole company matches that amount. It sounds super unreasonable, just doing a sanity check.

Lines of code has always been a questionable metric of velocity, and AI makes that more true than ever.

There's a ton of cruft in code that humans are less inclined to remove because it just works, but imagine having LLM doing the clean up work instead of the generation work.

- get a feature request/bug

- understand the problem

- think on a solution

- deliver the solution

- test

- submit to code review, including sufficient explanation, and merge when ready

260 PRs a month means the cycle above is happening once per hour, at constant speed, for 60 hours work weeks.

This is more what agentic-assisted dev looks like:

1. Get a feature request / bug

2. Enrich the request / bug description with additional details

3. Send AI agents to handle request

4a. In some situations, manually QA results, possibly return to 2.

4b. Otherwise, agents will babysit the code through merge.

The second is that the above steps are performed in parallel across X worktrees. So, the stats are based on the above steps proceeding a handful of times per hour--in some cases completely unassisted.

---

With enough automation, the engineer is only dealing with steps 2 and 4a. You get notified when you are needed, so your attention can focus on finding the next todo or enriching a current todo as per step 2.

---

Babysitting the code through merge means it handles review comments and CI failures automatically.

---

I find communication / consensus with stakeholders, and retooling take the most time.

You know the features you'd like to have in advance, or changes you want to make you can see as you build it.

And a lot of the "deliver the solution - test - submit to code review, including sufficient explanation" can be handled by AI.

Which could mean that code was refactored and then built on top of. Or it could just mean that Claude had to correct itself multiple times over those 459 commits.

Does correcting your mistakes from yesterday’s ChatGPT binge episode count as progress…maybe?

I can easily imagine constant churn in the code because it switches between five different implementations when run five times, foing back to the first one on the sixth time and repeating the process.

I gotta ask, though, why exactly is that much code needed for what CC does?

It's a specialised wrapper.

    #!/usr/bin/env bash
    while true; do
      printf "> "
      read -r USER_INPUT || exit 0
      RESPONSE=$(curl -s https://api.openai.com/v1/chat/completions \
        -H "Authorization: Bearer $OPENAI_API_KEY" \
        -H "Content-Type: application/json" \
        -d "{
          \"model\": \"gpt-5.2\",
          \"messages\": [
            {\"role\": \"user\", \"content\": \"$USER_INPUT\"}
          ]
        }")
      echo "$RESPONSE" | jq -r '.choices[0].message.content'
    done

That's an awfully presumptious tone to take :-)

I'm not deciding "This is how many lines they are allowed", I'm trying to get an idea of exactly what sort of functionality that CC provides requires that sort of volume.

I mean, it's a high-level language being used, it's pulling in a lot of dependencies, etc. It literally is glue code.

Bearing in mind that it appears to be (at this point anyway) purely vibe-coded, I am wondering just how much of the code is dead weight - generated by the LLM and never removed.

I'm not affiliated with Claude or the project linked.

https://www.amazon.com/Vibe-Coding-Building-Production-Grade...

He also has some other agent-coordination software. https://github.com/steveyegge/vc

Don't know whether it's helpful, or what the difference is.

> Gas Town is also expensive as hell. You won’t like Gas Town if you ever have to think, even for a moment, about where money comes from. I had to get my second Claude Code account, finally; they don’t let you siphon unlimited dollars from a single account, so you need multiple emails and siphons, it’s all very silly. My calculations show that now that Gas Town has finally achieved liftoff, I will need a third Claude Code account by the end of next week. It is a cash guzzler.

https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d...

https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d...

> It’s also 100% vibe coded. I’ve never seen the code, and I never care to, which might give you pause. ‘Course, I’ve never looked at Beads either, and it’s 225k lines of Go code that tens of thousands of people are using every day. I just created it in October. If that makes you uncomfortable, get out now.

Humans writing is slow, no doubt, but humans reading code ain't that much faster.

Lines of code never correlated with quality or even progress. Now they do even less.

I've been working a lot more with coding agents, but my convictions around the core principles of software development have not changed. Just the iteration speed of certain parts of the process.

My understanding of the current state of AI in software engineering is that humans are allowed (and encouraged) to use LLMs to write code. BUT the person opening a PR must read and understand that code. And the code must be read and reviewed by other humans before being approved.

I could easily generate that amount of code and make it write and pass tests. But I don't think I could have it reviewed by the rest of my team - while I am also taking part in reviewing code written by other people on my team at that pace.

Perhaps they just aren't human reviewing the code? Then it is feasible to me. But it would go against all of the rules that I have personally encountered at my companies and that peers have told me they have at their companies.

The AI evangelists at my work who say this the loudest are also the ones shipping the most "did anyone actually look at this code?" bugs.

  ratatui_ruby % git remote -v
  origin https://git.sr.ht/~kerrick/ratatui_ruby (fetch)
  origin https://git.sr.ht/~kerrick/ratatui_ruby (push)
  
  ratatui_ruby % git checkout v0.8.0
  HEAD is now at dd3407a chore: release v0.8.0
  
  ratatui_ruby % git log --reverse --format="%ci" | head -1 | read first; \
  echo "First Commit: $first\nHEAD Commit:  $(git show -s --format='%ci' HEAD --)" 
  First Commit: 2025-12-22 00:40:22 -0600
  HEAD Commit:  2026-01-05 08:57:58 -0600
  
  ratatui_ruby % git log --numstat --pretty=tformat: | \
  awk '$1 != "-" { \
      if ($3 ~ /\./) { ext=$3; sub(/.*\./, "", ext) } else { ext="(no-ext)" } \
      if (ext ~ /^(txt|ansi|lock)$/) next; \
      add[ext]+=$1; rem[ext]+=$2 \
  } \
  END { for (e in add) print e, add[e], rem[e] }' | \
  sort -k2 -nr | \
  awk 'BEGIN { \
      print "---------------------------------------"; \
      printf "%-12s %12s %12s\n", "EXT", "ADDED", "REMOVED"; \
      print "---------------------------------------" \
  } \
  { \
      sum_a += $2; sum_r += $3; \
      printf "%-12s %12d %12d\n", $1, $2, $3 \
  } \
  END { \
      print "---------------------------------------"; \
      printf "%-12s %12d %12d\n", "SUM:", sum_a, sum_r; \
      print "---------------------------------------" \
  }'
  ---------------------------------------
  EXT                 ADDED      REMOVED
  ---------------------------------------
  rb                  51705        18913
  md                  20037        13167
  rs                   8576         3001
  (no-ext)             4072         2157
  rbs                  2139          569
  rake                 1632          317
  yml                  1431          153
  patch                 894          894
  erb                   300           30
  toml                  118           39
  gemspec                62           10
  gitignore              27            4
  css                    22            0
  yaml                   18            2
  ruby-version            1            1
  png                     0            0
  gitkeep                 0            0
  ---------------------------------------
  SUM:                91034        39257
  ---------------------------------------

  
  ratatui_ruby % cloc .
       888 text files.
       584 unique files.                                          
       341 files ignored.
  
  github.com/AlDanial/cloc v 2.06  T=0.26 s (2226.1 files/s, 209779.6 lines/s)
  --------------------------------------------------------------------------------
  Language                      files          blank        comment           code
  --------------------------------------------------------------------------------
  Ruby                            305           4792          10413          20458
  Markdown                         60           1989            256           4741
  Rust                             32            645            530           4400
  Text                            168            523              0           4358
  YAML                              8            316             17            961
  ERB                               3             20              4            246
  Bourne Again Shell                2             24             90            150
  TOML                              5             16             10             53
  CSS                               1              3              8             11
  --------------------------------------------------------------------------------
  SUM:                            584           8328          11328          35378
  --------------------------------------------------------------------------------

We need to get marketshare by going fast!

I've been using AI codegen for months now, but on large projects. Turns out, the productivity multiplier that agentic AI can be scales at least partially in proportion to project size. Read that again, because I don't mean "inverse proportion".

When a codebase is small, every change touches a majority of the codebase, making parallel work difficult or impossible. Once it gets large enough to have functional areas, you can have multiple tasks running at once with little or no merge conflicts.

I was giving Cursor a shot because it's the tool that's most popular at my new company. Prior to this, I was using OpenHands. I've used Claude Code quite a bit for my personal stuff, but I wanted some hands-on experience with local tooling and Cursor was the default choice.

Now that I've got this app to the point where frontend and backend concerns are separate and the interfaces are defined I'm realizing that Cursor doesn't seem to have anything approaching Claude Code's parallel subagent support. That's... limiting.

So now I get to decide if the improvement in velocity I'll get from switching to CC will offset the time it'll take me to make the change before I have a deadline to meet.

But testing new version would have been downloading the not-yet-updated working changelog.

There are ways to deal with this of course, and I'm not defending the very vibey way that claude-code is itself developed.

There's something so unnerving about the people pushing the AI frontier being sloppy about testing. I know, it's just a CLI wrapped around the AI itself, but it suggests to me that the culture around testing there isn't as tight and thorough as I'd like it to be.

edit: it seems changelog.md is assumed to be structured data and parsed at startup, and there are no tests to enforce the changelog structure: https://github.com/anthropics/claude-code/issues/16671

```

  Problem: Claude Code 2.1.0 crashes with Invalid Version: 2.1.0 (2026-01-07) because the CHANGELOG.md format changed to include dates in version headers (e.g., ## 2.1.0 (2026-01-07)). The code parses these headers as object keys and tries to sort them using semver's .gt() function, which can't parse version strings with date suffixes.

  Affected functions: W37, gw0, and an unnamed function around line 3091 that fetches recent release notes.

  Fix: Wrap version strings with semver.coerce() before comparison. Run these 4 sed commands on cli.js:

  CLI_JS="$HOME/.nvm/versions/node/$(node -v)/lib/node_modules/@anthropic-ai/claude-code/cli.js"

  # Backup first
  cp "$CLI_JS" "$CLI_JS.backup"

  # Patch 1: Fix ve2.gt sort (recent release notes)
  sed -i 's/Object\.keys(B)\.sort((Y,J)=>ve2\.gt(Y,J,{loose:!0})?-1:1)/Object.keys(B).sort((Y,J)=>ve2.gt(ve2.coerce(Y),ve2.coerce(J),{loose:!0})?-1:1)/g' "$CLI_JS"

  # Patch 2: Fix gw0 sort
  sed -i 's/sort((G,Z)=>Wt\.gt(G,Z,{loose:!0})?1:-1)/sort((G,Z)=>Wt.gt(Wt.coerce(G),Wt.coerce(Z),{loose:!0})?1:-1)/g' "$CLI_JS"

  # Patch 3: Fix W37 filter
  sed -i 's/filter((\[J\])=>!Y||Wt\.gt(J,Y,{loose:!0}))/filter(([J])=>!Y||Wt.gt(Wt.coerce(J),Y,{loose:!0}))/g' "$CLI_JS"

  # Patch 4: Fix W37 sort
  sed -i 's/sort((\[J\],\[X\])=>Wt\.gt(J,X,{loose:!0})?-1:1)/sort(([J],[X])=>Wt.gt(Wt.coerce(J),Wt.coerce(X),{loose:!0})?-1:1)/g' "$CLI_JS"

  Note: If installed via different method, adjust CLI_JS path accordingly (e.g., /usr/lib/node_modules/@anthropic-ai/claude-code/cli.js).

  rm -rf ~/.claude/cache
  mkdir -p ~/.claude/cache
  echo "# Changelog" > ~/.claude/cache/changelog.md
  chmod 444 ~/.claude/cache/changelog.md

https://github.com/anthropics/claude-code/commit/870624fc158...

That actions-user seem to be mostly maintaining the Changelog but the commits does not seem consistent with an automated script. I see a few cases of rewriting previous change log entries or moving entries from one version to another which any kind of automation would not be doing. Seems like human error and poor testing.

Also, why would 2 or 3 versions be documented in the same commit.

But there's a good chance you are right.

I am curious what the logic here is.

"You are Claude Code, Anthropic's official CLI for Claude."

https://github.com/link-assistant/agent/pull/63

I like it but I am not too deep into the whole agentic coding business.

Btw, now it's back and limits are being enforced. Despite the super heavy usage, I'm still at just 50% of my total usage. They did lose some usage tracking for sure.

> While we are always monitoring instances of this error and and looking to fix them, it's unlikely we will ever completely eliminate it due to how tricky concurrency problems are in general.

This is an extraordinary admission. It is perfectly possible (easy, even, relative to many programming challenges) to write a tool like this without getting the design so wrong that the same bug keeps happening in so many different ways that you have to publicly admit you're powerless to fix them all.

[1] https://news.ycombinator.com/item?id=46523740

[2] https://github.com/anthropics/claude-code/issues/6836

I did some testing of configuring Claude CLI sometime ago via .claude json config files - in particular I tested:

- defining MCP servers manually in config (instead of having the CLI auto add them)

- playing with various combinations of ’permissions` arrays

What I discovered was that Claude is not only vibe coded, but basic local logic around config reading seems to also work on the basis of "vibes".

- it seemed like different parts of the CLI codebase did or didn't adhere to the permissions arrays.

- at one point it told me it didn't have permission to read the .claude directory & as a result ran bash commands to search my entire filesystem looking for MCP server URLs for it to provide me with a list of available MCP servers

- when restricted to only be able to read from a working directory, at various points it told me I had denied it read permissions to that same working directory & also freely read from other directories on my system without prompting

- restricting webfetch permissions is extremely hit & miss (tested with Little Snitch in alert mode)

---

I have not reported any of the above as Github issues, nor do I intend to. I had a think about why I won't & it struck me that there's a funny dichotomy with AI tools:

1. all of the above are things the typical vibe coder stereotypes I've encountered simply do not really care deeply about

2. people that care about the above things are less likely to care enough about AI tools to commit their personal time to reporting & debugging these issues

There's bound to be exceptions to these stereotypes out there but I doubt there's sufficient numbers to make AI tooling good.

All the AI websites feel extremely clunky and slow.

Perhaps I can laugh at the next Equifax of the world as my credit score gets torched and some dude from {insert location} uses my details to defraud some other party. Of which I don’t find out about until some debt collector shows up months later.

This is unacceptable. Why would I patronize a business that hires vibe coders? I would hope their business fails if they have such pitiful security and such open disdain for their clients.

I highly suspect no one in claude is concerned or working on this.

In any case, any blacklist guardrails will fail at some point, because RL seems to make the models very good at finding alternative ways to do what they think they need to do (i.e. if they are blocked, they'll often pipe cat stuff to a bash script and run that). The only sane way to protect for this is to run it in a container / vm.

Nothing new under the sun.

"Oh yeah, my AI keeps busting out of its safeguards to do stuff I tried to stop it from doing. Mondays amirite?"

Because indeed, one of the first times i played around with claude, I asked it to make a change to my emacs config, which is in a non-standard location. It then wanted to search my entire home directory for it(it did ask permission though).

So unless you're also happy about not reporting bugs to project managers and people using low-code tools, I urge you to reconsider the basis for your perspective.

If you do not, why are you vibe coding?

Also there are ways to use a coding agent that are different from this and produce great results, like this:

https://friendlybit.com/python/writing-justhtml-with-coding-...

I would actually argue that only a small percentage of programmers know what happens in code on an instruction level, and near none on a micro-op or register level. Vibe-coding is just one more level of abstraction. The new "code" are the instructions to your LLM.

I'm sure the 737 MAX seemed to work just fine to Boeing's test pilots. Observing the external behavior of a system is not a substitute for understanding its internal workings and the failure modes they carry.

LLMs are capable of producing junk, and they are capable of writing decent code. It is up to the operator to use them properly.

The prevailing research suggests this is not quicker than just writing it in the first place.

LLMs excel at tasks that are fresh. LLMs are wonderful at getting the first 80% of the way there. -- LLMs are phenomenally good for a first draft or so.

I've had worse experiences for getting LLMs / agents to refactor code. I would believe in many cases it could be quicker to just manually go through and make refinements compared to merely getting the LLM to keep trying.

To put it another way, ask what code an LLM can maintain, not just what code a human (of whatever experience level) can maintain.

* in the original sense, no human feedback at any point

I'd say spending at least a quarter of my vibe coding time on refactoring + documentation refresh to ensure the codebase looking impeccable is the only way my projects can work at all long term. We don't want to confuse the coding agent.

I’ve noticed the same thing and it frustrates me almost every day.

They have been tricked into a world-view which validates their continual, lazy use of high-tech auto-generators.

They have been tricked into gleefully opting in to their own deskilling.

Expecting an "AI"-addicted developer to file a bug is like expecting an MSNBC or Fox News viewer to attend a town meeting.

The goal of "AI" products is to foster laziness, dependency, and isolation in their users.

Expecting these users to take any sort of action outside of further communication with their LLM chatbots does not square with the social function of these products.

Edit (response to the guy/LLM below me):

Hackernews comments written by fearmongering LLM idiots will tell me to "keep an open mind" about dogshit LLM chatbots until the day I die.

LLM technology is garbage.

If these tools are changing the world, they're only doing so by:

1. Dramatically facilitating the promulgation of idiotic delusions

2. Making enterprise software far, far more vulnerable than it was even in the recent past

part of what we do, as developers is to learn. to have an open mind to new tools and technologies.

these tools are… different, they’re changing the world (fast), and worth trying to understand. your mental rigidity to doing things “the right way” will hold you back and limit your growth. the world is changing. are you?

Everytime you "prompt" and you "vibe" you're not "changing with the world", you're using copious amounts of energy on very expensive hardware that you would never, in your lifetime, would be able to use if it wasn't backed by trillions in VC funding. Don't believe me? Try to match the performance of a current model with local hardware, report back with how much that costs in hardware and energy.

They're all in the stage A of enshittification, the bait phase. You're willingly making yourself reliant on a tool that eventually will be uncostable for any individual, and only affordable for big orgs.

If the job of a developer is to "learn, and have an open mind to new tools and technologies", and "my mental rigidity to doing things "the right way" will hold me back and limit my growth", then I don't want to be an engineer. Because one thing is to experiment, and another one is to, pardon the expression, suck off any new technology as the new epitome of anything. I don't want to be a "developer" with no criteria. Call me an engineer instead, I do things "the right way", and I don't fall prey to fashion under the guise of "growth".

---

(that it's a big pile of spaghetti that can't be improved without breaking uncountable dependencies)

I use LLMs on a daily basis. With the rules/commands/skills in place the code generated works, the app is functional, and the business is happy it shipped today and not 6 months from now. Now, as as super senior SWE, I have learned through my professional experiences (now an expert?) to double check your work (and that of your team) to make sure the 'logical' flows are implemented to (my personal) standard of what quality software should 'look' like. I say personal standard since my colleagues have their own preferred standard, which we like to bikeshed during company time (a company standard is after all made of the aggregate agreed upon standards of the personal experiences of the experts in the room).

Today, from my own personal (expert) anecdotal experiences, ALL SOTA LLMs generate functional/working code. But the quality of the 'slop' varies on the model, prompts, tooling, rules, skills, and commands. Which boils down to "the tool is only as good as the dev that wields it". Assuming the right tool for the right job. Assuming you have the experiences to determine the right tool for the right job. Assuming you have taken the opportunities to experience multiple jobs to pair the right tool.

Which leads me to, "Vibe coding" was initially coined (IMO) to describe those without any 'expertise' producing working/functional code/apps using an LLM. Nowadays, it seems like vibe coding means ANYONE using LLMs to generate code, including the SWE experts (like myself of course). We've been chasing quality software pre-LLM, and now we adamantly yell and scream and kick and shout about quality software from the comment sections because of LLM. I'm beginning to think quality software is a mirage we all chase, and like all mirages its just a little bit further.

All roads that lead to 'shipping' are made with slop. Some roads have slop corners, slop holes, misspelled slop, slop nouns, slop verbs, slop flows and slop data. It's just with LLMs we build the roads to 'shipping' faster.

(Just kidding.) Some of it is unawareness of the 'subscribe' button I believe, occasionally you'll see someone tell people to cut it out and someone else will reply to the effect of wanting to know when it's fixed etc. But it's also just lazy participation, echoing an IRL conversation I suppose, that you see anywhere - replied instead of up votes on Reddit and to a slightly lesser extent here for example.

It's about adding another "fuck you" to the Claude Code developers on top of the pile, not about incrementing a counter.

So what should one pick? The rocket, the thumbs up?

Also the emoji won't turn into a notification to steal the dev attention and make him fix the thing lok

We vibing out here.

I don't understand how that would fit the context window. But with prompts like that your workday would be very boring if you had to run one single agent and wait for it to be done.

@jayeshk29 is our hero

Finally i can finish my fizzbuzz for the interview