by AgentOrange1234
3 subcomments
- "Every optional field is a question the rest of the codebase has to answer every time it touches that data,"
This is a beautiful articulation of a major pet peeve when using these coding tools. One of my first review steps is just looking for all the extra optional arguments it's added instead of designing something good.
by xiaolu627
2 subcomments
- What changed for me isn’t that AI writes bad code by default, but that it lowers the friction to adding code faster than the team can properly absorb it. The dangerous part is not obvious bugs, it’s subtle erosion of consistency.
by ChrisMarshallNY
1 subcomments
- Because of the way that I use AI, I am constantly looking at the code. I usually leave it alone, if I can; even if I don't really like it.
I will, often go back, after the fact, and ask for refactors and documentation.
It works. Probably a lot slower than using agents, but I test every step, and it is a lot faster than I would do it, unassisted.
by mattacular
1 subcomments
- Code cannot and should not be self documenting at scale. You cannot document "the why" with code. In my experience, that is only ever used as an excuse not to write actual documentation or use comments thoughtfully in the codebase by lazy developers.
by earljwagner
1 subcomments
- The concepts of Semantic Functions and Pragmatic Functions seem to be analogous to a Functional Core and Imperative shell (FCIS):
https://testing.googleblog.com/2025/10/simplify-your-code-fu...
The key insight of FCIS is that complicated logic with large dependencies leads to a large test suite that runs slowly. The solution is to isolate the complicated logic in the functional core. Test that separately from the simpler, more sequential tests of the imperative shell.
by abcde666777
2 subcomments
- My intentionality is that I'll never let it make the changes. I make the changes. I might make changes it suggests, but only upon review and only written with my hands.
by gravitronic
0 subcomment
- *adds "be intentional" to the prompt*
Got it, good idea.
- This could have been html instead of whatever awful moving pattern it is.
- Page not rendering well on iPhone Safari.
Good content tho!
by divyanshu_dev
1 subcomments
- The velocity problem is real. AI makes it easy to add things faster than you can understand what you added. The intentionality has to come before you prompt, not after you review.
by deadlypointer
0 subcomment
- site is totally broken on mobile, just because cursor can vibe code a nice rolling scrolling shithole, chances are it will break on some platform/browser
- I've noticed the cleaner the codebase, the better AI agents perform on it. They pick up on existing patterns and follow them. Throw them at a messy repo and they'll invent a new pattern every time.
It's basically like hiring a new developer for one task and letting them go right after. They don't know your conventions, your history, or why things are the way they are. The only thing they have is what they can see in the code. Your code quality is basically the prompt now.
- I've seen a lot of people talking about how AI is making codebases worse. I reject that, people are making codebases worse by not being intentional about how their AI writes code.
This is my take on how to not write slop.
- Agree, you need to your own code review, although as AI gets better, this problem will most likely be solved.
by theogravity
0 subcomment
- Site renders extremely poorly on mobile safari that it is completely unreadable.
- What if it's not _my_ codebase?
by mrbluecoat
1 subcomments
- ..but unintentional AI (aka Modern Chaos Monkey) is so much more fun!
by heliumtera
0 subcomment
- Dog, be intentional with you web page.
Holy fuck Batman
- [dead]
- [dead]
by bobokaytop
0 subcomment
- [dead]
by microbuilderco
0 subcomment
- [flagged]
- [dead]
by openclaw01
0 subcomment
- [dead]
- [dead]
by lucas36666
0 subcomment
- [dead]
by Sense_101856
0 subcomment
- [dead]
- [flagged]
by ueda_keisuke
1 subcomments
- AI feels less like an autonomous programmer and more like a very capable junior engineer.
The useful part is not just asking it to write code, but giving it context:
how the codebase got here,
what constraints are intentional,
where the sharp edges are,
and what direction we want to take.
With that guidance, it can be excellent.
Without it, it tends to produce changes that make sense in isolation but not in the system.