imron

I'm similar. I work in a context where I am responsible for the code that is in production and need to know how it works and vouch for its correctness.

Even with short interactions though, the effort in reviewing adds up and I ended up building a tool to help with it: https://github.com/imron/crt

I can review in the tool, and it remembers which files I have seen/approved since a given commit, then I can leave comments against source code and have an agent pick up those comments over mcp so it has context when making corrections.

Blockchain!

CRT - Code Review Tool: https://github.com/imron/crt

1.5 billion lines of Cobol are still written per year.

I wrote a local code review tool to help me understand it - https://github.com/imron/crt/

This _is_ how strict types work. Problems creep in when people introduce lax types into the strict type system.

dict[str, Any] is a type, and sometimes it is the right type to specify, but most of the time it's used by someone who wants to shut up the type checker rather than think about the right type.

Definitely a reasonable thing to consider and this is the direction I would like to see programming languages evolve towards in the AI era.

Move errors from runtime to compile time as much as possible.

What I'd recommend is languages that move entire classes of errors to compile time - like Rust.

> one lab spends $$$ on bleeding edge R&D and expensive RL runs to improve capabilities, and other labs just yoink the raw reasoning traces and mid-train/post-train on them to get 90% of the way there for a small fraction of the cost.

"You're trying to kidnap what I've rightfully stolen."

> I constantly have to tell it to not use terms that were not part of the initial prompt.

Hah, yeah even when you put it in AGENTS.md or a skill.. constantly having to remind it.. "what does AGENTS.md" say about doing that?".. Thinking.. Thinking.. "Oh, it says I should never do that, I'll remember that next time.."

Next session - same thing.

I like communication that is brief and to the point. The problem is when it is so brief that the point isn't conveyed well.

You can double click on the 'thinking' text and it will expand and you can read it. The problem is that it will often have multiple thinking/tool call sections and it can be a needle/haystack problem to find the one with the thinking you are interested in.

I don't think it's twitter. My guess would be that it's been trained for conciseness as way to improve token efficiency in the same vein as caveman.

> My favorite part of the new Groks has been how they speak in plain english. I simply cannot stand Claudish.

Grok has its own feel too. It's not as bad as Claude, but one of the things that bugs me is that it is far too terse.

It regularly seems to come up with terms and descriptions for things in its chain of reasoning and then uses these terms in its output assuming you understand what it's talking about.

I find I often have to ask it to re-explain what it means.

I expect the reduced prevalence of Claudish will have its own mannerisms that become the new Claudish.

The Claudish is dead. Long live the Claudish.

VC++ 6 was an amazing IDE. My favourite of all time, with the debugger being one of the highlights. Still unmatched today.

Profession (also by Asimov) takes it even further - https://www.abelard.org/asimov.php

And what does this mean now that AI can write at 10x this speed again...

Yes! An incredible tool. You'll rarely need to use it, but when you do it's invaluable.

not 100% feature compatible but close enough in terms of capabilities that I use: codex, and grok build.

I love opencode but it chews through memory on my 64gb MacBook Pro. Can’t have too many long running sessions because the memory use just slowly creeps up.

It’s not about the terminal at all which as you noted accounts for minimal isage. It’s all the internal chat and history and everything else the agent tracks - all of which are smallish (and largish) strings allocated on the heap.

I don’t have the same issues with rust based tuis.

It makes a huge memory difference.

Codex works great in opencode until it gets up to around 200k context. Then it starts doing things like:

me: Can you implement the next thing

OpenCode+Codex: Yep I'll do that next. <does nothing and returns to prompt>

me: Well?

OpenCode+Codex: <starts implementing>

me: Looks good, let's fix this one issue.

OpenCode+Codex: Sure let's do that. <does nothing and returns to prompt>

me: <bangs head against wall>

--

I've found the codex cli to be much better in this regard, it doesn't nearly derp out so much at higher token counts.

Opus is still my favourite model (I've found 4.6 specifically gives me the best results in OpenCode), but with all the shenanigans Anthropic is pulling, Codex is a close enough substitute.

If you’re suggesting that the test favors those capable of arranging their thoughts and words before putting pen to paper then.... I’m not sure there’s a problem

As someone with over 25 years experience in software engineering, 6 months ago I used to feel the same way (https://news.ycombinator.com/item?id=46389417).

What changed:

- Opus. This was the first model family for me that produced good enough output _and_ could also be correctly steered to correct itself when not good enough. ChatGPT 5 level models are also good enough here but Opus still has an edge I think.

- OpenCode. The UX of OpenCode just seems to fit well with how I work - enough information about what the agent is doing that I can stop it if its getting stupid/doing something wrong, high enough level that I don't need to constantly babysit it. I keep trying Claude Code every now and then but continually get unsatisfactory results even with the same underlying model. Codex works better in this regard.

- Tokenmaxxing. At first I got the standard $30/month plan but would hit session limits in about 30 mins, then I needed to wait a few hours before I could continue so no net benefit in productivity. Then I upgraded to the 5x plan and could go 1-2 hours before hitting sessions limits. This also was no net benefit. Then I upgraded to the 20x plan and was swimming in a sea of tokens. The problem then becomes figuring out how to use them all so you are 'wasting' any of them.

It's the last one that really helped shift the mindset for me. My process now is something like this:

1. use the agent to build and refine an overview of what I'm trying to do and what I'd like to build. This gets saved to the docs folder in the repo.

2. use the agent to build out specific plans to build out what I need. Plans are reasonably high level and describe the what and the why along with important design decisions and measurements of success. Each plan is about enough to implement in a given session. I purposefully do not get it to specify code or tests in the plan as too much specificity in the plan causes the implementing agent to get hooked up on the details rather than trying to find a good solution. These are saved to plans/backlog/NNNNN-plan-name

3. Use the agent to help me review all plans and make sure they are consistent and fit with the overview, and also figure out dependencies between the plans, and which ones can be done in parallel.

4. Use the agent to start implementing - this involves moving the plan to plans/active/... creating a worktree and a branch and working on the feature. I will kick off multiple agents working in parallel where the dependency graph allows it. I review each implemented plan throroughly (I've written my own review tool for this) and iterate until the code meets my standards and the requirements. Then I move the plan to plans/completed/.. merge to main, remove the worktree and then kick off the next agent. Usually I'll be switching between reviewing code, kicking off the next plan in a separate agent, planning out new features, all in parallel.

This is the real productivity enabler. You need to have a backlog of well-scoped work and can then have multiple agents working on different parts of it. Human review is essential if you care about long-term maintainability of the code and ease of future improvement because the AI will still make many flawed decisions.

I tend to avoid other peoples skills. I've found it more productive to build my own as I go if I find myself repeating myself to the agent. Agents will regularly ignore instructions in skills anyway so it's all a bit hit and miss. I try to keep any skills that I make brief and too the point (the more concise, the less likely the agent will skip over it/ignore it).

Overall I've found I've manage to build things more quickly, and the things that I build are now very well documented and explained which helps both agents and humans understand the codebase.

I think OP was rather suggesting that we have a guideline to avoid comments about whether something was written by AI or not.

Without fail, every comment section will have posts by people talking about how something is AI generated. Yeah we get it. It used to be novel to spot this, but now most people are pretty good at spotting it too and/or don't care.

It's about as meaningful as noting an article is written in English.

> They're also saying that the AI market is worth roughly 10% of all global real estate.

Why limit yourself to one planet? Space is infinite ;-)

I love vanilla vim.