tepmoc

256k seems sweet spot. Even large codebase can be handled you just has to map out areas for agent. Anything past 256k usually exception than norm to be.

At least this my discovery when I did evals on my reviewers skills. 10k LOC is high end for high effort or around 150k context using opus. You can push towards 15k but that’s on max effort with about 400-500k ctx.

Fast models like haiku do not even need 1M ctx in my view

Country specific CA that can only sign ccTLD actually make sense to me

Shiller PE ratio still below dotcom peak but it’s getting close. It must overtake previous peak first.

Depends on model, promt and amount of agents that review. I found that default code-review in Claude code is pretty mid for finding all issues especially if you downgrade model and effort.

During my evals on my own 3 agents that review in parallel they are much more cost efficient and cover 75% issues. Even on model like haiku it’s better score than default. Multiple passes or raising effort will cover 90+. And this was tested on large diff, about 3500 LoC changes

One downside is that you cannot tell if format lossy or lossless by looking at its extension.

I found using just skill isnt enogh. You have to bounce its turn and inject skill text to actually follow instructions 100%.

Because even if you use PreToolUse hook and don't bounce it, it will never work since skill text is injected when along with text that already perpared to it need to be edited.

My first ban was 3 weeks ago after 5 months of usage.

And ban came after 6-8 hours of last session. My guess they didn’t like that I asked to verify RCE opus found, so he made workable exploit.

Everything else similar to your workflow, no token maxing and etc.

Then, just do not add text that adds no value. Less is more.

Documentation is first part people see when presented. I personally hate AI written text even though I do agentic engineering a lot as well. Any user facing documentation must be reviewed, if you snoozy by reading it - remove or rewrite.

I do not care about paragraph long comments in code, because I’m not gonna read them, but I still follow my internal guideline and cut all this verbosity to level where it readable using hooks and skills.

So basicly like you said if you care about product do not add placeholders. It’s take away first impression.

They all within same close tied frequency range, so it’s pretty easy. Though L1,L2,L5 need separate jammers if you only target GNSS

I surprised how many people don’t even read their own PR commits and diffs, like at basic level.

So many don’t even bother to tide-up fold their commits into single logical change, consider how many commit agent doing, seems logical to have folded commit history when you open PR.

Default commit and PR body text is word salad didn’t seems to bothered these people. Because if it did they already had hooks and skills to make it look tidy and lack of any AI attribution inserted.

I don’t even consider myself developer more like really weak devops guy, but I was already doing all of that.

I found both models produce word salad for PR bodies by default. Same thing with commits messages.

I had to create hooks that invoke skills when pushing new commit and open PR body text.

Not really. Co-signed is part of system promt that injected by harness.

lots of low end switches use RTL837x series as basis nowadays