HN user

headcanon

2,273 karma
Posts2
Comments555
View on HN

agreed, but IMO thats been true for most off-the-shelf skills I've seen. Instead I built my own "/meta" skill to improve my workflows, which I can use in targeted ways across my projects

I think AI optimism is an easier jump for those already immersed in computer culture, or at least the subset of that culture who view automation as a virtue.

For those either outside computer culture, or those within who might view "craft" as virtue, automating that craft is an affront.

Right now, the "automators" (pro-AI) folks seem to be pushing that culture onto the "crafters" and naturally getting pushback.

Two years ago (Dec 2023), I visited Japan and try to use ChatGPT (GPT-3 era) to translate Kanji signs, it was OK but not great. A little over a year later (late April 2025, o1 era IIRC), I visited again and saw a political rally with hand-painted-style Kanji signs. I took a picture and asked what the political party was about. The big "wow" moment was how it would write inline python code to crop analyze the image while it was thinking, then combine it with web searches to eventually find me the website with a summary of what they were about. It definitely hit home for me the potential of what these were capable of.

Human Bottlenecks 2 months ago

I've been trying to solve a lot of the issues brought up here, like personal automation, note taking, article summarizing/indexing, etc. What I've learned so far is that no level of AI-enabled automation will help me with my inherent ADD. All it means is that I have more started projects, but just as many finished ones. It has been a big enabler for things I'm already knowledgeable about, but the cognitive debt issue is real: A machine that thinks for me can't help me think better by itself.

To use your analogy, I would say the "blanket ban" attitude would be more like wishing all viruses would just go away, or have never existed in the first place, which:

1) is an impossible and unproductive attitude, and

2) fails to recognize the important contribution to evolution, genetic diversity, and our immune systems that viruses introduced, not to mention the possible beneficial applications that could exist by understanding it.

Rejecting something without nuance makes you more vulnerable down the road because it prevents you from building an effective immunity. Engaging with it is the only productive way to mitigate its downsides and promote its benefits.

My wife bought a Neo and has been very happy with it. I was wary of the 8gb memory limit but she is running claude code doing web development with a reasonable number of tabs open and no noticeable lag, so I'd say its definitely getting a lot of mileage out of it.

It honestly seems good enough that it might cannibalize Macbook Air sales.

As others have said, the main benefit with Python over Rust is library support especially with ML features. The other gap as I see it with Rust is the lack of native flexible UI support. The nice thing about Rust though is it can serve as a very fast and stable core for an app and offload specifics to TS and Python as their strengths allow, so you get the best of all worlds.

My current goto for desktop apps is Tauri, which give us a rust backend and TS fronted (usually React). Local ML features can be easily loaded as a python sidecar. Production bundling can be a little challenging but it seems to work well so far.

Sidenote: Golang is also an amazing language for LLM use, I generally do most of my "infra" stuff in Golang over Rust, but either work fine most of the time.

I've been trying to toe the line here myself, here's how I've been doing it. For context, I pay for a Max 5x subscription.

My main goal is to maximize my subscription token usage while trying to comply with the rules, but its not clear where the line is for automation so I feel like I need to be clever.

- regular development (most token use): all interactive claude mode, standard use case

- automated background development: experimenting with claude routines (first-class feature, on subscription)

- personal non-nanoclaw claude automations (claude -p): uses subscription token, but only called as needed (generally just fix something if something in my homelab infra goes does down, its set up to not fire on an exact cron time)

- other LLM based automations: usually openrouter API key, cheap models as needed

- nanoclaw: all API key based, but since its expensive I keep usage mostly minimal and try to defer anything heavyweight to one of the other automation strategies (nanoclaw mainly just connects my homelab infra with telegram)

I tried openclaw when it was released, but I preferred the minimalism of nanoclaw and replaced it. I have it on a mac mini now

For context: I have additional automation with scripts set up on the mini, some of them call LLMs to do things like summarizing today's news.

I have other automations that are agentic and just run "claude -p" (mainly just checks status of other jobs and fixes them automatically). Agentic automations are great because they can handle unexpected situations (at the cost of predictability). They're all sandboxed and we have control over tools for the most part. Any files it would write to are typically git-controlled so we have change records and rollback built in.

Nanoclaw acts as an agentic layer but combines it with the communication layer over telegram to make it interactive.

I use it to go through my centralized task list (currently beads in my main 'wiki' monorepo), give me nudges for todos, I can also send it pictures of say, food and it will fetch a recipe and sort it into the wiki via a general "inbox" skill (claude has it as well). Every day at 12:30 it will give me a mini "standup" of all my personal projects and todos, and once in a while will give me some thoughts based on my interests.

Its set up to do appropriate tasks with local models to keep token costs down, so far it doesn't seem to cost more than $10-20/mo, it would use less if I didn't drive it with sonnet.

I'm still experimenting with it, and trying to go slow, one thing at a time. I don't give it access to anything super sensitive yet, and try to keep it observable.

Early career folk join some toxic startup and stay because the internet told them all CEOs are like this.

I literally did this 12 years ago based on this reasoning, its good you're trying to counter that with the next generation.

With that said, I do wish there was more discourse around systemic issues rather than the usual finger-pointing towards rival social groups. Unfortunately I feel like our language gets in the way, systems issues are more abstract, but "bad people" are more visceral and easy to talk about.

This is a big part of why I'm looking to develop a local LLM capability: having the hardware is a good start, but also developing the understanding on what the SoTA of local edge models can do, so we're not crippled if remote models stop being served, or at least some risk management.

It doesn't solve the problem of general LLM dependency (at the end of the day we gotta keep our brains sharp), but any LLM-based workflows aren't all of a sudden put at risk if we set up something that depends on it.

Kind of. I'm finding that my terminal window in VSCode went from being at the bottom 1/3rd of my screen to filling the whole screen a lot of the time, replacing the code editor window. If AI is writing all of your code for you based on your chat session, a lot of editing capabilities aren't needed as much. While I wouldn't want to get rid of it entirely, I'd say an AI-native IDE would deemphasize code editing in favor of higher-level controls.

I've been getting close to that myself, I've been using VSCode + Claude Code as my "control plane" for a bunch of projects but the current interface is getting unwieldly. I've tried superset + conductor and those have some improvements but are opinionated towards a specific set of workflows.

I do think there would be value in sharing your setup at some point if you get around to it, I think a lot of builders are in the same boat and we're all trying to figure out what the right interface for this is (or at least right for us personally).

I agree with most of the other comments so far, the "magic" of the show is going to be hard to replicate.

My bull case for this is that Nathan Fillion and crew have had 20 years of exposure to this fact and likely know what they're getting into and how to do it right. The only question is if they'll be able to execute. I'm excited!

Thats exactly what we as software engineers do. We are constantly automating ourselves out of a job. The trick is that we never actually accomplish that, there will always be things for humans to do.

We're discovering so much latent demand for software, Jevon's paradox is in full effect and we're working more than ever with AI (at least I am).

+1 for Tauri, I've been using it for my recent vibe-coded experimental apps. Making rust the "center of gravity" for the app lets me use the best of all worlds:

- declarative-ish UI in typescript with react

- rust backend for performance-sensitive operations

- I can run a python sidecar, bundled with the app, that lets me use python libraries if I need it

If I can and it makes sense to, I'll pull functionality into rust progressively, but this give me a ton of flexibility and lets me use the best parts of each language/platform.

Its fast too and doesn't use a ton of memory like electron apps do.

I've been cruising on rust too, not just because it works great for LLMs but also the great interop:

- I can build SPAs with typescript and offload expensive operations to a rust implementation that targets wasm

- I can build a multi-platform bundled app with Tauri that uses TS for the frontend, rust for the main parts of the backend, and it can load a python sidecar for anything I need python for (ML stuff mainly)

- Haven't dived too much into games but bevy seems promising for making performant games without the overhead of using one of the big engines (first-class ECS is a big plus too)

It ended up solving the problem of wanting to use the best parts of all of these different languages without being stuck with the worst parts.

Maybe have it build some toy apps just for fun! My wife and I were talking once about typing speed and challenged each other to a typing competition. the existing ones I found weren't very good and were riddled with ads, so I had Claude build one for us to use.

Or maybe ask yourself what do you like to do outside of work? maybe build an app or claude skill to help with that.

If you like to cook, maybe try building a recipe manager for yourself. I set up a repo to store all of my recipes in cooklang (similar to markdown), and set up claude skills to find/create/evaluate new recipes.

Building the toy apps might help you come up with ideas for larger things too.

Agent Skills 6 months ago

Its additional context that can be loaded by the agent as-needed. Generally it decides to load based on the skill's description, or you can tell it to load a specific skill if you want to.

So for your example, yes you might tell the agent "write a fantasy story" and you might have a "storytelling skill" that explains things like charater arcs, tropes, etc. You might have a separate "fiction writing" skill that defines writing styles, editing, consistency, etc.

All of this stuff is just 'prompt management' tooling though and isn't super commplicated. You could just paste the skill content into your context and go from there, this just provides a standardized spec for how to structure these on-demand context blocks.

I've been coming around to the view that the time spent code-reviewing LLM output is better spent creating evaluation/testing rigs for the product you are building. If you're able to highlight errors in tests (unit, e2e, etc.) and send the detailed error back to the LLM, it will generally do a pretty good job of correcting itself. Its a hill-climbing system, you just have to build the hill.