Linus Torvalds pushed back on calls to ban LLM-generated patches from open-source projects. His argument is simple: review the technical result like any other contribution.
The debate is not over
As AI coding tools improve, open-source maintainers keep facing the same question: should projects reject patches written with help from a language model? Critics worry about hidden bugs, unclear provenance, and a flood of changes nobody reviews carefully. Others argue that the tool used to produce a patch is not a quality metric.
Ars Technica reported on a Linux discussion in which Linus Torvalds pushed back on calls to reject LLM-generated patches by default. The argument is that code should be judged on technical merit like any other contribution, not only on how it was written.
That means reviewing the patch: does it solve the problem, pass tests, remain maintainable, avoid side effects, and fit the project's conventions? If a patch is bad, it should fail because the patch is bad. If it is good, rejecting it solely because an AI tool helped produce it can discard useful work. This is not an argument for unsupervised generation; it is an argument for a reviewable standard.
The real risk is not the word AI. It is a contributor submitting code they do not understand, an agent making unrelated changes, or a project lacking tests that catch regressions. Human review becomes more important, not less, when agents enter the workflow.
For your own project, ask the agent to explain its changes, run tests, inspect the diff line by line, and stop if you cannot explain an important part. When reviewing someone else's contribution, ask the same questions regardless of the tool: is it correct, necessary, tested, and consistent with the project?
Torvalds's position does not solve every AI-coding problem, but it puts the debate somewhere useful. Instead of asking only whether a model was involved, ask whether the patch is understandable, testable, and an improvement. That standard is harder than a ban, but it can survive the next tool too.
Transparency still helps
Even when a project has no AI ban, contributors should be clear about agent assistance when it affects the review. Disclosure does not replace tests, and tests do not replace understanding, but both make the process easier to inspect.
There is also a difference between asking for a small suggestion and delegating a rewrite of an authentication system. As the agent's permissions and change size grow, the review should grow with them. Small patches, clear explanations, tests, and a specific reason for each change protect quality better than a slogan about any particular tool.
Arabic version
Linus Torvalds: احكم على رقعة AI من نتيجتها
Linus Torvalds ردّ على دعوات منع الرقع المولّدة بـ LLM من مشاريع المصدر المفتوح. فكرته بسيطة: راجع النتيجة التقنية متل أي مساهمة تانية.
النقاش مو خلص
كل ما زادت أدوات البرمجة بالذكاء الاصطناعي، رجع نفس السؤال: هل لازم المشروع المفتوح المصدر يمنع الكود اللي ساعد نموذج لغوي بكتابته؟ في مشرفين بيخافوا من أخطاء مخفية، ومن صعوبة معرفة مصدر الكود، ومن ضغط مساهمات سريعة ما حدا راجعها منيح. وبالمقابل، في ناس شايفين إن الأداة بحد ذاتها مو معيار جودة.
بتقرير Ars Technica عن نقاشات Linux، Linus Torvalds ردّ على مشرفين بدهم مشاريعهم ترفض رقع LLM بشكل مبدئي. الفكرة المنسوبة إله إن الكود لازم ينحكم عليه بميزته التقنية، متل أي مساهمة كمانة، مو فقط بالطريقة اللي انكتب فيها. وعبارته الحادة كانت إن اللي بيشكك بفائدة AI غالباً ما جرّبه فعلياً.
شو يعني الحكم على الرقعة؟
يعني إن عملية المراجعة ما بتتغير: هل التعديل بيحل المشكلة؟ هل الاختبارات بتمر؟ هل الكود واضح وقابل للصيانة؟ هل في آثار جانبية؟ هل في توثيق؟ وهل التغيير صغير ومحدد كفاية حتى ينراجع؟
إذا الرقعة فاشلة، ما لازم نقبلها لأن النموذج كتبها. وإذا الرقعة جيدة، رفضها فقط لأن فيها مساعدة آلية ممكن يحرم المشروع من مساهمة مفيدة. هاد مو دفاع عن ترك النماذج تكتب بلا مراقبة؛ هو دفاع عن معيار قابل للفحص بدل حكم مبني على الانطباع.
فين الخطر الحقيقي؟
الخطر مو بكلمة AI بحد ذاتها. الخطر لما المساهم يرسل كود ما فهمه، أو لما الوكيل يضيف تغييرات جانبية، أو لما المشروع ما عنده اختبارات تكشف الانحدارات. المراجعة البشرية ما بتصير أقل أهمية مع الوكيل؛ بالعكس، لازم تصير أوضح.
المشكلة كمان إن بعض المشاريع ممكن تستخدم منع AI كطريقة سهلة بدل ما تستثمر بمراجعة أفضل. وبنفس الوقت، بعض المساهمين ممكن يستخدموا كلام "الكود مولّد" حتى يبرروا إرسال رقعة كبيرة ومبهمة. بالنتيجتين، المقياس التقني بيضل أفضل من الشعارات.
كيف تستخدم هالمنطق بمشروعك؟
إذا عم تستخدم Claude Code أو Codex على مشروع مفتوح، لا تبعت النتيجة مباشرة. خلي الوكيل يشرح التغيير، شغّل الاختبارات، راجع الفرق سطر بسطر، وخلي عنوان الـ commit يصف السبب الحقيقي. إذا في جزء ما فهمته، وقّف قبل الدمج.
ولما تراجع مساهمة من شخص كمان، اسأل نفس الأسئلة بغض النظر عن الأداة: هل الكود صحيح؟ هل بيحترم أسلوب المشروع؟ هل في اختبار؟ هل التغيير ضروري؟ هاد بيحمي المشروع من الكود السيئ بدون ما يحوّل المراجعة إلى محكمة على الأدوات.
موقف Torvalds ما بيحل كل مشاكل AI بالبرمجة، بس بيحط النقاش بمكان مفيد: لا تسأل فقط "هل استخدم نموذج؟" اسأل "هل الرقعة مفهومة، قابلة للاختبار، وبتحسن المشروع؟" هاد معيار أصعب من المنع، بس هو المعيار اللي بيقدر يعيش مع أي أداة جديدة.
الشفافية بتساعد المراجعة
حتى لو المشروع ما عنده منع رسمي، المساهم لازم يكون صريح إذا استخدم وكيل. مو لأن الكود صار أقل قيمة، بل لأن المشرف ممكن يحتاج يعرف كيف يراجع التغيير أو يطلب شرح أعمق. الإفصاح ما بيغني عن الاختبارات، والاختبارات ما بتغني عن فهم الكود، بس الاثنين بيخلّوا العملية أوضح.
وفي فرق بين مساعدة صغيرة وبين تفويض مهمة كاملة. اقتراح اسم متغير مو مثل إن الوكيل يعيد كتابة نظام مصادقة. كل ما كبرت صلاحية الأداة وحجم التغيير، لازم تكبر المراجعة معه.
بالنهاية، المشروع المفتوح بيحتاج مساهمات قابلة للصيانة، سواء كتبها شخص من الصفر أو استعان بأداة. أفضل طريقة تحمي الجودة هي إنك تطلب رقع صغيرة، توثيق واضح، اختبارات، وسبب محدد لكل تغيير. هيك بتصير الأداة وسيلة ضمن العملية، مو بديل عن المسؤولية.
