If I want to have a good AI pair programmer, whose job is only to implement my ideas, rather than give me ideas, what would be the best choice?

One could get an iPhone 18 and an iPad Air for the same cost as this.

I wonder where in the training data does this behaviour exist that the LLMs are doing it.

It's as if the training data is filled with internet discussions on approaches to hacking and the LLMs are mimicking it.

The power of the other tools mostly shines in large scales. For most applications, though, performance of postgres more than suffices.

I tried to use rabbitmq for a small app, installed it, configured it and then it didn't work. Spent a day jumping through hoops getting it right.

Dumped it and used postgres, in half an hour. Worked like a charm.

Sure, best not to overcomplicate early if you don't need it.

PG is great and I work with it daily, but it's also not a problem to think about scale early and at least have a notional plan for what to and how to know when scale is becoming an issue in your system as you're designing it. Even PG is overkill and sqlite is more than enough for some of my projects.

There are a lot of specialized tools available, but you definitely don't need to put every one in your toolbox. Experience and observation help you make those edits -- and of course there's almost always room for improvement, but "good enough" definitely exists (until it doesn't anymore :D).

This is the way. Notionally building a space/path to scale into architecture early, but delaying implementation of that scaling component until actually needed.

Then a system gets most of the benefits of not accidentally making it torturous to rearchitect for scale, without paying the headcount / complexity cost until it's needed.

Would your app run equally well with sqlite?

If NASA made a lightbuld, it would outlast the universe !

The one thing I hate about flutter is the ui code having an ungodly amount of nested brackets.

I treat nesting as a feature: if the nesting starts getting deep, that's the code indicating to extract a child widget. It pushes me toward better composition and smaller, reusable components instead of giant monolithic views.

While you aren't wrong, in my experience when the amount of nesting starts giving me bad vibes it usually indicates that something can be refactored out as a standalone widget.

Still, Flutter now feels ancient to use compared to something like Compose, in that regard.

For some reason I prefer those to curlies.

On what hardware do you run the model locally, if so?

Not the GP, but I run this model as daily driver too. It runs great on a Macbook Pro 64GB (M3 Max). Token generation speed can be about 100 tokens/sec with multi-token prediction, although it depends on the context. Worst case speed is around 50 tokens/sec.

The weaker point is prompt prefill, which starts at 1,400 tokens/sec but decreases significantly at high contexts. That said, for agentic scenarios, if you're using a harness that doesn't needlessly bust the cache, it doesn't feel slow.

I really hope they release a Qwen 3.8 35B, although the lack of a mention seems ominous.

The last bit of the last bit of what you said is what Warren Buffett has been saying for decades.

I still wish we had more phones that have eink screens in them.

I love the folding ones, but if only I had a folding eink screen, that would be glorious !

Or at least, something close.

I loved technical books from Mir publishers. Russian authors have a special place in my heart for explaining complex technical topics in concise yet engaging way.

Books like Problems In physics by I E Irodov were my favourites