Use the best tools, the lowest tier of Claude Code is perfect for the stuff you do at home in the evenings and weekends. It's also by far the best at being a "pair coder" as it's chatty and tells you what it's doing and doesn't get confused if you hit ESC and tell it to do something else.
Build your own tools, need a small utility? Use an LLM to create it with you.
Create LLM-focused tools and adjust your workflows to be LLM-friendly.
I personally have a Taskfile setup that follows the same formula regardless of language. "task build" runs lint+test+build. Test and lint are kinda self-evident. All output is set to minimum, only errors are verbose (don't waste context on fancy output).
I also have tools for LLMs to use to find large code files, large and overly complex functions etc.
All project documentation lives in docs/ as markdown files with Mermaid charts.
This way I can just have the general "how to use a taskfile" instructions in my global WHATEVER.md and it'll work in every project.
Learn project management. Working with LLMs is exactly like project managing a bunch of smart and over eager junior coders who want to use every trick and pattern they learned at school for every tiny shell script.
Do a few test projects where you just pretend you're a non-techinical project lead and know WHAT you want but not HOW you want it done. Plan the project, split it into tasks (github tasks or beads[0] both work pretty well). Then have the LLM(s) tackle the tasks one by one and test the end result like a non-techical PM would do in a demo. Comment, critique and ask them to change stuff that doesn't work.
If you can afford it, bring in an outside consultant (Codex or Gemini), both of which are _really_ good at evaluating large codebases for duplication, test coverage, repetition, bad patterns etc. Give their responses verbatim to Claude and ask what it thinks about them.
Working with LLMs is a skill you just need to use to get a feel for it, it's not a science and more like an art. For example I can "feel" when Claude is doing its thing and being either overeager or trying to complete a task while ignoring the burning pile of unit tests it leaves behind and interrupt. it before it gets too far.
Another thing I'd suggest: look into and use non-coding AI tools that improve productivity. For example:
Zoom meeting transcriptions and summaries or Granola. A lot of context is lost when you take manual notes in meetings. If you use a tool that turns a meeting into notes automatically, you can use those notes to bootstrap a prompt/plan for agents.
We use "Notion AI" to transcribe meetings and it's actually pretty good, we just had a team meeting where we talked shit about stuff going on in the company along with actual tasks.
It picked just the tasks and actual points from the transcript and skipped all of the jokes and us bitching about processes =)
Build your own tools, need a small utility? Use an LLM to create it with you.
Create LLM-focused tools and adjust your workflows to be LLM-friendly.
I personally have a Taskfile setup that follows the same formula regardless of language. "task build" runs lint+test+build. Test and lint are kinda self-evident. All output is set to minimum, only errors are verbose (don't waste context on fancy output).
I also have tools for LLMs to use to find large code files, large and overly complex functions etc.
All project documentation lives in docs/ as markdown files with Mermaid charts.
This way I can just have the general "how to use a taskfile" instructions in my global WHATEVER.md and it'll work in every project.
Learn project management. Working with LLMs is exactly like project managing a bunch of smart and over eager junior coders who want to use every trick and pattern they learned at school for every tiny shell script.
Do a few test projects where you just pretend you're a non-techinical project lead and know WHAT you want but not HOW you want it done. Plan the project, split it into tasks (github tasks or beads[0] both work pretty well). Then have the LLM(s) tackle the tasks one by one and test the end result like a non-techical PM would do in a demo. Comment, critique and ask them to change stuff that doesn't work.
If you can afford it, bring in an outside consultant (Codex or Gemini), both of which are _really_ good at evaluating large codebases for duplication, test coverage, repetition, bad patterns etc. Give their responses verbatim to Claude and ask what it thinks about them.
Working with LLMs is a skill you just need to use to get a feel for it, it's not a science and more like an art. For example I can "feel" when Claude is doing its thing and being either overeager or trying to complete a task while ignoring the burning pile of unit tests it leaves behind and interrupt. it before it gets too far.
[0] https://github.com/steveyegge/beads