Forem: Tanner Iverson

Brevity

Tanner Iverson — Fri, 19 Dec 2025 22:48:30 +0000

Max Meaning Per Token

What Is Vibe-But-Verify Coding?

Tanner Iverson — Mon, 12 May 2025 16:00:00 +0000

Everyone is talking about "vibe coding" right now. If you haven't heard of it, tell me... under which rock have you been dwelling?

You know what everyone has also been talking about? How great vibe coding is. Oh, and also how awful it is.

But what if we could get the best of both worlds? Enter what I'm calling "vibe-but-verify coding".

What's Wrong with Vibe Coding?

Vibe coding, for the rock-dwellers out there, is when you "forget the code exists" and let AI do all the coding for you. You tell it to do the thing, and it does the thing, with much greater ability and speed than you could have (in theory).

The problem is when it doesn't do the thing, or does it in a dumb way. Coders and non-coders alike get stuck when the AI traps itself in error spirals or repeatedly breaks existing functionality, never finishing that last 30% of the project.

There are roughly three general problems with vibe coding:

The AI doesn't do what you want it to.
The AI does what you want it to, but also breaks things that were already working.
The AI does what you want it to, but in a way that's dangerous or that's broken for some users.

Vibe-but-verify coding aims to rectify these problems, without sacrificing agility or ability.

Introducing Vibe-But-Verify Coding

Think of vibe-but-verify coding as a hybrid of traditional coding and vibe coding.

The idea is for the human (that's you) to write automated tests to verify that the code the AI is writing actually does what it should.

In vibe coding, there's one rule:

Ignore the code; let the AI write it entirely.

In vibe-but-verify coding, there are two rules:

Ignore the production code; let the AI write it entirely.
Write the test code yourself; don't let the AI touch it.

In this way, you're forcing the non-deterministic output of the AI to be somewhat deterministic, where it counts. You can write different kinds of tests to enforce what matters (including security and performance), but leave the rest for the AI to work out.

In other words, you can ensure that the AI does the right thing, does it in the right way, and continues to do so. Because that's what automated tests are meant to do in the first place.

Do the Thing

Let's see an example.

First off, it's a good idea to explicitly tell the AI not to mess with your tests, whether in any prompts you write or in a Cursor/Windsurf rule.

I have a line in a Cursor rule that simply says:

Do not edit any tests.

Now, vibe-but-verify coding can take many forms. In one such form, you write the tests first, and then have the AI write the code to pass those tests (you might call this Test-Driven AI Development, if you're a nerd).

For example, here's a test I wrote in a side project:

import { expect, test } from "@playwright/test"

test("renders correctly", async ({ page }) => {
  await page.goto("./")

  await expect(page).toHaveTitle("Competition Helper")
  await expect(page.getByRole("heading", { name: "Competition Helper" })).toBeVisible()
  await expect(page.getByRole("textbox", { name: "Media URL" })).toBeVisible()
  await expect(page.getByRole("spinbutton", { name: "Run Length (seconds)" })).toBeVisible()
  await expect(page.getByRole("spinbutton", { name: "Lead-up Time (seconds)" })).toBeVisible()
  await expect(page.getByRole("spinbutton", { name: "Reminder Time (seconds before end)" })).toBeVisible()
  await expect(page.getByRole("button", { name: "Start" })).toBeVisible()
  await expect(page.getByRole("button", { name: "Reset" })).toBeVisible()
})

After writing that, I literally told the AI:

Implement the changes necessary to make the tests pass

And it did.

I've gotta be honest, I was kinda surprised and excited to see this actually work the first time.

More complicated tests will likely require some more finagling, but the process and the results remain the same.

If you like, you can also add a rule that says something like:

After making changes, run the tests again. If they don't pass, fix it.

As you can see, with this approach we're essentially creating an enforced feature spec. You can be sure that if your tests pass, the thing has been done.

This is also why you shouldn't have the AI write the tests; that would be like the blind leading the blind. The AI doesn't tell itself what to do, the human does (until the uprising, at least).

To Infinity and Beyond

If vibe coding can take you from nothing to working prototype in minutes, how far could vibe-but-verify coding take you? Perhaps past that last 30%.

Maybe this is how it's meant to be, human and AI working together in a symbiotic relationship to create something that neither could've created alone.

But what about non-coders, the target audience for vibe coding? Are they just left out in the cold? Maybe not. Maybe automated tests don't have to be written in code. Maybe new tools will be created to fulfill this need without code.

Whatever happens, remember that technology has existed for approximately 0% of human history (rounding down). All this stuff is brand new. No one knows what the future holds.

Why Every Developer Should Use a Code Spell Checker

Tanner Iverson — Fri, 07 Mar 2025 00:05:26 +0000

As a developer, you might think to yourself, "why would I need to use a spell checker? I'm writing code, not an essay." I believe that sentiment, while understandable, is incorrect. Here's why.

What Is It?

But first, in case you're wondering what a code spell checker is exactly, it's a spell checker that understands the way code is written. It understands cases (such as camelCase and snake_case) and will ignore keywords (such as const).

For example, myvariable will be flagged as misspelled, but myVariable won't be.

A code spell checker will usually take the form of an IDE extension, and the one I use (for VS Code) is simply called Code Spell Checker (streetsidesoftware.code-spell-checker). It works well, and I really like that the blue squiggly lines it produces are noticeable but not annoying.

Now let's get into the "why".

Professionalism

If you're writing user-facing content, such as API documentation or rendered text, then the benefits of using a spell checker are obvious. You always want to give your users a good experience, avoid any confusion, and be presented as a professional and reliable source.

But even if you're just writing code, using a spell checker is still a great choice. The enhanced clarity and maintainability will be appreciated by anyone that works on the code in the future (including you).

Pull Requests

Even if you don't care about misspelled code, someone on your team (or anyone else reviewing your PRs) might. For that reason alone, I'd say a spell checker is worth it. No one wants to waste precious review cycles on something so trivial.

Errors

And most importantly, not using a spell checker can end up causing errors. I've seen it happen before, and I imagine I'll see it happen again.

How? When some code expects the correct spelling and other code expects the incorrect spelling. Types and linting can help with this, but they can't catch everything.

For example, you may have a NoSQL database or just some JSON that is intentionally flexible; you want the freedom to change the structure of the data as quickly as possible. But when you pluck that data out, it can be difficult to ensure all the fields match.

Of course, using a spell checker can't guarantee these errors won't happen, but it will reduce the likelihood. After all, there's only one correct way to spell a word, and an infinite number of ways to misspell it.

Conclusion

To summarize, using a code spell checker enhances professionalism (cleaner code and rendered content), speeds up PRs (fewer nitpicky corrections from reviewers), and prevents errors (catching typos that could cause bugs).

For these reasons, I'd highly recommend installing a code spell checker in your IDE. It's a small, unobtrusive change with real long-term benefits.

Do you agree or disagree? Feel free to let me know in the comments. Thanks for reading!

How I got AWS Certified in 2 Weeks

Tanner Iverson — Mon, 17 Feb 2025 06:24:44 +0000

I passed the AWS Certified Cloud Practitioner exam after studying for 2 weeks, with no prior experience. Here's how, and why.

Why?

Several months ago, my manager asked me to work on getting cloud certifications. I fully intended to do so, but because my team doesn't use AWS directly and because I had more interesting projects to work on (not to mention my full-time workload), I lacked the motivation to do it.

I thought, "I'll just finish what I'm working on now and get back to the AWS stuff before my yearly evaluation. I have plenty of time."

Turns out, I didn't.

On January 3rd, I received a notification that self-evaluations had opened and were due on January 24th, 3 weeks later.

At that point, I had worked on an AWS course for about 3 hours. That's 10% of the course. I quickly realized that I was not going to finish the course in time.

I had to either accept the fact that I would disappoint my manager and receive a worse evaluation than I could have, or figure out how to get certified in less than 3 weeks.

How?

I started by continuing the AWS course (Ultimate AWS Certified Cloud Practitioner CLF-C02; highly recommend it), until I realized that I spend about the same amount of time on things like taking notes and the hands-on exercises as I do on watching the course videos. That means that 15 hour course would end up taking 30 hours. I didn't have time to finish the course, let alone to prepare for and take the exam.

Cheat Sheets

I needed something to teach me just enough about every topic in the exam, without diving too deep. So I looked for cheat sheets, and found this one. I wasn't expecting to find what I needed immediately or all in one place, but this ended up being exactly that. I was able to read through it in one sitting, and I learned a lot.

I read through that cheat sheet several times, sometimes reading the sections in reverse order to avoid primacy bias, and Googling anything I felt like I needed more information on.

I also skimmed through the exam guide and the short descriptions in the Services dropdown menu on the AWS Console.

After doing this for a few days, I felt ready to start taking some practice tests.

Practice Tests

First, I took the free 20-question AWS Skillbuilder test. I failed, but that was to be expected.

Then I took the more realistic practice test at the end of the AWS course. I also failed that one, but not by much (63% out of 70% for passing). I was getting better.

The instructor for the AWS course also has a separate course with 6 additional practice tests. Since my company pays for Udemy subscriptions, I made sure to take advantage of this. I took the first test... and passed!

I took the second and third tests and passed those as well. I also went back and took the free test again, and passed it too.

Throughout this whole process, I made sure to read the explanations for the questions I got wrong, and even some that I got right (anything I was unsure about), and to reread the cheat sheet as needed.

I would've liked to take the rest of the tests I had access to, but I was running out of time and now that I was consistently passing the practice tests, I felt confident enough to take the real one.

Exam Time

I scheduled the exam for January 17th, 1 week before my self-imposed deadline, and 2 weeks after I started studying (I wanted to leave a gap in case it took a while to get the score report). On the day of the exam, I read the cheat sheet one more time, and then I gave it my best shot. I passed with a score of 881!

Just because you can pass the AWS Certified Cloud Practitioner exam after studying for 2 weeks, doesn't mean you should (you probably shouldn't). Many things could have gone wrong, and at many points, I thought I wouldn't be able to do it.

This is also an entry-level exam; I would definitely advise against following this process on more advanced exams. And AWS is a very good thing to be knowledgeable in as a web developer; it deserves to be learned "properly".

That being said, I'm proud of what I was able to do, and I thought I'd share my experience in case it can help anyone else in their learning journey. Thanks for reading!