Re:I will not be using LLMs in my coding
by XCSme on Monday November 09, 2026 @10:42AM
(#50427124)
It's because good software and architecture has always lived in my mind. I simply make a mind model of what I want, and how it should work, and how all pieces interact, and I ask the AI to implement it. I give very broad requirements, and then notice what works as expected as what doesn't.
I steer the implementation broadly by telling the model what libraries to use, what to pay attention to, where are the common source of bugs, gotchas, possible performance issues, security concerns, etc.
Let's say I want to add a good search functionality to my website, I wouldn't just say implement search, good way. I would say to use TypeSense, have that as a separate service, to benchmark performance on various queries, make use of caching, test cold starts, make sure autocomplete has good UI/UX on both desktop and mobile, to avoid layout shifting, display clear progress while search is loading, etc.
I don't care much how it implements them, as long as the result works as expected. Yes, there might be small bugs, but that happens when coding and testing manually too, and they will simply be fixed over time.
Competitive programming is rarely about writing code, it's mostly about knowing which data structure, libraries and ideas to use for each problem. When two competitive programmers talk, and talk about the solution, the solutions to even the hardest problems can often be described in just a few keywords. One would say "dynamic programming + binary search", and that's enough for the other guy to know exactly what the solution is and how to implement it. Same with LLMs, if you just give them a problem and ask them to solve it, they will likely do a shitty job, but once you just give one or two hints to put them on the right path, the solution is then almost perfect and as good as I would have implemented it, or even better, because when I implement it I might be lazy and cut corners to write code faster, but the LLM can organize and test code at such speed that it comes at basically no cost.
I steer the implementation broadly by telling the model what libraries to use, what to pay attention to, where are the common source of bugs, gotchas, possible performance issues, security concerns, etc.
Let's say I want to add a good search functionality to my website, I wouldn't just say implement search, good way. I would say to use TypeSense, have that as a separate service, to benchmark performance on various queries, make use of caching, test cold starts, make sure autocomplete has good UI/UX on both desktop and mobile, to avoid layout shifting, display clear progress while search is loading, etc.
I don't care much how it implements them, as long as the result works as expected. Yes, there might be small bugs, but that happens when coding and testing manually too, and they will simply be fixed over time.
Competitive programming is rarely about writing code, it's mostly about knowing which data structure, libraries and ideas to use for each problem. When two competitive programmers talk, and talk about the solution, the solutions to even the hardest problems can often be described in just a few keywords. One would say "dynamic programming + binary search", and that's enough for the other guy to know exactly what the solution is and how to implement it. Same with LLMs, if you just give them a problem and ask them to solve it, they will likely do a shitty job, but once you just give one or two hints to put them on the right path, the solution is then almost perfect and as good as I would have implemented it, or even better, because when I implement it I might be lazy and cut corners to write code faster, but the LLM can organize and test code at such speed that it comes at basically no cost.