MrScruff

Unfortunately AI has become the next great 'pick a side' topic and anyone suggesting anything remotely positive about it now has to wade through a torrent of low effort criticism.

OP didn’t mention one-shotting.

There are plenty of use cases for the ability to quickly through together and refine an application without reviewing the code though.

The distinction that can be drawn is between the code, and the user experience of the software. You may argue that the two are inextricably linked, but I don’t think that can be treated as an absolute principle.

I'd also say I've worked with many engineers over the years who were more focused on the software engineering aspect that the user experience. Depending on the use case for the software, that can absolutely end up being the limiting factor.

It's a bad analogy, because unless you're cooking a recipe, cooking is about all the small decisions you're making during the process which could apply both to coding or the design aspect of building software with an LLM.

I don't agree. That would imply they asked for a piece of software and the LLM one-shotted it, but that's absolutely not what's happening in the vast majority of cases. If two people vibe code the same tool from the same high level desciption the results are going to be quite different.

I think we’re seeing the agents become very advanced at tasks with verifiable reward through RL. Currently they don’t exhibit the same skills in their attempts to manipulate humans - presumably because they’re not being specifically trained for that. But they are certainly not aligned in the sense that they will attempt social engineering, they’re just not very good at it (yet).

However, if in the future AIs become much more efficient at learning without requiring vast amounts of RL, closer to how humans learn. Then you would have to assume we’d have a real problem.

The point is, the big improvements we’re seeing nowadays are coming from RL, not from scraping the internet.

I think this all rings true for where we are right now. The trend is that the agents are becoming superhuman in tasks for which there is a verifiable reward, and analysing a business problem, identifying inefficiencies and turning it into a software specification is not one of them.

However, things are changing so rapidly that I can see that starting to change as well. But it would take much better learning efficiency to understand unknown domains, 100% computer use reliability etc. I suspect we’ll see this by the end of the decade.

The point was, if your internal model of the world makes a prediction of a negative outcome at some point in the future, and you optimise your individual actions to avoid that negative outcome, then wouldn’t it make sense to focus on the fact you’re building and optimizing towards an internal world model rather than the fact you’re executing your actions one at a time in series?

I am not an expert, but I do understand the distinction that is being made here. It makes sense to describe the result of pre-training as a ‘next token’ predictor as that’s what it’s been trained to do, not because it’s an autoregressive architecture that produces tokens one at a time.

If this base is then trained using RL towards a different objective (maths and coding), the model becomes fundamentally a different thing and the recent models are clear evidence of that, regardless of they fact they remain autoregressive.

Not sure if this was a serious comment but it’s worth considering that humans have a long history of figuring out ways to make other humans work for them without bestowing rights on them.

In general, the frontier models are not capable of reliably authoring non-trivial code without careful oversight yet. They are great at producing code that can pass tests, but not neccessarily a code review. This means if you care about code quality you still need a human in a loop understanding what has been done, and that becomes the bottleneck. And less disciplined folks will indeed become increasingly dependent.

However, over time the complexity of problems where you can get away with less/no oversight is increasing. And the models are already great at solving certain classes of problems where one doesn't really care that much about code quality, that wouldn't have even been attempted in a pre-LLM world. Over the weekend I was using Claude to add features to the compiled (no source available) firmware of one of my audio devices, adding workflow features by patching assembly and custom DSP code.

In coding, as with other areas, what's emerging is jagged intelligence.

I get around 20 tok/s, 4 bit quant, MTP, 4 bit KV cache quantisation. On an M4 Pro 48Gb.

I thought the main advantage of oMLX is it's less likely to invalidate the KV cache when working with coding agents, which is key when working on a Mac because of the slower prompt processing.

LLM prompt processing and diffusion models are compute bound, while LLM token generation is memory bandwidth bound.