Yesterday I had a discussion with some friends in the software industry and it turns out I am a bit more leaning into the LLM thing than some of my friends. It is very tempting to write an in-depth description about how I use LLMs, but I’d like to highlight one skill I use a lot in particular: feature-dev.

I found myself repeating the same statements a lot to my agents: “Please explore and come up with a plan”, “Do not continue until I agree to the plan”, and “Explore the way we do things in this codebase, and follow that pattern”. This I turned into a reusable skill, or rather, I had Codex do it for me.

Here is what the steps of that skill roughly looks like:

1. Read the ticket, and gather more context. Look at related tickets, look at the codebase. Figure out the way we do things, and how this problem fits into that.
2. Come up with an in-depth plan. I find that once the plan is detailed enough, I almost never care about the implementation details. Architecture and approach are difficult to get right, but LLMs are almost universally better at the details than I am, and certainly are faster. In this stage I will go back and forth a lot, challenge the plan, and ask the LLM to come up with alternatives. This is a hard stop, the LLM is under no circumstances allowed to continue without user approval.
3. Implement the plan.
4. Run automated checks: run typecheck, linting, tests, etc. This should happen automatically, with no user intervention. I don’t want to be involved in making the typechecking work, I wouldn’t involve myself in that if I passed it off to a junior, and I shouldn’t be involved here.
5. Validate the outcome. This is where I will test the code and do a code review. Typically less of an ‘are the details correct’, but more of an ‘do I like this architecturally’, much in the same way I would review code from a colleague. The implementation details are sometimes wrong, but this will normally get caught by a code review bot. Again, LLMs tend to be much better at the implementation details, so I should stop micromanaging it. Again, this is a hard stop, no progressing past this point without user validation.
6. Ship. Commit, push, open up a PR. Here is where I will put some instructions for what I want PRs to look like.

I find that I have been a lead software engineer for long enough where it comes natural to me to treat LLMs as a competent mid-level engineer on my team: they need the context both in a technical and a business sense, they need a sparring partner to get the plan right, but once that is agreed upon they will be fine at the implementation details.

You shouldn’t copy this skill as-is, just steal the inspiration and build your own version. If you’re a software engineer, DRY comes natural to you. Same thing applies to LLMs, but the abstraction can be fuzzier. Go ahead and try it!