411–420 of 870 posts
A big wow moment coming up is going to be GPT 5.* in Codex with Cerebras doing inference. The inference speed is going to be a big unlock, because many tasks are intrinsically serial. It's going to feel literally like playing God, where you type in what you want and it happens ~instantly.
Earlier quoted context omitted.
Yeah to be clear it will have the same issues as a flyby contributor if prompted to. Meaning if you ask it “handle this new condition” it will happily throw in a hacky conditional and get the job done. I’ve found the most success in having it reason about the current architecture (explicitly), and then to propose a set of changes to accomplish the task (2-5 ways), review, and then implement the changes that best suit…
The failure mode is missing constraints, not “coding skill”. Treat the model as a generator that must operate inside an explicit workflow: define the invariant boundaries, require a plan/diff before edits, run tests and static checks, and stop when uncertainty appears. That turns “hacky conditional” behaviour into controlled change.
The LLM is onboarding to your codebase with each context window, all it knows is what it’s seen already.
I wish the people who wrote this let us know what king of codebases they are working on. They seem mostly useless in a sufficiently large codebase especially when they are messy and interactions aren't always obvious. I don't know how much better Claude is than ChatGPT, but I can't get ChatGPT to do much useful with an existing large codebase.
I'm not sure how big your repos are but I've been effective working with repos that have thousands of files and tens of thousands of lines of code.
If you're just prototyping it will hit wall when things get unwieldy but that's normally a sign that you need to refactor a bit.
Super strict compiler settings, static analysis, comprehensive tests, and documentation help a lot. As does basic technical design. After a big feature is shipped I do a refactor cycle with the LLM where we do a comprehensive code review and patch things up. This does require human oversight because the LLMs are still lacking judgement on what makes for good code design.
The places where I've seen them be useless is working across repositories or interfacing with things like infrastructure.
It's also very model-dependent. Opus is a good daily driver but Codex is much better are writing tests for some reason. I'll often also switch to it for hard problems that Claude can't solve. Gemini is nice for 'I need a prototype in the next 10 minutes', especially for making quick and dirty bespoke front-ends where you don't care about the design just the functionality.
[flagged]
xcancel? What is the purpose or benefit of providing a free mirror to x? Doesn't it end up sparing the x servers and causing their costs to decrease?
> It's so interesting to watch an agent relentlessly work at something. They never get tired, they never get demoralized, they just keep going and trying things where a person would have given up long ago to fight another day. It's a "feel the AGI" moment to watch it struggle with something for a long time just to come out victorious 30 minutes later. Somewhere, there are GPUs/NPUs running hot. You send all the neces…
Earlier quoted context omitted.
Plain Claude Code doesn’t have enough scaffolding to handle large projects At a base level, people are “upgrading” their Claude Code with custom skills and subagents - all text files saved in .claude/agents|skills. You can also use their new tasks primitive to basically run a Ralph-like loop But at the edges, people are using multiple instances, each handling different aspects in parallel - stuff like Gas Town Tbf yo…
Is there anywhere where we can learn more about creating your own agents/skills? Maybe some decent public repos that you could recommend.
Anthropic’s own repo is as good place as any
> It's so interesting to watch an agent relentlessly work at something. They never get tired, they never get demoralized, they just keep going and trying things where a person would have given up long ago to fight another day. It's a "feel the AGI" moment to watch it struggle with something for a long time just to come out victorious 30 minutes later. Somewhere, there are GPUs/NPUs running hot. You send all the neces…
> It might become cheaper or it might not If it does not, this is going to be first technology in the history of mankind that has not become cheaper. (But anyway, it already costs half compared to last year)
There have been plenty of technologies in history which do not in fact become cheaper. LLMs are very likely to become such, as I suspect their usefulness will be superseded by cheaper (much cheaper in fact) specialized models.
Earlier quoted context omitted.
People keep using these analogies but I think these are fundamentally different things. 1. hand arithmetic -> using a calculator 2. assembly -> using a high level language 3. writing code -> making an LLM write code Number 3 does not belong. Number 3 is a fundamentally different leap because it's not based on deterministic logic. You can't depend on an LLM like you can depend on a calculator or a compiler. LLMs are t…
There are definitely parallels though. eg you could swap out your compiler for a different one that produces slightly different assembly. Similarly a LLM may implement things differently…but if it works do we care? Probably no more than when you buy software you don’t care precisely what compiler optimisation were used. The precise deterministicness isn’t a key feature
It often doesn't work. That's the point. A calculator works 100% of the time. A LLM might work 95% of the time, or 80%, or 40%, or 99% depending on what you're doing. This is difference and a key feature.