I built Signet in Go to see if an autonomous system could handle the wildfire monitoring loop that people currently run by hand - checking satellite feeds, pulling up weather, looking at terrain and fuels, deciding whether a detection is actually a fire worth tracking.
All the data already exists: NASA FIRMS thermal detections, GOES-19 imagery, NWS forecasts, LANDFIRE fuel models, USGS elevation, Census population data, OpenStreetMap. The problem is it arrives from different sources on different cadences in different formats.
Most of the system is deterministic plumbing - ingestion, spatial indexing, deduplication. I use Gemini to orchestrate 23 tools across weather, terrain, imagery, and incident tracking for the part where clean rules break down: deciding which weak detections are worth investigating, what context to pull next, and how to synthesize noisy evidence into a structured assessment.
It also records time-bounded predictions and scores them against later data, so the system is making falsifiable claims instead of narrating after the fact. The current prediction metrics are visible on the site even though the sample is still small.
It's already opening incidents from raw satellite detections and matching some to official NIFC reporting. But false positives, detection latency, and incident matching can still be rough.
I'd especially welcome criticism on: where should this be more deterministic instead of LLM-driven? And is this kind of autonomous monitoring actually useful, or just noisier than doing it by hand?
I built k-synth as an experiment to see if a minimalist, K-inspired array language could make sketching waveforms faster and more intuitive than traditional code. I’ve put together a web-based toolkit so you can try the syntax directly in the browser without having to touch a compiler:
Live Toolkit: https://octetta.github.io/k-synth/
If you visit the page, here is a quick path to an audio payoff:
- Click "patches" and choose dm-bell.ks.
- Click "run"—the notebook area will update. Click the waveform to hear the result.
- Click the "->0" button below the waveform to copy it into slot 0 at the top (slots are also clickable).
- Click "pads" in the entry area to show a performance grid.
- Click "melodic" to play slot 0's sample at different intervals across the grid.
The 'Weird' Stack:
- The Language: A simplified, right-associative array language (e.g., s for sine, p for pi).
- The Web Toolkit: Built using WASM and Web Audio for live-coding samples.
- AI Pair-Programming: I used AI agents to bootstrap the parser and web boilerplate, which let me vet the language design in weeks rather than months.
The Goal: This isn't meant to replace a DAW. It’s a compact way to generate samples for larger projects. It’s currently in a "will-it-blend" state. I’m looking for feedback from the array language and DSP communities—specifically on the operator choices and the right-to-left evaluation logic.
Source (MIT): https://github.com/octetta/k-synth
A few weeks ago I saw a post about someone converting an entire C++ codebase to Rust using AI in under two weeks.
That inspired me — if AI can rewrite a whole language stack that fast, I wanted to try building a programming language from scratch with AI assistance.
I've also been noticing growing global interest in Korean language and culture, and I wondered: what would a programming language look like if every keyword was in Hangul (the Korean writing system)?
Han is the result. It's a statically-typed language written in Rust with a full compiler pipeline (lexer → parser → AST → interpreter + LLVM IR codegen).
It supports arrays, structs with impl blocks, closures, pattern matching, try/catch, file I/O, module imports, a REPL, and a basic LSP server.
This is a side project, not a "you should use this instead of Python" pitch. Feedback on language design, compiler architecture, or the Korean keyword choices is very welcome.
Hey guys, about two months ago I started this side-project for "asynchronous coding" where I can prompt Claude Code from my mobile on train rides, get a notification when it's done and then review and commit the code from the app itself.
Since then I've been using it on and off for a while. I finally decided to polish it and publish it in case someone might find it useful.
It's a self-hosted PWA with four panels: Agent (terminal running Claude Code), Explore (file browser with syntax highlighting), Terminal (standard bash shell), and Git (diff viewer with staging/committing). It can run on a cheap VPS and a fully functioning setup is provided (using cloud-init and simple bash scripts).
This fits my preferred workflow where I stay in the loop: I review every diff, control git manually, and approve or reject changes before they go anywhere.
Stack: Go WebSocket bridge, xterm.js frontend, Ubuntu sandbox container. Everything runs in Docker. Works with any CLI AI assistant, though I've only used it with Claude Code.
Side project, provided as-is under MIT license. Run at your own risk. Feedback and MRs welcome.
EDIT: Removed redundant text
A popular philosophy in the HN community is that inventing problems to be solved by a technology is antithetical to the user experience. Much to the horror of some, I did just that to discover/invent this game.
I started with the structure of quantum com putation and asked what kind of problem benefits from it. The answer was surprisingly narrow, but this was one of the results. Enjoy!
by katspaugh ·
Look, every journaling app out there wants you to organize things into folders and tags and templates. I just wanted to write something down every day.
So I built this. One note per day. That's the whole deal.
- Can't edit yesterday. What's done is done. Keeps you from fussing over old entries instead of writing today's.
- Year view with dots showing which days you actually wrote. It's a streak chart. Works better than it should.
- No signup required. Opens right up, stores everything locally in your browser. Optional cloud sync if you want it
- E2E encrypted with AES-GCM, zero-knowledge, the whole nine yards.
Tech-wise: React, TypeScript, Vite, Zustand, IndexedDB. Supabase for optional sync. Deployed on Cloudflare. PWA-capable.
The name means "one day" in Japanese (いちにち).
The read-only past turned out to be the thing that actually made me stick with it. Can't waste time perfecting yesterday if yesterday won't let you in.
Live at https://ichinichi.app | Source: https://github.com/katspaugh/ichinichi
We built GitAgent because we kept seeing the same problem: every agent framework defines agents differently, and switching frameworks means rewriting everything.
GitAgent is a spec that defines an AI agent as files in a git repo.
Three core files — agent.yaml (config), SOUL.md (personality/instructions), and SKILL.md (capabilities) — and you get a portable agent definition that exports to Claude Code, OpenAI Agents SDK, CrewAI, Google ADK, LangChain, and others.
What you get for free by being git-native:
1. Version control for agent behavior (roll back a bad prompt like you'd revert a bad commit) 2. Branching for environment promotion (dev → staging → main) 3. Human-in-the-loop via PRs (agent learns a skill → opens a branch → human reviews before merge) 4. Audit trail via git blame and git diff 5. Agent forking and remixing (fork a public agent, customize it, PR improvements back) 6. CI/CD with GitAgent validate in GitHub Actions
The CLI lets you run any agent repo directly:
npx @open-gitagent/gitagent run -r https://github.com/user/agent -a claude
The compliance layer is optional, but there if you need it — risk tiers, regulatory mappings (FINRA, SEC, SR 11-7), and audit reports via GitAgent audit.
Spec is at https://gitagent.sh, code is on GitHub.
Would love feedback on the schema design and what adapters people would want next.