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

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

ואז הגיע AI.

שימו לב לשלושת הפרומפטים הכמעט זהים:

Write tests for the following python function:

def count_lines(x):
  ...

Write tests for the following python function:

def count_lines(url):
  ...

Write tests for the following python function:

def count_lines(file_path):
  ...

Write tests for the following python function:

def count_lines(fp):
  ...

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

הפוסט היום הוא תרגום של פוסט מהבלוג של הגורו סת גודין. הערות שלי בסוף.

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

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

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

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

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

כמה הערות:

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

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

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

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

https://www.youtube.com/watch?v=90WD_ats6eE

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

import tariff

# Set your tariff rates (package_name: percentage)
tariff.set({
    "numpy": 50,     # 50% tariff on numpy
    "pandas": 200,   # 200% tariff on pandas
    "requests": 150  # 150% tariff on requests
})

# Now when you import these packages, they'll be TARIFFED!
import numpy   # This will be 50% slower
import pandas  # This will be 200% slower

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

builtins.__import__ = _tariffed_import

זה מקור החבילה בגיטהאב:

https://github.com/hxu296/tariff/tree/main

ועכשיו אתם - מה הייתם משנים ב import? ולמה?

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

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

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

https://www.tocode.co.il/mentoring

ועכשיו לפוסט.

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

בכל אופן עד לאחרונה חשבתי שזו פשוט דעה לא פופולרית שלי, והנה גוגל יוצאים עם IDE חדש משולב AI בשם Firebase Studio, שעושה קסמים עם נקסט 15 ובאמת נראה אחלה ובינתיים גם לא ביקשו עליו כסף, והסטארטר של פרויקט חדש מתחיל עם קובץ הקונפיגורציה שלי:

import type {NextConfig} from 'next';

const nextConfig: NextConfig = {
  /* config options here */
  typescript: {
    ignoreBuildErrors: true,
  },
  eslint: {
    ignoreDuringBuilds: true,
  },
};

export default nextConfig;

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

בכל אופן על חינם אי אפשר להתלונן. אפשר להתחיל לקודד איתו כאן:

https://firebase.studio/

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

from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/hello', methods=['GET'])
def hello():
    message = "Hello, world!"
    return jsonify(message=message)

if __name__ == '__main__':
    app.run(debug=True)

ואתם מקנאים בילדים המקובלים מ JavaScript שיכולים פשוט לכתוב:

return {message}

ולא צריכים לחזור על השם פעמיים, פעם אחת בשביל המפתח ופעם שנייה בשביל הערך, אז אתם יכולים לכתוב:

@app.route('/hello', methods=['GET'])
def hello():
    message = "Hello, world!"
    return jsonify(**locals())

כדי לקבל בדיוק את אותה תוצאה, ובלי להקליד את שם המשתנה אפילו פעם אחת. או, אם אתם חוששים (בצדק) שאיזה משתנה שלא התכוונתם ייכנס לכם ל JSON תוכלו לכתוב:

@app.route('/hello', methods=['GET'])
def hello():
    message = "Hello, world!"
    return jsonify(**{k: v for k, v in locals().items() if k in ['message']})

וכן זה קצת ארוך אבל אפשר לקצר עם פונקציית עזר ואז נקבל:

def only(d, *keys):
    return {k: d[k] for k in keys}

@app.route('/hello', methods=['GET'])
def hello():
    message = "Hello, world!"
    foo = 10
    bar = 20
    return jsonify(**only(locals(), 'message', 'bar'))

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

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

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

אחרי יום עם GPT4.1 ב Cursor ברור לגמרי שזאת המציאות של כולנו.

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

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

אמג'ד מסד, המייסד של רפליט, צייץ לאחרונה:

I no longer think you should learn to code.

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

כמה מחשבות על זה-

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

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

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

this doesn’t mean engineering is obsolete. The engineering approach to solving problems is now even more crucial to make best use of AI tools. the paradigm of what the focus of engineering just changes from syntax and semantics to problem solving

1. עכשיו לשאלות - איך לומדים Problem Solving בהנדסת תוכנה? איך מתאמנים על אותן המיומנויות שיהפכו אותנו למהנדסים הטובים של העתיד? האם לא סביר לחשוב שהשיקולים של ברנדון איי ב 1995 יכולים ללמד אותנו על פיתרון בעיות והנדסת תוכנה? אולי אפילו יותר מבניית עוד מערכת SaaS ?

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

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

נ.ב. קריאה מעניינת לגבי null ב JavaScript (תורגם מקוריאנית על ידי AI)

https://witch.work/en/posts/javascript-why-typeof-null-is-object