הבלוג של ינון פרק

טיפים קצרים וחדשות למתכנתים

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

28/07/2025

מתכנתת פרונט אנד כתבה ברדיט-

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

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

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

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

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

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

כמה רעיונות יותר טובים מהשלמת טאבים כדי ללמוד

27/07/2025

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

ויש בזה לא מעט.

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

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

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

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

  2. לתת ל AI לכתוב את הקוד דרך Agent Mode בחלון הצד ואז לעבור על הקוד ולשאול עליו שאלות. דיאלוג מאלץ אותנו להבין ולחשוב יותר מאשר צפייה במישהו אחר עושה.

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

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

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

  6. לתת ל AI לממש ולהעתיק אלינו לקוד כל פעם פונקציה או בלוק קצר אפילו ב Copy/Paste. לקרוא, לוודא שהבנתם ולתת Code Review ל AI על כל בלוק כזה.

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

טיפ רובי: מילים ואינדקסים במחרוזת

26/07/2025

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

3.3.5 :027 > "hello world".split
 => ["hello", "world"]

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

3.3.5 :029 > "Don't. go. there".split
 => ["Don't.", "go.", "there"]

שהיה עובד הרבה יותר טוב בלי הנקודות שצמודות למילים. דרך אחת לסדר את זה היא לחפש "התאמות" במקום "הפרדות" ובשביל זה יש לנו את scan:

3.3.5 :032 > "Don't. go. there".scan(/\p{L}+(?:'\p{L}+)*/u)
 => ["Don't", "go", "there"]

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

3.3.5 :036 > text = "Don't means Don't - Don't press the button"
 => "Don't means Don't - Don't press the button"
3.3.5 :037 > third_word = text.scan(/\p{L}+(?:'\p{L}+)*/u)[2]
 => "Don't"
3.3.5 :038 > index_of_third_word = text.index(third_word)
 => 0

זה החזיר 0 כי המילה השלישית זהה למילה הראשונה.

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

3.3.5 :039 > class String
3.3.5 :040 >     def tokenize
3.3.5 :041 >     regex = Regexp.new(/\p{L}+(?:'\p{L}+)*/u)
3.3.5 :042 >
3.3.5 :043 >     Enumerator.new do |y|
3.3.5 :044 >       pos = 0
3.3.5 :045 >       while m = regex.match(self, pos)
3.3.5 :046 >         y << m
3.3.5 :047 >         pos = m.end(0)
3.3.5 :048 >       end
3.3.5 :049 >     end
3.3.5 :050 >   end
3.3.5 :051 > end

3.3.5 :056 > text.tokenize.to_a
 =>
[#<MatchData "Don't">,
 #<MatchData "means">,
 #<MatchData "Don't">,
 #<MatchData "Don't">,
 #<MatchData "press">,
 #<MatchData "the">,
 #<MatchData "button">]

עכשיו בשביל לקבל את כל המילים ואינדקס ההתחלה של כל מילה אני כותב:

3.3.5 :057 > text.tokenize.map { |m| [m.to_s, m.begin(0)] }
 => [["Don't", 0], ["means", 6], ["Don't", 12], ["Don't", 20], ["press", 26], ["the", 32], ["button", 36]]

ובשביל לקבל את אינדקס ההתחלה של המילה השלישית אני כותב:

3.3.5 :060 > text.tokenize.drop(2).first.begin(0)
 => 12

ואם קלוד החזיר לי PR של 700 שורות?

25/07/2025

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

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

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

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

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

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

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

המטרה היא לא לתת לקלוד לכתוב 100% מהקוד. המטרה היא להשתמש בקלוד כדי להתקדם מהר יותר ולבנות מערכות יציבות יותר, יפות יותר וטובות יותר.

לחפש את ה"נכון"

24/07/2025

אחד היתרונות של מפתחים מנוסים שמתחילים לעבוד עם AI הוא היכולת להבדיל בין קודבייס "נכון" לקודבייס מסורבל. מרסל ניומן סיפק דוגמה לכזאת אבחנה בפוסט שפרסם על פיתוח אפליקציית Cross Platform עם React Native.

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

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

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

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

תשומת לב - המיומנות של העשור הבא

23/07/2025

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

test 'Person name with only spaces is trimmed to empty' do
  b = Person.new(name: '   ')
  b.save
  assert_equal('', b.name)
end

הבדיקה עברה ואני קיבלתי את ה PR. הבעיה היחידה? במערכת יש וולידציה שמוודאת ש name לא יכול להיות ריק.

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

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

test 'Person name with only spaces is trimmed to empty' do
  b = Person.new(name: '   ')
  b.valid? # trigger validation to trim b.name
  assert_equal('', b.name)
end

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

איך לשלוח הודעות עדכון מ Tools ב Vercel AI SDK

22/07/2025

בדוגמה מהאתר של Vercel AI SDK הם מראים איך לקרוא לכלים מתוך הסוכן עם הקוד הבא:

import { z } from 'zod';
import { generateText, tool } from 'ai';

const result = await generateText({
  model: yourModel,
  tools: {
    weather: tool({
      description: 'Get the weather in a location',
      parameters: z.object({
        location: z.string().describe('The location to get the weather for'),
      }),
      execute: async ({ location }) => ({
        location,
        temperature: 72 + Math.floor(Math.random() * 21) - 10,
      }),
    }),
  },
  prompt: 'What is the weather in San Francisco?',
});

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

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

  1. צריך ליצור את ה Stream בצורה יזומה לפני שמפעילים generateText, ואז לחבר את הפלט של generateText ל Stream שיצרנו.

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

writer.write('0:"hello"');

אבל יותר קל להשתמש בפונקציה מובנית שלהם שנקראת formatDataStreamPart.

התוצאה נראית כך:

import { openai } from '@ai-sdk/openai';
import { generateId, createDataStreamResponse, streamText, formatDataStreamPart } from 'ai';

import tools from '@/lib/tools';

// Allow streaming responses up to 30 seconds
export const maxDuration = 30;

export async function POST(req: Request) {
  const { messages, data } = await req.json();

  // immediately start streaming (solves RAG issues with status, etc.)
  return createDataStreamResponse({
    execute: dataStream => {
      dataStream.write(formatDataStreamPart('text', 'Warming up!ֿ'));
      dataStream.writeMessageAnnotation({ chunk: 'processing' });

      const result = streamText({
        model: openai('gpt-4-turbo'),
        maxSteps: 5,
        tools: tools(jwtToken, dataStream),
        messages,
        onFinish() {
          // message annotation:
          dataStream.writeMessageAnnotation({
            id: generateId(), // e.g. id from saved DB record
            other: 'information',
          });

          // call annotation:
          dataStream.writeData('call completed');
        },
      });

      result.mergeIntoDataStream(dataStream);
    },
    onError: error => {
      // Error messages are masked by default for security reasons.
      // If you want to expose the error message to the client, you can do so here:
      return error instanceof Error ? error.message : String(error);
    },
  });
}

עכשיו מתוך כל tool אפשר לקרוא ל dataStream.write כדי להוסיף הודעות לשיחה, או לבנות Workflows יותר מורכבים עם מספר סוכנים שכל אחד יוסיף הודעות לשיחה מתוך generateText שלו.

קודבייס ידידותי ל AI

21/07/2025

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

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

  1. שלוש דרכים לעשות X, אבל רק אחת עובדת.

  2. שתי טבלאות ב DB עם שמות דומים שמחזיקות מידע שקשור לדברים אחרים לגמרי.

  3. סקריפט שמריץ את הפרויקט אבל לא את כל רכיבי הפרויקט (כי יש רכיב שאף אחד לא צריך ומי שצריך יודע להריץ אותו לבד).

  4. התקנה שדורשת שינוי ידני ב DB באמצע הדרך.

  5. שפה פנימית ולא מתועדת של צוות הפיתוח.

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

בן האדם שבלופ

20/07/2025

שלוש שיחות עם קלוד-

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

קלוד עונה עם קלאס בשם GitHubIssuesManager

  1. למה בחרת לכתוב קלאס? הצג יתרונות וחסרונות של יצירת קלאס מול כתיבת פונקציות והמלץ על ארכיטקטורה.

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

def example_usage():
    """Example of how to use the functions programmatically."""
    config = create_config("your_token", "owner", "repo")

    # Open an issue
    issue = open_issue(config, "Bug found", "Description here", labels=["bug"])

    # List all open issues
    issues = list_issues(config, state="open")

    # Close an issue
    if issues:
        close_issue(config, issues[0]["number"], "Fixed!")
  1. ואיזה משתי הגישות תהיה קלה יותר עבור AI לקרוא ולתחזק?

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

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

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

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

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

19/07/2025

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

כן. כשדברים נשברים.

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

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

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