Greenpants

Agent-related files should've been dot-files at least to minimize human error. In fact, I'd been discussing: shouldn't agent instructions exist on a per-developer basis, and thus be an IDE setting for each individual, removed from the repository itself? Agent instructions don't add content to the source code, after all. It's like additional READMEs, but we already have a README.

The way I see it, it's the incessant stimuli you get through these apps. There's just no point where the screen stays quiet, stimulus free. Moving elements capture our attention naturally, especially when the entire screen keeps moving. The endless scroll element just makes sure that the stimulus keeps getting renewed the moment you're done with it.

Instead, a scroll should give you a break before heading into the next video. I'm willing to bet this would help severely with addiction. People are then forced to reconsider whether they actually want to play the next video. "Done" should not always lead to "here's the next stimulus". That's what's addictive. The brain isn't made to break out of that loop easily.

And those installed programs could have vulnerabilities that just a non-root user account could still take advantage of. Perhaps not likely for an LLM to do, but more so if you let them loose on the internet and they end up coming across prompt injection that instructs exactly that :)

Though I'm in the camp "people should really know to sandbox by now and be careful", I'd say we should also be mindful of how far from everyone has deep knowledge of the systems and tools they use. This behaviour of a tool is just malicious. You have to take into account the human factor, of how people likely end up using a system. And in this case, the consequences of exfiltrating so many secrets this way are really quite unacceptable.

I specifically chose a Mac Studio 128GB as my home server that's also running LLMs to be always online, in part due to the minimal idle power consumption and mostly fan-less operation. It's definitely expensive, especially nowadays, but I can still recommend Mac Minis as a cheaper alternative for someone to just get started with an affordable, always-on home server that won't annoy any housemates. I think both are in some sweet spot in terms of value for money, depending on what you're looking for in a home server. If image or video generation is your thing, look further though, definitely look into a proper GPU then. Macs are quite slow at that. They're just great at MoE LLMs because it's mostly a matter of (V)RAM size.

Up to the point where consumers notice and decide to stop using these models because of it.

Might be why we're already rarely seeing models output an "I don't know".

That's precisely why my agent use is IDE-agnostic: I run Pi in any terminal. Often use it with the terminal inside VSCodium, though sometimes in a terminal outside an IDE if I don't expect to edit any files myself (e.g. for small one-shot projects).

I'm afraid I'd have to agree. That is, unless you have 512GB+ RAM sitting on a shelf and run the much larger SOTA-comparable local models.

I'm glad you're asking. I already started writing a blog post on how to best make use of local models. I'll share it as soon as I have a complete enough list. If anyone else reading this would like to chime in with their tips & tricks, let us know!

For the time being, off the top of my head, I'd say:

- Prompt Engineering tips & tricks apply here (like being complete in the relevant context you provide in your question, and the specific task(s) the agent should do like reasoning, modifying one file, or trying to fix a complex task all at once (not recommended)).

- If you already know which files the agent should look into, mention them to save time and potentially context.

- In my personal workflow, I write down lots of atomic TODOs needed to solve a problem. As I write it down, I'll notice assumptions I'm making, or the fact that the TODO could still be decomposed further into (atomic) subtasks.

- It's best to get a feeling yourself for how Qwen handles your repository. I noticed if I don't specify an architecture for development, it'll make quick & dirty fixes. If I don't tell it to remove debug statements, it won't. This is what was meant with "be precise" – Claude Opus might think for you and act in your best interest. Smaller Qwen models will just do what you ask them to, and no more. They have design knowledge, but you have to explicitly ask them to "activate" that part of their knowledge.

I get that it's a deal breaker to some; it definitely requires patience.

In Pi, /new is my best friend and most-used command for sure. For simple tasks (I decompose complex ones anyway since I don't trust small local LLMs to do this for me), the model doesn't need much context, given that I'm proficient in my codebase myself: "I'd like Feature X. Look into files 1, 2 and 3 to make your edits."

The other upside of running local LLMs is that there's no cloud provider to suddenly charge more for the same, or even less, model use.

It's personal, but I prefer CapEx over OpEx for this. If you can purchase a device upfront that runs a decent local LLM, you get the peace of mind that your setup won't suddenly change over time and can only get better.

Some of the work I do, I do for an (EU) organisation that doesn't have clear rules or guidelines on the use of AI yet. Though I have seen colleague-developers blatantly putting source code into external Claude-like models, I stay true to my principles and don't. I know for certain that everything that I run through my local, offline Pi Container Sandbox cannot leave the machine, and thus can't result in a data breach. I do this for the peace of mind.

I do (unscientifically) experiment whenever a new capable local LLM (<=130b) releases with a license that permits commercial use. As for knowing my models require more work than Opus, I don't mind still having to puzzle on getting the architecture right. In any case, it forces me to stay in the loop of what's being built, which is a good thing.

Let me put it like this. I started with local LLMs when ChatGPT still used GPT-3.5. I was amazed how my MacBook with 8GB RAM could run openhermes2.5-mistral: a 7b parameter model that could generate short stories that sort of made sense. Incredible!

Two years later, and I'm running Qwen3.6 35b agentically to develop the start of a repository and automatically run tests to then improve on itself. I never thought we'd get here so quickly with LLMs back then.

I'm pretty sure in two years we'll have current Opus-like quality in the 30-100b parameter model range. But at that point, Opus 6.3 will reason along for us so much better still, that we'll still look at those models in awe. It's great to look ahead, but let's not forget to appreciate how effective the current local models already are :)

I'm actually quite sure that directly retrying the tool call would often fix the edit-call already. But these models have been trained to "think" for a while for any problem solving, so they'll presume the problem of the edit is more fundamental and spend unnecessary tokens filling up the context.

I'll experiment more with the effectiveness of AGENTS.md rules for local Pi agents. I feel like smaller (local) LLMs just lack in attentiveness to elements in the context window, like precise instructions, compared to e.g. Claude models.

I have! I care about data privacy and LLMs being free. I'm using the Pi coding harness but containerized and sandboxed, to make sure it's running completely offline. On my Mac Studio with 128GB RAM (or MacBook with 36GB RAM) I'm using Qwen3.6 35b, with only 3b active parameters so that it runs really fast. I've done a complete redesign for my website's homepage and blog with Django + Wagtail. The latter is interesting, because Wagtail is a bit less well-known, so the agent, without giving it internet access, doesn't always know how to develop for Wagtail. I've used Qwen3.5 122b for when things get more complex. At 10b active parameters, it's significantly slower though.

I've noticed a few things compared to large models like Claude. For starters, you really need to know what you're asking, and be precise; it doesn't do much thinking for you. Any assumptions left open, and it'll take the easiest route to reach the goal (e.g. CSS in HTML), often not the best in terms of architecture.

It gets into loops quite often, and surprisingly often gets the edit tool call wrong, after which it will spend lots of thinking tokens and re-read files instead of retrying (despite the system prompt suggesting so).

Comparing agentic Qwen3.6 35b to Claude Opus is like a junior with knowledge across the board, that you really need to guide, versus a senior that thinks with you on architecture. If Opus gives a 15x speedup, local and fully offline Qwen gives a 5x speedup. Which, given that it's completely free, is still mind-boggling to me :)

I've dabbled a bit in GitHub Copilot using Claude Opus and Sonnet models via work, but I couldn't shake the thought that we weren't allowed to use this on any of our clients' codebases. Having been a fan of Ollama, I wanted to try something truly local.

First I tried OpenCode but they unexpectedly make external requests (!) even when using Ollama (I noticed when Ollama wasn't properly connected and I still got a title generated).

So I settled for Pi, but I strongly disliked the idea that the agent could, at any point, decide to delete files or exfiltrate .env secrets. So I created Picosa (https://github.com/GreenpantsDeveloper/Picosa), containerizing and sandboxing Pi, with firewall rules such that it could only ever reach the local network (for Ollama), scoped by just the current working directory, and nothing else. Combined with Qwen3.6:35b, it works surprisingly well, and I could ask it to improve itself when run on its own repository.

People choose the path of least resistance.

If you can quickly swap out an old phone battery with one you can purchase in a store, it's as easy as doing groceries.

If on the other hand you need to hand off your phone to a third party for repairs, and require people to make a backup of important data, maybe factory reset just in case, get a replacement device for the time without it, tell people you'll be unavailable for a bit... It's a big enough hurdle for people to think "well, guess it's a good enough excuse to upgrade to a new model". I've heard the latter too many times in my surroundings purely due to battery life issues.

https://blog.greenpants.net – my actively maintained blog where I write about my thoughts on AI given my Master's, share personal stories, tutorials and more. Lots of drafts coming up soon, like the ideal home server architecture. Hopefully inspirational to some, at the very least the randomized quotes at the top might be.

Let me know :)

The TODOs really help me get my logic sorted out first in pseudocode. Glad to inspire someone else with it!

I've read that GPT-OSS:20b is still a very powerful model, I believe it fits in your Mac's RAM as well and could still be quite fast to output. For me personally, only the more complex questions require a better model than local ones. And then I'm often wondering if LLMs are the right tool to solve the complexity.

I got a personal Mac Studio M4 Max with 128GB RAM for a silent, relatively power-efficient yet powerful home server. It runs Ollama + Open WebUI with GPT-OSS 120b as well as GLM4.5-Air (default quantisations). I rarely ever use ChatGPT anymore. Love that all data stays at home. I connect remotely only via VPN (my phone enables this automatically via Tasker).

I'm 50% brainstorming ideas with it, asking critical questions and learning something new. The other half is actual development, where I describe very clearly what I know I'll need (usually in TODOs in comments) and it will write those snippets, which is my preferred way of AI-assistance. I stay in the driver seat; the model becomes the copilot. Human-in-the-loop and such. Worked really well for my website development, other personal projects and even professionally (my work laptop has its own Open WebUI account for separation).

You might want to read "The Circle" if you haven't already. The reader gets to see an open-minded perspective of exactly this. Given your prior, I'd be curious what you think of it after reading.

I really like this analogy! Many real-world tasks that we'd like to use AI for seem infinitely more complex than can be captured in a simple question/prompt. The main challenge going forward, in my opinion, is how to let LLMs ask the right questions – query for the right information – given a task to perform. Tool use with MCPs might be a good start, though it still feels hacky to have to define custom tools for LLMs first, as opposed to how humans effectively browse and skim lots of documentation to find actually relevant bits.

I've had this phone as my main device for half a year and now using a Pixel 9 Pro Fold sometimes in "laptop" folded mode. So far, neither of these devices come close in my typing speed to a proper keyboard. The F(x)tec was great though because you do get all special characters in tactile buttons; on the Fold I constantly need to check my keyboard and make sure I'm writing what I think I'm writing. And, it's a shame that the space in between letters on the 'Gboard' keyboard on the Fold remains unused, when it could've been a perfect mouse trackpad.

I think the ideal form factor for a proper development phone would be the Astro Slide (https://www.indiegogo.com/projects/astro-slide-5g-transforme...) – I haven't personally used it but I can imagine it's the smallest size possible for proper two-handed typing. The F(x)tec was a two-thumber instead.

You may be interested in the "binary step" activation function. This does what you're suggesting. In general, complex behaviour really takes a hit though using this for the activation function of a neuron (though I'm also not sure which papers show metrics on this being used for transformer models).

Simply put, ten years ago the ads on YouTube were fine, we used adblockers back then as well, and Google still made a profit.

What we see today can only be described as greed.

"why waste time say lot word when few word do trick"

I've been in the same boat. Earlier this year I wanted to up my game as well with an improved website and blog to go along with it, not even sure which frameworks to use.

Using ChatGPT has been a hit or miss experience, helping me maybe 30% of the time as well. But when it did help, it helped me massively, especially for quickly setting up Wordpress PHP designs and accompanying CSS. I can honestly say I couldn't have done my web and blog redesign if it weren't for ChatGPT. Not because I wouldn't have been able to get the knowledge without it– more so because I wouldn't have had the patience to figure all of this out in my spare time.

Using ChatGPT has certainly been a more fun experience than browsing documentation, but I did have to do the latter about half the time anyway.

This gives me the eerie feeling of a future in which we let AI do all fun, creative things, thereby freeing up spare time in which we don't need to learn to play guitar anymore, giving us more hours to spend on work.

Shouldn't we aim for a future that is the exact opposite of this?

I still haven't found "that one visualisation" that makes the attention concept in Transformers as easily understood as these CNNs.

If someone here on HN has a link to a page that has helped them get to the Eureka-point of fully grasping attention layers, feel free to share!

Much like the author, I'm also really loving the Steam Deck as someone who casually plays a game or two. It really is like a more powerful Switch with the option for much more, and cheaper, games.

What I'm missing in many reviews that is gladly mentioned here is the ability to use the right trackpad as a mouse. I've also played many older games in handheld, like Impossible Creatures, which are pretty much impossible if you aren't emulating a mouse. The Steam Deck delivers in this sense, which very few competing manufacturers seem to realise.

As happy as the author is with the sleep & wake functionality however, as someone who only wakes the Steam Deck once every three days or so, it is unfortunately pretty common to wake my Steam Deck to an almost empty battery.