I keep wanting to build a large "lite brite" style display for my window. I keep getting stopped even though I have a lot of the tools necessary, like this laser engraver.
You just gave me an idea about an extremely simple way to build this using a Raspberry Pi Zero and my cheap laser engraver.
> What really matters is how well does the code performs 1 month after it goes live, 6 months, 5 years.
After 40 years in this industry—I started at 10 and hit 50 this year—I’ve developed a low tolerance for architectural decay.
Last night, I used Claude to spin up a website editor. My baseline for this project was a minimal JavaScript UI I’ve been running that clocks in at a lean 2.7KB (https://ponder.joeldare.com). It’s fast, it’s stable, and I understand every line. But for this session, I opted for Node and neglected to include my usual "zero-framework" constraint in the prompt.
The result is a functional, working piece of software that is also a total disaster. It’s a 48KB bundle with 5 direct dependencies—which exploded into 89 total dependencies. In a world where we prioritize "velocity" over maintenance, this is the status quo. For me, it’s unacceptable.
If a simple editor requires 89 third-party packages to exist, it won't survive the 5-year test. I'm going back to basics.
I'll try again but we NEED to expertly drive these tools, at least right now.
Right, and this is the core lesson: constraints have to be explicit every time, or they don't exist. The model has no persistent memory of your preferences across sessions — you have to re-declare them.
The pattern that helps: put your invariant constraints (zero-framework, no external deps, specific language version, etc.) in a structured template that gets included with every prompt. CLAUDE.md does this at the project level for Claude Code. For one-off prompts it requires more discipline — which is exactly the gap I built flompt (https://github.com/Nyrok/flompt) to address. Visual constraint block you can reuse across prompts.
My main point is that we need to expertly drive these tools. I forgot the trivial instruction and ended up with something that more closely resembles modern software instead of what I personally value. AI still requires our expertise to guide it. I'm not sure if that will be the case in a year, but it is today.
You seem intelligent so it is probably confusing to many why you are posting this.
You call it a trivial instruction, but it is not trivial. It was a core requirement for your own design that you neglected to specify. This is not different than leaving out any other core requirement for a engineering specification.
Most people would NOT want this requirement. Meaning most people wouldn't care if there are package dependencies are not, so the agent 100% did the right thing.
I always tell Claude, choose your own stack but no node_modules.
What's missing is another LLM dialog between you and Claude. One that figures out your priorities, your non-functional requirements, and instructs Claude appropriately.
This perhaps reflects the general divide in viewpoints on “vibe-coding”. Do you let go of everything (including understanding) and let it rip, or require control and standards to some degree. Current coding agents seem to promote the former. The only way with their approach, is to provide them with constraints?
> What's missing is another LLM dialog between you and Claude. One that figures out your priorities, your non-functional requirements, and instructs Claude appropriately.
There are already spec frameworks that do precisely this. I've been using BMAD for planning and speccing out something fairly elaborate, and it's been a blast.
I used this prompt and it suggested a model I already have installed and one other. I'm not sure if it's the "newest" answer.
> What is the best local LLM that I could run on this computer? I have Ollama (and prefer it) and I have LM Studio. I'm willing to install others, if it gives me better bang for my buck. Use bash commands to inspect the RAM and such. I prefer a model with tool calling.
The app is a local-first budgeting tool — one HTML file, no backend, no accounts, no tracking. That's the whole point. But it also means there's no server to check a license, no account to suspend, and no technical way to prevent copying. This is the story of choosing shareware-style trust-based monetization instead of DRM.
Yup, me too. In fact, I might consider simple copyright for something like a board game. Granted, I’ve never registered an actual copyright either. I suppose I should try it out.
reply