המקום של Coroid במערך הפיתוח

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

ארבע קטגוריות#

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

מושב ומפעל הם בעיות שונות#

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

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

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

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

פרוטוטיפינג וייצור הם בעיות שונות#

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

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

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

Coroid נבנה סביב מגבלות אלה ולא סביב הימנעות מהן:

הם משתלבים היטב#

אין כאן בחירה בין שניים; השניים משלימים זה את זה באופן טבעי:

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

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

אב-הטיפוס עונה על השאלה האם כדאי לבנות את זה?. Coroid עונה על השאלה לבנות אותו כראוי במערכת שכבר יש לנו.

מתי לא להשתמש ב־Coroid#

להיות כנה בנושא זה שימושי יותר מרשימת תכונות:

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

מה נובע מהדגש על ייצור#

כמה דברים ב־Coroid נראים כעומס עד שתבין שמדובר בדרישות ייצור:

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

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

קשורים#

• מהו Coroid?
• מערכת ההפעלה של Coroid
• כיצד משימה הופכת ל־pull request