Using AI to help do things

I’ve been using AI more and more, but not really in the way the breathless articles tend to describe it. I don’t ask it to go away and magically solve my life. Most of the time it’s more like having a technical assistant sat next to me who is very fast at reading, reasonably good at pattern matching, and occasionally far too confident.

The pattern is usually the same. I provide the actual situation: logs, screenshots, code, command output, measurements, photos or whatever constraints apply. It suggests likely causes or next things to try. I test those on the real system, or against the thing I’m physically working on, then feed the result back. After a few rounds the conversation is no longer generic advice, it’s about the specific problem in front of me.

That’s the bit that has changed how I use it. A single question and answer can be handy, but the real value is in the back and forth.

Infrastructure and the joy of real logs

A lot of my use is infrastructure and Linux troubleshooting, which probably won’t surprise anyone. I’ve used it while diagnosing a Linux install on a laptop that completed successfully but then hung, or threw me straight back to the login screen. That sort of problem can send you round in circles: display manager, Wayland, desktop session, graphics driver, permissions, half-written config, or something daft I did at 1am.

Working from TTYs and recovery shells, restoring networking and feeding back command output changes the conversation. Instead of “try reinstalling the driver”, it can look at the actual log snippet, compare that with what has already been ruled out, and suggest the next sensible place to look. I’ve used the same approach for Wayland and COSMIC desktop oddities, bootloader configuration, BIOS settings for Secure Boot and AMD virtualisation, Docker build failures, mail relay configuration, WireGuard, firewalld, fail2ban, NRPE, Nagios and the usual general Linux admin swamp.

Screenshots help as well. A photo of a BIOS screen, a login loop, a recovery shell or a weird installer state often explains the problem better than me trying to describe it from memory. That’s not because AI is magic, it’s because it has more of the same evidence I have.

It also works well for research jobs: comparing major kernel changes, finding modern replacements for things like an old x2vnc workflow, or sanity checking whether a suggested approach still makes sense on current distributions. I still check the answer, but it gets me to the relevant part of the problem faster.

Longer engineering tasks

The more interesting uses are not one-off questions. One decent example was building an automated Oracle Linux 9 VMware template using Packer against my ESXi/vCenter homelab. That involved vsphere-iso, Kickstart, UEFI boot automation, guest IDs, boot menus, cloud-init, SSH availability, provisioning and deployment into a content library.

It wasn’t a case of asking “make me a Packer template” and getting a finished result. One failure exposed the next. An HTTP-served Kickstart wasn’t practical in one part of the setup, so the approach moved towards OEMDRV/floppy injection. Then there were boot automation details, then guest identity problems, then SSH timing, then provisioning, then CI/CD constraints. The advantage was being able to keep the context of why each decision had been made. By the time a later problem appeared, the conversation already knew what had been tried and why some obvious answers were no longer on the table.

Another strong example was an AWS Lambda based SFTP monitoring system. The shape ended up being roughly:

event -> connect to SFTP -> list files -> apply regex -> create SQS work -> scale processing capacity when required

That touched Python 3.13, Paramiko, SOCKS/TCP proxies, AWS Secrets Manager, SQS, EventBridge/Scheduler, EC2 Auto Scaling, Terraform, YAML endpoint configuration and Splunk logging. The conversation covered design, implementation, packaging, debugging, tests and documentation. Some of the problems were very specific, such as _cffi_backend and Lambda packaging, cross-architecture container builds, proxy handling, handler configuration, certificate verification, optional SQS settings, invocation-specific logging IDs and only scaling an ASG after messages had actually been created.

Again, the important bit was not a clever snippet. It was the ability to say “this is the current error, here is the Docker build, here is the Lambda handler, here is what changed since the last attempt” and keep moving. It also helped turn the end result into README and Confluence-style documentation, which is exactly the sort of thing I know I should write but would often rather avoid.

I’ve used the same style on a smaller Node.js/Fastify application for Farmfoods vouchers. It scrapes and normalises voucher information, then works out the best combination for a bill. That has gone through Cheerio/import problems, Docker packaging, CSP nonces, security headers, rate limiting, client-side/offline calculations, UI behaviour, automatic refreshes and explaining why a voucher can or cannot be used. That’s a good example of it being a development partner over many revisions rather than a one-shot application generator.

The same workflow at home

What surprised me a bit is how well the same workflow applies away from “proper” infrastructure work.

When replacing a Cosy heating system with Drayton Wiser, I used it while joining the dots between Wiser, wiser2mqtt, MQTT, Telegraf, InfluxDB and Grafana. The problems were exactly the same sort of problems I see professionally: invalid values, awkward data shapes, Telegraf/Starlark processing, MQTT topics and dashboards that only make sense once the data is clean.

During a bathroom refurbishment it worked in a completely different way. I could provide photos, measurements and product details while doing the job. That made questions about removing tiles, assessing walls, Thistle Bonding Coat, Easifill, mixing ratios, allowable depths, drying times, sanding, PVC shower panels, CT1, panel cutting, bath supports, upstands, silicone and even identifying a bath mixer/diverter seal much more specific. A generic tutorial rarely matches the wall in front of you. Being able to ask “given this photo and this depth, what are my options?” is much better.

I’ve also used it for iterative 3D printing and CAD changes. One example was modifying a caulking-tube rack: changing three rows into two, altering the stepped layout, retaining the overall height, increasing flexible supporting walls to 3 mm, increasing the opening to 50 mm, trying curved transitions and then deciding they were not worth keeping. That’s a nice compact version of the whole process: change, inspect, revise, revert the bit that didn’t help.

There are plenty of smaller uses too: identifying hardware, plants, insects, posters and components from photos; comparing monitors; appliance and printer troubleshooting; car-related research; consumer rights; rental-property questions; calculating materials and finding replacement parts. Individually they’re not exciting, but together they show where the habit forms. Instead of starting with a blank search box, I start with the specific facts I have.

Keeping context over time

One of the less technical but more telling examples was a long-running smart-meter complaint. Over months, the conversation helped me keep track of correspondence, maintain a timeline, understand the technical meter/comms problem, prepare responses, analyse bills and estimated readings, track rebilling and work out the effect of a large credit balance.

That eventually reached a conclusion: the meters were replaced, smart readings resumed, rebilling was completed, a substantial credit was refunded and the direct debit was reduced. None of that happened because an AI wrote a magic complaint letter. The value was in not losing the thread over a long-running issue with lots of dates, readings, estimates, responses and partial fixes.

Persistent context matters. The more it knows about what has already happened, the less time is wasted repeating the obvious.

Where Codex fits

ChatGPT is a good fit for discussion, analysis, research and working through a problem. Codex becomes the better tool when there’s a repository or machine state to inspect. I’ve increasingly found a pattern where I talk through an issue first, work out the symptoms and constraints, then give Codex a more carefully constructed prompt: here is what is broken, here is what must not change, here is how to validate it.

This site is a simple example. Codex has reviewed old Hugo content, checked links, tidied front matter, normalised filenames, removed unfinished gallery pages and explained why CI behaved differently to my local build. It found that CI was running an older Hugo version than I was testing against locally. The fix was not glamorous: pin the CI image to the same version and print hugo version in the job. The important part was getting from a template error to the real cause quickly.

That still needed review. Some broken links in old posts are historical and should remain. Some technically valid cleanups would change the character of old content. That’s my decision, not the tool’s.

It still needs checking

AI can be wrong in very convincing ways. It can misunderstand the version of the software you’re using, suggest something that applies to a different operating system, miss a physical constraint, or confidently head down the wrong path because the first description was incomplete. If you treat the answer as authoritative, you’re going to have a bad time.

The productive workflow is verification. Commands get run. Code gets built. Logs get checked. Measurements get taken again. Advice gets compared with documentation, or with the actual wall, pipe, Lambda package, VM console or config file in front of me.

Used like that, AI has become another practical tool. Not a replacement for knowing what you’re doing, and definitely not a substitute for judgement. More like a second pair of eyes that can read quickly, remember the last dozen things you tried, and occasionally point out the simple thing you missed while you were busy swearing at the complicated thing.

This post was AI generated from my notes and real examples, then reviewed and edited before publishing.