heavymemory

always blue

ai written

Prompt injection is the same problem all agents face, ChatGpt Atlas, claude cowork, openclaw, all of them. It's a known unsolved problem across the industry.

I mitigate it by giving the agent a fixed action set (no scripts, no direct API calls), and breaking tasks into focused subtasks so no single agent has broad scope. The LLM prioritises its own instructions over page content, but if someone managed to hijack it, the agent can interact with authenticated sessions. Everything's visible in real time though, and all actions are logged, so you can see exactly what it's doing and kill it.

Practically speaking, I use it similar to how people use Zapier or n8n, you set up specific workflows and make sure you're only pointing it at sites you trust. If you're sending it to random unknown websites then yeah, there's more risk.

But even then, an attacker would need to know what apps you're authenticated with and what data the agent has access to. The chances of something actually happening are pretty low, but the risk is there. No one's fully solved this yet.

Interesting. Part of why I built this was to avoid screen capture as the control layer. Once you’re taking screenshots, guessing what to click, moving the mouse, and repeating, it gets slow and brittle fast. Here the workflow is just described in text, executed in the browser, and saved for reuse.

Yeah, instruction drift is a real problem in long agent chains. In this case the workflow gets decomposed into steps up front and each step is executed by a separate sub-agent.

So the model isn’t carrying the whole instruction chain across multiple steps, it’s just solving the current task. Similar pattern to what tools like Codex CLI or Claude Code do.

linux and windows support is on the way, i’ve designed it in a decoupled way, so should be straight forward.

Just need to see if people find this version useful

I audited 3 vibe coded products that were posted on Reddit in a single afternoon. All three had critical security vulnerabilities. One was a live marketplace with real Stripe payments where any logged-in user could grant themselves admin and hijack payment routing with a single request. Another had development endpoints still in production that let anyone mark themselves as a paid user and give themselves unlimited credits. The third had its entire database of 681,000 salary records downloadable by anyone with no authentication at all.

I wasn't looking for these. They appeared in my feed. I signed up as a normal user and opened dev tools

This isn't another 'AI bubble bad' post. The article traces a specific financial contagion pathway that hasn't been covered elsewhere in a single piece. Tech companies are moving hundreds of billions in AI debt off their balance sheets into special purpose vehicles. That debt gets rated investment grade, securitised, and sold to pension funds and insurance companies. The Bank of England's December 2025 Financial Stability Report explicitly flags this as a financial stability risk, comparing AI valuations to the dot-com bubble. Mercer, the UK's largest pension advisor, is warning defined benefit schemes about concentration risk and comparing the situation to the early 2000s telecom bust. The collapse-relevant point: nobody can actually quantify how much pension money is exposed, because the entire structure is designed to be opaque. When AI revenue projections fail to materialise, the debt doesn't disappear. It sits in the retirement savings of ordinary workers who have no idea they're exposed. The article traces the full chain from SPV creation to bond index to auto-enrolled workplace pension. This is a documented mechanism by which a tech correction could directly degrade the material conditions of millions of people.

DHH argued Facebook couldn't monetise. I'm not arguing Anthropic can't monetise. I'm arguing the debt structure financing AI infrastructure creates systemic risk regardless of whether individual companies succeed. Cisco survived the dot-com bust. The bondholders who financed the fibre didn't

This still seems like gradient descent wrapped in new terminology. If all learning happens through weight updates, its just rearranging where the forgetting happens

The idea is interesting, but I still don’t understand how this is supposed to solve continual learning in practice.

You’ve got a frozen transformer and a second module still trained with SGD, so how exactly does that solve forgetting instead of just relocating it?

Do you have a source for the NVIDIA “diffusion plus autoregression 6x faster” claim? I can’t find anything credible on that.

This started as a small experiment in structural rewriting. The basic idea is that you give the system two or three before and after examples, press Teach, and it learns that transformation and applies it to new inputs.

It is not an LLM and it is not a template system. There is a small learned component that decides when a rule applies, and the rest is a deterministic structural rewrite engine.

There are a few demo modes:

TEACH: learn a structural rule from examples COMPOSE: apply several learnt rules together TRANSFER: use the same rule in different symbolic domains SIMPLIFY: multi step rewriting CODEMOD: for example you can teach lodash.get to optional chaining from two examples

Once a rule is learnt it generalises to inputs that are deeper or shaped differently from the examples you gave. Everything runs on CPU and learning happens in real time.

Demo: https://re.heavyweather.io

If anyone saw odd behaviour just now in the demo, that was my fault. One of the codemod rules was leaking into the shared rule registry instead of being scoped to the current user. I have isolated that and it should be fixed.

The core engine was not affected. The issue was simply that a user taught rule was visible to other demo modes, which made it fire that rule everywhere.

If anyone notices anything else strange, let me know. It should behave normally now.

Right, associativity is the simplest case because the structure is visible directly in one example.

The system needs multiple examples when there is more than one varying part and a single example is ambiguous. A simple example is wrapping a function call. With:

    doThing(x) → log(doThing(x))
    process(y) → log(process(y))

the system learns that: the function name varies the argument varies he outer log(…) is constant

From that it infers the general rule and applies it to new inputs. A single example would not be enough to disambiguate that pattern.

Thanks, i'll try and publish something soon.

6th time in the last year that this was posted, apparently

I think primarily in structures, spaces, and transformations. Language tags along afterward.

If thought needed words, you’d be unable to think of anything you can’t yet describe