Hacker Newsnew | past | comments | ask | show | jobs | submit | cwyers's commentslogin

Codex now lets you tell the LLM tgings in the middle of its thinking without interrupting it, so you can read the thinking traces and tell it to change course if it's going off track.

That just seems like a UI difference. I've always interrupted claude code added a comment and it's continued without much issue. Otherwise if you just type the message is queued for next. There's no real reason to prefer one over the other except it sounds like codex can't queue messages?

Codex can queue messages, but the queue only gets flushed once the agent is done with whatever it was working on, whereas Claude will read messages and adjust accordingly in the middle of whatever it is doing. It sounds like OP is saying that Codex can now do this latter bit as well.

The problem is if you're using subagents, the only way to interject is often to press escape multiple times which kills all the running subagents. All I wanted to do was add a minor steering guideline.

This might be better with the new teams feature.


They actually made a change a few weeks ago that made subagents more steerable

When they ask approval for a tool call, press down til the selector is on "No" and press tab, then you can add any extra instructions


That is so annoying too because it basically throws away all the work the subagent did.

Another thing that annoys me is the subagents never output durable findings unless you explicitly tell their parent to prompt the subagent to “write their output to a file for later reuse” (or something like that anyway)

I have no idea how but there needs to be ways to backtrack on context while somehow also maintaining the “future context”…


Ironically they had the foresight, they were just too early/didn't execute. They ran an online service (co-owner with IBM and CBS) called Prodigy that competed with AOL and CompuServ, and they tried to do online shopping there.


Everyone is talking like creating Amazon was some kind of low hanging citrus to be picked from the tree.


For a company that had Sears’ positioning at the time? It wasn’t far off from that description.


But a lot of stuff had to be invented and Bezos was the person to do it. Amazon sounded intense to work for to get to where it is.


They invented almost all of that a century earlier. Amazon improved their warehouse management and, later, delivery times but that happened later. If Sears management had been earning their pay in the 90s that would have been much harder because Sears had a huge inventory and unmatched local presence for returns, support, etc. if they hadn’t been AWOL moving the catalog online. Amazon was shipping at regular postal speeds then, too, so Sears could even have beat them if they shipped from their warehouses.

This wasn’t uncommon back then: we had several clients in the 90s who just couldn’t wrap their heads around how quickly many of their customers would switch to email or online forms when it saved them a few days on the transaction.


People are talking about putting a mail order catalog store online. Presumably, sears already had the catalog, shipping infrastructure - so it really should have been about digital payments, and an online storefront.

How significant their shipping catalog was in the 1990s I do not know, scaling the online storefront would have required Amazon scale investments which a dividend maximizing company was unlikely to do.


> People are talking about putting a mail order catalog store online. Presumably, sears already had the catalog, shipping infrastructure - so it really should have been about digital payments, and an online storefront. [...]

> How significant their shipping catalog was in the 1990s I do not know

Sears discontinued its general mail order catalog (which had declined in relevance for years) in 1993, the same year NCSA Mosaic was released, while the web had about 0 public penetration and no commercial use.

So, it wouldn't have been a matter of adapting the catalog business to the web, it would have been rebuilding it from scratch.


people underestimate how slow picture loading was back then. Online storefronts seem to live and die by their product images. It wasn’t really feasible to sell anything other than books until DSL came along.


It wasn’t perfect but we had plenty of successful sites where most users used dialup. You’re talking small, heavily compressed JPEGs but it was manageable and especially important to remember that people didn’t expect it to be super fast. For browsing, it was slower than paging through a full catalog but still days faster than mailing an order and less stressful for a surprising number of people than calling an order phone line, especially if they weren’t certain about what they wanted. Web pages had room for a lot more text than a printed catalog, too.


Online ordering from the paper catalog would have worked well enough to bootstrap. For items in the catalog, you don't need a lot of pictures, and they don't need to be big. If you want to have a few more pictures on a details page, you would put them behind a more photos link and show one at a time so you don't trash the connection.


After that, when the internet buzz was really picking up (around Win95 release cycle)... The prevailing opinion from their leadership was "the internet is a fad." and they just didn't try moving into that space at all until it was way too late.


Just use WSL2 and Docker Desktop. VS Code has DevContainer support so you can standardize on a Docker image for your project.


It's as much of a stretch as describing using an Azure service as "I have to use Halo" or AWS as "I have to use Rings of Power."


No, Fortnite is/was directly made by Epic Games and is their most well known product/service.

Better analogies would be Azure as "I have to use Windows" or AWS as "I have to use the Amazon store", which sound a lot less ridiculous than your analogies.


"Slop" is at _least_ as fair a description of "we had an LLM rewrite HN headlines" as "we rewrote it in Rust so you have to upvote it" is of "we removed our biggest source of crashes on Android by getting rid of Go FFI issues."


I mean, he's _allowed_. The Compiler Police aren't going to roll up to his house and take away his Jai compiler if there isn't a quorum of HN users blessing his efforts. But people can point out they don't feel the juice is worth the squeeze. Also, Blow is certainly an advocate for his position, which means this kind of public debate is germane to the question of if _other_ people should adopt Jai.


If you have bills to pay, it really is.


The point is that Blow has two blockbuster hits under his belt and can afford to take a decade to ship a single game. Most people would go broke never having shipped a game if they tried to do things Blow's way.


Yeah, there's only two differences between using Markov chains to predict words and LLMs:

* LLMs don't use Markov chains, * LLMs don't predict words.


* Markov chains have been used to predict syllables or letters since the beginning, and an LLMs tokenizer could be used for Markov chains

* The R package markovchain[1] may look like it's using Markov chains, but it's actually using the R programming language, zeros and ones.

[1] https://cran.r-project.org/web/packages/markovchain/index.ht...


I was surprised by that, too, and assumed it was a decade-old article until I saw the date at the bottom. Both being mentioned before Python is wilder, as is the total exclusion of JavaScript.


JavaScript on the backend is a rare thing to see, even in "resume driven development" scenarios it's usually some sort of static build that gets pushed to S3 or whatever.


Are you time traveling from 1998, when AOL acquired Netscape and sidelined Livewire?


Node.js is the most popular web framework/technology in the StackOverflow developer survey. Express is more popular than FastAPI, Django, Flask and Rails in the same survey. Just... what are you talking about?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: