AI-assisted Programming Tips
Author:
Kokko Ng
Published: August 16, 2025
2 minutes to read
Thoughts on Effective AI Programming (August 2025)
See my AI Project Template that this post is based on.
Please note that I am currently defaulting to Claude Sonnet 4 for all AI-assisted coding.
Initial Setup Workflow
- Run
uv init
to initialize the project - Run
uv run pre-commit install
. If this doesn’t work, runuv run python -m pre_commit install
- this will ensure that the entire codebase is linted every time you commit using git hooks - Add dev dependencies:
uv add vulture mypy --group dev
- this is needed for some of the pre-written prompts
Development Workflow
Daily Development Process
- Add features using Claude Code/Github Copilot + live review changes
- Run /mypy /ltest /vulture /ltest
- Run /compush
PR Merge Workflow
- Install Github MCP in Claude Code and Github Copilot
- Create branch to-stable-2
- Run /pr-merge - note that this will only be effective if you have good coverage using pytest (see earlier note about increasing pytest coverage for stability)
Best Practices and Tips
Core Programming Principles
- I don’t use Claude Code hooks on purpose. I don’t want the agent’s context flooded with lint fixes
- When the codebase is stable enough, I ask AI to create at least 40% code coverage in pytest with no long-running tests. This ensures stability when multiple people are working on the codebase
- My go-to stack right now is FAB (Flask, Alpine, Bootstrap) - concise libraries with a focus on Python. This is just a personal preference - feel free to modify the prompts to fit your stack
Practical Tips
- Use highly starred libraries with lots of high-quality public code. For APIs that change fast, use the #fetch tool on Github Copilot or ask Claude Code to look at a specific docs link and load the latest syntax of the API you’re going to use in its context
- Feedback loops using curl for APIs and Playwright MCP for UIs are the fastest way to get results
- ACTUALLY READ THE CODE. Prod code is for AI-assisted programming, not for vibe coding
Future Considerations
Thoughts that are still marinating in my brain:
- Preventing context rot - customizing tools for prompts, figuring out how much guidance a specific model needs. The less guidance, the less cognitive load there is on you
- Understanding Bash tools in the CLI Agent era is a superpower. Still diving around this part of the internet. Think mysterious Linux sysadmin vibes
- Understanding codebase architecture is honestly the skill issue a lot of vibe coders have. Modularity, targeted DRYness, and abstractions using SOLID principles go a long way. Think of your codebase as a bunch of mini codebases. This is helpful for both LLMs and humans grokking your code