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

הי קרסר - כתוב לי בבקשה משחק סנייק.

אין בעיה בוס, מתחילים בקובץ הזה:

import dynamic from 'next/dynamic'

// Use dynamic import to prevent hydration errors with canvas
const SnakeGame = dynamic(() => import('@/components/SnakeGame'), {
  ssr: false
})

export default function Home() {
  return (
    <main className="flex min-h-screen flex-col items-center justify-center p-4 bg-gray-100">
      <h1 className="text-3xl font-bold mb-6">Snake Game</h1>
      <SnakeGame />
    </main>
  )
}

הי קרסר הקוד לא מתקמפל - הוא מתלונן שאי אפשר לקרוא ל dynamic בלי SSR מתוך קומפוננטת צד שרת.

אין בעיה בוס אני על זה. בוא נעשה ככה:

1. ניצור קובץ חדש בשם SnakeGameWrapper שיתחיל ב use client ונעביר אליו את כל הקוד מ page.

2. נעדכן את page שיטען את הקובץ החדש הזה.

קרסר מסיים. הקוד עובד. אבל מי נשאר להגיד לקרסור שאפשר היה לכתוב use client פשוט בהתחלה של page.tsx במקום להוסיף קומפוננטה מיותרת? ומי יקרא את הקוד שבוע הבא ויחשוב בטעות ש page.tsx חייב להיות קומפוננטת צד שרת? ולמה בכלל משחק הסנייק צריך את dynamic? למה שלא יהיה קומפוננטת צד לקוח רגילה?

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

ואז הגיע 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 שלכם יכתוב?