I do the same and I'm having the most incredible success.

Here is an example of the skills I define. [0] It will copy the repository into a /tmp/ folder, load all the dependencies, change all the code at the important places injecting debug statements that print to file with timestamps and meta data, and even if the code works it will still analyze the output. It will also use a snapshot test utility which is several times less expensive after performance tuning than any MCP or browser use service, drive user journeys looking for any place it isn't pixel perfect. (hmmm I didn't fold the snapshot util into that project because the project is a testing tool to begin with). Here is the snapshot utility. [1] With any front end code it will run it in Playwright using Chrome DevTools Protocol to do performance testing. [2]

It does this in iterations with little friction and my sh*t is flawless! Moreover, Fable offer no benefit over Opus with this approach. Plus, the red-team and especially any adversary testing utility or skill will trigger Fable.

[0] https://github.com/adam-s/goldseam/tree/main/.agents/skills

[1] https://github.com/adam-s/HNswered/blob/main/scripts/snapsho...

[2] https://github.com/adam-s/HNswered/blob/main/scripts/perf-pr...

You should do an experiment of splitting that up to multiple reviews that are logically together. My hypothesis is that you may be losing signal due to the amount of text expected back.

The comments that drive the most homicidal behavior are outdated or inaccurate comments rather than no comments.

> continually run codebases through different models

When I have spare usage before a reset, I just throw a part (depending on how much usage left) of a non-critical codebase to refactor overnight and push to PR.

If it's marginally more maintainable/better after review it's good to merge.

How did you know you're not stuck at a local optimum where the AI could iterate even faster if you enforced higher quality on what it produced?

To make up some hypothetical numbers in order to illustrate with math: if you ship bugfixes 10x faster but then have 11x more bugs you need to fix, that's not a net improvement. Even if it's only 5x more bugs, maybe you could reduce that to 2x if you changed how you worked to only be 8x as fast in a way that produced higher quality code. Similarly, maybe you could cut the time it needed to produce a new feature by 50% if your code were higher quality by moving 20% slower.

My point in all of this isn't that you literally need to work the same way you did before you had these tools, but that framing it as either "move fast and ignore the code" and "use the same exact heuristics you would in the pre-LLM days for what code is acceptable" is a false dichotomy. If you aren't thinking about how effectively you're using these tools and whether there are changes you could make to move even faster because "AI go brrr", I think you've lost the plot in the same way you probably think that other people in this thread have.

> That sounds like a good idea, but shipping 10x as many features and bugfixes sounds better.

This work great until you reach a certain size, then good (or even "not bad") code is required otherwise the model spins its wheel trying to ensure the change is correct.

The way I've measured how good/bad the code is (for AI) is to have one "baseline fixed change" that I measure how long time it takes to implement. Always in the beginning (less than 10K LOC, as just some measurement), this baseline change will take 2-3 minutes. As you add more code, the same change starts to take 5-6 minutes, and once you hit 1 million LOC, it can take as long as 10 minutes, even though the change is the same.

It's when this baseline task starts to take longer time, that you need to update the design/architecture/layout/whatever, to better fit the task/domain, and to actually make it easy to maintain and still possible to add changes without spending 10 minutes. So its at this point you refactor, and once done, the baseline task will again be easy for the model to do.

So yeah, if all you do is smaller projects, then "shipping 10x as many features" is easy and doable, for the lifetime of the projects. But once the projects start to accumulate technical debt, the model will have a harder time making sure the changes are correct, and suddenly "shipping 2x as many features" is maybe doable, but you could still have had 10x if you just spend slightly more time on the actual design and architecture of the program.

Yeah, the flip side of the article is that Fable level models can fix the majority of codebases created from the past 3 years and one shot it to a fixable state that is "human maintainable"

How long has "so far" been?

One does not exclude the other

That sounds like a good idea but how do you know what you’re shipping?

Man, I bet Jia Tan is simultaneously kicking themselves and having a field day. All those years of wasted effort gaining trust and making good contributions to try to land a sophisticated backdoor into a tool via layers of indirection, and then not long after we have devs just going “I don’t need to read this code, or prioritise, or think about what makes sense, just prompt for fractals of kitchen sinks and ship it”.

Anthropic themselves have admitted you don’t need much to poison LLMs¹. I can’t wait for us to discover the backdoors that are being introduced. I hope it happens soon so people get to their senses. Bah, what am I saying, when (not if) that happens, the response will just be to throw more LLMs at it.

¹ https://www.anthropic.com/research/small-samples-poison

I find myself doing this but then I worry that the slop will just compound and 3, 6, 12 months from now as my services scale I'll have a harder time operating them. Maybe I'm wrong.

CLAUDE.md is not good place to put all code change rules, because these rules "distract" the agent e.g. during bugs triage or business analysis.

Instead modularize the knowledge with skills and specialized MD files. Agent should lazy load what is needed to do focused work.

Skills have usage description metadata, but with free files you can refer to the from the CLAUDE.MD with e.g.: "Before you attempt to change any code first load `...`".

But LLMs can do it much faster and more consistently.

Just this morning I was trying to scrape nitter, for funsies. One hour and neither gemini nor kimi were able to write something working, despite trying selenium (or playwright), beautiful soup, and a specific library that can be used to scrape it.

I eventually read the library docs and managed to build a scraper for what I wanted in a few mins. Llms are great for a lot of things, but sometimes you stumble in something that's just outside of what they know/can do and you're sol. And of all the thinks, I didn't expect they would fail at this, to be honest the opposite

It’s bizarre to me that so many people feel the need to keep parroting this corporate talking point. What do you care? If you think people who eschew LLMs for coding “are not going to make it” or “are going to get left behind”¹, then let them. More opportunities for you, right? Go do your own thing.

¹ As if “moving forward” or “progress” were always a positive. It’s not. Just look at how many regulations we have to forbid or curtail uses of stuff we found to be harmful.

People are so desperate for this to be true. Maybe it comes from a subconscious recognition that their own self-imposed deskilling will inevitably catch up with them.

It's unlikely that AI will get to the point where it makes handwritten coders redundant, and then not immediately be at the point where vibe coders are redundant too. So if you earnestly take the position that handwriting code is a "ngmi" type activity, you also need to take the position that the vibe coder (or agent- assisted-developer/loop-architect, or whatever its nom de guerre is this week) is "ngmi".

I type it in myself, but occasionally i do write notes out by hand if I'm thinking about something away from my desk.

Why stop there? If you _use_ handwritten products you’re ngmi. I only use vibe coded operating systems, JavaScript sandboxes, compilers, TLS libraries, databases, rendering engines..

If you don't understand the software you're creating (handwritten or not) you are ngmi.

None of us are "going to make it"

Gotta touch grass.

if your skillset is tied to corporate bullshit, yourre better off buying lottery tickets