Giving an AI coding agent strict, explicit rules about how to write components (e.g., banning side-effect-heavy patterns) makes the code it produces easier to read afterward, because it ends up matching the style you'd have written yourself.
Scott says he heavily dictates component style rules to AI agents (e.g., 'no effects' in Svelte) so the resulting code reads the way he'd write it, making it easier to understand. ✦ AI generated
Scott Tolinski · Syntax · 2026-07-08 · original ↗
starts at this moment · 2:22
“The problem I'm struggling with is whenever I ask an AI agent to create a component or any large piece of code, it takes me a considerable amount of time to understand what it wrote before I can make any changes. What advice do you have to help me better understand the code it generates?”
I heavily dictate the style at which they're allowed to write components in. You know, in the Svelte world I'm saying do not use effect. Don't even think about it. Side effects are almost never the right decision here... So, therefore, when I go to read the code, it reads like the code I want to read.
verbatim transcript · starts at 2:22
2:22component, one comment. I like to lean on a lot of rules, particularly when I'm working with AI agents myself, I heavily dictate the style at which they're allowed to write components in. You know, in the Svelte world I'm saying do not use effect. Don't even think about it. Side effects are almost never the right decision here. But because so many things happen in effects in React, it's always wanting to
2:49lean towards that. So, I have a number of strict rules that I give it when I'm prompting. So, therefore, when I go to read the code, it reads like the code I want to read. >> Yeah, I think with UI code specifically, because that often dictates how it looks, I find myself drilling in a little closer with with the UI. Whereas like if I'm writing some like back-end
3:12functionality, I've no problem for it to generate several hundred lines or maybe even a thousand lines of like functionality. You know, you got your database and everything is a subject function. >> Yeah, it's a >> Your is even function. >> It's pretty good at like actual subjective functionality. But when it comes to actually building out the UI, I drill in a little closer and I spend a lot more
3:40time on it and do sort of smaller changes because I think that's why a lot of these apps feel like crap is because the UIs on them are just absolutely awful. They technically work well, but how you [clears throat] use them, how you interact with them, and and what they look like is often leaves a lot to be desired. So, my recommendation here is just drill in and use it at a much
4:01smaller Hell, even go back to using tab completion if if you must for that type of thing. Other things you can lean on like Scott says is is lots of rules in there, example code, prompts over if something should be duplicated or not. I find that that's a really interesting one where >> Yeah. >> [snorts] >> you have two things that have somewhat overlapping functionality. In in some