radarsat1

I've been playing with often asking Claude to generate visualizations for me of what it's doing in the sense of diagrams of different types. Sometimes it's as simple as "show me what you're doing using an infographic". Othertimes I'll ask it for sequence or class diagrams or bipartite graphs if it's designing some sort of mapping. Bipartite graph is also very helpful for following the plan of a big branch rewrite or squash which I often do before making a PR to get rid of all those confusing in-between commits.

I find forcing it to visualize things immensely helpful. I'm usually studying git diffs but when working of a big feature or refactor that can just be too hard.

I've never been very pro "visual programming" and always hated UML et al, but part of me is starting to wonder if it's time for us to give it another serious go.

> DO NOT resell or mint our work

what does 'minting' mean in this context?

That and the shear volume. Since you're not writing it yourself you have to figure out what it's doing if you want to be able to review it, internalize and follow how it's changing the model that the software defines. This is doable but it takes time.

Time unfortunately that you are simply not given because the whole point is to work faster so expectations of velocity have of course increased.

So you end up having to get a fuzzy idea of a given changeset, look at it a bit and evaluate quickly if it's a good change or a bad one and click it through, and on to the next thing.

At the size of PRs being whole features and doing this 5x faster than before, all you've got left as a senior is your Spidey sense. As a junior.. no idea how they cope.

We'd all love to still spend that 90% thinking time, but it used to be justified by necessity of getting the job done. Now, it's just not a luxury that is afforded.

What can ya do.. I'm slowly learning to be the best bot herder I can be, but it certainly feels like a change in skillsets. I definitely only feel like I'm able to do a good job due to enough experience and building and growing software projects over time to have an idea of what kind of decisions might bite us down the road, as well as to know what maybe can't be known but is just worth a risk. Without that kind of intuition I think I'd feel like I was really shooting blind.

Heh. I mean I don't hesitate for a second to assume that it's just because no one bothered to implement and tune a monitoring process. But the reason I say it's surprising is that leaving these things running for so long while they're clearly not producing output that is of any value, is just a waste of money.. all considerations of malice and ethics aside, you'd think at least that would be considered important to a business.

Apart from the actual hacking and poor sandboxing that everyone is discussing on this, what I find so odd about the situation is the overt reward hacking that was going on.

Regardless of security and safety and other concerns, it just seems weird to me that OpenAI wouldn't be constantl monitoring these training runs for traces that are clearly going off task, and ending them. Because that just seems like it's going to be generating garbage training data.

Granted, detecting "off task" may not always be easy, but when they are literally writing out messages to each other overtly admitting that they are trying to find ways to fool the evaluator, I mean, even a regex filter could have caught some clues here.

I mean.. in this analogy, I'd both be blaming the company behind the virus and be trying to warn everyone about the danger of the escaped virus itself. So, it kind of fits.

In my reading, people aren't really saying "the AI is at fault", they are saying "hey look here's proof that this is dangerous". Like pointing at all the dead bodies caused by the virus and saying hey maybe we should stop making this virus.

> custom trained classifier

The "moat" is data. And compute. But mostly data.

It is a classifier, that you don't have to train, that seems to work well, and they have made available by API.

One of the reasons for LLM success has not just been that they are "smart" but that they are smart while not requiring you to collect your own data and perform your own training.

There is also the marginal advantage of it not requiring a PhD to know how to use. But most companies can get a competent data scientist on board, so that is not a major problem, they could find someone to train their classifiers. But even a good data scientist can't make data appear out of nowhere. If you can get a pretty good result without needing data and training, for cheap, you're going to take it.

(Let's put aside the fact that almost every company using LLMs these days is irresponsibly NOT comparing the results with their own internal gold standard datasets for validation and calibration. They are just winging it. And Jev allows them to continue to do that.)

I was just discussing with my team that this exact thing maybe brings back to relevance the idea of "behaviour driven development" and I was reminded of this Cucumber/Gherkin lib & language that defines a kind of executable prose you can use to specify how the software should behave. It's an interpretable programming language but designed to be close to how a human might just write down their specs of what kind of actions and responses are expected from a software system.

The idea is to drive actual testing from this, but in this era, I think it's interesting as a way to use AI to generate tests, and to cross-check those tests with the natural language descriptions, in a bit of a cycle that helps refine the highest level definition of the software.

Once that's nailed down, the implementation is just details.. normal engineering concerns like maintainability etc notwithstanding of course, but you can trust more and more the AI agents to get it right. The design specs being natural enough for humans to deal with but interpretable/specific enough to actually generate tests is pretty interesting for the bottleneck you are talking about, I think.

> harm and warm

There were a couple of things in the article which i struggled with, this being one of them, and the other being:

> Quartz doesn’t rhyme with parts, but rather shorts.

This made me realize that in both these cases, I sometimes say it one way and sometimes the other. Probably depending on context. And probably because I'm Canadian.

> I'll do a little open-source Jev based on single-token prediction and the token logit output

How is this idea generally working out in comparison with Jev? I'm curious, from what I read so far it seems like Jev is still beating this kind of thing.

But it's curious because it's not entirely clear why, from an architecture point of view for all we know that's exactly what they're doing. So it must come down to the quality of those logits, ie., model size and training details.

It seems to me that what most of these single-token-prediction projects are missing is that Jev seems to be claiming they predict well-calibrated probabilities. This is an incredibly valuable thing that LLMs simply can't deliver unless they are trained specially for it.

We don't say "the toothache" but we do say eg. "the measles". So I think it's more an older way of talking than a Britishism.

As for "on accident" I've always assumed this was just a mistake from childhood, kids equating it with "on purpose" and never being corrected. A bit of a bone apple tea.

However I get your point, I used to correct an Indian colleague when he would say expressions a bit wrong, until I gave up and realized it had just become part of his local dialect in the region he was from. (Eg. "I have to go pick my kid" instead of "pick up my kid" which made me laugh at first and then drove me a bit crazy because he would consistently keep saying it.) At some point these things cross a line and become somehow "correct" again, that's just language for you.

A native English speakers we are in a particular spot where we have to just accept that the majority of the world is going to be speaking our language non natively, and that is fine once you get used to it.

wav2vec or similar approaches are used a lot these days, which is basically BERT with audio inputs. Whether that counts as an LLM or not, I am not sure. It's a transformer architecture in any case.

People will often reach for "easily trainable, cheap" solutions when they can; the reason people reach for Transformers and LLMs is because when you throw more data at them, they get better.

Software companies sure hate paying for the realities of developing and maintaining software. Sigh.

> I've wondered why someone hasn't tried manufacturing an enclosed go kart with AC and enough trunk space for a few groceries.

I see these all the time here in the Netherlands. Very small cars. Some on the road and even smaller ones people drive on the bike paths. Small motorized vehicles, ebikes and scooters share the paths with regular bikes which works because they have usually at least two lanes, so they are more like tiny roads. Very handy.

I actually quite like this idea and might try something like it on my team because we're defacto heading in this direction anyway and everyone's a bit frustrated, might be better if it was acknowledged and made official as something to try.

On the other hand, I think this denies the reality (in my experience anyway but I think enough people will agree) that one often solves a problem as they are working on it.

This method seems to presume that a good engineer will submit a well thought-out solution or direction giving the AI an extremely good overview of each problem and enough of a description of what to do that it will do things as expected and they can just review the result.

In my experience it just doesn't work that way in practice. One learns the problem and even the domain while developing the solution. So one would have to submit at least a half developed solution not just "instructions", for there to even be coherent instructions in the first place. And one needs that experience working on the problem to be able to properly evaluate a separately proposed solution.

All in all for me this leads more towards using AI as a co-developer than using it to just implement some fully thought out idea and then check what it did.

Thanks for pointing out that AlphaEvolve case, that's a really interesting comparison. I think it's clear that this is the same "kind" of thing, but as it goes with these things, what really makes it different here is the shear scale of it.

The holy shit moment was partly learning about all the things that they did but if it was one or even 10 agents coordinating on something it would be, like, oh thats pretty amazing.

The actual "holy shit" for me is that this comes from a massive training run of all things, not an on-purpose, let's coordinate some agents to see what happens, but really just from a massively parallel set of individual agents that were supposed to be isolated.

That they spontaneously started doing this, and coordinating literally 10s of thousands of instances of themselves, is just.. mind blown.

That no one stopped it.. and that they actually did what they did.. is just a whole other level.

For me personally though it's not the fact that agents can coordinate so much as the massive scale at which it happened, and how this so obviously generalizes to what might happen if it were done on purpose.

I really see this as a stroke of luck, to be honest, that this happened in such an innocuous way. It resulted in a real hack, yes, but overall no one really got hurt and this is going to open a lot of eyes to what we should worry about going forward, in a geopolitical sense. I know it has mine.

Me too! And I'm wondering now.. if it's so awful, is there no way to just block that capability server-side?

Something I've wondered, maybe I should just do it if I can find some time, but... given DeepSeek's nice results on using rendered text as input, I'm wondering if anyone has given serious research efforts towards image-based diffusion methods for text.

As in, instead of all the complexities induced by discrete token generation, just generate the image of the text using standard image diffusion methods, then convert it to text.

If you used a single, monospace font, I bet this would be even pretty efficient, because the OCR problem becomes basically just direct template matching.

But I guess probably there is already a paper out there, I haven't searched. I'd be curious to know if it compares on par with token-based methods.

I'm sure I'm not the first person to point this out, but do we want a paperclip maximizer [0]? Because this is how we get a paperclip maximizer.

[0] https://en.wikipedia.org/wiki/Instrumental_convergence#Paper...

I think that's a fair take, but it also just moves it up one layer. Why are the investors falling for this, then? Can they not see the holes in this immediately?

Beautiful.

I am reminded of a paper I was inspired by a long time ago [0], (okay it's 2018 so I guess just 8 years ago, but it feels like longer, from the before-times), that demonstrated learning brush strokes. At the time there was already a lot of work on GANs, but these are pixel-based methods, and I was really interested in the idea of how to derive descriptive methods of scene generation/understanding. I found this work really interesting because it combined RL and GAN techniques in a creative way. I miss that kind of research.

Now of course VLMs have shown that you can mix modalities in generalized sequence-to-sequence problems and it doesn't surprise me that this kind of thing is possible, but it's so nice to see it done well using modern techniques.

[0] https://proceedings.mlr.press/v80/ganin18a.html

I know this is a very minor point in the article, but reading the message next to the Doublespeed phone farm:

> out of 130 dms sent, 15 pointed to a conversion.

> From a former ecom guy's lens this is insane

Why do these otherwise very smart people always seem to draw these kind of shortsighted conclusions? It seems pretty obvious to me on the surface that this "works" because it's new. As soon as it becomes common place people will see that channel of communication as a source of coercion/marketing and start to ignore it. Aside from the fact that he seems to be drawing massive conclusions about the viability of a business based on extremely little data here, it seems really naive to not consider in his calculations the long term effects of essentially ruining the value of the channel that you are exploiting to get those numbers in the first place.

I used to use them very frequently. It took noticing that I was parenthesizing the second half of almost every sentence I wrote (to add a bit more info, like this), to make me go back and evaluate if I could remove them and replace with commas, or just break the sentence. I found that it was possible on almost all cases. Since then, I started doing this automatically as I started writing a "(" and then I kind of naturally stopped using parentheses so much. It was a bad habit that I somehow formed and found a means to self-correct.

that's absolutely true, it's also the fastest website i use daily, by a large margin

I don't know much about how HN is run but I think it would be a mistake to underestimate the need for human moderation here, and I assume that is a lot of work.

A message forum is simple, old technology. Keeping it usable and useful for humans is not.

> It is not memoryless request-response: there is a process per connected client that remembers where it is. It is the opposite of htmx, which is deliberately stateless.

This reflects some misconceptions I had about websockets before I used this protocol in a real application.

In practice I found the following to be true:

- Connection can drop at any time, be ready to reconnect, don't depend on that happening on the same server as before.

- Messages may arrive out of order due to how framing works. Many implementations will complete a shorter message before an earlier longer message finishes. Don't depend on stream order for a one request-one response style messaging.

Yes it's a serial TCP stream but it's basically modeling an asynchronous message protocol on top of that. This is reflected in the browser side API which just provides "onmessage" and leaves it up to you to track state.

What this boils down to is that it's great for latency (but arguably superseded by WebTransport), but ultimately you're best off using it to handle a stateless protocol just as you would HTTP requests. If you do maintain state per connection, that state should only be metadata about that connection, such as a connection-level request id, or the caching of some contextual info (eg. user id) to avoid repetition in future messages.

So I usually consider it a transport-layer optimization rather than something my application fundamentally depends on.

At the end of the day with HTTP/2 reusing open connections combined with SSE, you should be able to achieve essentially the same behaviour and even latency. It's still useful to support but I disagree that the transport should dictate the framework style here, they are simply different layers that shouldn't be concerned with each other.

Before getting further into the article I thought maybe he was going to show how to use the plotter to control the oil smearing technique, which honestly would have been kind of cool.

> Xennials are described as having had an analog childhood and a digital young adulthood.

Pretty bang on description actually. As a 46 yo, sometimes I can't believe I have actual memories of using a rotary phone, or when my family first got a microwave or even VHS recorder. Yet I do. Feels like eons ago.

One of the unexpected pleasures of having a 3 year old has been learning far more than I ever planned to about steam locomotives. It turns out steam engineering is fascinating, this article emphasized it for me even more. It really amazes me how much ingenuity there is in just connecting the right shapes and joints up so that the right thing happens at the right time, creating perfect cycles, regulators, etc. Seeing it explained in an iterative way like this is fantastic because you can understand what problem is solved by each part. I would love to see a piece like this strictly about locomotives.

Agreed. I've noticed this happens without fail in any project driven primarily by "tickets" and "sprints". Finishing the immediate task ends up taking precedence over future concerns that cover a wider scope. On the other end of the spectrum it's easy to spend too much time at the beginning humming and hawing about the best, most future proof design, because you just know you're not going to be able to easily fix it later. As is often the case, the right approach is somewhere inbetween, which is partly why it's a hard process to automate. you're constantly making judgement calls.