← All “ai” posts

Thoughts On AI Programming At Work August 2026

Ongoing thoughts about AI at work

I’ve been taking AI more seriously at work, partly due to a soft mandate to increase AI usage, and partly to keep up with the times. Company gives free credit, what’s not to love?

I think I’m finally getting it. For now I’m mostly seeing huge benefits in AI/LLM in work environments, where automation sees the most benefit to the user. For personal use, AI use takes away the frustration of fighting with a framework, but it also takes away the joy of coding, so a balancing act is needed there.

Been trying to wrap my head around the supplementary context mechanism of AI tools (AGENTS.md, skills, etc). I think I’m starting to get it?

AGENTS.md

AGENTS.md provide generalised and always-on instructions/context. This would be rules guarding how the LLM should behave, high level navigational hints, personal preferences, etc. In-line with the concept of hierarchical/progressive context, it is encouraged to have multiple AGENTS.md files at different levels of a project so as not to overload the LLM agent with unnecessary context.

This could mean:

  • a global home-dir-level AGENTS.md for general instruction on operating within the user’s computer
  • a repo-level AGENTS.md for high-level architectural record and navigational context of the repo
  • a module-level AGENTS.md for module-specific context on the design and intent of that module

A good thing to include in the global AGENTS.md file is some sort of self-maintenance. In mine, I instruct it to perform a self-reflection at all notable milsetones to improve on any context/memory files and skills based on any discovery it made in that session. This is one effective way to continuously build and maintain context for using LLM agents, instead of having to remember every quirk and common mistakes an LLM is prone to make.

Skills

SKILLS is a way to eliminate repetition of prompts when performing a similar task. Codify the task so that instead of stating (and re-stating) the task objective and preferences and rules and available tools when performing the task, you can just state it once in a SKILL.md file, and invoke it whenever you want to perform a similar task. Codifying it this way can help the LLM avoid having to re-discover context and waste token.

Examples would be codifying the task of creating a PR, or implementing an API endpoint. Ideally you write the first version of the skill, invoke it when performing the task, steer the agent until the task is completed, then instruct the agent to reflect upon the session and refine the skills used to bring it closer to a one-shot next time. I have a /refine-skill skill that does this, I also reference this skill in the global AGENTS.md file as self-maintenance at the conclusion of a milestone of the session. So far I find gpt-5.6-luna (what I use at work) better at following these instructions from AGENTS.md than hy3 (what I use at home).

Think of it as automating your job away. Documenting each task so that it can reliably be performed and completed by an LLM agent. In some ways, that’s a morbid concept, in other ways, that frees up the human to perform the architecting tasks (though nothing stopping us from creating an architect subagent with the architecture skill). Recently there’s a video/tweet going around:

Coding is solved, but problem solving hasn’t.

It’s liberally been interpreted as

Programming languages and syntax are concerns of the past, do whatever it takes to deliver value, even if that means using plain English.

Skills are also a good way to codify some determinism into an otherwise probalistic operation. We don’t want the agent to re-discover how to use the Atlassian CLI acli everytime, so we declare in the related SKILL.md that:

  • this is how you auth
  • this is how you grab information from this ticket number
  • you should probably be prepared to do some jq manipulation to strip away some noise in the retrieved text
  • etc

Then the next time the agent is instructed to perform a task based on a ticket number, it invokes the get-jira-context skill, knows that it should use the acli tool, verified that it is logged in, and proceeds to grab the context and jq manipulation in one go.

Knowledge Base

The new “in” thing to aid in LLM context supply. Every team is generating KBs for their projects. I guess there’s value in an LLM not having to rediscover the repo everytime it is instructed to perform a task, but it needs to be tightly coupled with a maintenance loop, otherwise the knowledge drift due to lack of maintenance will be counter-productive.

So in some ways, a lot of these additional things around LLM usage (mcp, harness, skills, KB, etc) are just strategies in context maangement and discovery. Ideally we don’t want to load everything in the beginning, but we also don’t want to give it insufficient information that it can’t perform its tasks.