AndyJessop

AndyJessop

@andyjessop.bsky.social

Staff Engineer @ Cense

859 followers483 following511 posts

A specification is fundamentally a lossy compression of somebody’s mental model. Humans fill in the missing pieces using experience, taste, and common sense. But agents are fundamentally nincompoops. We need a different language or set of primitives to get better alignment with the machines.

A cool side-effect of coding with llms is that you don't get so attached to the code, so pivoting is easy (mentally). I imagine it would remove a huge source of friction for teams.

One thing I've recently noticed is that when vibe coding, I'm much more creative. My mind is freed from the coding detail and logical issues to think more holistically about the system. I've built much better architectures and systems because of it.

Im seeing my best results from the following strategy: - burn all your frontier model credits building out a spec that breaks it down into independently verifiable tasks - get your base model to just hammer away until completion - wait until you get more credits, then repeat.

I'm ready to say that LLMs/agents enable me to build systems that used to be far out of my normal ability. They're not just junior coder level any more - those days are gone.

If you're trying to save money on Claude/Cursor/etc. do you: 1. Get the best models to do the planning, then the cheap models to do the grunt work, or 2. The other way around.

I honestly believe that model capability has crossed a threshold over the last few months, and the bottleneck is now the humans orchestrating the bots. The focus now needs to be on generating structured product requirements and feeding them to agents.

Spec-driven development gives me better code than when I write the code manually. By starting from the spec each time, I'm forced to think architecturally from the beginning, and edge-cases are handled from the outset. I'm writing less and less code, but actually enjoying the process more.

Also, I've defaulted to Mistral initially as it's a good privacy option, but will be moving towards a hybrid model based heavily on Ollama, but with smaller models so that it can be run on small machines. Hosted LLMs will be used, but sparingly, and possibly with some obfuscation.

I think I've created the homelab version of a "useless machine". I got an old laptop, booted with proxmox, installed mosquitto, telegraf, grafana, and zigbee2mqtt, got myself a smart plug, and now I can automatically manage the battery level of the same laptop so that the battery lasts.

A bash script launched as a service measures the battery level and reports it to mqtt. I have an automation in node-red (oh, I forgot I also installed node-red) that will listen to the battery status and turn off the plug if it gets over 50%, and turn on again when it gets under 40%.

Just got fibre to the house. It's ridiculous that I can get 3+ gbps here in remotest France. They've really done so well with the rollout. France is 5th in the world for average Internet speeds. Chile is the only decently sized country above us.

This is how I'm building front-end side projects these days. I have a framework that is AI-first. In the next few posts I'll describe what makes it AI-first, and why it makes building with AI faster, less tedious, and more productive.

View full thread

To make it practical, the framework uses a "Trace Middleware." It logs every action and state change to a JSON file. If a test fails, the AI ingests this log file to replay the event timeline. Basically like a replay button for the LLM to see where it went wrong.

The goal isn't raw performance (bundle size, etc). The goal is velocity and maintainability. Most vibe-coded projects hit a wall when the code gets too complex for the LLM to understand. The framework is an architecture designed to keep the "context" clear, so LLMs can keep building correctly.

This is how I'm building front-end side projects these days. I have a framework that is AI-first. In the next few posts I'll describe what makes it AI-first, and why it makes building with AI faster, less tedious, and more productive.

View full thread

Testing is usually where AI builds fall apart. Selenium/Puppeteer are flaky and slow. The framework creates a "Headless" environment. Since the Router is just Redux state, we can run full integration tests without a browser: fast execution, 100% coverage

There is also a strict rule: no business logic in useEffect. React hooks can obfuscate logic inside the render loop, which is hard to trace for LLMs in complex apps. In the framework, logic lives in middleware. Data flow is linear. If something breaks, you (or the LLM) know exactly where it broke.

This is how I'm building front-end side projects these days. I have a framework that is AI-first. In the next few posts I'll describe what makes it AI-first, and why it makes building with AI faster, less tedious, and more productive.

View full thread

In the framework, Redux isn't just for data state - it's the whole application, e.g. routing, data, UX, UI, everything. All effects are triggered by actions. This gives the AI a serialised, step-by-step audit trail of exactly what happened and when.

This structure creates a genuine feedback loop for Agents. Usually, AI generates code and hopes it works. With Pi, because everything is deterministic, the AI can: dispatch an action > inspect the resulting state > read the error logs > Fix its own code

This is how I'm building front-end side projects these days. I have a framework that is AI-first. In the next few posts I'll describe what makes it AI-first, and why it makes building with AI faster, less tedious, and more productive.

AI-first means acknowledging that AI struggles with "magic" and hidden side effects. The framework is a set of strict conventions. • Routes are plain data. • Components are pure. • Side effects are isolated. When code is predictable, AI can read, write, and debug it without hallucinating.

The top 10 things I did this year all revolve around moving soil from one side of the property to the other, and ordering far too much Douglas Fir from the local wood merchant. Sorry I don't have anything more interesting to share. That's my 2025 wrap.

Coding with LLMs is about discovering the right level of abstraction. They're great at writing small, self-contained systems, but fail when you try to leave the details up to them. There is a sweet spot of abstraction that favours senior+ developers

You still need to know system design because you should be prompting to build the systems, not the end-to-end product. I feel like the term "vibe coding" was a mistake, because vibing it from the top is not the most effective way - it's too many levels abstractions for the LLM's capabilities.

I find that Claude/Antigravity/Cursor/etc. is much more accurate if you try to avoid having to get it to fix things. Instead, keep on committing changes and then revert any change where it's decently wrong, reword your request, then submit again.

RSCs: Where the boundary between client and server is so blurry, even the security team couldn’t tell where the attack surface began. bsky.app/profile/reac...

React@react.dev

There is critical vulnerability in React Server Components disclosed as CVE-2025-55182 that impacts React 19 and frameworks that use it. A fix has been published in React versions 19.0.1, 19.1.2, and 19.2.1. We recommend upgrading immediately. react.dev/blog/2025/12...