A.I. with Coffee or Tea https://fterry.su.domains/ Notes and tips from people working this out at work. Yours welcome too. en-us Tue, 29 Sep 2026 00:00:00 GMT Before You Build Anything With A.I., Write Down What Right Looks Like https://fterry.su.domains/posts/write-down-what-right-looks-like https://fterry.su.domains/posts/write-down-what-right-looks-like Tue, 29 Sep 2026 00:00:00 GMT Forrester Terry A.I. is great at making things that look finished. It can't know what right means for your work. Three hand-written examples, written before anyone prompts, fix most of that. ai process requirements developers The team meets. Everyone is excited. Someone opens a chat window and types "build us a dashboard that tracks our renewals." Twenty minutes later there is a dashboard. It has charts. It has a dark mode. It looks amazing.

Then the person who actually handles renewals every month looks at it and says, "That number is wrong."

Nobody can say why and nobody wrote down what right was supposed to be.

Two-panel cortisol meter meme. Left, blurry and shaking, "Me Not Having Requirements Doc" with the needle pinned at high. Right, calm and sharp, "Me Having Requirements Doc" with the needle at low.

Why this step matters so much

A.I. is really good at making things that look finished. That's the magic, and it's also the trap.

What it can't do is know what "right" means for your work. It doesn't know that a charge on the 3rd is normal but a charge on the 30th means someone forgot to cancel. It doesn't know which column in the export can't be trusted. You know that, or someone on your team does.

That knowledge is the most valuable thing your team brings. Getting it out of people's heads and onto the page before anything gets built is where most of the win comes from.

What it looks like in practice

Say the project is tracking software subscriptions. You have a list of what your team pays for, and a card statement of what actually got charged. The goal is to catch surprises.

Before anybody prompts anything, write three examples by hand.

A normal one. "Design tool, $15 a month, charged on the 5th, matches the list. Nothing to flag."

A wrong one. "Survey tool. The list says $20 a month. The card says $340. It renewed annually at a new price. Flag it."

A weird one. "A $9 charge from a vendor nobody recognizes. Not on the list at all. Flag it and find out who owns it."

Three examples, ten minutes. Now you have something to hand the A.I., and something to check its work against. When the tool says "everything looks good," you can run your three and know whether that's true.

The weird one is usually the most useful. It's where the real work lives, and it's the case the A.I. may quietly skip.

Tips for getting started

1. Start with a small slice of real data. Twenty rows beats twenty thousand. You can read twenty rows yourself and spot what the A.I. gets wrong. Stick to data and tools you're allowed to use, and leave out anything sensitive you don't need.

2. Write your examples before you prompt. One normal, one wrong, one weird. If you have issues here, you may need to spend more time sorting your data and approach. That's a great thing to find out on day one instead of week three.

3. Decide what "wrong" looks like. One sentence is enough: "This is wrong if a charge shows up that isn't on the list." I wrote more about this in Checking A.I. Work is Hard. If you can't name what broken looks like, you'll end up with misleading results.

4. Pick the smallest version that helps someone next week. Skip the full vision for now. Find the one piece that would save somebody real time on Monday. A spreadsheet of flagged charges is a win. The dashboard can come afterwards.

5. Let the person who knows the work be the judge. On a mixed team, the most important person in week one often isn't the one writing code. It's the person who can look at an output and say "that's wrong, and here's why." If that's you, everyone on the team will need you.

6. Make the A.I. ask questions first. Give it your sample and your examples, and tell it not to build anything yet. Let it interview you. The questions it asks will show you what your team hasn't decided.

Three-panel comic of a cartoon dog. Panel one: "Time to develop?" Panel two: a hand reaches in and the dog frowns, "No". Panel three, the dog looking stern: "Answer open questions first".

Tips particularly for developers

Turn the examples into tests. Your team's hand-written cases can become your first test fixtures. Every change then gets checked against what the team said right looks like.

Don't let the agent edit the examples. Keep them in their own file and mark it read only. If a test fails, the code is likely wrong, not the example. Agents love to "fix" a failing test by changing what it expects.

Add an example every time something surprises you. Every bug the domain expert catches becomes a new case. By the end of the project you have a real test suite written by the people who know the work best.

Prove the logic before the interface. A small script that reads the sample and prints the flags is a great first deliverable. Once the flags are right, the UI is the easy part.

Wrapping up

The tools keep getting faster at building. Knowing what right looks like is still on us, and it's the part that makes everything else worth building.

So before your team opens a chat window this week, grab a whiteboard, pull twenty rows, and write down three examples. It takes 10 minutes, and will be very worth it.

Good luck to everyone kicking off something new.

Example prompts

Before you start 

Here is a small sample of our data and three examples of what correct
output looks like, including one that should be flagged. Do not build
anything yet. Read everything, then ask me the questions you need
answered to get this right. Ask them one at a time.
Here is what we want to build: <one or two sentences>. What is the
smallest version of this that would still be useful to someone next
week? What would we leave out, and what would we lose by leaving it out?

Writing your examples 

Here is a sample of our data. Help me write examples of correct output:
one normal case, one that is clearly wrong, and one edge case that is
easy to miss. Don't guess at our rules. If you are not sure how a case
should be handled, ask me.

Before it builds 

Before you build anything, restate in plain language what "done" means
for this project, and list how each of my examples should come out. If
anything I've told you conflicts, point it out.

After it says it's done 

Run my examples through what you built and show me the result for each
one next to what I said it should be. Do not change the examples. If
any don't match, tell me which ones and why.
What kinds of cases did my examples NOT cover? Give me three new
examples I should add, and tell me how you currently handle each one.

For developers 

Turn examples.md into test fixtures. Treat examples.md as read only.
If a test fails, fix the code, never the expected result. If you think
an example itself is wrong, tell me instead of changing it.
]]> 26 Ways to Use Coding Agents for Non-Coding Tasks https://fterry.su.domains/posts/using-coding-agents-for-non-coding-tasks https://fterry.su.domains/posts/using-coding-agents-for-non-coding-tasks Tue, 15 Sep 2026 00:00:00 GMT Forrester Terry Cloud bills, app store releases, marketing videos, a broken headset, and a road-trip playlist for my mom. Here are 26 things I actually use my coding agents for. ai agents productivity operations Most people think of coding agents as tools for just writing code. But they can be effective for a lot more than that! If it has a command line, an API, or a screen, a coding agent can usually operate it.

For this post I figured folks could jump around and look at what they find interesting. There is a quick table of contents below to let you select what you want.

In this post

How I found these examples

1. Digging through my own agent history

To write this post, I asked Claude Code to go find the examples for me. Seven agents ran in parallel and swept 356 project folders, 6,818 of my past prompts, and the job history from FOREMAN, a tool I built to run coding agents unattended. They came back with about 80 examples.

This post counts as example 1, haha! Here are the other 25 worth sharing.

Cloud, money, and store ops

2. The cloud spend report

I asked for an expense report across all of my team's Google Cloud projects: what we aren't using that still costs money, what we could scale down, and what is expensive but actually used. I told it to use the gcloud CLI and to MAKE NO CHANGES. It swept every project my account could see, read-only, and wrote it up. The headline: about 59% of the spend it could identify was Cloud Run instances kept online 24/7 and sitting almost entirely idle. I then had it rewrite the report for leadership and link it from the ticket. (NOTE: using a Read Only Service Account and env isolation is best when allowing an LLM to drive your cloud infra. We don't want boo-boos...)

A terminal-style card. The prompt asks for an expense report across the team's Google Cloud resources using the gcloud CLI, in capitals: MAKE NO CHANGES. The agent replies that it ran a read-only sweep, that about 59% of identified spend is idle Cloud Run instances, and that it saved the report.

3. Publishing a game to the App Store and Google Play

For my game MagLava, the agent found the store credentials I had staged in Keychain, filled in the store listings in seven languages, uploaded builds to TestFlight and Google Play testing, and pushed the signing certificates into CI. It also rendered 126 localized screenshot cards, a trailer, and an App Store preview. The release notes it keeps are nice.

Seven App Store screenshot cards for the game MagLava, side by side, each showing the same level with its caption translated into English, German, Spanish, Japanese, Portuguese, Turkish and Chinese.
Watch on YouTube
An excerpt of the MagLava release log: the Apple build is valid and beta approved on TestFlight, Google Play open testing is configured but public availability is not confirmed, and store information is saved in all seven game languages.

4. Setting up subscriptions through admin APIs

For my food tracker app, it used the RevenueCat and Google Play admin APIs to create the subscription plans: monthly and annual, with a 7-day trial. It did a dry run first, because Play base-plan IDs can never be reused once created. Along the way it noticed RevenueCat was still on sample settings, which would have made Pro silently fail.

5. A cost-per-user model

For the same food tracker app, it built a cost-per-user model from real usage, noticed billing export had never been turned on, and changed one Cloud Run setting that took the idle cost from about $37 a month to about $0.05.

Media production

6. A marketing kit for my food tracker

A hero video, three short clips, captions, 23 generated food photos, Play Store screenshots, and a feature graphic. The pipeline writes the narration first (Gemini text-to-speech), so every on-screen action is held exactly as long as its voice-over. Playwright drives the app at phone size, Remotion puts the footage in a phone frame, and ffmpeg mixes in a music bed. Everything is captured from a seeded demo account, so no real user data shows up anywhere. It did however use a really old TTS model, so it sounds bad.

Watch on YouTube
A grid of 18 of the generated food photos: avocado toast, banana pancakes, salmon and rice, chicken tacos, lentil soup, pepperoni pizza and more.

7. A demo video set, rendered around midnight

For FoFo Care, a Mac help app I built a while ago, the agent recorded the real packaged app, generated narration, captioned it with Whisper, composited it in Remotion, added music, and checked its own output. It even left notes on bugs it ran into while recording. OBS was installed, but it chose not to use it. It captured the app window through Chrome DevTools instead, which needs no screen recording permission and keeps desktop clutter out of the shot.

Watch on YouTube

8. A commercial from six clips and a jingle

For "Robots Save The Call," it mapped the song's beat (120.96 BPM) and cut on it, generated four voiceover takes and checked each one by transcribing it back, then rendered nine versions across aspect ratios. Here is the full ad.

Watch on YouTube
The same frame of the commercial in three aspect ratios side by side: a cheerful blue robot with a headset floating among colorful phones, captioned "Answers 24/7 so you don't have to".

9. A band that doesn't exist

One FOREMAN job, $3.90: a made-up band called Saltline with a persona, lyrics, four songs, cover art, and a website.

The Saltline band website: four musicians standing on a misty beach at dusk under the band name, the tagline "Songs for the long way home," and a Play the EP button.

A note on the music: the four tracks on that site are 30-second instrumental clips from Google's Lyria model, and honestly they are... not the best yet (getting there). The good stuff came later. Here is "Super Quick," a full song I made for the band with Suno:

10. Recording gameplay with OBS

I made a StepMania song pack out of my own songs using A.I. and wanted a gameplay video for each one. I asked if it could automate it: open the game, play each song on Hard, and have OBS record. I set up the OBS scene, told it to go, and 13 videos landed about two minutes apart, each chart played by the game's AutoPlay.

Watch on YouTube

Eyes on the screen

11. An unattended UX review

I told the agent I needed a general test and UX review of my app's pilot build, to work as autonomously as possible, and that OBS was set up if it wanted to record. It drove the real packaged app with Playwright over six passes and came back with a prioritized bug list, 14 annotated screenshots, and a two-minute walkthrough video. A couple of the finds I would not have caught quickly: the chat invented a fake technical reason when a tool was behind the paywall, and a confirmation dialog showed text that was written for the LLM, not the user.

The OBS part: it tried OBS first. OBS pulled in desktop clutter and audio, and one of its automation calls crashed OBS outright. So it switched to recording the app window through Chrome DevTools, on its own. The same tool that worked great for gameplay was the wrong tool here, and the agent figured that out without me.

A bug screenshot from the UX review: the chat assistant gives an invented technical reason for a failure instead of saying the tool requires an upgrade.
A bug screenshot from the UX review: a confirmation dialog for a destructive tool shows prompt text that was written for the LLM.
Watch on YouTube

12. Vision-driven testing

This one has been a long time coming. I have been chasing vision-driven testing for a while: started as a screen-grid experiment with a local vision model, now an auto-tester that screenshots the screen, lets Gemini pick the next click, and handles native macOS dialogs a browser driver cannot see. The goal every time has been the same: download one of our work apps and run it to completion.

The manager's copilot

13. Launches: before, day-of, and after

I have started using agents at all three points of a launch.

  • Before: For my food tracker, I asked "am I actually ready to launch this thing?" and had it check the marketing site, app, backend, security, payments, and deployment, then save findings to a file. My favorite part: it later corrected one of its own findings ("My original finding was wrong on the facts") after checking the actual database.
  • Day-of: At work, the morning we rolled out a new feature, I asked it to check recent logs and tell me how it was going for folks. READ ONLY. It queried the logs and database, built an HTML report, and screenshotted it so I could share it.
  • After: When one of my side projects hit v1, I asked it to look at all my git commits and all my Claude chats for the project and figure out how much development time went into it.
The top of the FoFo Food Tracker launch readiness audit, written by Claude: a P0 remediation table listing items like "Legal docs named the wrong payment processor" and "Alerting could not fire", each marked fixed or closed.
A terminal-style card. The prompt says a feature just rolled out and asks for a read-only check of recent logs. The agent replies that it queried Cloud Logging and Firestore, covered adoption, latency and errors, and built an HTML launch report with a screenshot to share.

14. How our team's work actually flows

I asked it to use six months of git and Jira history to answer three questions: how long does it take us to get work done, how much carries over from sprint to sprint, and is our pace sustainable? It built an HTML report. I cannot show the real one, so the chart below uses made-up numbers for what most teams see: most of a ticket's life is spent waiting, not being worked on.

An illustrative stacked bar chart with made-up numbers titled "Most of a ticket's life is spent waiting." For all teams and Teams A, B and C, waiting in backlog takes 58 to 74 percent of elapsed time, with in progress, review and test, and blocked making up the rest.

15. The stray K

We started getting alerts that users were having issues. On day one, the agent traced it to a vendor service being down. On day two, the same alerts came back. I asked it to check if the vendor endpoint was up, without posting to it or authenticating. It was healthy. So it pulled the deployed source from the storage bucket and found a single stray K character in one file. That threw an error inside a success handler, the error handler swallowed it and reported failure, and the vendor call had actually succeeded the whole time. It was live for about 12 minutes. I had it write up the incident for our lead developer.

A terminal-style card with names stripped. The prompts ask the agent to check whether the vendor endpoint is up without posting or authenticating, then why the error alerts keep firing. The agent replies the endpoint was healthy, a stray K in the deployed copy of one file threw inside a then handler that the catch swallowed, and the vendor call had actually succeeded.

16. A kernel vulnerability, checked and patched

When a Linux kernel vulnerability was announced, I asked if it affected any of our stuff, read-only. It checked across our projects, identified already patched VMs over SSH one at a time, and wrote a Slack summary I could send my boss.

17. Planning a team event

My agent also helped plan our team event: a participant journey, an agenda, a dry run against a fake team, and a live site.

Home lab and personal IT

18. "Is something jamming my audio card?"

My Mac would start playing audio and then immediately stop. I asked the agent in the middle of a video project. It checked audio processes, virtual audio drivers, and system logs, and found the real problem: my JBL headset was stuck in hands-free mode, the 16 kHz mono mode meant for calls, instead of stereo playback. Nothing to do with code at all. So turned off headphones and things worked again!

A terminal-style card. The prompt asks whether something is jamming the Mac's audio card. The agent replies that the JBL headset is stuck in hands-free mode, showing system output with an input sample rate of 16000 marked "HFP/SCO, not A2DP".

19. A home lab, set up over SSH

I have four machines at home for running local models. Agents did the setup over SSH: firewall rules, a scheduled task to keep WSL running on the Windows box, text-to-speech, speech recognition, and local model servers, a LiteLLM proxy, SearXNG search, and Langfuse tracing. Every service has a check script it can rerun. Now all of it is saved as a skill, so any future session already knows the boxes and the traps we have already hit.

A diagram of the home lab. Claude on the Mac reaches four machines over SSH: HULK runs shared services like LiteLLM, SearXNG, Langfuse and Firecrawl; HERMES runs a personal agent with calendar and Spotify connections; INFINITY runs a local reasoning model; WARLOCK runs voice services under Windows and WSL2.

20. A VPN on my Raspberry Pi

My agent set up a VPN on my Raspberry Pi with an auto-rollback timer, so if the VPN cut off SSH, the change would undo itself.

21. Rescuing a new inference server

At work, a brand new server came up with a (too) bare-minimum install (no sudo, no DNS). The agent got the machine working over SSH.

Life

22. A road-trip playlist for my mom

I was going to San Francisco with my mom (likes 70s, R&B, soul) and my brothers (video game music, electronic). I asked for a playlist called "SanFranTripping," at least 30 tracks, with a good mix of what we all like, saved straight to my Spotify. It used my listening history and my Spotify connection and came back with 60 songs.

The SanFranTripping playlist on Spotify: 60 songs, about 4 hours 15 minutes, described as an SF road trip blend for the fam, starting with September by Earth, Wind & Fire, A-Punk by Vampire Weekend, and Lose Yourself to Dance by Daft Punk.

23. 11 years of my Spotify data

I requested my full streaming history from Spotify and had an agent turn it into a single-page HTML report: 11 years, 394,588 streams, 17,332 hours. It was research for FoFo Radio, an AI radio station idea, so the agent went well past totals.

The top of a dark-themed Spotify listening report called FoFo Radio: 394,588 total streams, 17,332 hours listened, 8,577 unique artists, and a timeline of monthly streams from 2015 to 2026.

It ranked my top artists and tracks. "Pogo" by Digitalism wins by a mile, with 1,289 plays.

The Top Artists section of the report: The National leads with 9,286 plays, followed by Modest Mouse at 7,070, Death Cab for Cutie at 5,072, then STRFKR, Brand New, Tegan and Sara, Santigold and Daft Punk.
The Top Tracks section of the report: Pogo by Digitalism leads with 1,289 plays, far ahead of A-Punk by Vampire Weekend at 824, Disparate Youth by Santigold at 756, and Hot Thoughts by Spoon at 753.

It split out the songs I never skip, which it labeled as "A-list" rotation candidates for the station, from the ones I bail on within seconds.

The skip analysis section: a table of never-skipped tracks such as Afraid Of Everyone by The National with 602 plays, labeled A-list candidates, next to a table of the most skipped tracks with skip rates up to 90 percent.

And it found my longest "listening sessions," using a rule of no more than 10 minutes between tracks. The top one ran 47 hours and 741 tracks.

The Marathon Listening Sessions table: the longest session started September 8, 2022, ran 47.74 hours across 741 tracks with Modest Mouse as the top artist, followed by a 45-hour session led by Kanye West.

24. Reading my old Facebook data

I also exported my Facebook data and asked an agent to write about me from it, to "learn about myself from back in the day… the good moments, the sad moments." That one was a trip.

25. Kitchen timers and a meal plan

My self-hosted assistant, Hermes, has set a cookie timer and a muffin reminder, and made me a meal-prep plan in Google Sheets.

26. An AI phone receptionist

For an AI phone receptionist I set up, the agent configured Twilio, my router, and DNS. The receptionist answered my test call with "let me transfer you." My response: TRANSFER ME TO WHO????

When it goes sideways

It is not all smooth. A few of my favorite misses:

  • An agent running my art shop created about 800 Etsy draft listings I did not want.
  • I found out my assistant could reach my Mac directly casually via conversation: "you are not sandboxed??"
  • Deploying this blog, the agent would not listen to my upload instructions: "STOP IGNORING MY DIRECTIONS."

Patterns that worked

  • Say READ ONLY or MAKE NO CHANGES in the prompt. Scoped API Keys!!! Most of the examples above started this way.
  • Dry run first for anything that writes, creates, or can't be undone.
  • Auto-rollback timers for network changes, so a mistake can undo itself.
  • Disable, don't delete. You can turn something back on. You can't un-delete it.
  • Stage credentials in Keychain so you are not pasting secrets into the chat or storing in plaintext on disk.
  • Take a snapshot before admin changes, so you can restore.

More on this in Checking A.I. Work is Hard.

Try it

There is a lot you can do with an a.i. coding agent. In these examples, I typically used Claude Code via Max subscription -- but a lot of other setups work too.

Next time you wanna get a big task done, if you know the steps and can provide the APIs, see if A.I. can do it!

]]> Checking A.I. Work is Hard: How I Handle It https://fterry.su.domains/posts/checking-ai-work-is-hard https://fterry.su.domains/posts/checking-ai-work-is-hard Wed, 09 Sep 2026 00:00:00 GMT Forrester Terry A.I. makes more work than you can reasonably review. You cannot read your way out of that. Here is where I move the checking instead, plus the prompts I actually use. ai process review developers You spent a few good cycles, did some troubleshooting, and finally, it works!

With A.I., "working" does not always mean "ready to go" though. Something can work but have:

  • Security issues
  • Resource and cost issues
  • Usability issues
  • Incomplete features
Futurama Fry squinting suspiciously. Top caption: "Not sure if 'ready' ready". Bottom caption: "Or just ready".

We are making way more code than we can reasonably review.

The takeaway is not that you should read harder. You cannot read your way out of this. The takeaway is that you have to move the checking somewhere it fits.

So what should we do to handle this?

Whether you are shipping code, a spreadsheet, a policy draft, or a slide deck the A.I. built for you, here are some things to try.

1. Check the plan first, not the output. The plan might be forty lines or so, compared to output that is three thousand. Before you prompt for what you want to build, ask for the approach first: read that carefully, approve it, and then let it build. Ask it to do some research before starting.

2. Define what "wrong" would look like before you start. Try writing out: "X is wrong if Y does not match Z." Then try reviewing the work afterwards against this list.

3. Ask it what it changed that you did not ask for. "List every change you made that was not required by what I asked. For each one, say why." A.I. tools quietly improve things. Renamed a field. Moved a file. Swapped a library. Individually reasonable, collectively how you end up somewhere you never chose.

4. Focus on consequence, not size. Careful not to spend too much time reading every change and line. For critical functionality, read more closely. For other things, read at a high level.

5. Do a security pass. Once the A.I. claims to be done, tell it to check the work it did for any security issues or gaps. I have seen the A.I. forget to implement authentication and basic security from time to time, especially while working on bigger tasks and prompts.

6. Ask the A.I. to explain what it did. Sometimes I ask my agent to give me a summary of what it did and why. You can also ask it to explain how to manually test components or chat through any questions you have.

The two-buttons meme. A sweating man reaches for two buttons labelled "High Level Human Review" and "Automated A.I. Review". Second panel, he gives a thumbs up: "Both Sounds Good To Me".

A few bonus ones for developers

Commit often, not once per session. Be sure to do commits per milestone or feature. This makes things way easier to review ultimately, since you get smaller chunks of code changes.

Review the test, then lock it in. Have the A.I. write the test from the requirement before it writes the code. Then review the tests to ensure they evaluate what you need. From there, you can use these tests as your bar for the coder. Do not let the coder adjust the tests once locked in, this is key.

Some things are best for humans. If the risks are high, you should double check the work yourself. Do not let the automation handle critical actions like deletes or live data manipulation without supervision and review.

Commit before you start. Otherwise, you risk the coding agent wiping out your uncommitted changes. I had this happen to me once, so it is worth throwing out there.

You own it

Though we can move faster than ever, we need to make sure our workflows and processes for quality keep up.

By creating a process, and having some checks before and after you start, you can keep up with the new pace at which everyone is moving.

Example prompts

These are ones I have used, cleaned up so you can paste them as is.

Before you start

Get a plan you can read instead of output you cannot.

I have outlined the requirements and specs for this project in <FILE>.
Before we write any code, do the relevant research and read the whole
requirements file, then write a detailed design document that will guide
the implementation. Save it as design.plan.md in the docs/ directory.
I will review it before we start building.

Make every requirement fail-able.

Rewrite these requirements so each one has a stable ID (REQ-001, REQ-002)
and an "Acceptance:" line describing exactly what must be true for it to
count as done. If a requirement cannot be given a checkable acceptance
criterion, flag it instead of guessing.

Anything it flags is something you had not actually decided yet.

Confirm you have a clean starting point.

Before we begin, confirm the working tree is clean and everything is
committed. If it is not, stop and tell me what is uncommitted.

Guardrails to paste in every time

Stop it from acting before you have answered.

DO NOT MAKE CHANGES WITHOUT ASKING. First investigate and answer my
question. Do not touch the code until I say go.

Stop it from quietly editing the plan.

Do not change the scope of our work in PROGRESS.md. If work remains, we
handle it later. Never delete tasks.

Make the dry run mandatory for anything that touches real data.

Default to read-only. Before any action that writes, deletes, or changes
live data, show me the full plan of what you are about to do and wait for
me to say go. One plan at a time, no chaining. If any part of it cannot be
undone, say so explicitly at the top.

After it says it is done

Find out what it changed on its own.

List every change you made that was not required by what I asked.
For each one, say why you made it.

Run a security pass and send it somewhere you will actually read it.

Review this application and make sure it is secure, both when run as a
normal user and as an administrator. Include code snippets and links to
the relevant code so I can review each finding myself. Put everything in
an MD document in the docs folder rather than answering here.

Shorter version for a smaller project:

Do a security review of this entire app and repo. Identify anything that
needs to be addressed before it goes live.

Writing findings to a file instead of the chat window is the whole trick. Chat scrolls away. A file is still there tomorrow.

Ask how to check it yourself.

How do I test this myself? Write a short guide covering how to manually
verify each piece, including anything I need to set up first.

Asking for a summary lets the A.I. grade its own work. Asking for testing instructions hands you something you can go check independently.

For developers

Lock the tests before any code exists.

Write the tests from the spec first, before any implementation exists.
Once I approve them, they are locked: you write code to pass those tests
and you do not modify or weaken them. If you believe a test is wrong,
stop and tell me. That is a conversation, not an edit.
]]> You Picked the Project. So Why Can't You Start? https://fterry.su.domains/posts/you-picked-the-project https://fterry.su.domains/posts/you-picked-the-project Tue, 01 Sep 2026 00:00:00 GMT Forrester Terry You picked the project and you still cannot start. Five minutes, tasks matched to the energy you actually have, and fewer things open at once. focus productivity process Sometimes it's hard to get motivated to work on things you don't want to do.

Sometimes it's hard to work on things you DO want to do.

That second one can feel confusing. You picked the project. You were excited about it last week! But now you're sitting there with the editor open doing absolutely nothing. This is normal.

I'm an engineering manager, and I still sometimes lose whole evenings staring at a file, thinking in circles.

What I have come to appreciate is that sometimes all you need to do is chip away at something over time, not all at once.

Hide the Pain Harold meme, two panels. Top: "Git repo initialized, blank README ready to go." Bottom, same forced smile: "Project progress: 70% complete!"

Some common tricks:

1. Just start. Five minutes.

That first step is the heaviest one. So give it five or ten minutes of real attention. More often than not you get hooked and keep going, and if you don't, you still move something forward and that counts a lot!

2. If it's tiny and you're between things, knock it out

If something takes two or three minutes and you're already between tasks, just do it. Don't log it, don't schedule it, don't file it in a tool. The overhead of tracking a two minute task costs more than the task.

But do NOT do this mid-flow. A "quick" fifteen minute detour is never fifteen minutes, because you also pay for the twenty it takes to get your head back where it was. Let the small stuff pile up, then clear it in one pass when you're ready for lighter work.

3. Do less at once

Too many active projects burns you out faster AND ships slower. Every open thing is renting space in your head whether you're working on it or not.

Putting something down is not failure. It's the sign of someone who has done this a few times, and knows how to say yes to the right things.

4. Block the time, but be reasonable about it

If you don't have the energy right now, spend a minute figuring out when you will, and put it on the calendar.

Two rules when you do:

  • Don't underfeed a task. An hour blocked for something that needs three is just a scheduled failure
  • Don't overpack a day. Leave wiggle room. Things run long, that's normal

Sometimes setting goals for the day vs a particular hour block can be helpful.

Some of my personal tricks:

5. Match the task to the energy you actually have

You may not have the same amount of gas every day. So plan accordingly.

I stopped sorting my work by just priority and started sorting it by energy cost:

  • High energy stuff (architecture, hard decisions, difficult conversations) goes in my sharpest window / peak of day
  • Medium stuff (code review, routine dev, meetings) goes in the middle of the day
  • Low stuff (email, docs, cleanup) goes in the valleys

Low energy day? Don't try to refactor the payment gateway. Go update the README nobody has touched since 2023, or bump the dependencies that have been throwing warnings at you for a month.

Small stuff very much counts, and it usually gets you moving on the bigger tasks anyway.

The domino chain meme. A man crouches to tip over a tiny domino labelled "Small Tasks" at the end of a line that grows into a very large one labelled "Big Task".

6. Let yourself actually recover

If burnout is what's stopping you, take the break. Heal.

Do not underestimate sleep, food, medication, and having a life outside the screen. If you're not recharging, you're running the battery down, and you WILL feel it. Usually at the worst possible time.

Mr Bean waiting meme, four panels, captioned "Me trying to wait out burnout so I can get back to what burned me out." He stands waiting, checks his watch, sits down, then lies flat in the field.

7. Build a process, and set real deadlines, pat yourself on the back!

For anything you do more than twice, have a process or workflow.

Write it down and follow it. It makes you faster every single time after the first.

I have a process for deciding whether to even take on a new project: determine the value, determine if someone else is already doing what I am doing, determine the effort needed, etc. If the project doesn't meet certain criteria, it is likely a candidate for skipping.

Set deadlines and mean them. Miss one, don't spiral about it. Do a quick retro on why things fell behind, make a plan, get back on track.

And celebrate the small wins. You will be shocked how much you've done when you start keeping track.

Remember: it will suck sometimes

It will not all be fun. There's a stretch in the middle of every project where it's just grinding and there's no fun in it at all.

Be gracious with yourself when that hits. But also take credit for what you're taking on, and take responsibility for it. You signed up for something hard. That's allowed to be hard.

That's the game

You don't need a perfect system. You need five minutes, a task that matches your energy, and fewer things open at once.

Start there. You can do this!

]]> A.I. Made It… But Can You Explain It? https://fterry.su.domains/posts/ai-made-it-but-can-you-explain-it https://fterry.su.domains/posts/ai-made-it-but-can-you-explain-it Sun, 30 Aug 2026 00:00:00 GMT Forrester Terry A vendor asked how my own system worked and I stalled. Here is what I do so A.I. writes the code without taking the understanding with it. ai skills developers Imagine: You are in a meeting with a vendor. It is going fine. Then they ask a completely normal question:

"So, how exactly does X work?"

And you stall. Not because it is a hard question. Because you shipped X, you own X, and you did not actually write X. Your A.I. did, and you skimmed it, and it worked, and you moved on.

Two-panel comic. Panel one: a vendor in a meeting asks "So, how exactly does X work?" Panel two: the engineer, typing rapidly into Claude Code, answers "Uhhhhh... one second, let me double check."

I had this happen to me. It was no big deal, I explained myself and found the answer, but I did not like the feeling of not knowing.

The worry is real, and it is not new

One of the big fears about A.I. is what it does to how much we learn, and how well.

We are already leaning on it hard. People get their news explained to them. Kids get their homework answered. We get our custom software written. These are genuinely great use cases.

The problems start when:

  • We read the A.I. summary and never look at the actual source.
  • We get the answer instead of doing the work, so we never actually learn much.
  • We accept the code without understanding it, and then something breaks and we have no idea where to even start looking.

For a developer or IT professional, the bill comes due in three ways. You learn less about how your own system works. Your troubleshooting gets slower and shallower. And your codebase quietly turns into a liability, because you are responsible for something you cannot explain.

None of that shows up on day one.

The Manager Parallel

I have kinda lived a version of this transition, and so has every manager reading this.

When you move from writing code all day to managing people who write code all day, you produce less. Way less. And you do lose a little of your edge. That is real.

But something else happens. You start exercising different skills, and they turn out to matter a lot: reading a system at the architecture level, asking the question that unblocks somebody, knowing which risk is actually the risk. You stop being the person who types the most and you become the person who understands more.

And honestly, your "old" skills become a foundation for those new skills. For non-technical folks, your expertise in your domain becomes incredibly useful for directing the output and checking the quality.

So the goal is not "use less A.I." The goal is to make sure the thing you traded away is the typing, and not the understanding and awareness.

How I Avoid This Issue

I let A.I. do nearly all of my coding, and I have not felt myself getting dull. Here is what that actually looks like for me:

General Tips

Make it explain itself, on purpose. I ask a lot of "why" out loud. Some prompts I use constantly:

  • "Explain this like I have to defend it in a design review tomorrow."
  • "What approaches did you consider and reject here, and why?"
  • "What is the riskiest part of this change?"
  • "What would break if traffic went up 10x?"

Any of those will teach you something or even catch real problems.

Stop on the words you do not know. A term goes by that you cannot define: so stop and ask, or go look it up. Small but fundamental and very powerful.

Recite it back before you ship it. For anything meaningful, I close my agent and try to explain the change or work to myself in my head. If I cannot get through it cleanly, I should review the work and plan again.

Keep building things that challenge you. Do it on your own time or as time allows, on something you actually care about. Run into the wall, get stuck, try again. Nobody is watching, there is no deadline, and it is still a quick way to learn anything.

Watch how other people use theirs. Everyone has worked out some workflow trick. Ask them.

Tips Particularly For Developers

Read the logs yourself, especially when the agent is circling. Let the A.I. read them first, absolutely. But the moment your agent takes its third swing at the same bug, that is your cue to open the logs personally. Nine times out of ten there is a line in there that it skipped right past, and you spotting it is what breaks the loop.

Use the design phase as your learning budget. Before anything gets built, I will have it lay out two or three approaches with real tradeoffs, and tell me who else does it that way. That is the requirements and design part of the SDLC. This is where most of my exposure to new frameworks and patterns comes from now.

Read the diff instead of the file. Telling yourself you will "skim the whole file later" can end up a daunting task. Reading the diff is easier and it is the difference between approving code and reading code. If something looks weird in there, stop and ask the bot about it before it merges.

So…

Like I said, I let A.I. write most of my code. But my role remains involved, I am just not doing the actual writing anymore. I'm still testing, still designing, still exploring and asking questions.

Next time you finish something, try asking this to yourself.

"If someone stopped you in a meeting and asked how it works, could you tell them?"

Not line by line. Just the shape of it, out loud, without opening your laptop or asking your agent.

If yes, you are fine. Go faster, fam!

If not, there is likely something new for you to learn.

]]>