Effective AI use: Not committing mistakes that cost everyone.

[Shashank-Tripathi-07]

Hello everyone !

It's my first time starting a discussion and decided it should be on an error that I've noticed not with me but with multiple contributors. I've seen multiple contributors make the same mistake and hence I'd like everyone to read this and not do it like us.

The mistake lies in adjusting the scope in which your AI Agent works. We all use different AI models like (Claude, Codex, Qwen and others). They all are very good at understanding things, the bugs and solving them. The only place where they go wrong is in the scope of the problem.

What do I mean by scope ?

• I will first explain this by example, suppose a bug that occurs in all modules of TinyTorch, you notice this bug on your interaction with the first module, retry it, confirm that this is a genuine problem, correct this make a PR of this (or ideally you should first raise an issue, so that we can review it and confirm it a genuine bug or an issue on your end only). Now, the problem that existed in all modules of TinyTorch got corrected only in the first module and if not spotted by any of the reviewers and got merged, all other modules will have the same error that will be corrected again in another PR.

• This leaves us with errors that persist in multiple places but are correct in a single place thus killing the consistency of the expected behavior of the software you're working with. (This happened in one of the issues regarding TinyTorch and I made an error too in the past because of this and you should avoid it, I also reviewed a recent PR where I spotted this error caused by AI agents due to wrong scope of things, thankfully I timely corrected it and we merged a good version of that PR.)

• Even a lot of times, A certain issue is raised that has a bug spotted in narrow scope whereas the bug exists project wide (a wide scope) and as soon as we read it, all discussion trace and objectify that bug in the narrow scope only. Before you agree/disagree, please research the problem extensively, being late and with complete information is better than being fast with wrong information. Take your time and learn, we're here to help you and support you.

---

General thoughts and ideas:

• I would consider people who want to contribute to go through the docs, understand the systems and internals before raising an issue/PR so that (of course, if you want to raise a behavioural PR stating something doesn't work can be made without researching the internals. 🤗, and I or whosoever is assigned will handle it well. )

• Don't completely rely on AI to help you out everyone in the project, a lot of times, the AI models can give you a wrong answer confidently and it is your knowledge that will guide you towards the right path. Avoid being totally on AI-pilot.

• If you want to use my docs that I refer to learn and keep myself updated about the project, you can read about it here: https://github.com/Shashank-Tripathi-07/cs249r-docs

• Read things, you are the best intelligence humanity has ever made. You have the capacity to build things better than what we all can imagine and take humanity further with your talent. I wish you all the best and feel free to tag me wherever you need my help.

• I would love to hear your thoughts about this, I'm all ears !

[aadityansha06]

Good point, this matches a pattern worth calling out generally. When a fix is scoped narrowly on purpose, it helps to explicitly flag the wider surface as a separate tracked issue rather than either quietly pulling it into the same PR or letting it get forgotten. Also worth adding to this, tests that mock the failing function can pass clean while the real bug is still there. Testing against the real thing rather than trusting AI generated mocks is what actually catches it. Narrow scope on the fix, wide scope flagged explicitly, seems like the right balance to aim for.

[Shashank-Tripathi-07]

Yesss....For a lot of such cases you should define the things and know what is actually happening and what you want. This helps you to take better decisions regarding your work. A nice point indeed !