היום למדתי: בדיקת שייכות ל Range ב Ruby
תמיד השתמשתי ב include? כדי לבדוק אם מספר נמצא בטווח מסוים והקוד הזה עובד ודי יעיל:

3.3.5 :007 > (1..10).include?(5)
 => true

רובי לא מתאמץ לעבור איבר-איבר בטווח מאחר וזה טווח של מספרים שלמים ו-5 הוא מספר שלם אז מספיק לבדוק שהוא גדול מההתחלה וקטן מהסוף. אגב קל לראות את זה כשמחפשים שבר בתוך הטווח:

3.3.5 :010 > (1..10).include?(4.5)
 => true

כשברור שאם ננסה לעבור איבר-איבר לא נמצא את ארבע וחצי:

3.3.5 :011 > (1..10).to_a.include?(4.5)
 => false

השבוע נתקלתי במקרה בפונקציה conver? שנראתה כאילו עושה אותו דבר:

3.3.5 :008 > (1..10).cover?(5)
 => true
3.3.5 :009 > (1..10).cover?(4.5)
=> true

גם היא לא צריכה לרוץ על כל הטווח ומסתפקת בבדיקת קצוות. אז איפה זה מתחיל להיות מעניין? מסתבר שאנחנו צריכים 2 פונקציות כדי לטפל אחרת בטווחים של דברים יותר מסובכים ממספרים, למשל מחרוזות. ברובי גם זה טווח:

3.3.5 :013 > ('a'..'z').class
 => Range

וכמו עם שברים גם בטווח של מחרוזות אנחנו יכולים לבדוק שמחרוזת מסוימת נמצאת בין ההתחלה לסוף:

3.3.5 :014 > ('a'..'z').include?('t')
 => true
3.3.5 :015 > ('a'..'z').cover?('t')
 => true

את ההבדל בין cover ל include אנחנו מגלים כשמנסים לחפש מחרוזת שנמצאת בטווח אבל לא תופיע ברשימה אם נהפוך את הטווח למערך:

3.3.5 :018 > ('a'..'d').to_a
 => ["a", "b", "c", "d"]
3.3.5 :019 > ('a'..'d').include?('bob')
 => false
3.3.5 :020 > ('a'..'d').cover?('bob')
 => true

עכשיו צודקים מי שיגידו שזה לא הוגן כלפי השברים עם הנקודה העשרונית, הרי הם היו צריכים לקבל את אותו יחס של מחרוזות. צודקים גם אם תגידו שזה מבלבל שאותה פונקציה include? לפעמים מחזירה תוצאה ב O(1) ופעמים אחרות מחזירה את התוצאה ב O(n). אני יכול רק לענות שהחיים לא הוגנים ורובי באמת יכולה להיות לא עקבית אבל טוב שגיליתי את cover? שייחודית לטווחים ותמיד מחזירה תשובה ב O(1).

פתרון AoC 2025 יום 5 חידת הטווחים
אתמול כתבתי על בדיקת cover? של רובי והיום נראה איך היא עוזרת לנו לפתור בעיה אמיתית מתוך Advent Of Code האחרון ואני מתכוון לחלק השני של יום 5. מה שאהבתי בחלק הזה היה שכשניסיתי לקחת את הפתרון של חלק 1 ולהרחיב אותו לחלק 2 זה פשוט לא עבד וכך הבנתי את הטעות שהיתה לי בחלק 1. אבל בואו לא נקדים את המאוחר ונלך לראות את התרגיל.

חלק 1 חיפוש דברים שלא בשום טווח
בחלק הראשון של התרגיל קיבלנו רשימה של טווחים ורשימה של מזהים והיינו צריכים לבצע בדיקת קיום כלומר לראות מי מהפריטים לא נמצא בשום טווח. בגלל ש Range תומך בבדיקת שייכות מהירה זה היה קל ואחרי פענוח הקלט אפשר היה להריץ:

def part1
  @to_check.count {|i| @fresh_ids.any? {|r| r.include?(i) } }
end

כאשר @to_check זה רשימת הערכים שצריך לבדוק, @fresh_ids זו רשימת הטווחים ו include? בודק אם טווח מכיל מספר. יש פה לולאה כפולה שרצה על כל אחד מהמספרים לבדוק ובודקת אותו מול כל אחד מהטווחים.

חלק 2 חיפוש כל הדברים
בחלק השני התבקשנו לספור כמה אלמנטים שונים מוכלים בכל הטווחים. לדוגמה עבור רשימת הטווחים:

3-5
10-14
16-20
12-18

התשובה היא 14 כלומר המספרים 3, 4, 5, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 ו 20.

פה כבר ברור שהלולאה הכפולה לא תעבוד כי בקלט אמיתי יש יותר מדי ערכים לבדוק. גם לפרק את הטווחים למספרים שלהם ולסנן כפולים (הרעיון השני שלי) יהיה בזבזני ולא יצליח להתמודד עם הקלט הארוך. מה עושים? זוכרים שטווחים הם רציפים ולכן המטרה שלנו היא לבנות רשימה של טווחים ללא חפיפות, כלומר את רשימת הטווחים מהדוגמה נרצה להפוך לרשימה:

3-5
10-20

איך עושים את זה? מתחילים עם רשימה ריקה, כל פעם שקוראים טווח מחפשים את כל הטווחים שמתנגשים איתו (או שהם מכילים אותו, או שהוא מכיל אותם, או שהם מכילים את ההתחלה של הטווח החדש או את הסוף שלו), מוחקים אותם ומייצרים טווח חדש שמכיל את כל מה שמחקנו ואת הדבר החדש. חוזרים על זה בלולאה עד שכיסינו את כל הטווחים. זה הקוד:

def add_range(r)
  affected, unaffected = ranges.partition do |range|
    range.cover?(r) || r.cover?(range) || range.cover?(r.begin) || range.cover?(r.end)
  end

  self.ranges = unaffected
  new_range = ([*affected, r].map {|r| r.begin }.min)..([*affected, r].map {|r| r.end }.max)
  return add_range(new_range) unless affected.empty?

  self.ranges << r
end

אלה מכם שצריכים הסבר נוסף מוזמנים להדביק את הפונקציה למנוע AI לבחירתכם ולבקש הסבר כולל דוגמאות מבטיח שהתוצאה מעניינת.

סך הכל זה הקוד המלא של הפתרון:

require 'set'

class RangeSet
  attr_accessor :ranges

  def initialize
    @ranges = []
  end

  def add_range(r)
    affected, unaffected = ranges.partition do |range|
      range.cover?(r) || r.cover?(range) || range.cover?(r.begin) || range.cover?(r.end)
    end

    self.ranges = unaffected
    new_range = ([*affected, r].map {|r| r.begin }.min)..([*affected, r].map {|r| r.end }.max)
    return add_range(new_range) unless affected.empty?

    self.ranges << r
  end
end

class Day5
  attr_accessor :fresh_ids, :to_check
  def initialize(fname)
    fresh_ids, to_check = File
      .read(fname)
      .lines
      .map {|l| l.strip }
      .slice_when {|e1, e2| e1.empty? }
      .to_a

    @fresh_ids = fresh_ids.reject(&:empty?).map do |r|
      r.split("-").map(&:to_i).then {|a| Range.new(*a) }
    end
    @to_check = to_check.map(&:to_i)
  end

  def part1
    @to_check.count {|i| @fresh_ids.any? {|r| r.include?(i) } }
  end

  def part2
    stock = RangeSet.new
    @fresh_ids.each {|r| stock.add_range(r) }
    stock
  end
end

if $PROGRAM_NAME == __FILE__
  d = Day5.new("input.txt")
  pp d.part1
  pp d.part2.ranges.map {|r| r.size }.sum
end

לימודי תכנות עם AI - מה יותר קל, מה יותר קשה ולאן זה הולך
חבר שואל - אני רוצה ללמוד תכנות אבל לא בטוח אם יש טעם. אני רוצה לעבוד בפיתוח אבל כל מה שאני רוצה לכתוב ה AI כותב טוב יותר. מי צריך אותי שם בכלל?

בואו נתחיל בלשים את הקלפים על השולחן: ג'מיני יודע היום לכתוב משחק סנייק יותר טוב ויותר מהר ממה שאני כותב. קלוד כתב לי משחק כרטיסיות ללימוד ספרדית עם מנגנון Spaced Repetition כשכל המידע שמור בקבצי טקסט והתרגול משורת הפקודה (ראסט כמובן). לא יהיה הזוי להגיד שכבר היום או בעתיד המאוד קרוב מנועי AI יוכלו לפתור כל תרגיל תכנות של בית ספר יותר טוב מהתלמידים וכנראה גם יותר טוב מהמורה.

עכשיו מה זה אומר עלינו?

מה יותר קל
עברו מזמן הימים בהם אנחנו צריכים להזיע רק כדי שתוכנית תתקמפל, תרוץ או אפילו תחזיר תשובה נכונה. יש לך בעיית קומפילציה? תדביק אותה ל AI ותקבל הסבר מלא לבעיה (כולל אפשרות לשאול שאלות המשך). התוכנית התרסקה בגלל בעיית זכרון? ה AI ימצא לך את הטעות. התוכנית לא החזירה את התשובה הנכונה? ה AI יסביר למה. התוכנית נראית עובדת? בוא ניתן ל AI לקרוא ולוודא שהכל נכון ב 100% ולהציע שיפורים. והדובדבן על הקצפת - אחרי שכבר סיימתי את כל התרגילים אני יכול לבקש מ AI לייצר לי קבוצה נוספת של תרגולים כדי לוודא שהבנתי הכל.

מי שרוצה ללמוד יכול לקבל היום מורה פרטי 24/7 שמסביר כל פרט ומכיר את כל ההיסטוריה. אז נכון מנועי AI (לדעתי) לא מספיק טובים בבניית סילבוס או בהסבר מאפס, אבל בתור מוצר משלים לקורס הם משפרים כל חוויה לימודית.

מה יותר קשה
הבעיה שאנחנו לא מצליחים לעצור שם. החוויה הלימודית האנושית של בוגרי מערכת החינוך היא מרדף אחרי הצלחות קטנות, מרוץ כדי לסמן V ולהצליח במבחן. בעולם של AI זאת בעיה, כי כל תרגיל לימודי שתנסו לעשות ה AI יכול לפתור בשבילכם יותר מהר.

הבעיה הזאת דומה לבעיה של תלמידי יסודי עם מחשבון. הם לא מבינים למה להתאמץ לפתור תרגיל חשבון בלי מחשבון ואנחנו לא מבינים למה להתאמץ לכתוב תוכנית בלי AI. אבל ההבדל הוא תהומי: תלמידי בית ספר יסודי לומדים כי הם יודעים שבמבחן המורה לא תתן להם להשתמש במחשבון, וכי הם עוד קטנים. מי שלומד תכנות חושב על אופציות לתעסוקה וכרגע קשה לו מאוד לראות איזה ערך הוא יקבל מלימודי תכנות. "מה זה מה שאני אעשה כל היום? אגיד ל AI איזה קוד לכתוב?".

ה AI, בכך שהופך את לימודי התכנות להרבה יותר קלים, מוריד משמעותית מהמוטיבציה ללמוד. בגלל שאנחנו לא יודעים איך יראו החיים המקצועיים של מפתחי תוכנה בעוד שנתיים אנחנו מרגישים שקשה להתחייב וללמוד תכנות, שאולי לא יהיה בו צורך.

ובכל זאת
מתכנתים היום שעובדים עם AI מתחלקים ל-2. יש את מי שמשתמש ב AI כדי להשתפר, מבין כל שורה שה AI כותב ודואג שה AI יכתוב את הקוד שהוא היה כותב בעצמו. כן ה AI כותב בדקה משחק סנייק שהיה לוקח לי יום לכתוב וזה מדהים, אבל בגלל שכתבתי כבר משחקי סנייק דומים אני יכול להסתכל על משחק הסנייק שה AI כתב ולוודא שהוא זהה למה שאני הייתי כותב. כן ה AI כותב אלף בדיקות יותר מהר ממה שלוקח לי לשים כוס קפה, אבל מספיק לי לרוץ על הבדיקות האלה בעין כמה דקות כדי להבין אם הוא היה בכיוון או אם צריך להעיף את כל הבדיקות ולייצר אותן מחדש עם פרומפט יותר מדויק.

סוג שני של מפתחים מעדיפים לדלג על הקוד ולהתמקד ב Spec בצד אחד וב Output בצד שני. הם ינסחו יחד עם ה AI מפרט בדיקות מדויק לאותו משחק סנייק ואז יוודאו שהקוד עושה מה שצריך לפי המפרט. הם לא רוצים לדעת מה כתוב שם וממילא מרגישים שזה בזבוז זמן. לא צריך ללמוד מה זה עץ אדום שחור ומתי להשתמש בו במערכת אמיתית, מספיק לאפיין ל AI מה רמת הביצועים הנדרשת ושה AI יבחר איזה מבנה נתונים יתאים.

וצריך להגיד ביושר, אנחנו לא יודעים איך יראו החיים המקצועיים של מפתחי תוכנה בעוד שנתיים, ארבע או שמונה שנים, ואם הם יהיו יותר דומים לתיאור הראשון או השני. כל תיאור מתאים לעבודה אחרת, ואנחנו צריכים לבחור "מה אנחנו רוצים להיות" בלי לדעת אם הדבר שנבחר בכלל יהיה קיים כשנסיים את הלימודים.

ובכל זאת, שני התיאורים כן עוזרים לנו לתכנן קצת יותר בבירור את ההמשך. הנה הנקודות המרכזיות שהייתי משאיר בראש:

1. סיכוי טוב שבעשור הקרוב נמשיך לראות את שני סוגי התפקידים. יהיו לא מעט אנשים שייכנסו לקוד ואם אתם אוהבים את ההיבט הטכני של איך דברים בנויים ועובדים זה מסלול שכדאי לקחת. יש פה גם הרבה כיף. יהיו גם לא מעט אנשים שיאפיינו מערכות ופיצ'רים לסוכני AI ואם אתם מסוג האנשים שאוהבים לתכנן מה לבנות החיים שלכם כנראה יהיו הרבה יותר מעניינים בזכות ה AI. היום אנחנו קוראים לתפקידים מהסוג הראשון מפתחי תוכנה ומהסוג השני מנהלי מוצר, אבל ההיבטים הספציפיים של כל תפקיד הולכים בוודאי להשתנות.

2. אם העולם של פיתוח תוכנה מעניין אתכם כדאי להסתכל על AI בתור "מורה" ולא בתור "עובד". אתם לא בתחרות איתו, אתם כן צריכים להבין כל שורת קוד ולהיות מסוגלים לכתוב כל מערכת בעצמכם.

3. מפתחי תוכנה עדיין לומדים הכי טוב דרך הקלדה. AI לא משנה את זה. כדאי לחשוב על AI כמו ספר לימוד ולא כמו מחשבון.

ולחבר מהפתיח הייתי אומר - אתה צודק. כל מה שאתה כותב היום ה AI כותב טוב יותר. כרגע מבחוץ זה נראה כאילו AI כותב קוד יותר טוב ויותר מהר מכל האנשים שאתה מכיר וקשה להבין למה צריך מתכנתים בעולם. אבל דברים שרואים מכאן לא רואים משם והאמת היא שהבנה מערכתית, היכרות לעומק עם עולם פיתוח התוכנה ובעיקר יכולת ניתוח וחשיבה עם המושגים בעולם זה היא עדיין רחוקה מהיכולות של מערכות AI. במובן מסוים AI העלה את הרף והגביר את קצב הלימוד האפשרי. בזכות ה AI אתה לומד יותר מהר, אבל כך גם כל המתחרים שלך שמתמודדים על אותם תפקידים בתעשייה.

ובאותו נושא שווה לקרוא גם את הפוסט האחרון של הסולידית:
https://www.hasolidit.com/וייב-קודינג-לעצמאות-כלכלית. שאלת המפתח שלה:

"אם הדיוטה כמוני יכולה “לשאול” מיומנות בהינף רגע, יכולת שאחרים השקיעו שנים כדי לרכוש ולפתח, האם עוד אפשר בכלל להתייחס אליה כמיומנות?"

אני מבין למה זה נראה ככה מבחוץ. מבפנים אנחנו יודעים שרוב מוחלט של המפתחים בתעשייה לא בונים מערכות שאפשר להחליף עם Vibe Coding. כשהתחיל טרנד ה Outsource חבר הזהיר אותי שעוד רגע לא יהיו בארץ מפתחי תוכנה כי הכל יעבור להודו. עברו כמעט 20 שנה ואנחנו עוד פה ועדיין כותבים קוד. כן וייב קודינג זה מדליק אבל זה רחוק מלאיים על העולם של פיתוח תוכנה.

מה דעתכם? אם הייתם מתחילים היום ללמוד תכנות הייתם מעדיפים לרוץ ולבנות פרויקטים עם AI בתור עובד או ללמוד מה עושה כל שורה עם AI בתור מורה? ולמה?

אז ה AI טעה בשם של הפונקציה
איך מבלבלים את קלוד? מסתבר שבקלות ואפילו בלי להתכוון. זה הקוד שהיה צריך לכתוב:

token_translations.each do |tt|
  word = tt.original_text
  translation = tt.translation

רואים את הבעיה? אפילו לפני שקלוד מתחיל לממש אנחנו מבינים שמשהו לא מסתדר, האם צריך את הסיומת _text או לא? ואכן כשביקשתי מקלוד לממש את הלולאה במקום אחר הוא כתב:

token_translations.each do |tt|
  word = tt.original_text
  translation = tt.translation_text

ואני אפילו לא יכול להאשים אותו. זה נראה כל כך יותר נכון ככה.

קוד צפוי הוא קוד קריא יותר ולהיפך. כש AI טועה בשם הפונקציה זו אינדיקציה חשובה לבעיית קריאות. לדעת לעבוד עם AI זה לא לא לכתוב קובץ Instructions ולזכור להוסיף לכל פרומפט שהוא צריך לוודא את השמות של הפונקציות. לדעת לעבוד עם AI זה קודם כל לשים לב שהטעות שלו היא הגיונית לגמרי ואז לתקן את הפרויקט.

עוד מאותו דבר
קלוד קוד יודע לפתור את כל Advent Of Code של השנה בשעתיים. זה בטוח יותר מהר ממני וכנראה יותר מהר מרוב בני האדם שניסו. וככל שהכלים האלה משתפרים אנחנו מבינים טוב יותר את העבודה שלנו כמהנדסי תוכנה:

1. פתרון בעיות מורכבות, כאלה שלא מופיעות בספר הלימוד, ודורשות אינטגרציה של חומר והתאמה אישית של רעיונות כלליים לעולם תוכן ספציפי.

2. תושיה - למצוא דרכים בטוחות וטובות לעשות דברים גם כשהרעיון הראשון לא עובד.

3. עבודת צוות.

4. תקשורת טובה עם עמיתים ומנהלים.

5. אמינות.

6. מבנה פרויקט שמאפשר לאוטומציה להתקדם יותר מהר עם הקוד - זה כולל גם את הקוד עצמו וגם הקמת סביבת בדיקות, מסמכים מלווים, יכולת להרים פרויקט בלחיצה אחת בסביבה נייטרלית, נתוני seed.

7. הבנת המסגרת, המגבלות, היכולות, הארגון.

בראייה קדימה הפיצ'רים היחידים שמפתחים צריכים לבנות הם פיתוחי תשתית. כל מה שהוא "עוד מאותו דבר" ניתן ל AI, עדיף לאנשי פרודקאקט טכניים ומוכשרים שישמחו לשחק עם הכלים החדשים. שתי השאלות החשובות שאנחנו חייבים לשאול היום על כל פיצ'ר שאנחנו בונים:

1. האם AI יכול לבנות את זה?

2. אם לא, איך צריכה להיראות המערכת כדי ש AI יוכל לבנות את זה?

בדיקות של AI נגד בדיקות של בני אדם
איזה כיף לעשות Code Review ל AI! נתתי לו לכתוב משחק סנייק עם בדיקות בפרויקט ריק, כלומר לא היו דוגמאות איזה בדיקות צריך לכתוב ואיזה בדיקות לא. התוצאה הזכירה לי ש AI כמעט תמיד יכתוב קוד שנראה טוב וזה חלק ממה שמאוד מבלבל בעבודה איתו.

הוא התחיל את קובץ הבדיקות בהגדרת אוביקט mock:

mockContext = {
  clearRect: vi.fn(),
  fillRect: vi.fn(),
  fillText: vi.fn(),
  measureText: vi.fn(() => ({ width: 100 })),
  beginPath: vi.fn(),
  arc: vi.fn(),
  fill: vi.fn(),
  stroke: vi.fn(),
  moveTo: vi.fn(),
  lineTo: vi.fn(),
  textAlign: 'left',
  textBaseline: 'alphabetic',
} as unknown as CanvasRenderingContext2D;

ואנחנו כבר רואים שמשהו כאן חשוד. מצד אחד הוא מנסה להגדיר אוביקט mock שיתנהג בדיוק כמו CanvasRenderingContext2D אבל מצד שני הוא לא מגדיר את כל הפונקציות והמאפיינים של האוביקט המקורי.

הצעד הבא זה איפה שדברים הופכים מעניינים עם בדיקות כמו:

it('should update snake head position correctly', () => {
  render(<Home />);
  const initialCalls = mockContext.fillRect.mock.calls.length;
  
  act(() => {
    vi.advanceTimersByTime(150);
  });
  
  expect(mockContext.fillRect.mock.calls.length).toBeGreaterThan(initialCalls);
});

לבדיקה יש כותבת "צריך לעדכן את ראש הנחש בצורה נכונה" אבל הבדיקה עצמה רק מוודאת שפונקציית fillRect נקראה אחרי זמן שהוגדר מראש. הבדיקה הזאת גרועה כי:

1. הזמן 150 כתוב כמספר קסם בקוד הבדיקה למרות שבקוד המשחק הוא מופיע כקבוע. מי שישנה אותו בקוד המשחק יצטרך להתמודד עם עשרות בדיקות שיישברו סתם.

2. היא לא בודקת מה שהיא צריכה לבדוק. אם הנחש לא זז ורק מפעילים את fillRect כדי לצייר עוד ועוד מלבנים באותה נקודה הבדיקה עדיין תעבור.

3. היא משתמשת בפרוקסי - מספר הקריאות ל fillRect במקום לבדוק את הדבר האמיתי.

יש שתי גישות כן לבדוק את הלוגיקה של תזוזת ראש הנחש במשחק סנייק: דרך אחת היא להסתכל מה באמת מופיע על המסך, אני יכול לעשות את זה עם ספריה כמו node-canvas ולוודא שמה שצויר ב canvas אכן תואם את הציפיות שלי. דרך שניה היא לארגן אחרת את הקוד כדי שתהיה לי גישה למבנה הנתונים שמייצג את הנחש ואז אני מסתכל על הקואורדינטות של הנחש במבנה הנתונים.

ברור שאפשר לכתוב את זה במסמך דרישות ולהיות מפורשים בפרומפטים שלנו, אבל אני חושב שזו לא הדרך הכי אפקטיבית לעבוד עם AI. עלינו לשים לב שהדרך הכי טובה להסביר ל AI איך לכתוב את הבדיקות היא בדיוק לעשות את הצעד הקשה של לכתוב את שתי הבדיקות הראשונות. אחרי שיש במערכת שתי בדיקות שבודקות את מבנה הנתונים של הנחש אחרי תזוזה ה AI יוכל להשתמש בתבנית ולייצר עוד 50 בדיקות באותו סגנון.

במקום למדוד כך באמת תגדילו את שימוש המפתחים ב AI
מנהלים, עדיין מודדים כמה זמן מפתחים מבלים עם AI? עדיין מתעקשים על כלי AI ספציפי ולא מבינים למה כולם מדברים על היתרונות של AI ורק אצלכם המפתחים לא משתמשים בו? בואו נפתח את זה.

אם תשאלו את המפתחים למה הם לא משתמשים יותר ב AI התשובה הראשונה שתקבלו היא התירוץ - ה AI לא מתאים לנו. אצלנו הפרויקט ישן ו AI מתאים רק לפרויקט חדש, ה AI מתאים לפייתון ואנחנו כותבים ב Go, ה AI עוזר רק בפיתוח פיצ'רים ואצלנו רוב העבודה היא מחקר, אנחנו עושים משהו שאף אחד אחר לא עושה. תירוצים.

אם תלחצו קצת תוכלו להגיע לאמת - הם ניסו להשתמש ב AI וקיבלו תוצאות פח. אחרי פעמיים שלוש שקיבלת תוצאות גרועות אתה מבין שמשהו לא כמו בפרסומת וממשיך הלאה. מנהלים שנמצאים בסיטואציה הזאת לא יכולים להתעקש על שימוש ב AI, כי זה אומר להתעקש על תוצאות פח. אף אחד לא רוצה תוצאות פח.

מה שאנחנו צריכים לעשות במקום זה להבין למה ה AI נותן תוצאות פח ואיך לגרום לו לתת תוצאות שישפרו את הפרודוקטיביות של המפתחים פי 10 כמו בפרסומת. הנה כמה דברים שכדאי לעשות, לפי סדר חשיבות:

1. לקבוע פגישה שבועית בצוותי עבודה קטנים בה אנשים משתפים מה הם ניסו לעשות עם AI, מה הצליח ומה לא הצליח. גם הדברים שהצליחו וגם הדברים שלא הצליחו שווים זהב כי כך אנחנו מבינים את ההזדמנויות ואת הפערים.

2. כשתתחילו את הפגישות האלה אתם תראו שחלק אחד מהכשלונות מגיע מפערים בקוד. ה AI מנסה להשלים את הפערים לפי נתוני האימון שלו אבל הקוד שלכם יותר מדי שונה מנתוני האימון של המודל. נתיב שיפור ראשון הוא לעדכן את הקוד כדי שיתאים למודל: שינוי שמות, שינוי היררכיות, עדכוני גרסאות בספריות. מה שצריך.

3. אתם תגלו גם שתוצאות טובות מגיעות כשלמודל יש את כל המידע הדרוש כדי לענות על השאלות שלכם. זה יעודד אתכם לייצר מסמכים ספציפיים ל AI ולחבר אותו למערכות הידע הארגוני הקיימות, אולי בעזרת MCP.

4. כשתתנו ל AI לכתוב קוד אתם תגלו שנדרשות מספר איטרציות מהן המודל יכול "ללמוד" מה עבד ומה לא, כלומר ה AI צריך דרך להרים את הפרויקט על מכונת בדיקה בצד ולראות אם התיקון שלו עבד. כדאי שתהיה גם חבילה של בדיקות אוטומטיות שאפשר יהיה להריץ כדי להבין שלא נשבר כלום. זכרו שזאת מכונה שכותבת את הקוד אין שם חשיבה ולכן נדיר מאוד שהתוצאה הראשונה היא הנכונה.

כל הסיפור הזה הוא תהליך לא השקעה חד פעמית. בהתחלה כמובן שתהיה השקעה גדולה אבל זכרו שכל עוד AI כותב קוד האבסטרקציות לאורך זמן מתקלקלות, הבדיקות נהיות פחות מדויקות והמסמכים פחות עדכניים. לא מוזר שפרויקט שמשתמש ב AI לפיתוח דורש מפתחים שישמרו על ה AI ויתאימו כל הזמן את המערכת לדרישות שלו. ועדיין יש אמת בפרסום. שימוש נכון ב AI בתהליך הפיתוח יכול לתת תשואה של פי 5 ויותר במהירות הפיתוח תוך כדי שיפור איכות הקוד. כלומר אנחנו גם כותבים מערכות טובות יותר, גם לומדים יותר דברים ומשפרים את הכישורים שלנו כמפתחים וגם עושים את הכל יותר מהר. כשזה עובד אף אחד לא צריך למדוד שימוש ב AI כי התוצאות מדברות בעד עצמן.

צריכים עזרה לשלב AI בתהליך הפיתוח? מרגישים שלא מקבלים את התוצאות שבפרסומת? תשאירו לי הודעה

ללמוד לחשוב על בעיות קטנות וגדולות
האם ללמוד לחשוב על שאלות קטנות עוזר לנו ללמוד לחשוב על שאלות גדולות?

האם לדעת לכתוב סקריפט שממיין מספרים נותן לך בהמשך כלים לבנות ארכיטקטורה גדולה יותר של מערכות מורכבות?

השאלה הזאת עומדת בלב "החלק הטכני" בראיונות העבודה לתכנות, החלק שתקופה ארוכה הטיל אימה על מחפשי עבודה רבים. אין ספק ששאלות האלגוריתמים הקטנות שמופיעות בראיונות עבודה נגמרות שם וברוב מוחלט של עבודות הפיתוח אנחנו לא כותבים פונקציית מיון מאפס. וכן צריך לזכור את ה AI כי הוא כבר חלק מהעולם ולשאול "האם פתרון בעיות תכנות ש AI יכול לפתור שקול לפתרון תרגיל חשבון עם מחשבון?", כלומר נחמד אבל חסר ערך מעשי.

גם אני עדיין מחפש את התשובה אני רוצה לשתף כמה מחשבות בכיוון:

1. הרבה בעיות של תוכניות קטנות לא קיימות בתוכניות גדולות ולהיפך.

2. יש דברים משותפים בין בעיות קטנות וגדולות. שני המקרים דורשים צורת חשיבה מסוימת, שני המקרים דורשים בנייה של דבר גדול מחלקים קטנים יותר ומחשבה על אינטרקציה בין חלקים שונים, שני המקרים עשויים להפתיע כשהנחות היסוד משתנות בגלל שינוי אפיון.

3. מה קורה בתחומים אחרים? ללמוד לנהוג על גיר ידני יעשה אותך נהג טוב יותר עם הגיר האוטומטי? ללמוד לקרוא מפה ייתן לך יותר כלי ניווט בהשוואה לניווט עם GPS? לפתור תרגילים בלי מחשבון יעזור לך בהוכחות מתמטיות? לכתוב מכתבים לחברים יעזור לך לכתוב ספר שירה טוב יותר? לפעמים, אבל נשמע שבהרבה מקרים אנחנו בוחרים ללמוד את "השיטה הישנה" רק כגיבוי, למקרה שהטכנולוגיה לא תהיה שם. אנחנו לא חושבים שמי שיודע לנווט עם מפה ישתמש בווייז טוב יותר.

4. אנחנו כן חושבים שהבנה של היסודות עוזרת לפתור בעיות מורכבות. הדבר החשוב הוא להבין איך דברים עובדים. להבין למה נוסחה מתמטית מסוימת נכונה חשוב הרבה יותר מאשר להצליח לפתור מהר יותר תרגיל באמצעותה.

5. האם אפשר באמת להבין איך דברים עובדים בלי קודם לכתוב אותם בעצמך? האם אפשר להבין מתמטיקה בלי לפתור לפני זה תרגילים בחשבון? האם היה אפשר לתת לילדים מחשבון מכתה א? אני מרגיש שלא אבל לא לגמרי מבין למה.

לכאורה עברנו את ההתלבטות הזאת כשהופיע Stack Overflow. עד אז היינו צריכים לקרוא תיעוד ואחרי SO הספיק לנו חיפוש מהיר בגוגל כדי להגיע לכל תשובה. אני חושב שהקפיצה היום עם ה AI היא גדולה יותר וזה הופך את השאלה לבוערת יותר. אין יותר בעיות קטנות ש AI לא יכול לפתור. זה לא קיים. הוא עובר ראיונות עבודה, הוא פותר את פרויקט אוילר, הוא פותר מבחנים. אין לי דרך היום בקורס לתת בעיה קטנה לתרגול ש AI לא יפתור יותר טוב מהתלמידים. ועדיין אני מרגיש שיהיה קשה למישהו ללמוד ריאקט בלי לכתוב תוכניות קטנות לפני שמתחילים לכתוב תוכניות גדולות. אבל אולי זה רק בגלל שגדלתי בעולם הישן.

המשחק הקצר, המשחק הארוך
בלוגר שמסתכל על המשחק הקצר יודע שכשהוא יכתוב פוסט ממש ויראלי כל האינטרנט יגיעו אליו וכולם יקנו את המוצר שלו. במשחק הארוך אין הטיפה חוצבת בסלע מכוח עוצמתה אלא מכוח התמדתה. כתיבה עוזרת לשים לב לדברים ובלוג טוב מעלה את הרמה לכולם.

יזם שמסתכל על המשחק הקצר יודע ששבוע הבא יש דמו וצריך לתת את המקסימום ויותר ואם צריך כולם נשארים לישון במשרד כי חייבים להשיג השקעה לפרויקט. במשחק הארוך פרויקט שמושך משתמשים ומהווה מוצר חיוני לקבוצה ימצא את הדרך להרוויח.

מפתח שמסתכל על המשחק הקצר חייב לסיים את הפיצ'ר גם אם הוא לא מבין 100% מהקוד. אם זה עובד לא נוגעים. במשחק הארוך מפתחים בונים קריירה ומיומנות ואלה חשובות יותר מהקדמת לו"ז בפיצ'ר מסוים.

ובעבודה עם AI במשחק הקצר כולנו במתח מה המודלים יכולים או לא יכולים לעשות ואיך ה AI בונה כמה שיותר מהר את הפיצ'ר. במשחק הארוך הרבה יותר מעניין להסתכל איפה המודל לא מיושר עם המערכת שלנו ואיך לשנות את התשתית כדי לקבל תוצאות טובות יותר.

כלל אצבע טוב למחפשים את המשחק הארוך - התרחקו מקרבות הכרעה ומרגעי "הכל או כלום" וכשרגעים כאלה מתקרבים חפשו את ההשפעה לטווח הרחוק של כל החלטה.

לייטנסי
שליחת פקודת insert של אלף שורות משמעותית יותר מהירה משליחת אלף פקודות insert. כשנסתכל על לוחות הבקרה של שרתים שמבצעים יותר מדי קריאות ל DB לא נראה שמישהו עובד קשה מדי: הרשת לא עמוסה, המעבד לא מזיע והזכרון ריק. כולם מחכים שמעט מידע יעבור מצד לצד. אפשר לדמיין את זה כמו צינור רחב מאוד שמישהו מזרים דרכו זרזיף מים. הצינור פנוי לגמרי, אם היו לך עוד מים להעביר הם לא היו צריכים לחכות, אבל אתה החלטת להעביר את המים שלך בטיפטופים.

השבוע נעזרתי ב AI לכתוב סקריפט שמעביר מידע ממקום למקום ב Batch-ים. הקריאה אכן בוצעה ב Batch עם limit כמו שתכננתי, אבל בכתיבה קרה משהו אחר. כנראה בגלל שהיתה בקוד פונקציה שכותבת שורה בודדת ל DB ה AI השתמש בה בלולאה כדי לכתוב את כל ה Batch במקום לכתוב פונקציה חדשה שתכתוב את כל ה Batch ב insert אחד. את הבדיקה הרצתי על בסיס נתונים מקומי ולכן לא ייחסתי לזה חשיבות.

בהרצת הסקריפט בסביבה אמיתית האיטיות היתה מאוד ברורה. עם הפרומפט הנכון לקח ל AI רק כמה דקות לכתוב את הפונקציה של ה Bulk Insert ולעדכן את הסקריפט שישתמש בה במקום בלולאה הישנה. זה עבד בנסיון הראשון.

עכשיו לשאלה - האם זה באג?

בעולם שלפני ה AI המעבר בין שתי הגרסאות היה לוקח לפחות חצי יום. יש פה פונקציה של 100 שורות לכתוב ועוד שינויי קוד במקומות אחרים מפוזרים. ברור מה צריך לעשות אבל ה"איך" היה דורש כתיבה ובדיקה. היום החצי יום הזה מבוצע בחמש דקות ומספיק מבט זריז כדי להבין שזה הצליח ולהריץ על השרת. בעולם שלפני ה AI "גילוי" של בעיית latency רק בהרצה הראשונה על נתוני אמת היה מתסכל את כולם. בעולם שאחרי ה AI זה כאילו יש מתג, המעבר משיטת עבודה אחת לאחרת הוא בסך הכל לחיצה על כפתור. קסם.

בעולם שלפני ה AI היה חשוב לתכנן מראש ל Latency של סביבת הפרודקשן. בעולם שאחרי ה AI חשוב לבנות את הקוד בצורה שתאפשר לשנות את ההחלטה בלחיצת כפתור. זה השינוי הגדול שאנחנו צריכים לאמץ וההשקעה הגדולה בתשתית שנצטרך לבצע, לבנות פרויקטים ש AI יוכל לשפר.