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.

While that is true, its really not easy to do without re-writing from scratch and scrapping a load of features which is organisationally difficult to do.

What large piece of software with a user interface do you work with that is actually fast and stays fast? For me, its probably just Chrome / Firefox. Everything else seems to get slower over time.

Looks interesting, we solved this problem with Kinesis Firehose, S3 and Athena. Pricing is cheap, you can run any arbitrary SQL query and there is zero infrastructure to maintain.

I wish they would do this. But my experience is that building efficient software is hard, and is very very hard the larger the team gets or the longer the product exsits.

Even zoom, used to be very efficient, but has gradually got worse over time :-(

The point being made is that while this may be grating for you. It is magic for a large part of the population. This combined with chatgpt advanced voice mode shows a direction of travel for AI agents. It makes it possible to imagine a world where everyone has personalized tutors and that world isn't very far away.

100% agree. We don't expect human developers to be perfect, why should we expect AI assistants. Code going to production should go through review.

I do think that LLMs will increase the volume of bad code though. I use Cursor a lot, and occasionally it will produce perfect code, but often I need to direct and refine, and sometimes throw away. But I'm sure many devs will get lazy and just push once they've got the thing working...

I have to agree with the parent. LLMs are excellent at a large range of NLP tasks. Of course they are not going to replace all ML models, but when it comes to NLP they are clearly better than lots of trained models (e.g. https://arxiv.org/pdf/2310.18025).

Thanks :-)

I've not done much profiling on DuckDB and what the overhead is - i.e. after the data is parsed how much memory is used. Would be really interesting to push it to the limit - or to explore not loading the entire file in, but only reading the relevant parts, but again that probably requires a conversion first, e.g. to parquet or some other column based storage format.

Hey congrats on the Show HN. Local, browser based data exploration works for a lot of uses cases and is so much faster thancloud based tools. We've implemented something similar at https://addmaple.com/ - but with a graphical interface designed for rapid exploratory data analysis of large datasets.

Memory per tab can be an issue for really big files (1gb+) but we're exploring a transform to CBOR which allows us to free up JS memory, i.e. when parsing CBOR we can leave row level data as Uint8Array and it doesn't increase the JS memory overhead.

while this is impressive technically I also get the feeling that we are back in 1982. Spreadsheets are great general purpose tools and useful for financial modeling. But I'd argue they provide a terrible UX for most other tasks. The default assumption that every cell is editable is demonstrably bad - even for financial modeling. Yes you can lock cells and columns, but this is a sticking plaster. Anyway I'm probably biased in this area as I'm working on a https://addmaple.com where we are attempting a very different UX for working with tabular data.

This video dropped 2 weeks ago: https://www.youtube.com/watch?v=9iqn1HhFJ6c

Ilya clearly has a different approach to Sam

Do you have speed comparisons vs OpenAI - for live transcription?

A deep dive into using the seldom used multipart/x-mixed-replace content-type for streaming combined text, audio and JSON from an LLM API.

It was a fun experiment that I think could be useful for many projects. It seems highly likely that as a tech community we are going to be building a lot of software on top of LLM APIs. It also seems highly likely that more LLMs will become multi-modal AND that no matter the speed improvements there will be many use-cases where you want to stream the data to your application rather than wait for the full response.