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

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

data = {"x": 10}
if "x" in data:
    print(data["x"])

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

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

ניקח דוגמה יותר מעניינת מפרויקט maigret. בקובץ report.py של הפרויקט אני מוצא שתי פונקציות: get_plaintext_report ו generate_report_context. הפונקציה generate_report_context מייצרת מילון עם נתונים והפונקציה get_plaintext_report לוקחת את הנתונים ובונה מהם דוח.

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

Search by username Dr.
Evil returned 0 accounts.
Extended info extracted from 0 accounts.

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

output = (context['brief'] + " ").replace('. ', '.\n')

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

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

if "brief_lines" in context:
    output = "\n".join(context['brief_lines'])
else:
    output = (context['brief'] + " ").replace('. ', '.\n')

זה מיותר כיוון שאנחנו יוצרים את המילון וברור שאם יש בו את brief יהיה בו גם את המפתח החדש brief_lines.

הניסיון הראשון שלי לתקן את זה היה עם התוספת הבאה לקובץ CLAUDE.md:

Project Philosophy

- When we replace a mechanism in code don't keep the old one for record or backward compatibility
- Implement minimalistic solutions
- Consider what data is actually in a dictionary and use the correct key, don't cover too much ground

זה לא עבד.

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

בניסיון השלישי הוספתי את הטקסט הבא ל CLAUDE.md ונראה שזה עובד:

Dictionary Defensive Programming

- When you read a key from a dict/object we construct ourselves, access it directly never .get() with a fallback. Fallbacks and defensive access are only for data crossing a trust boundary we don't control: user input, network responses, parsed files

וכן זה מאוד ספציפי למילונים. אבל אולי פה הקסם.

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

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

1. שרת MCP מסוג stdio הוא בסך הכל כלי משורת הפקודה או סקריפט.

2. שרת MCP מסוג http הוא בסך הכל API.

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

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

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

1. שאלתי את קלוד מה הכתובת של שרת ה MCP של ספוטיפיי אליה הוא מחובר. את זה לא היתה לו בעיה לספר לי.

2. שמתי לב שכשאני מתחבר לשרת ה MCP של ספוטיפיי הדפדפן מראה כתובת ארוכה שכוללת משתנים כמו redirect url ו client id. רשמתי אותם בצד.

3. שמתי לב שאחרי אישור הגישה לספוטיפיי הדפדפן שלי עובר בבקשת POST לקלוד שלוקח את הקוד שהתקבל ומשתמש בו כדי לקבל אסימון גישה, כל זה מאחורי הקלעים. אז חסמתי את הגישה ל claude באמצעות קובץ /etc/hosts כדי שלא יקבל את האסימון ולקחתי את הכתובת הזאת אליי, גם אותה רשמתי בצד.

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

import asyncio
import os
from urllib.parse import parse_qs, parse_qsl, urlencode, urlparse, urlunparse

from dotenv import load_dotenv
from fastmcp.client.auth import OAuth
from pydantic import AnyHttpUrl
from pydantic_ai.mcp import MCPToolset


MCP_URL = "https://mcp-gateway-external-pilot.spotify.net/mcp"
REDIRECT_URI = "https://claude.ai/api/mcp/auth_callback"


class ConsoleOAuth(OAuth):
    def __init__(self, client_id: str) -> None:
        super().__init__(
            mcp_url=MCP_URL,
            client_id=client_id,
            callback_port=1,
            callback_timeout=600,
        )
        redirect_uris = [AnyHttpUrl(REDIRECT_URI)]
        self.context.client_metadata.redirect_uris = redirect_uris
        if self._static_client_info is not None:
            self._static_client_info.redirect_uris = redirect_uris

    async def redirect_handler(self, authorization_url: str) -> None:
        parsed = urlparse(authorization_url)
        query = dict(parse_qsl(parsed.query))
        query["show_dialog"] = "true"
        print(urlunparse(parsed._replace(query=urlencode(query))))

    async def callback_handler(self) -> tuple[str, str | None]:
        callback_url = await asyncio.to_thread(input, "Paste callback URL: ")
        query = parse_qs(urlparse(callback_url).query)
        code = query.get("code", [None])[0]
        state = query.get("state", [None])[0]
        if not code:
            raise RuntimeError("Callback URL does not contain an OAuth code")
        return code, state


async def main() -> None:
    load_dotenv()
    client_id = "a0894f3786c34e64b0fa0e77f8ea83db"
    toolset = MCPToolset(
        MCP_URL,
        auth=ConsoleOAuth(client_id),
        init_timeout=600,
    )

    async with toolset:
        tools = await toolset.list_tools()
        search = next(tool for tool in tools if tool.name == "search")
        field = "query" if "query" in search.inputSchema["properties"] else "prompt"
        result = await toolset.client.call_tool(
            "search",
            {field: "nice Spanish music", "language": "en"},
        )

    print(result.model_dump_json(indent=2, exclude_none=True))


if __name__ == "__main__":
    asyncio.run(main())

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

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

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

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

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

בפרויקט חמישי ה AI פיתח מאפס מנגנון שקורא HTML ומוציא ממנו את החלקים החשובים בטקסט במקום להשתמש בספריה קיימת כמו readability של מוזילה או trafilatura.

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

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

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

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

https://claude.ai/share/87cbabb1-608f-4375-b37c-b6f659b9bba4

אלה הנקודות המרכזיות שאני העליתי:

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

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

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

בסוף השיחה קלוד הסביר את זה מאוד יפה:

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

2. הרבה מהיכולות ממומשות ברמת ה Harness ולא ברמת המודל. קלוד קוד הוא חלק מהמוצר שלנו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

את הדוח עצמו אפשר למצוא כאן: https://www.taasuka.gov.il/media/oauod4pb/hitech_report.pdf

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

https://www.themarker.com/career/2026-07-07/ty-article/.premium/0000019f-377d-d07c-af9f-ff7dcc840000?fromLogin=success

זה המשפט:

לפי נתוני הלשכה המרכזית לסטטיסטיקה, כיום מוצעות 13.8 אלף משרות בענף ההייטק, ועוד כ־4,000 משרות "שירותי הייטק", שהן משרות טכנולוגיות בענפים לא-טכנולוגיים.

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

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

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

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

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

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

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

בפרק האחרון של rework דייויד הנסן מדבר על פיתוח משולב AI ב 37 Signals.

https://37signals.com/podcast/ai-challenges-in-software/

אלה הדברים המרכזיים שאני לוקח מהפרק:

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

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

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

4. אם תתנו ל AI לכתוב קוד ללא השגחה התוצאה תהיה בלאגן. או במילים של DHH:

The problem is if you just keep doing that, if you keep asking the monkeypaw for more wishes, you’re going to get a distorted code base.

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

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