Letting the machines think for us

There are times when I find myself using LLMs even when I’d rather not, and it’s not because of any organizational policy. No, when I’m lacking the focus or patience to do deep work, the models are there to take instructions for me. In these moments of weakness, I can give prompts like:

  • Read these logs, why could there be an issue here?
  • Please add print statements to this block of code for debugging. I promise I will do unit tests later.
  • Does this architecture diagram make sense?
  • Does this HCL config file make sense?

When you don’t have the time or attention to think things through, that’s when you end up leaning on generative AI tools too heavily. They should save you time, not thought, and thinking shouldn’t be a luxury.

There’s a good reason why no one likes to ‘center a div’, it’s tedious, frustrating, and doesn’t get you closer to what you were trying to do initially. The issues that beleaguer AI-written code are in my experience the same ones that affected code ripped from stack overflow, or an example in a book - redundant, not fully understood, shoe-horned in, off-gassing weird smells.

A convenient tool

I did find there to be one thing that takes a consistent amount of effort, regardless of what’s on my plate that day, and that’s writing good tickets. I am fastidious about taking notes when investigating an issue, including my line inquiry and any output or inisghts gathered in the hopes that it might help the next person (often me) find a better resolution should it be relevant in the future. I really do think that this is an appropriate use of time, and colleagues over the years have let me know how much they appreciate it.

However, it takes a lot of time, and can run very long in the tooth. There should ideally be a structure for documenting an engagement, be it on the behalf of yourself or a user.

  1. “What happened?”
  2. “What did you do?”
  3. “Why did you do it?”
  4. “Did it work? If not, what was the result?”
  5. “What did you learn?”

Not only should these questions be answered in detail, but they should also be answered succintly. Cleanliness may not be close to godliness, but there’s no sense in having extraneous information front and center when an executive summary can facilitate a deeper conversation just as well, if not better.

To help make this process a little easier on myself, I wrote a (simple tool) for keeping myself accountable on the record. I have no doubt that TicketDuck will look pretty anemic in a few months time [i] given the increasing capabilities of agentic AI and MCP, but it succeeds at helping me get thoughts down quickly, and produce a summary that at least has the bones of what my process has entailed. It works like this:

  • After launching the application, configure the model that you’d like to use.
  • Once that’s done, select your form type from the main menu.
  • Answer each question in the form, or skip the ones that you don’t like.
  • Submit the form, copy the output, and edit it down to what makes sense.
  • Did you save time? Maybe not, but the words were put to the page, and the task of documenting your work has been split into smaller chunks!

I’ve written a few different sets of questions and prompts for different types of tasks, and it’s on my list to add the ability to create more ad-hoc. I’ve always loved the idea of creating a generator which does the right thing for you, as opposed to the wrong thing, and once you’ve written things down and committed them to the record, you are making yourself more trustworthy. You can always go back later to make yourself more clear, but any void is subject to interpretation. Who hasn’t been through seemingly unending chains of meetings and had the goalposts move bit by bit, month by month, until they were unrecognizable? The more that I’ve written and the interacted with what I was writing, the better I’ve been able to reflect on what I put forward as a developer.

Project management can be difficult, and I don’t deny that, but being clear communication from individuals can only help coordination in the long run. One of my biggest takeaways from studying music has been recognizing the cost benefit characteristics of improvisation vs. composition. The act of playing out your inspiration is not the same as refining it, and each requires its own mindset.

When you get something done just for the sake of it needing to be done, it’s a lot better if there’s the potential upside of some larger accomplishment that can be built upon it around the corner. Even the act of taking a process that is manual, or exists only your end, into something like a (do-nothing script) can be relevationary. It’s true that some people want to be led, rather than wander down the garden path on their own, but if punching text into an LLM lowers your personal activation energy to embark on a project and get an MVP going, that’s phenomenal[ii].

Footnotes

[i] Lest I be mistaken for charlatan seeking to growth hack your startup with an API wrapper and a prayer, this has already happened several times since I’ve started writing it, where a friend asked me about a certain feature, and it was already available, polished and at no cost to them.

[ii] If you know the chords you want, let the machine keep you in key.