hitradostava

Keen to try this out. Composer 2 is a reliable workhorse and much cheaper than the frontier models. Yes it may be based on Kimi, but it is good, really good. My workflow: - If its simple/obvious - give it to composee 2 immediately - If its complex either work on a plan with ChatGPT (pro mode is insane) or create a plan with GPT 5.5 or GPT 5.3 codex, and then implement with composer

I continue to be surprised at how good Anthropic are at getting people to promote an agent harness that doesn't have a decent UI. Cursor has as good (arguably better) coding agent AND a decent UI. Yes its forked from VS Code, but who cares it's good. I tried Zed the other day, but can't really see the advantage - on a decent mac performance is the same, and Cursor is more polished. Anthropic may be winning the PR battle but I think cursor is laughing all the way to the bank.

Patrick, the problems you describe (speed, cost, cross-border friction) already have solutions. SEPA Instant, FedNow, PIX, and providers like Wise move money in seconds, at negligible cost, inside regulated systems. Tempo doesn’t solve payments; it sidesteps oversight.

By shifting flows onto a private stablecoin ledger, Stripe isn’t fixing inefficiency; it’s making it easier to route money in ways regulators and tax authorities can’t easily monitor. That’s not innovation, it’s the oldest trick in the crypto playbook: pretend you’re improving payments, when what you’re really selling is a way around the rules.

Thats not what OpenAI are claiming. They are claiming that there are two new flagship models and a router that routes between them.

"GPT‑5 is a unified system with a smart, efficient model that answers most questions, a deeper reasoning model (GPT‑5 thinking) for harder problems, and a real‑time router that quickly decides which to use"

Planning was ok for me, much slower than Sonnet, but comparable. But some of the code it produces is just terrible. Maybe the routing layer sends some code-generation tasks to a much smaller model- but then I don't get why it's so slow!

The only thing that seems better to me is the parallel tool calling.

I agree, I just don't understand how the team at Cursor can say this:

“GPT-5 is the smartest coding model we've used. Our team has found GPT-5 to be remarkably intelligent, easy to steer, and even to have a personality we haven’t seen in any other model. It not only catches tricky, deeply-hidden bugs but can also run long, multi-turn background agents to see complex tasks through to the finish—the kinds of problems that used to leave other models stuck. It’s become our daily driver for everything from scoping and planning PRs to completing end-to-end builds.”

The cynic in me thinks that Cursor had to give positive PR in order to secure better pricing...

Had Sonnet 4 not been able to?

Amazing project. The question I have is why rust? Is the compiled WASM significantly faster than JS?

Exactly, and LLM based tools can be very frustrating right now - but if you view the tooling as a very fast junior developer with very broad but shallow knowledge then you can develop a workflow which for many (but not all) tasks is much much faster writing code by hand.

In a couple of years time I don't see why AI based tooling couldn't write Redis? Would you get a complete Redis produced with a single prompt? Of course not. but if extreme speed is what you want to optimize for, then the tooling needs to be given the right feedback loop to optimize for that.

I think the question to ask is what do I do as a software engineer that couldn't be done by an AI based tool in a few years time? The answer is scary, but exciting.

I agree with you and its confusing to me. I do think there is a lot of emotion at play here - rather than cold rationality.

Using LLM based tools effectively requires a change in workflow that a lot of people aren't ready to try. Everyone can share their anecdote of how an LLM has produced stupid or buggy code, but there is way too much focus on what we are now, rather than the direction of travel.

I think existing models are already sufficient, its just we need to improve the feedback loop. A lot of the corrections / direction I make to LLM produced code could 100% be done by a better LLM agent. In the next year I can imagine tooling that: - lets me interact fully via voice - a separate "architecture" agent ensures that any produced code is in line with the patterns in a particular repo - compile and runtime errors are automatically fed back in and automatically fixed - a refactoring workflow mode, where the aim is to first get tests written, then get the code working, and then get the code efficient, clean and with repo patterns

I'm excited by this direction of travel, but I do think it will fundamentally change software engineering in a way that is scary.

I'm continually surprised by the amount of negativity that accompanies these sort of statements. The direction of travel is very clear - LLM based systems will be writing more and more code at all companies.

I don't think this is a bad thing - if this can be accompanied by an increase in software quality, which is possible. Right now its very hit and miss and everyone has examples of LLMs producing buggy or ridiculous code. But once the tooling improves to:

1. align produced code better to existing patterns and architecture 2. fix the feedback loop - with TDD, other LLM agents reviewing code, feeding in compile errors, letting other LLM agents interact with the produced code, etc.

Then we will definitely start seeing more and more code produced by LLMs. Don't look at the state of the art not, look at the direction of travel.

Kinesis supports buffering - up to 900 seconds or 128mb. So you are way out on your cost estimations. Over time queries can start costing more due to S3 Requests, but regular spark runs to combine small files solves that.