This post is an edit and repost of my rant from Bluesky

Some problems with vibe coding

Having done a lot of vibe coding lately, I think I’ll move away from it (for now) as a primary approach to build any software that I care about, even a little bit. Current agents eventually fail to adhere to some prompt despite various attempts and approaches. Whenever this happens and I look in the codebase I am usually mortified by what I find.

Goose is a CLI language model-based agent. Goose exposes a chat interface and uses tool calling (mostly to invoke shell commands) to accomplish the objective prompted by the user. These tasks can include everything from writing code to running tests to converting a folder full of mov files to mp4s. Most things you can do with your computer, Goose can do with your computer.

Goose runs most commands by default. Some other tools call this “YOLO mode”. If this approach concerns you, you may want to prompt Goose to let you know before it runs commands (this approach does not substitute for running the tool in an isolated/containerized environment). You ultimately never know what an LLM-based tool will actually run when given access to your system.

Today, I set out to add an llms.txt to this site. I’ve made a few similar additions in the past with raw post markdown files and a search index. Every time I try and change something with outputFormats in Hugo, I forget one of the steps, so in writing this up, finally I’ll have it for next time.

Steps

First, I added a new output format in my config.toml file:

[outputFormats.TXT]
mediaType = "text/plain"
baseName = "llms"
isPlainText = true

Then, I added this format to my home outputs:

Today, Anthropic entered the LLM code tools party with Claude Code.

Coding with LLMs is one of my favorite activities these days, so I’m excited to give it a shot. As a CLI tool, it seems most similar to aider and goose, at least of the projects I am familiar with.

Be forewarned, agentic coding tools like Claude Code use a lot of tokens which are not free. Monitor your usage carefully as you use it or know you may spend more than you expect.

An LLM stop sequence is a sequence of tokens that tells the LLM to stop generating text. I previously wrote about stop sequences and prefilling responses with Claude.

As a reference, here’s how to use a stop sequence with the OpenAI API in Python

from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
  model="gpt-4o",
  messages=[{"role": "user", "content": "What is the capital of France?"}],
  stop=["Paris"],
)
print(response.choices[0].message.content)

which outputs something like

'The capital of France is '

Notice the LLM never outputs the word “Paris”. This is due to the stop sequence.

I had an interesting realization today while doing a demo building a web app with Cursor. I was debugging an issue with an MCP server, trying to connect it to Cursor’s MCP integration. The code I was using was buggy, and I’d never tried this before (attempting it live was probably a fool’s errand to begin with).

When I ran into issues, someone watching asked, “Why don’t you just ask the Cursor chat what’s wrong?” This didn’t occur to me because I instinctively figured that Cursor chat (and Claude, the model powering it) wouldn’t know what was happening.

I built an Astro component called CodeToggle.astro for my experimental site. The idea was to create a simple wrapper around a React (or other interactive component) in an MDX file so that the source of that rendered component could be nicely displayed as a highlighted code block on the click of a toggle. Usage looks like this:

import { default as TailwindCalendarV1 } from "./components/TailwindCalendar.v1";
import TailwindCalendarV1Source from "./components/TailwindCalendar.v1?raw";

<CodeToggle source={TailwindCalendarV1Source}>
  <TailwindCalendarV1 client:load />
</CodeToggle>

The implementation of CodeToggle.astro looked like this

Deepseek is getting a lot of attention with the releases of V3 and recently R1. Yesterday, they also released “Pro 7B” version of Janus, a “Unified Multimodal” model that can generate images from text and text from images. Most models I’ve experimented with can only do one of the two.

The 7B model requires about 15GB of hard disk space. It also seemed to almost max out the 64GB of memory my machine has. I’m not deeply familiar with the hardware requirements for this model so your mileage may vary.