41–50 of 59 posts
In my typescript codebase case, it solves a lot of problems, it probably helps that I use tRPC type rather aggressively (i.e. using UUID types, separate dates and datetimes etc).
A few weeks ago it wasn't working nearly as well in my experience.
Some pragmatic tips:
- Work with AI like a junior developer, except with unlimited energy and no problem being corrected repeatedly.
- Provide the AI with guidance about conventions you expect in your code base, overall architecture, etc [1]. You can often use AI tools to help write the first draft of such "conventions" documents.
- Break the work down into self-contained bite sized steps. Don't ask AI to boil the ocean in one iteration. Ask it to make a sequence of changes that each move the code towards the goal.
- Be willing to explore for a few steps with the AI. If it's going sideways, undo/revert. Hopefully your AI tool has good checkpoint/undo/git support [2].
- Lint and test the code after each AI change. Hopefully your AI tool can automatically do that, and fix problems [3].
- If the AI is stuck, just code yourself until you get past the tricky part. Then resume AI coding when the going is easier.
- Build intuition for what AI tools are good at, use them when they're helpful. Code yourself when not.
Some things AI coding is very helpful for:
- Rough first draft of a change or feature. AI can often speed through a bunch of boilerplate. Then you can polish the final touches.
- Writing tests.
- Fixing fairly simple bugs.
- Efficiently solving problems with packages/libraries you may not have known about.
[0] https://aider.chat/HISTORY.html
[1] https://aider.chat/docs/usage/conventions.html
> How often do you catch AI trying to make breaking changes? I think this is the wrong way to think about the problem. The AI isn't breaking your code, the engineers are. AI is just a tool, and you should always keep this in mind when talking about this sort of thing. But I understand some of the problems you describe while using AI. And the way I work around is to never let the AI write more than a few lines at a ti…
It sounds like you're not training it with your existing code base, and that you're running it with relatively small contexts. Have you done any custom LLM training on your code base, and what model are you using?
Do you not have code reviews? These are all problems with regular humans, too. You prevent it via code reviews.
Or even better, before the code review. If your engineers commit substandard code that was generated by an AI, they’re not doing their job. It’s ok to miss some things, but "breaking the codebase" should absolutely not happen.
Whether it is generated by AI or not is irrelevant. I've seen junior engineers submit better code than normal because it is AI generated.
Small functions, small modules, small codebases. Keep state as contained as possible. Tightly control interfaces and interactions. Know your paradigms. Example: in Rust multi threading it loves putting things in an Arc. You have to tell it to use MPSC queues instead. I love coding with AI. It has made me 100x more productive. I am able to work on my distributed event processing backend in Rust, then switch to my mobi…
Just curious have you been working in those disciplines for years though regarding: rust -> swift -> uart driver gps esp32
Earlier quoted context omitted.
Just curious have you been working in those disciplines for years though regarding: rust -> swift -> uart driver gps esp32
Not really, since I was in management for five or so years with not much code writing. Embedded programming -- never in my life. Swift -- briefly, when it just came out years ago, but modern Swift is extremely different. Rust -- sure, I guess that's what I'd been doing before moving to management.
Earlier quoted context omitted.
Not really, since I was in management for five or so years with not much code writing. Embedded programming -- never in my life. Swift -- briefly, when it just came out years ago, but modern Swift is extremely different. Rust -- sure, I guess that's what I'd been doing before moving to management.
Dang that's impressive then. I've been a programmer of different languages for a while and I tried to learn/use rust ehh... but that's cool to hear.
Luckily, tooling is good.
It's one of those things where "trying" to learn it doesn't work. You should commit yourself to it and do it. Don't try too hard to understand all the abstractions and concepts. Just write an incredible amount of code. Your brain, over time, will pick up the patterns and make sense of the abstractions. It will do that while you're resting, not while you're actively trying to internalize. Just put in the "saddle time", and the brain will work its miracle.