How I code with AI

How I code with AI #

Recently, like many developers, I’ve been experimenting a lot with coding with AI.

Overall I’ve found that I am more productive with AI: some PRs are vastly easier, although I do write a decent bit myself (especially with https://aep.dev/, which is basically an english specification).

I’ll update this page over time as I learn some new tricks as well.

Adding a personal coding styleguide #

Most editors provide a way to add a custom styleguide. vscode calls these “instructions”.

My personal instructions are here:

---
applyTo: '**'
---
# yft's personal coding guidelines
- prefer fewer comments. Only add them when the code is not self-explanatory.
- prefer functional programming.
- IO with network and filesystem should be in wrapper functions that call inner functions that work on data structures.
- unit tests should be written to run on the data structures directly rather than through IO, with only a single test on IO to serve as an integration test.
- prefer composition over inheritance.
- prefer to use constants, especially for hard-coded directories or values.
- helper functions should have minimal logic.

One-off experiences #

2025-11-10: using Jules and GitHub copilot #

I had trying Jules (https://jules.google/docs/) this weekend on a personal project. It’s kind of similar to this so thought it was worth bringing up.

Basically I had it write a PR to create a new proto schema for me: https://github.com/aep-dev/aep-components/pull/41. The workflow is you add a label “jules” to a GitHub issue, and it goes and generates a PR.

The first pass (like many AI tools) was ok, but had a lot of changes that needed. Many were me not being clear about the initial expectations. But one major hangup was that jules didn’t understand that there was a github CI workflow that it should have run to find more errors. I tried to explain it here, but gave up because it was still failing and I was moving toward comments that just hand-fixed it: https://github.com/aep-dev/aep-components/pull/41#issuecomment-3506923393

I actually tried the exact same change with the built-in copilot generator, which was much closer: https://github.com/aep-dev/aep-components/pull/44. It seemed to better understand the linting and ci workflows, and didn’t have the same breakages with buf.

My workflow was still leaving a bunch of comments, many of which are direct code fixes. But I was able to massage and merge it in.

Ultimately I think this would have been faster for me to have just done locally with cursor / copilot, then hand-fix and submit the PR myself, then have a PR generator do it. But it felt like needing a fundamental understanding of the tooling in the repo was critical.