Trendande ämnen
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Översättning: Varför stora språkmodeller inte riktigt kan bygga programvara
Av Conrad Irwin
En sak som jag ägnar mycket tid åt är att intervjua mjukvaruingenjörer. Detta är naturligtvis en svår uppgift, och jag vågar inte säga att jag har några knep. Men det gav mig tid att reflektera över vad en effektiv mjukvaruingenjör gör.
Kärnan i programvaruteknik
När du tittar på en sann finsmakare kommer du att se att de alltid utför följande steg i en cykel:
* Bygg en mental modell av behov.
* Skriva (förhoppningsvis?!) ) som genomför kraven.
* Bygg en mental modell av hur din kod faktiskt beter sig.
* Hitta skillnaden mellan de två och uppdatera sedan koden (eller kravet).
Det finns många sätt att utföra dessa steg, men det fina med effektiva ingenjörer är deras förmåga att bygga och underhålla tydliga mentala modeller.
Hur presterar stora språkmodeller?
För att vara rättvis är stora språkmodeller ganska bra på att skriva kod. De gör också ett bra jobb med att uppdatera koden när du påpekar problemet. De kan också göra alla de saker som en riktig ingenjör skulle göra: läsa kod, skriva och köra tester, lägga till loggar och (förmodligen) använda felsökaren.
Men vad de inte kan göra är att upprätthålla en tydlig mental modell.
Stora språkmodeller kommer att hamna i oändlig förvirring: de kommer att anta att koden de skriver faktiskt är användbar; När ett test misslyckas kan de bara gissa om det är en fixkod eller ett test fixat; När de blir frustrerade klipper de helt enkelt ut allt och börjar om.
Detta är raka motsatsen till vad jag skulle förvänta mig av en ingenjör.
Programvaruingenjörer testar medan de arbetar. När ett test misslyckas kan de använda sin mentala modell för att avgöra om de ska åtgärda koden eller testet, eller samla in mer information innan de fattar ett beslut. När de känner sig frustrerade kan de be om hjälp genom att kommunicera med människor. Även om de ibland raderar allt och börjar om, är det ett val som görs efter en tydligare förståelse av problemet.
Men det kommer att bli snart, eller hur?
Kommer detta att förändras i takt med att modellerna blir mer kapabla? Kanske?? Men jag tror att detta kräver en grundläggande förändring av hur modeller byggs och optimeras. Programvaruteknik kräver modeller som är mer än att bara generera kod.
När en person stöter på ett problem kan han eller hon tillfälligt lägga hela sammanhanget åt sidan och fokusera på att lösa det aktuella problemet, och sedan återvända till det stora problemet. De kan också växla mellan den stora bilden och mikrodetaljerna, tillfälligt ignorera detaljerna för att fokusera på helheten och gräva i delarna när det behövs. Vi blir inte mer produktiva bara för att vi klämmer in fler ord i vårt "kontextfönster", det kommer bara att göra oss galna.
Även om vi kan hantera en stor mängd kontext vet vi att dessa generativa modeller för närvarande har flera allvarliga problem som direkt påverkar deras förmåga att upprätthålla tydliga mentala modeller:
* Kontextuellt utelämnande: Modeller är inte bra på att upptäcka förbisedd kontextuell information.
* Recency bias: De är föremål för allvarlig recency bias när de arbetar med kontextfönster.
* Hallucinationer: De "fantiser" ofta om detaljer som inte borde finnas.
Dessa problem kanske inte är oöverstigliga, och forskare arbetar med att lägga till minne till modeller så att de kan utöva liknande tankeförmåga som vi gör. Men tyvärr, för tillfället, kan de (efter att ha gått bortom en viss nivå av komplexitet) inte riktigt förstå vad som verkligen hände.
De kan inte bygga programvara eftersom de inte kan underhålla två liknande "mentala modeller" samtidigt, ta reda på skillnaderna och bestämma om de ska uppdatera kod eller uppdatera kraven.
Så, vad händer nu?
Det är uppenbart att stora språkmodeller är användbara för programvaruingenjörer. De genererar kod snabbt och utmärker sig när det gäller att integrera krav och dokumentation. För vissa uppgifter räcker det: kraven är tillräckligt tydliga, problemen är så enkla att de kan göras över en natt.
Med det sagt, för alla uppgifter av viss komplexitet, kan de inte upprätthålla tillräckligt med kontext exakt för att iterera för att slutligen producera en genomförbar lösning. Som mjukvaruingenjör är du fortfarande ansvarig för att se till att kraven är tydliga och att koden faktiskt levererar vad den påstår sig göra.
På Zed tror vi på en framtid där människor och AI-agenter kan bygga mjukvara tillsammans. Vi är dock övertygade (åtminstone för tillfället) om att det är du som sitter bakom ratten och att stora språkmodeller bara är ytterligare ett verktyg du har nära till hands.
86,1K
Topp
Rankning
Favoriter