ToCode

ייצוא קובץ HAR לטקסט בעבר כשהיינו צריכים לכתוב סקריפט שיבצע תהליכים שאנחנו מבצעים ידנית בדפדפן היינו פותחים את כלי הפיתוח, מסתכלים בבקשות שיוצאות ובתשובות ולפי זה מקודדים את הסקריפט. היום כש AI יכול לעשות את הבנייה בשבילנו כל מה שאנחנו צריכים זה להקליט את ה Session ולייצא את כל ההודעות בתור טקסט כדי שנוכל לתת ל AI לתרגם אותן לפקודות curl או לכתוב מהן סקריפט. הבעיה היחידה - דפדפנים לא מייצאים Session שלם מטאב network בכלי הפיתוח לקובץ טקסט. איזה מזל שאנחנו יודעים פייתון. זה הסקריפט:

import re
import json
from haralyzer import HarParser, HarPage
with open('demo.har', 'r', encoding='utf8') as f:
    har_parser = HarParser(json.loads(f.read()))

data = har_parser.har_data

for page in har_parser.pages:
    print(f"Page URL: {page.url}")

    for entry in page.entries:
        print("---\n\n")
        print("Request URL: ")
        print(entry.request.url)
        print("Request method: ")
        print(entry.request.method)
        print("Request Headers: ")
        print(entry.request.headers)
        print("")
        print("Response Headers: ")
        print(entry.response.headers)
        print("")
        if 'content' in entry.response:
            print("Response Body: ")
            print(entry.response['content'].get('text'))

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

if entry.request.url.endswith('.jpg'): continue

סדר פריטים ב SQL כשאני מושך מבסיס נתונים את כל השירים במערכת:

select * from songs;

לפי איזה סדר הם מגיעים? האם אני מצפה לסדר? ואיך לוודא שהם יגיעו בסדר שאני צריך? 1. בלי לכתוב order by השירים יכולים לחזור בכל סדר. הרבה פעמים בפיתוח הם יגיעו לפי הסדר בו הם נוצרו ובפרודקשן לפי סדר אקראי כלשהו, רק כי הם יכולים. 2. אם יש הרבה שירים ולא אכפת לכם מהסדר, להוסיף order by יאט את השאילתה וידרוש יותר זיכרון. ועכשיו לשאלה - האם כדאי לכתוב order by בכל שאילתה ראשית במערכת (כלומר לא במצב שה select בתוך where)? אני מודה שאחרי שביליתי השבוע כמה שעות בשביל להבין שגיאה שנבעה משאילתה בלי order אני מתחיל לחשוב בחיוב על האופציה. מה דעתכם?

איך לקרוא את החלוקה לרמות של תומאס דומקה תומאס דומקה, מנכ"ל גיטהאב, כרגיל מצליח לעורר הדים בקהילה כשהוא כותב ששימוש בכלי AI יהיה מיומנות הכרחית למפתחים של העתיד, ופורט את המיומנות הזו ל-4 שלבים של אבולוציה: 1. סקפטיים - משתמשים ב AI למשימות קטנות או השלמת קוד (Tab Completion) 2. חוקרים - משתמשים ב AI כדי לדבג, לשאול שאלות, לקבל הסברים על קטעי קוד שהם לא מבינים ולייצר קטעי קוד ב ChatGPT שאחר כך יעתיקו לתוך המערכת. 3. משתפי פעולה - מפתחים שמשתמשים ב AI IDEs כמו קופיילוט או קרסר, מנסים מודלים שונים. 4. שימוש אסטרטגי - מפתחים שמשתמשים בסוכנים אוטונומיים במיוחד סוכנים אסינכרוניים בענן וממקבלים את העבודה למספר סוכנים. האבולוציה כאן היא לא תהליך שבסופו אנחנו משתמשים רק בסוכנים אסינכרוניים. מונח יותר נכון יהיה עקומת לימוד. יש פה 4 מיומנויות ללמוד, אנחנו לומדים אותן אחת אחרי השניה וכל מיומנות דורשת יותר השקעה מהקודמת כדי להגיע לתוצאות טובות. בסוף התהליך מפתחים שיודעים לעבוד עם כלי AI ישתמשו בכל 4 המיומנויות כל הזמן בעבודה על פרויקט: סוכני AI אוטונומיים מסוגלים לבנות דברים מרשימים אבל לא עובדים מתוך הבנה של המערכת והטכנולוגיה הנוכחית לא קשורה בכלל להבנה, ולכן יש המון דברים שהם לא מסוגלים לעשות. כלי פיתוח מבוססי AI יכולים להאיץ את העבודה, אבל גם להסיח את הדעת וכך לדחוף מפתחים לפספס מקרי קצה או פערים בין המימוש להתנהגות הרצויה של המערכת. מצד שני כשמשתמשים בהם במקום שאפשר היה להריץ סוכן אוטונומי אנחנו סתם מבזבזים זמן בלהסתכל על הסוכן מקודד. וגם מפתחים שמכירים AI טוב לפעמים יעדיפו לכתוב מימוש בעצמם כשצריך לתת תשומת לב לכל פרט. לפעמים נעדיף לקיים התייעצות עם AI במסך הצ'אט בדפדפן כי הוא מאפשר יותר בקלות לשלוט בקונטקסט ולהשוות תשובות של כמה מודלים, לפעמים נעדיף להשתמש בעורך משולב AI במיוחד כשרוצים לראות מספר מימושים ולהשוות ביניהם ולפעמים נשמח לתת ל AI לרוץ במקביל למרחקים ארוכים בצורה אסינכרונית כדי לממש אוסף של משימות קטנות או משימה שדורשת שינוי בהמון קבצים. אין פה אבולוציה ואתם לא צריכים "להגיע" לשימוש נרחב ב AI. כן כדאי להבין איך לעבוד בצורה יעילה בארבעת המצבים שתומאס דומקה זיהה, וכן נכון לשים לב שעקומת הלמידה שלהם לא זהה - כמעט כל אחד יכול ליהנות מהשלמות טאבים, עם קצת יותר השקעה אפשר לקבל תשובות טובות מ AI במסכי ה Chat, מצב סוכן כבר דורש יותר השקעה בלימוד הכלי והכנת תשתיות והסוכן האסינכרוני דורש הכי הרבה השקעה לפני שמקבלים תוצאות טובות.

אני לא מאמין ש PHP קיבלו את האופרטור הזה לפנינו כבר הרבה זמן שיש הצעה על השולחן לאופרטור Pipe ב JavaScript. זה יראה כך:

value |> foo(%)

או בשירשור ארוך יותר:

[1, 2, 3]
|> %.filter(x => x % 2 === 0)
|> %.map(x => x * 4)
|> %.join(' ')
|> console.log(%)

או אפילו:

return links
  |> Object.keys(%).map(function (rel) {
    return '<' + links[rel] + '>; rel="' + rel + '"';
  })
  |> link + %.join(', ')
  |> this.set('Link', %);

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

$result = "Hello World"
    |> strtoupper(...)
    |> str_shuffle(...)
    |> trim(...);

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

ניסוי OpenRouter מ Python אופןראוטר מספק גישה להמון מודלים מסחריים ומודלי קוד פתוח דרך API אחד, מסך תשלום אחד ומסך אחד בו אפשר לראות את הפעילות והעלויות. זה מאוד נוח כשרוצים לשים לב כמה עולה כל ה AI הזה וגם לחסוך כסף באמצעות גיוון במודלים. אפשר להירשם כאן: https://openrouter.ai/ וגם לדבר עם המון מודלים מתוך ממשק ה Web שלהם, אבל אני רוצה להריץ ניסוי מתוך פייתון כדי לתת לכמה מודלים לענות לאותה שאילתה. התחלתי עם הקוד הבא:

import asyncio
from agents import Agent, Runner
from agents.extensions.models.litellm_model import LitellmModel
import os

async def main():
    models = [
        "openrouter/moonshotai/kimi-k2",
        "openrouter/z-ai/glm-4.5",
        "openrouter/cognitivecomputations/dolphin-mistral-24b-venice-edition:free",
        "openrouter/inception/mercury"
    ]

    for model in models:
        agent = Agent(
            name="Assistant",
            model=LitellmModel(model=model),
            instructions="You only respond in haikus.",
        )

        print(f"Model: {model}")
        result = await Runner.run(agent, "Tell me about recursion in programming.")
        print(result.final_output)
        print("---")

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

הקוד משתמש בספריית OpenAI Agents SDK אותה אני מאוד מחבב ומבקש מ-4 מודלים להסביר בשיר Haiku מהי רקורסיה. אלה התשובות שקיבלתי:

Model: openrouter/moonshotai/kimi-k2
Function calls itself
Each step unpeels a layer
Base case stops the fall
---

Model: openrouter/z-ai/glm-4.5
Function calls itself
To solve a smaller problem
Base case stops the loop

Code within the code
Stack grows deeper with each call
Until base is found

Divide and conquer
Breaking problems into parts
Solve the simplest
---

Model: openrouter/cognitivecomputations/dolphin-mistral-24b-venice-edition:free
A function calls itself,
Looping back in endless dance,
Chasing its own tail.

Base case breaks the spell,
Else infinite descent,
Stack overflow lovers.

Elegant solutions,
Complex problems simplified,
Beauty in repetition.

But beware the trap,
Unchecked, it can drive you mad,
Like rabbits in a field.

Fibonacci, trees,
Recursion's grace is seen,
In patterns endless woven.

So with care and caution,
Wield this tool, and watch it grow,
A tapestry of code.
---

Model: openrouter/inception/mercury
Function calls itself,
In layers it goes UNCer hands depthHappyLe Finding to end.

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

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

def ask_ai
  Langfuse.trace("extract_lyrics", attributes: {
     "gen_ai.request.model" => "gemini-2.5-pro-preview-06-05",
     "gen_ai.system" => "Gemini"
  }) do |tracer|
    chat = RubyLLM.chat(model: 'gemini-2.5-pro-preview-06-05')
    response = chat.ask("hello")
    tracer.trace(response)
  end
end

ביקשתי גם להשתמש בממשק ה OpenTelemetry של Langfuse עבור המימוש וסיפקתי קישור לדף התיעוד שלהם על מאפייני ה OpenTelemetry הדרושים כדי לתעד שיחה. התוצאה היתה קוד לא נורא שגם עבר בכל המקרים שבדקתי:

require 'opentelemetry-api'

module Langfuse
  class TracerWrapper
    def initialize(span)
      @span = span
    end

    def trace(llm_response)
      # Customize based on RubyLLM / OpenAI / Gemini format
      if llm_response.respond_to?(:model)
        @span.set_attribute("gen_ai.response.model", llm_response.model)
      end

      if llm_response.respond_to?(:content)
        content = llm_response.content

        # Set the completion content according to GenAI semantic conventions
        @span.set_attribute("gen_ai.completion.0.role", "assistant")
        
        if content.is_a?(Hash)
          # For structured responses, store as JSON string
          @span.set_attribute("gen_ai.completion.0.content", content.to_json)
        elsif content.is_a?(String)
          @span.set_attribute("gen_ai.completion.0.content", content)
        end
      end

      if llm_response.respond_to?(:usage)
        usage = llm_response.usage
        @span.set_attribute("gen_ai.usage.prompt_tokens", usage.prompt_tokens)
        @span.set_attribute("gen_ai.usage.completion_tokens", usage.completion_tokens)
        @span.set_attribute("gen_ai.usage.total_tokens", usage.total_tokens)
      end
    end
  end

  def self.trace(name, attributes: {}, &block)
    tracer = OpenTelemetry.tracer_provider.tracer('langfuse)
    tracer.in_span(name, attributes: default_attributes.merge(attributes)) do |span|
      yield TracerWrapper.new(span)
    end
  end

  def self.default_attributes
    {
    }
  end
end

וקובץ האיתחול config/initializers/opentelemetry.rb:

require 'opentelemetry/sdk'
require 'opentelemetry/exporter/otlp'
require 'base64'

public_key = Rails.application.credentials.langfuse[:pk]
secret_key = Rails.application.credentials.langfuse[:secret]

auth_token = Base64.strict_encode64("#{public_key}:#{secret_key}")

exporter = OpenTelemetry::Exporter::OTLP::Exporter.new(
  endpoint: "https://us.cloud.langfuse.com/api/public/otel/v1/traces",
  headers: { "Authorization" => "Basic #{auth_token}" },
)

span_processor = OpenTelemetry::SDK::Trace::Export::SimpleSpanProcessor.new(exporter)

OpenTelemetry::SDK.configure do |c|
  c.add_span_processor(span_processor)
end

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

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

chat = RubyLLM.chat
response = chat.ask "What is Ruby on Rails?"
puts response.content

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

image = RubyLLM.paint("A photorealistic red panda coding Ruby")

תמיכה מובנית ב Async זה היה Deal Breaker מבחינתי בכל ספריית רובי שבדקתי עד עכשיו. הבעיה עם תקשורת עם AI היא שרוב הזמן אתה מחכה לטוקנים של ה AI אבל עדיין צריך להחזיק את כל החיבורים פתוחים בשביל שהסטרימינג יעבוד. מבנה קלאסי של Threads לא יכול לעמוד בעומס מהסוג הזה ואנחנו צריכים ניהול של כל החיבורים האלה בממשק אסינכרוני, כלומר שהשרת יכול לטפל בהמון שיחות עם AI בו זמנית. מה שיפה כאן זה שאחרי שמסיימים את הסטאפ האסינכרוני אפשר להמשיך לכתוב Jobs בדיוק כמו שהיינו כותבים רגיל ב Rails, ובאופן אוטומטי מריץ המשימות האסינכרוני יריץ את הג'ובים בתוך לולאה אסינכרונית. זה הקוד מדף התיעוד שלהם:

* Keep your existing adapter as default *
config.active_job.queue_adapter = :solid_queue  # or :sidekiq, :good_job, etc.

* Base class for all LLM jobs *
class LLMJob < ApplicationJob
  self.queue_adapter = :async_job
end

* LLM jobs inherit the async adapter *
class ChatResponseJob < LLMJob
  def perform(conversation_id, message)
    # Runs with async-job - perfect for streaming
    response = RubyLLM.chat.ask(message)
    # ...
  end
end

* Regular jobs use your default adapter *
class ImageProcessingJob < ApplicationJob
  def perform(image_id)
    # Runs with solid_queue - better for CPU work
    # ...
  end
end

אנחנו מקימים שני Queue Adapters, אחד זה Good Job הרגיל עבור הג'ובים הסינכרוניים והשני הוא Async::Job עבור הג'ובים של ה AI. קוד קריא וקל להרחבה הספריה בנויה בתור ספריית Ruby והאינטגרציה עם ריילס היא סוג של "קומה מעל" וכולה כתובה בקובץ אחד. קל מאוד להחליף חלקים באינטגרציה עם ריילס או אפילו לכתוב את כל האינטגרציה הזאת בעצמנו כדי להתאים למערכת ולשיטת העבודה שלנו. אחת הדוגמאות מהתיעוד מדברת על מתי שומרים ב DB הודעה חדשה. ברירת המחדל באינטגרציה הקיימת היא לשמור את ההודעה לפני ש AI מתחיל לענות כדי שיהיה יותר קל לעשות Streaming. בתיעוד יש דוגמה איך לשנות את זה ולשמור את ההודעה רק כשכבר יש תוכן כדי שאפשר יהיה להוסיף וולידציה ב DB. בעבודה שלי עם הספריה הייתי צריך לסנן חלק מההודעות לפני השליחה ל AI ולהוסיף Metadata להודעות, שני דברים שהצלחתי לעדכן מאוד מהר ורק דרך המנגנון של ירושה. סך הכל מאוד אהבתי את הספריה. כן צריך להגיד שאנחנו על קרקע מאוד לא יציבה, אני בטוח שעוד יהיו שינויי API ויש דברים בצורת הפעולה היום שאני לא אוהב - לדוגמה הבחירה שלהם לשמור את ה System Prompt ב DB גם בתור חלק מהשיחה. אבל באקוסיסטם של רובי וריילס אני בטוח שהיא תזכה להצלחה.

התסכול של AI ותחושת מסוגלות כלי AI היום מנסים לענות על שני צרכים בו-זמנית: הם מנסים לחסוך לנו זמן במשימות אותן אנחנו מסוגלים לעשות לבד, וגם לעשות בשבילנו דברים שאנחנו עדיין לא יודעים או לא רוצים לדעת איך עושים. וככה אני יכול בתור מתכנת להיעזר ב AI כדי לעשות Boostrap לכל ה Boilerplate של פרויקט חדש שאני יודע לבד איך לכתוב אבל בפרומפט אחד חסכתי שעה-שעתיים של הקלדה, ובאותו כלי אני יכול לתרגם דף תיעוד מסינית ולקבל גירסה שלא היתה מביישת הרבה מתרגמים אנושיים. לאורך זמן ושימוש ב AI מתכנתים מדווחים על תחושת שחיקה וחוסר הנאה מהקוד. חלק מהגורמים לתחושה הוא בלבול בתחושת המסוגלות. כשאני משתמש ב AI גם לדברים שאני יודע לעשות כדי לחסוך זמן וגם לדברים שאני לא יודע לעשות כדי לחסוך זמן לימוד, לאורך זמן אני עלול לשכוח מה זה מה. בתכנות זו אפילו בעיה יותר רצינית כי כתיבת קוד היא לא כמו רכיבה על אופניים. זו מיומנות שנעלמת מהר ואנשים שמפסיקים לכתוב קוד באמת מגלים שעם הזמן גם כניסה קטנה לקוד יכולה להיות מאתגרת. כשמתכנת או מתכנתת פרונט אנד מסתכלים על AI מנסה ליצור דף HTML ותמיד יוצר דף מכוער, ההתעקשות של חלקם לא להיכנס לקוד, לא לכתוב את השלד או להכניס תיקונים רק כדי "להתאמן על עבודה עם AI" לדעתי לא הגיונית. להסתכל על AI מג'נרט קוד גרוע שוב ושוב לא הופך אותך ליותר מיומן עם AI, אלא רק לפחות מיומן עם קוד. הדרך קדימה היא לא לזרוק את כל מה שלמדנו אלא להשתמש במה שלמדנו כדי לבנות מוצרים טובים יותר בעזרת AI. יודעת לכתוב את ה HTML שאת צריכה בצורה נכונה סמנטית? מצוין, כתבי אותו, ואם את יותר מהירה מ AI תכתבי אותו בלי AI. המשחק, והאתגר, הוא למצוא את הדברים ש AI יכול לכתוב יותר מהר ממך ולשלב כוחות כדי לייצר מערכות טובות יותר ומהר יותר. דוגמאות: 1. אחרי מימוש פונקציה או קלאס אפשר לתת ל AI לכתוב על זה Code Review כדי לקבל רעיונות לשיפור. 2. אחרי שינוי ארכיטקטורה ה AI יכול לרוץ על הקוד ולעדכן מסמך ארכיטקטורה. 3. לפני ריפקטורינג ה AI יכול לרוץ על הקוד בצורה יותר מדויקת מחיפוש טקסטואלי כדי להראות לי מה הולך להיות מושפע. 4. שינוי API שמשפיע על רכיבי צד שרת וצד לקוח הכתובים במספר קבצים יכול להיות מטופל מהר יותר על ידי AI. 5. מימוש פונקציה לפי Spec במיוחד אם היא ניגשת ל APIs חיצוניים או עושה שינויים מבניים ב Data. אז כן תנו ל AI לעבוד ותעזרו לו כשצריך. תסכול והרצה חוזרת של שאילתות לא יעזרו ל AI "ללמוד" אלא רק יגרמו לכם לשכוח.

בוקר טוב מזכיר שעוד רבע שעה בשעה 10:00 נתחיל וובינר על כתיבה והעלאה לאוויר של שרת MCP מוזמנים להצטרף בלינק: קישור לזום: https://tinyurl.com/tocodeai