imron

7,860 karmajoined hace 13 años

http://www.imralsoftware.com/

comments

hace 5 díasdiscuss

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.

hace 12 díasdiscuss

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

hace 15 díasdiscuss

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.

hace 22 díasdiscuss

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.

hace 25 díasdiscuss

> 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 ;-)

el mes pasadodiscuss

I love vanilla vim.

el mes pasadodiscuss

The debugger doesn’t even come close

el mes pasadodiscuss

All the good borland devs were poached by Microsoft. VC5 and 6 were the spiritual successors of the Turbo XXX family of IDEs.

hace 2 mesesdiscuss

Here's one that hit the frontpage recently:

https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

hace 2 mesesdiscuss

Litigation

hace 2 mesesdiscuss

> This requires using the extremely unintuitive `git rebase --onto A B C` invocation.

Unintuitive yes, and I'm not going to disagree with you on UX, but it's not a particularly difficult thing to learn if you use a rebase centric workflow and this is a command I use daily.

P.S. don't forget to use --update-refs (or add to your .gitconfig) ;-)

hace 2 mesesdiscuss

> Not any more.

`git add -p` FTW

hace 2 mesesdiscuss

Large volumes of training data is a blessing and a curse, especially when you consider who wrote it.

hace 2 mesesdiscuss

> Changing the default behavior for all of your users with no notification is pretty unforgivable

How else is a poor programmer gonna hit their KPIs and get that promo?

hace 2 mesesdiscuss

> Analyze if it's malware how exactly?

By spending thousands and thousands of tokens of course :-)

hace 3 mesesdiscuss

Can we get OpenCode support back as well?

hace 3 mesesdiscuss

Any service that hosts git?

hace 3 mesesdiscuss

> I do wonder, though, if it would have been designed differently if the whole “code forge” sort of application (or whatever GitHub and the like are called) was envisioned at the time.

I would argue that it was purposefully designed in contrast against that model.

GitHub is full of git anti patterns.

hace 3 mesesdiscuss

My biggest gripe with skills is that even clear and explicit instructions are regularly ignored - even when the skill is brief (< 100 lines).

I’ll often see the agent saying it’s about to do something so I’ll stop it and ask “what does the xxx skill say about doing that?’ And it’ll go away and think and then say “oh, the skill says I should never do that”

hace 3 mesesdiscuss

4. Someone who wants to keep all their fingers, and not meet some kind of horrifying death.