Az AI-driven-development egyik legnagyobb előnye (deveknek, sysadminoknak, db guruknak)...

...hogy baromi egyszerű így command-line tool-okat készíteni.

 

Terminal

Ezt a shell scriptet összesen kb. (max.) 5 perc alatt hoztam össze, úgy, hogy gyakorlatilag fogalmam sincs a bash-ról. Egy sor kódot nem írtam, viszont az AI pár lövéssel beletett mindent, ami kell. Info logolás, error handling, stb.

Mivel a DB feltöltése kb. 15-20 percet vesz igénybe, ezért adtam hozzá egy progress-bart. Ez az etymology-db-populator.py Python scriptben van implementálva. A fentebbiekhez hasonlóan szintén minimális tudásom van a Python-ról, az egész script AI-jal lett generálva.

Tanulság: az AI nem csak production kód generálásra használható, sőt...! Ha kell egy script, legyen az hosszabb életű, vagy csak valami eldobható manuális teszteléshez, az manapság, AI-driven-development segítségével pillanatok alatt legenerálható.

Nem kell context-switchelni, nem kell gondolkozni, hogy "vajon ezen a nyelven pontosan hogyan is oldom ezt meg? Mi is a szintaxis?", hanem a fontosabb dolgokra lehet koncentrálni.

AI-driven-developmenttel nem az a kérdés, hogy "pontosan hogyan csinálom ezt meg?", hanem az, hogy "mit akarok csinálni?"

Ez egy nagyon komoly érv az AI használata mellett.

---------

Miután lefutott a script. A statisztikát sem én készítettem, hanem megkértem az LLM-et, hogy generáljon valami értelmeset a kontextus alapján.

Nem csalódtam.

 

Terminal

Hozzászólások

Szerkesztve: 2024. 08. 29., cs – 01:45

Az AI által generált populate_db.sh. Persze nem egyszerre generálta az egészet, hanem több prompton keresztül módosítgattam a követelményeknek megfelelően, mire idáig jutottam.

Ahhoz képest, hogy egy pillanatig nem kellett azon gondolkoznom, hogy "hogyan oldom ezt meg bash-ben", meg hogy "hogyan setupoljam pontosan a Pythont?", csak azon, hogy "mit akarok csinálni?" ahhoz képest szerintem elég korrekt megoldás lett.
 

#!/bin/bash

set -e  # Exit immediately if a command exits with a non-zero status

# Default values
DB_FILE="test_db.sqlite"
SCHEMA_FILE="db-schema-v1.sql"
DATA_FILE="../raw-wiktextract-data.jsonl"
USE_LIMITS=false
START_LINE=0
END_LINE=5000
VENV_DIR="venv"

# Parse command line arguments
while [[ $# -gt 0 ]]; do
    case $1 in
        --start)
            START_LINE="$2"
            shift 2
            ;;
        --end)
            END_LINE="$2"
            shift 2
            ;;
        --useLimits)
            USE_LIMITS=true
            shift
            ;;
        *)
            echo "Unknown option: $1"
            exit 1
            ;;
    esac
done

# Check if the files exist before attempting to delete them
if [ -f "$DB_FILE" ]; then
    rm "$DB_FILE"
    echo "$DB_FILE has been deleted."
else
    echo "$DB_FILE does not exist. No action taken."
fi

if [ -f "${DB_FILE}-journal" ]; then
    rm "${DB_FILE}-journal"
    echo "${DB_FILE}-journal has been deleted."
else
    echo "${DB_FILE}-journal does not exist. No action taken."
fi

# Create and activate virtual environment
python3 -m venv "$VENV_DIR"
source "$VENV_DIR/bin/activate"

# Install requirements in the virtual environment
pip install -r requirements.txt

# Run the etymology-db-populator.py script
if [ "$USE_LIMITS" = true ]; then
    echo "Starting database population from line $START_LINE to $END_LINE..."
    python etymology-db-populator.py --start "$START_LINE" --end "$END_LINE" "$DB_FILE" "$SCHEMA_FILE" "$DATA_FILE"
else
    echo "Starting database population..."
    python etymology-db-populator.py "$DB_FILE" "$SCHEMA_FILE" "$DATA_FILE"
fi

echo "Database population completed successfully."

# Deactivate the virtual environment
deactivate

Érdekesen keveri a $VAR és ${VAR} formákat*.

És igen, amíg valami népszerű környezetben kell megoldást adnia, addig van remény. A minap puppet kérdést tettem fel neki, és tisztán előjött a statisztikai modell alapvető hibája: nem érti (hogy is értené) a kérdést, csak kamuzik valamit, hátha jó lesz (na, nagyon nem lett jó). És minél jobb minőségű mintából tud kamuzni, annál jobb lesz a válasz (pl. amikor sql query-ket kérdeztem tőle, akkor arra alapvetően használható válaszokat adott).

 

*) Igen, értem én, hogy ahol a változó után közvetlenül van "valami", oda kiteszi a {} jeleket, máshová meg "minek", csak ugye a humán - legalábbis én - törekszik az egységes kódra.

Elképzelhető, hogy menet közben modell-t váltottam (3.5 Sonnet és gpt4o-mini közt szoktam váltogatni - az utóbbi ingyenesen használható Cursorban), és ezért inkonzisztens a kód.

Cursorban amúgy van egy alpha módú "AI review" opció. Még nem próbáltam, lehet, hogy az segítene.

Sokadik éve használom a kis házi szerveremen futó scriptek tákolásához az AI-t :) 

Annyi hogy hajlamos tévedni, de nekem bevált a "nem jó, ezt az eredményt kapom" válasz, 4-5. nekifutásra általában már működő valamit rak elém.

Tök érdekes lenne látni, hogy milyen utasításokat adtál ki az AI-nak, és azokat hogyan finomítottad lépésről lépésre, mire kiadta a végső használható kódot.

 

Párszor már próbálkoztam én is kódot generáltatni AI-val, de sajnos eddig még mindig arra jutottam végül, hogy körülményesebb és sokkal lassabb volt neki megfogalmazni, hogy mit is kellene csinálnia, mint kézzel megírnom a kódot.

Nem beszélve arról, hogy elég gyakran olyan utasításokat kamuztak az AI-k a forráskódba, ami az aktuális programozási nyelvben nem is létezik.

Amire viszont használhatónak tűnt, ha átadtál neki egy kész forráskódot, és megkérted hogy gyártson fejlesztői kommenteket és leírást a kódról. Ott meglepően jól szerepelt.

Tök érdekes lenne látni, hogy milyen utasításokat adtál ki az AI-nak, és azokat hogyan finomítottad lépésről lépésre, mire kiadta a végső használható kódot.

Valószínüleg előbb utóbb megjelenik majd a "prompt as commit message" opció. Ha elfogadtál egy változtatást, akkor azzal a prompt-tal commitol, amit használtál. Egyszerűbb lenne nyomon követni, hogy pontosan mi is történt.

Én még eléggé az elején járok a dolognak, de ha valami web-es UI-t használtál korábban, akkor érdemes kipróbálni a Cursor-t, vagy a Zed-et (meg biztos van kismillió másik AI integrált IDE), mert az, hogy a kontextus mindig rendelkezésére áll az AI-nak, az nagy segítség.

hogy körülményesebb és sokkal lassabb volt neki megfogalmazni, hogy mit is kellene csinálnia, mint kézzel megírnom a kódot.

Ez sok esetben jogos.

Én úgy használom, ahogy amúgy programoznék is. Nem egyszerre akarok mindent megváltoztatni, hanem lépésenként promptolom az AI-t. Így általában nem veszik el a részletekben.

Pl (külön-külön prompt):

  1. Adj egy opcionális paramétert ehhez a függvényhez
  2. Ezt a függvényt hagyd defaulton, a másikat meg hívd meg nem default paraméterrel
  3. Adj logolást, error handlinget
  4. Stb.

Ezt a feladat lebontást amúgy is megcsinálom fejben magamnak, szóval emberi nyelven már tudom, hogy mit akarok. Akkor meg miért ne használjam a természetes emberi nyelvet fejlesztéshez? :) Kevesebb context-switch, kevesebb mentális elfáradás.

Ezt a xweetet tegnap láttam. Még nem próbáltam, de valószínüleg hasznos lehet.

Start building out a “prompts” folder in Cursor to 2x your workflow.

It allows you to create reusable pieces of frequently used instructions & context that you can give to the AI.

Totally takes things to another level.

Watch this demo of my workflow.

https://x.com/mckaywrigley/status/1828896727837094038

------

Amúgy lehet, hogy egy pici echo-chamber beszél belőlem, de aki AI-driven-developmenttel akar foglalkozni, annak muszáj feliratkoznia az X-re. Nagyon sok, komoly tudással rendelkező ember kommunikál ott, akiktől lehet tanulni.

És ezzel az a baj, hogy ez olyan, mint bármilyen másik cutting-edge technológia. Aki lemarad, kimarad.

Éppen most kezdek elemezni egy OpenAI-al készített Python szkriptet, ami nem azt csinálja, amit kell, a "készítője" (promptolója? ) pedig nem ért a Pythonhoz, az LLM meg nem tudja kijavítani. 

Van ennek a módszernek  egy nem is túl magas határa. 

#ötévmúlvajólesz

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Érdekelne, hogy mi volt a probléma, mekkora a Python script, stb.

Nem mondom, hogy jelenleg tökéletes az AI-driven-development. És azt is figyelembe kell venni, hogy én személyesen ugyan írni nem feltétlen tudok Pythont (fejből, nem doksit bogarászva), de olvasni a kódot nem gond.

Azaz jelenleg egy fejlesztői tapasztalattal nem rendelkező lehet, hogy zsákutcába kerül, mert nem érti minek kéne történnie.

De egy fejlesztői tapasztalattal rendelkező promptolás után gyakorlatilag csak code review-zik, és el tudja dönteni, hogy az AI által ajánlott változtatás jó-e vagy se.

Tehát gyorsítja a munkát azzal, hogy az AI által könnyen megoldható feladatokat automatizálja, így a fejlesztő a bonyolultabb problémákra tudja koncentrálni a véges mentális energiáját/kapacitását.

Egy tűzfal konfigurációs fájlt olvas be, ahol bizonyos tűzfal cím definíciókat (set emez, set amaz) változtat meg bizonyos feltételek alapján. A szkript, amit kaptam, 70 sor kommentek nélkül. Kiváncsiságból én is leprompoltam (mi a helyes ige erre a műveletre?), és jó eredményt kaptam. Ehhez persze az kellett, hogy megmutassam neki, milyen input-okra milyen outputot várok, és szabatosan megfogalmaztam a feltételeket. 

Hozzáértőnek segítség, a dilettáns meg pont úgy jár ezzel is, ahogy más eszközökkel is szokott a dilletáns járni, valami szemetet talán összehoz vele, de működő, használható, eladható dolgot soha nem alkot vele. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.