Home on Programming, But Relatable

Trust your experience

Sat, 04 Jul 2026 00:00:00 +0000

Simon Willison has become a SME darling for AI in software engineering. He wrote a blog post about how he feels that “vibe coding” and “agentic engineering” are blurring in his usage of AI, but I think the most interesting part of his post is this:

“And now I’ve got that feeling of guilt: if I haven’t reviewed the code, is it really responsible for me to use this in production?”

As a hobby, I play fighting games a bit more deeply than the average person: I go to tournaments, review my own gameplay, and seek counsel from better players on how to improve. I may not have 25 years taking fighting games seriously like Simon has developing software, but I’ve spent far longer than the average software developer doing so.

Some time ago, I sought the advice of a well-known player on how to handle opponents of a certain skill level with antsy or anxious playstyles. We reviewed a match I had against such a player, and he noted that when I chose aggression versus my knocked-down opponent, I would get the strike I sorely needed in order to win, but fail to turn it into another knockdown or a knock-out.

He expanded on that by saying while I was paying attention to the game, I wasn’t focused on the outcome of my aggression in those moments. I had already done the hard part of getting the information about my opponent’s behavior when they’re knocked down, but I was on autopilot: in those aggression situations, I had failed either to trust in my experience or not process the prior interaction at all.

I think AI tools are useful. I’ve grown fond of being able to block out larger tasks into smaller ones and hand them off to an agent while I review code, do research, or work on a more complex task. I like the notion of finally being able to delegate small fixes and other codebase improvements to a little genie in a terminal.

I also think that developers often forget that AI tools are tools. A coding agent is not conscious. A coding agent does not have prior experience. A coding agent has never experienced losing a game because it failed to block an opponent’s “get up” attack. A coding agent has never wrestled with the age old task of “how do I use this modern functionality in this older system?”

The prompts we provide to agents provide them with the experience we’ve gained over the years as developers. That experience doesn’t just come from the corpus of publicly available code, but from the experiences we have interacting with other people.

We navigate debates and strong opinions in pull request comments, meetings with teammates too passive or argumentative, the anxieties of team leads and product owners, the “just one more change” requests from a business-side team.

We wait patiently for other developers to reply to our messages about code they previously worked on. We wrestle with the decisions made by maintainers of third-party libraries and how we can write good code with what we’re given.

The result of all these interactions become our guidelines for the code we write: past, present, and future. An agent writing the code based on a prompt you wrote is the result of your natural language and your understanding made manifest.

It is an extension of yourself, which makes it your responsibility. If you don’t review that code, you are on autopilot: you are not focused on the outcome of your prompts.

You’ve done a lot of hard work over the years to accrue the experience you have. Don’t go on autopilot now.

Your browser does not support the video tag.

Thoughts on agentic development, February 2026

Sat, 14 Feb 2026 00:00:00 +0000

Earlier in the month I ended up purchasing a subscription to Github Copilot Pro, it’s (currently) $10/month. I wanted to try and replicate what a coworker was doing with agentically developing a board game; introduce “vibe coding” into some of my more creatively-focused workflows.

I have a gaming blog where I chronicle stuff and I wanted a nice solution for pop-up modals that worked with Jekyll. Trying to generate an entire modal with the free tier was doable, but required a lot of guiding and inevitably didn’t work exactly as I wanted it to: the anchor tag that would launch the modal would push all text following it to a new line no matter what, and the agent wasn’t good at debugging this.

I tried again today with the Paid Option™️ and with a little coaxing I got something I wanted. The first go was a bit disastrous where the modal would just be a opaque black box superimposed over the blog sidebar and some of the content, but when I told the agent to revise its approach, it finally got something that was both functional and looked good. The agent had to parse through the various subdirectories, which it didn’t do the first time, and it looks like that made all the difference.

I tried to have the agent extricate the inline CSS from the include, but this ended up breaking its work. I had it investigate why this was the case, and I was kind of surprised it was able to grep the answer. This is a Jekyll blog so this is a very repeatable “thing”. When the agent moved the CSS it generated into a Sass file, there were two issues:

Two media queries to forcibly keep the modal + popup on top of the blog content vs the sidebar were conflicting with CSS/Sass load order
The extracted-to-Sass-file styles weren’t being imported to the Sass files that were being transpiled into CSS; they were imported into index.css/sass, but required an import into another Sass file used exclusively for the blog posts

The agent fixed the latter point and I instructed the agent to remove the media queries in the former point.

Having it extract the JavaScript was much easier, but one thing I’ve noticed is that the agent will always take the easiest path to its detriment: I told it to “Extract the JavaScript from the video modal include” and it did a copypaste job where it made a new .js file, copypasted the JavaScript from the include into that file, updated the script tag to source it, and then “make sure the JS file [was] in the right location”.

It didn’t account for the fact that it was going to break the JavaScript because Jekyll passes information to the include via variables and once the JS leaves the include, all those variables are going to be missing. The agent realized this after I refreshed, saw the modal was broken, and prompted the agent to review the .js file again.

Last thing I did for this session was have it spit out some documentation on how to use the modal include; I want to use this a lot and I may want to use it more than once in a post. It did a pretty good job documenting usage and how I arbitrarily decided upon mp4 and webm file types as its “supported” files because I try to use webms as often as I can with online pages.

The “complete example” it gave was actually really bad because it forgot how to use its own modal: it created two links for the modal pop up but forgot that it needed to use multiple includes in order to differentiate the modals. This could probably work if I had the agent refactor the include and accompanying JS, but I just deleted this part of the documentation. I also deleted the entire “Tips” section where it said where to put videos, account for file size, etc., because I know about that already. The agent is just covering all of its bases and assuming this is documentation “for everyone”.

It wasn’t a perfect landing on Github Pages: the modal broke just like it did locally when I had the aforementioned CSS/Sass issues. I had the agent look up why Jekyll includes would run into CSS/Sass issues like this, and I got back a lot of results that were reasonable to parse but also kind of sparse. It was like reading google results and going “well I guess I better go look that up now”. The number 1 reason, “Safe Mode Restrictions”, is the likely culprit where there are probably restrictions in terms of what custom CSS/Sass I can have the agent add. I feel like I’m going to have to find a GH Pages + Sass SME just to find out why this works because my own google searches have not been fruitful.

I had the agent go back to using inline CSS and it worked on GH Pages.

Some closing thoughts:

I also added an AGENTS.md file + a starting skill for creating future includes to my gaming blog and I’ll update these as I tweak the blog more to my liking.
I’m simultaneously impressed and unimpressed with agentic development. I like that it actually made something that worked, but it left me with more review work to do.
My CSS isn’t great but the entire point of having a Jekyll blog is that it’s supposed to remove a lot of the heavy lifting of building & maintaining the HTML + JS + CSS and enable me to just focus on the important part: writing. I think if I do a web project in the near future I’d try to do the CSS by hand and study it myself. For something like this, I’m ok with the agent knowing more about it than I am.
I think a “project” like this is a great use case for agentic development. Based on how I interact with the agent on something like this, I don’t think the actual education and learning how to do [x] in HTML, CSS, JS, etc. can or should go away. It’s impossible to get the most out of an agent if you don’t know enough about what you’re looking at.

Thoughts on agentic development, January 2026

Fri, 02 Jan 2026 00:00:00 +0000

AI’s taking the development world by storm, and one of my thoughts as 2025 ended was that I should start recording my experiences with AI: agentic development, tooling, experiences of other devs, and so on. This will be the first in some number of posts that I manage to carve out time for. All of these types of post will be stream-of-consciousness in the moment.

Used Cursor today to generate unit tests for the main wrapper class for CurrenSee; all I really wanted it to do was generate some constructor tests and nothing more, and it did just that. I used Cursor’s auto mode to select a model so I’ll never know what model it selected, but based on how verbose and thorough it was and its usage of checkmark emoticons, I’m assuming it’s either Gemini or Sonnet. It consumed the AGENTS.md file properly and knew where to look for test creation guidelines (“Read src/test-creation.md”), and it took at look at everything relevant: the main wrapper class, its interface, the endpoints, the test project, etc.

Steve Kinney posted this article on Cursor models in September 2025, really high level but summarizes what the different models are.

It pointed to the LatestExchangeRateEndpointTests.cs file saying that there were test guidelines in there, but nothing was actually implemented in that file. It was just the typical NUnit boilerplate that’s generated with every new test class. This was a little weird and it’s probably a hallucination? Didn’t like how strange this was.

I was pleasantly surprised that it followed the instructions in the markdown file perfectly and followed some of my personal preferences, i.e. it created the Arrange-Act-Assert comments and treated them as sections, and if Act and Assert were the same operation, it wrote the comment as “Act & Assert”.

I didn’t like how it considered “proper coverage” splitting up an “invalid api key” test into a test for a null input, an empty string, a whitespace string, a string with a tab character, and a string with a newline character. It seemed to consider the volume of tests worth it, meanwhile NUnit supports TestCase attributes right out of the box and this could have been one test method. Considering the agent knew via the AGENTS.md file that the project was using NUnit and it’s all just pattern matching & linear algebra (go look at the NUnit docs and find something like “parameterized test method”), this feels somewhat like a dealbreaker: I shouldn’t have to tell NUnit that common library functionality exists.