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

אחרי שלמדנו ש 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

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

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

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