AI vs Human in Software Development


ความขัดแย้งทางอุดมการณ์ของ maliit-keyboard

Posted by cwt on February 13, 2026 at 06:04

หลังปีใหม่ผมได้ทดลองเปลี่ยน Fedora ที่ใช้งานจาก GNOME (Fedora Workstation) ซึ่งผมเป็น GNOME user มาโดยตลอด เป็น KDE แล้วก็พบว่า maliit-keyboard ซึ่งเป็น virtual keyboard (on-screen keyboard) crash รัวๆ อยู่เฉยๆ ก็ crash ไม่ใช่จอสัมผัสก็ crash (จะ crash ทำไม ไม่เมื่อไม่ได้ใช้?) และการ crash แต่ละครั้งก็จะสร้าง report บน ABRT (problem reporting ของ Fedora) ทำให้ notification เต็มไปด้วย crash report ครั้นจะ uninstall ก็ไม่ได้เพราะมันจะลากเอา SDDM และ package สำคัญๆ ของ KDE ตามไปด้วย

ผมก็เลยไปลองหาว่ามีใคร report bug นี้ใน bugzilla ของ Red Hat/Fedora แล้วไหม ก็พบว่ามีเพียบเลย เมื่อเข้าไปดูรายละเอียดพบว่ามี link กลับไปยัง GitHub issue #256, #262, และ #190 แต่ยังไม่มีใครจากทีมผู้ดูแล maliit-keyboard มาตอบ หลังจากพิจารณาดูแล้ว maliit-keyboard version ที่ Fedora ใช้คือ 2.3.1 นั้นถูก released มาตั้งแต่ปี 2022 และ commit ล่าสุดใน GitHub คือปี 2024 (ปัจจุบัน ณ เวลาที่เขียน blog นี้ คือปี 2026) ดังนั้นผมเลยถือว่า project นี้เข้าข่าย abandonware และคงหวังพึ่งให้ project maintainer มาแกปัญหาให้ไม่ได้ ผมเลยทำในสิ่งที่ชาว Open Source ทั้งหลายทำ นั่นคือ เอา source code มาลอง build เอง และแก้ bug เอง

ตรงนี้ขอแทรกหน่อยนึงว่า KDE มีแผนจะเปลี่ยน maliit-keyboard เป็น plasma-keyboard อยู่แล้วตามข่าวนี้ แต่เนื่องจากผมไม่รู้ว่าจะต้องรอไปถึงเมื่อไหร่ และไม่รู้ว่า Fedora จะเปลี่ยนตามเมื่อไหร่ แต่ ณ ตอนนี้ maliit-keyboard กำลัง spam ABRT ของผมรัวๆ ผมจึงรอไม่ได้

ผมลงมือแก้ bug โดยใช้ AI ช่วย ซึ่งมีขั้นตอนการทำงานดังนี้:

  1. AI analyze existing code
  2. AI summarize its understanding
  3. I verify or correct that understanding
  4. I define the requirements or the bug
  5. AI implements the solution
  6. I get another AI (in this case Gemini) to review the changes, and I repeat this step back and forth several times
  7. Finally, I make the final decision

ซึ่ง AI ได้ตรวจพบว่า maliit-keyboard ได้รับสิ่งที่เรียกว่า surrounding_text จำนวนมหาศาล เข้ามา และใน code ดั้งเดิมไม่ได้มีการป้องกันไว้ จึงเกิด buffer overflow และตามมาด้วย segmentation fault ในที่สุด ดังนั้นการแก้ไขจึงใช้ best practice ด้วยการจำกัดข้อมูลที่จะเอาไปประมวลผล โดยตั้งไว้ที่ 1 MB (ซึ่งก็เยอะแล้วถ้าเป็น plain text ธรรมดา) ดังจะเห็นได้จาก commit แรกของผม

diff --git a/src/lib/models/text.h b/src/lib/models/text.h
index 635c98b7..85a000c6 100644
--- a/src/lib/models/text.h
+++ b/src/lib/models/text.h
@@ -35,6 +35,8 @@
 #include <QtCore>

 namespace MaliitKeyboard {
+constexpr int MAX_SURROUNDING_TEXT_LENGTH = 1024 * 1024; // 1MB in characters
+
 namespace Model {

 class Text

และตัวอย่างการป้องกันตรง InputMethod

diff --git a/src/plugin/inputmethod.cpp b/src/plugin/inputmethod.cpp
index 23cacca6..cb0ac6c6 100644
--- a/src/plugin/inputmethod.cpp
+++ b/src/plugin/inputmethod.cpp
@@ -453,6 +453,15 @@ void InputMethod::update()
     int position;
     bool ok = d->host->surroundingText(text, position);
     if (ok) {
+        // Validate the surrounding text length to prevent buffer overflows
+        if (text.length() > ::MaliitKeyboard::MAX_SURROUNDING_TEXT_LENGTH) {
+            qWarning() << "Surrounding text too long, truncating from" << text.length() << "to" << ::MaliitKeyboard::MAX_SURROUNDING_TEXT_LENGTH;
+            text = text.left(::MaliitKeyboard::MAX_SURROUNDING_TEXT_LENGTH);
+            // Adjust position if it's beyond the new text length
+            if (position > text.length()) {
+                position = text.length();
+            }
+        }
         d->editor.text()->setSurrounding(text);
         d->editor.text()->setSurroundingOffset(position);

ซึ่งจะเห็นได้ว่าสิ่งที่ผมทำนี้ไม่ใช่ Vibe Coding แน่นอน และเมื่อได้ code ที่แก้ไขแล้วผมก็ลอง build RPM และใช้งานในเครื่องตัวเองเป็นเวลาหลายสัปดาห์ ซึ่งก็พบว่าไม่มีการ crash อีกเลยแม้แต่ครั้งเดียว ผมจึงทำในสิ่งที่ชาว Open Source ควรทำ นั่นก็คือ contribute กลับไปให้ต้นน้ำด้วยการส่ง PR หรือ pull request (แม้ต้นน้ำจะไม่มีการ update อะไรเลยมาตั้งแต่ 2024) และนี่คือสิ่งที่ได้กลับมาแบบรวดเร็วทันใจ


dobey commented 3 days ago

Co-authored-by: Qwen-Coder [email protected]

Absolutely not. LLMs have no context and do not understand how anything works and are not welcome here.

dobey closed this 3 days ago


โอโห ไม่มีแม้แต่การ review code แค่เห็นว่ามี AI (LLMs) ช่วยเขียนก็ reject ทันทีเลย ราวกับ if-then-else ผมซึ่งควรจะเจ็บปวดเหมือนสารภาพรักใครแล้วเขาปฏิเสธแต่ผมกลับยิ้มรับ และไม่ไปโต้เถียงอะไรต่อ ลองคนมันมีอคติกับ AI ไปแล้วแบบนี้ก็เสียเวลาเปล่าที่จะไปเปลี่ยนใจ และก็คงเปลี่ยนใจไม่ได้ด้วย

ไหนๆ ต้นน้ำเขาก็ไม่รับ code แล้ว ผมจึงกลับมาที่ GitHub ที่ผม fork ไว้ และเปลี่ยนชื่อ repo เป็น maliit-keyboard-robust และลงมือแก้ไข bug อื่นๆ ที่มีคนเคย report ไว้ใน issue ต้นน้ำ ปรับปรุงการป้องกัน buffer overflow ให้ดีขึ้น รวมถึงใส่ unit test สำหรับ surrounding_text ที่ใหญ่เกิน 1 MB ด้วย พร้อมกันนั้นก็ทำ COPR ของตัวเองอยู่ที่ https://copr.fedorainfracloud.org/coprs/cwt/maliit-keyboard-robust/ เพื่อให้ผู้ใช้ Fedora ทุกคนที่เจอปัญหานี้ และโอเคกับ code ที่เขียนด้วย AI สามารถแก้ปัญหาได้เอง

สำหรับขั้นตอนการติดตั้งก็ทำแบบนี้ครับ

$ sudo dnf copr enable cwt/maliit-keyboard-robust
$ sudo dnf install maliit-keyboard-robust --allowerasing

ที่ต้องมี --allowerasing เพราะว่า package นี้มันจะไปเปลี่ยนตัวกับของเดิม แต่ผมตั้งไว้ใน SPEC ว่ามันจะ provide ชื่อ package เดิม ทำให้มันไม่ลากเอา SDDM และ package อื่นๆ ของ KDE ออกไปเหมือนการ uninstall maliit-keyboard ตรงๆ

เรื่องนี้มันน่าขำตรงที่ว่าการมองว่า code ที่ส่งมามี AI ช่วยเขียนแล้วใช้ตรรกะ if-then-else ปัดตกทันทีโดยไม่ดู code เลยนี่ ใครทำตัวเป็น bot มากกว่ากัน?