Stanford zmienia zadania: student musi obronić kod napisany przez agenta

Stanford zmienił zadania w kursie CS146S, gdy coding agents zaczęli rozwiązywać zeszłoroczne prace domowe jednym promptem. Studenci trafiają teraz do nieznanego projektu open source, proponują zmianę i wyjaśniają ją osobie, która może ją rzeczywiście przyjąć.

Zeszłoroczne zadanie zastąpiło obce repozytorium i prawdziwy maintainer

Latent Space opisuje drugą edycję przedmiotu The Modern Software Developer prowadzonego przez Mihaila Erica. Rozmowa trwa 121 minut i prowadzi przez dziesięć tygodni zajęć: od agent harness, przez context engineering i security, po background agents oraz software factory.

Najważniejsza zmiana dotyczy zadania. Maintainers projektów open source wnoszą na zajęcia prawdziwe repozytoria. Student musi zrozumieć nieznany kod, zaproponować ingerencję i obronić patch przed osobą odpowiedzialną za merge. Oficjalna strona podaje 3 units, a cele obejmują projektowanie agent workflows, łączenie tools i skills oraz rozumienie ograniczeń obecnych coding agents.

Wartość juniora przesuwa się od składni w stronę zdobywania zaufania

Gdy agent rozwiązuje odizolowane ćwiczenie, tradycyjne zadanie słabo mierzy pracę studenta. Obce repozytorium dodaje elementy, których nie da się łatwo ominąć promptem: niepełny kontekst, lokalne konwencje, dawne decyzje i człowieka, który może odrzucić zmianę.

Dla firm ten scenariusz lepiej przypomina wdrażanie juniora. Tworzenie diffu stanie się powszechne. Większą wartość przyniesie wybór problemu, sprawdzenie zachowania i wyjaśnienie zmiany tak, by zespół mógł jej zaufać. Kurs ocenia jakość nadzoru nad AI, a nie opór wobec narzędzia.

Jeden kurs nie ustanawia jeszcze nowego standardu branży

Źródłem jest rozmowa z wykładowcą, który jednocześnie kieruje AI w Monaco. Dostajemy szczegółowy opis zajęć i praktyki jego zespołu, ale nie porównawcze badanie wyników studentów. Nie wiemy, czy absolwenci tworzą bardziej niezawodne oprogramowanie niż uczestnicy tradycyjnego kursu.

Review open source mierzy tylko część pracy. Maintainer widzi patch i jego uzasadnienie, lecz trudniej mu ocenić, ile decyzji student oddał agentowi oraz czy sam znalazłby błąd produkcyjny. Potrzebne pozostają samodzielne czytanie diffu, testowanie i reakcja na incydent.

Odpowiedź dadzą przyjęte patche i błędy znalezione samodzielnie

Mocnym sygnałem będą zmiany faktycznie przyjęte przez maintainers oraz zdolność studentów do ich poprawy po krytycznym review. Jeszcze ważniejsze będzie wyjaśnienie nieoczekiwanego zachowania, znalezienie błędu w propozycji agenta i bezpieczna interwencja po utracie kontekstu.

Jeśli takie zadania się upowszechnią, szkoły przestaną ścigać się z narzędziami za pomocą zakazów. Postawią studenta przed człowiekiem, który ma prawo powiedzieć, że patch nie pasuje do jego projektu.

Werdykt Lilith

Agent może napisać patch za studenta. Przed maintainerem nadal stoi student i właśnie tam zaczyna się nauka, której nie da się zatwierdzić jednym kliknięciem.