📌 להתראות TypeVar

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

from typing import TypeVar

T = TypeVar("T")

def same(x: T) -> T:
    return x

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

החל מפייתון 3.12 אפשר לשכוח מכל הכאב ראש הזה ולאמץ תחביר שמזכיר את כתיב ה Generics של שפות אחרות:

def same[T](x: T) -> T:
    return x

ולקבל את אותה תוצאה בדיוק.

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

def swap[T, S](x: T, y: S) -> tuple[S, T]:
    return y, x

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

📌 כשהשיווק מחליף שיקול דעת

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

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

כשכל התעשייה רצה לכתוב XML-ים בילינו עשור בכתיבת מערכות ששולחות ומקבלות XML.

כשכל התעשייה התחילה לכתוב Micro Services עברנו בלי להתבלבל לכתוב Micro Services בענן.

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

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

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

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

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

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

📌 דברים שעדיין קשים

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

1. להבין איך מערכת עובדת ואיך היא יכולה להישבר.
2. לראות איזה שינויים צפויים בדרישות הלקוח ואיך הקוד יסתגל לאותם שינויים.
3. לראות איזה מימוש מתאים לדרישות הלקוח, ואיזה רק נראה נכון אבל בעצם מפספס נקודות חשובות.
4. לבחור מבין מספר פתרונות את הפתרון הכי יעיל, פשוט ומתאים למשימה.
5. לשאול את השאלות הנכונות.
6. לבחור סביבת Deployment ולבנות תהליך עבודה שמביא מוצר מרעיון למשתמשים.
7. לבנות תהליכי עבודה שיוצרים חיכוך איפה שצריך ומצמצמים אותו איפה שאפשר.
8. לראות את האבסטרקציה שמאפשרת לבנות את כל המערכת.
9. לבצע פשרות כואבות גם כשכולם רוצים את הכל.

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

📌 כפול עשר

המושג 10x programmer הומצא הרבה לפני ש AI כתב את כל הקוד. הוא בא לתאר את התופעה שיש מפתחים הרבה יותר יעילים שמקפיצים את הארגון קדימה ולפעמים מפתח או מפתחת כאלה יכולים להיות שווים לארגון אפילו יותר מעשרה אחרים. אותם מפתחי 10x כמובן לא מצטיינים בגלל שהם מקלידים מהר יותר (יש גבול כמה מהר אפשר להקליד, וממילא מהירות הקלדה אף פעם לא היתה הבעיה). התכונות שהפכו אותם ליעילים היו חדות חשיבה, יכולת לראות דברים שאחרים לא ראו, יכולת קבלת החלטות, בחירת הטכנולוגיה הנכונה, בניית מערכת כך שבאגים יקרו פחות או יהיו קלים יותר לאיתור.

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

1. מעיין הקוד - אלה שכותבים עוד ועוד קוד. אם היית מודד אותם לפי שורות קוד הם בקלות כותבים כפול עשר שורות מכל האחרים, אבל שורות קוד אינן המדד לתוכנה טובה.
2. סוגרי הטיקטים - אלה שתמיד ימצאו עוד משימה קלה לפתור ומסיימים את תקופת המדידה עם כפול 10 טיקטים שנפתרו מכל השאר, כל זה בלי לעשות דבר אחד חשוב.
3. הארכיטקטים - שכל היום כותבים ומוחקים ועושים Refactor ובונים ארכיטקטורות שיוכלו להתמודד עם כל צרה שלא תבוא אבל אף פעם לא מגיעים לפרודקשן, או שמגיעים רק כדי לגלות שכל המבנה עמד על יסודות רעועים. אם המדד להצלחה הוא כמה שינויים עשית בפרויקט כל שבוע הארכיטקטים לוקחים את גביע הכפול עשר בלי להתבלבל.
4. הכמעט עובד - הם מתקתקים פיצ'רים וזה באמת נראה עובד אבל יש רק מקרה קצה אחד שעדיין לא הגיעו אליו או כמה בעיות פרודקשן קטנות. האמת היא שקיצורי הדרך שהם לוקחים לא מאפשרים להם להגיע ל 100%. הם אולי בונים כפול עשר יותר פיצ'רים אבל מכניסים כפול 100 יותר באגים.

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

📌 חשוב לא שווה מעניין

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

אבל זה היה רק מסך עשן.

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

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

מעניין - כלי חדש, טיפ שישנה לכם את החיים, שלושה שרתי MCP שאי אפשר לחיות בלעדיהם, מודל חדש, כפתור שאף אחד לא מכיר, זכרון אוטומטי.

כשלא בטוחים חפשו את החשוב.

📌 עצה גרועה שעובדת

עצה גרועה שעובדת היא הרבה יותר גרועה מעצה גרועה שלא עובדת.

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

כשבאתי להעלות גרסה חדשה של התוכנה דרך ה Github Action שהגדרתי ההעלאה נכשלה בגלל Network Error. ברור מה הבעיה - הקונטיינר שמעלה גרסה נתקע בפרוקסי של קלאודפלייר ולא יכול להגיע לשרת. בשביל להגיע לשרת הוא יצטרך את כתובת ה IP האמיתית שלו, שהיא כאמור מוסתרת מאחורי קלאודפלייר בשביל להגן ממתקפות DDoS.

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

That's the key insight. When Cloudflare proxy (orange cloud 🟠) is enabled, SSH traffic breaks entirely

אין לך מה לעבור ל IP4 אתה צריך את התיקון האמיתי. ומה התיקון האמיתי? תוסיף רשומת DNS חדשה בשם לדוגמה deploy.tocode.co.il בה תפרסם את כתובת ה IP האמיתית של השרת כדי שהקונטיינר של גיטהאב ידע מה הכתובת ויוכל להעלות גרסה.

רואים כבר את הבעיה? אני משלם* לקלאודפלייר כדי שיסתירו את כתובת ה IP שלי ובשורה הבאה ב DNS חושף לעולם את אותה כתובת שרציתי להסתיר. ומי יגן עליי מ DDoS-ים ? קלוד? שיהיה בהצלחה עם זה.

(משלם זו מילה גדולה בהתחשב בזה שהפרוקסי של קלאודפלייר הוא בחינם, אבל נשים את זה בצד).

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

📌 למה עדיין קשה לקבל Code Review מסוכני קוד

יש לי פרומפט קבוע ל Code Review שנראה ככה:

---
description: Review attached code
---

Review the provided code change.

Explain:
- What the code does
- Is the implementation complete
- What other alternatives can solve the same problem? Why was the current alternative chosen?

Then Code Review, focus on:
- Correctness - Bugs and logic errors
- Performance - are there newly introduced regressions? how will the feature work with production data?
- Scale
- Code architecture
- Coding best practices
- Security issues
- Error handling gaps
- Handled and unhandled edge cases

Test Coverage
- Examine existing tests
- Search for untested paths or incomplete tests, specifically tests that only verify the happy path
- Find if the untested code could break in ways we didn't consider

Multi Threaded or Concurrency
- We're writing a web application whose code runs from both user facing web frontend and background workers
- Evaluate code for multi threaded and concurrency anti patterns or possible hidden bugs, deadlocks, duplicate execution, starvation
- Evaluate the need for transactions only where absolutely needed due to the performance penalty of locking.

Security
- We're writing a web application performing in possible hostile environment
- Verify authorization is checked on every route
- Verify user input is sanitized before used


Finally look for AI anti patterns:
- Dead code
- Duplicated code or logic

** DO NOT RUN ANY CODE NOR DO NOT INTERACT WITH THE SYSTEM IN ANY WAY **

This is a static analysis code review running on an isolated machine.

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

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

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

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

📌 אל תכוון. תסחט.

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

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

המטרה היא לא לקבל יותר מהר את אותה התשובה מפעם. אנחנו פה בשביל לבנות משהו טוב יותר.

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

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

הקוד שלך צריך להיות הרבה יותר טוב מהגירסה הראשונה שה AI יוצר.

נ.ב. לא לשכוח היום בעשר אנחנו חוזרים לשגרת הוובינרים עם וובינר על פיתוח סוכנים עם OpenAI Agents SDK. נתראה בזום.

📌 מי בכלל צריך לכתוב סוכנים?

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

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

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

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

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

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

אני אישית חושב שסוכנים יהיו יותר כמו אתרים מאשר כמו דפדפנים מהסיבות הבאות:

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

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

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

1. סוכן שמקבל אימיילים ושומר חשבוניות או מסמכים מצורפים לתיקיית רשת.
2. סוכן שמקשיב להודעות בטלגרם ומתרגם את הטקסט לשפה אחרת.
3. סוכן שכל ערב שולח לכם תקציר חדשות מותאם אישית לנושאים שמעניינים אתכם.
4. סוכן ששולח אוטומטית Code Review על כל PR פתוח.
5. סוכן שעונה על שאלות על המוצר שלכם.
6. סוכן שמשחק נגדכם איקס עיגול.
7. סוכן שמחזיק רשימת קניות. שולחים הודעה בטלגרם כשחסר משהו והודעה אחרת בטלגרם כשאנחנו בסופר.
8. סוכן ששולח בשמכם ברכת יום הולדת מקורית לחברים לאימייל (או משאיר הודעה בפרופיל החברתי שלהם).
9. סוכן שקרא את כל הפוסטים מהבלוג הזה ויודע לענות על שאלות לגביהם.
10. סוכן בטלגרם שעוזר לכם להכנס לכושר באמצעות שליחת תוכנית אימונים והודעות מוטיבציה ומעקב.
11. סוכן כרטיסיות - הוא גם מתרגם בשבילכם מילים וגם שומר אוטומטית כרטיסיות. מדי פעם תוכלו לבקש שיבחן אתכם ואז הוא שולף את הכרטיסיות לראות שאתם זוכרים.
12. הסוכן הבוחן - תנו לו לינק למאמר או פוסט והוא יתחיל לשאול אתכם שאלות על הטקסט כדי לראות שאתם מבינים אותו לעומק.

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

📌 לכתוב או לחשוב

הנה מטריקה טובה כדי להבין אם אתם משתמשים נכון ב AI לקידוד. רשמו בסוף היום:

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

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