Windsurf, dziś Devin Desktop od Cognition

Windsurf, dziś Devin Desktop od Cognition

Windsurf to edytor kodu zbudowany wokół agenta, który czyta projekt, wprowadza zmiany w wielu plikach naraz, uruchamia polecenia i reaguje na ich wynik. Od zwykłego uzupełniania kodu różni się tym, że pracuje zadaniami, a nie linijkami. Od 2 czerwca 2026 roku nosi nazwę Devin Desktop, bo Cognition zebrało swoje produkty pod jedną marką.

Historia tego produktu jest niezwykła nawet jak na tę branżę i warto ją znać, bo tłumaczy, dlaczego materiały sprzed roku opisują coś innego, niż zobaczysz po instalacji.

Kto to dzisiaj robi

Firma nazywała się wcześniej Codeium i wypuszczała darmowego asystenta do kodowania. Potem przemianowała się na Windsurf i wydała własny edytor.

W 2025 roku wydarzyła się rzecz nietypowa. Google zapłaciło za niewyłączną licencję na technologię i zatrudniło dyrektora generalnego, drugiego współzałożyciela oraz część zespołu badawczego. Prasa podawała przy tej transakcji 2,4 miliarda dolarów. Firma została z produktem, klientami i resztą pracowników, ale bez kierownictwa.

Kilka dni później resztę przejęło Cognition, czyli firma stojąca za Devinem, autonomicznym agentem programistycznym. Warunków nie ujawniono, a kwota krążąca w doniesieniach to około dwustu pięćdziesięciu milionów dolarów, więc traktuj ją jako liczbę z prasy, a nie z komunikatu.

Kierunek po tej zmianie jest czytelny. Windsurf przestał być samodzielnym edytorem konkurującym funkcjami, a stał się częścią platformy łączącej pracę w edytorze z agentem wykonującym całe zadania bez nadzoru. Wydanie oznaczone numerem dwa ukazało się 15 kwietnia 2026 roku i dołożyło agenta chmurowego dostępnego wprost z edytora oraz Agent Command Center, czyli widok kanban ze wszystkimi sesjami agentów naraz.

Windsurf nazywa się teraz Devin Desktop

2 czerwca 2026 roku produkt został przemianowany i przyszło to zwykłą aktualizacją. Cognition zebrało cztery rzeczy pod jedną marką: Devin Cloud, Devin Desktop, Devin CLI i Devin Review.

Przy samym pisaniu kodu zmienia się niewiele. Edytor, rozszerzenia, skróty, przepływy pracy i ustawienia zostają przeniesione automatycznie, plany i ceny są bez zmian, a wtyczka do JetBrains zachowała nazwę Windsurf. Zmienia się to, czego w oknie edytora nie widać. Aplikacja nazywa się teraz Devin, czyli Devin.app na macOS i Devin.exe na Windows, więc firmowa polityka zarządzania urządzeniami dopuszczająca wyłącznie „Windsurf" zablokuje ją po aktualizacji. Polecenie surf zastąpiło devin-desktop, choć stare nazwy nadal leżą w ~/.codeium/windsurf/bin/. Pakiet na Linuksie nazywa się devin-desktop, a windsurf został przejściową zależnością. Dokumentacja i changelog przeniosły się na docs.devin.ai.

Osobno zmienia się agent. Cascade dostał następcę o nazwie Devin Local, dzielącego silnik z Devin CLI: zużywa do trzydziestu procent mniej tokenów na to samo zadanie, umie odpalać podagentów i działa w piaskownicy z izolacją systemu plików i filtrowaniem ruchu sieciowego. Nowe rozmowy startują domyślnie na Devin Local, Cascade został jako drugi agent do wyboru, a przepływy pracy i wspomnienia przenosi się kreatorem migracji. Rozliczenie w obu wariantach jest identyczne.

Praktyczna konsekwencja dla Ciebie: przy ocenie tego narzędzia patrz na wydania z ostatniego półrocza, a nie na porównania sprzed roku, bo dotyczą innego produktu i innej nazwy.

Agent, czyli sedno tego edytora

Agent, wszystko jedno czy Cascade, czy Devin Local, to nie jest okno czatu obok kodu. Różnica polega na tym, co dzieje się po Twoim poleceniu.

Zwykły asystent proponuje fragment, który wklejasz. Agent czyta pliki, których potrzebuje, zmienia kilka z nich naraz, uruchamia testy albo budowanie, patrzy na wynik i poprawia to, co się nie udało. Ty widzisz zmiany jako propozycję do zaakceptowania, a nie jako gotowy fakt.

Zysk pojawia się przy zadaniach rozłożonych na wiele plików: dodanie pola do modelu, które trzeba przeprowadzić przez migrację, warstwę danych, interfejs i testy, albo zamiana biblioteki na inną w trzydziestu miejscach. To jest praca mechaniczna, w której człowiek myli się z nudy, a agent nie.

Strata pojawia się przy zadaniach wymagających decyzji. Agent poproszony o „poprawienie wydajności" zrobi coś, co wygląda na poprawę, i niekoniecznie to, co było potrzebne. Im bardziej zadanie polega na wyborze między rozwiązaniami, tym mniej z tego pożytku.

Praktyczna zasada, która wychodzi po kilku tygodniach pracy: opisuj rezultat i ograniczenia, nie kroki. „Dodaj obsługę anulowania zamówienia, zachowując istniejący interfejs serwisu i dopisując testy do pliku obok" działa lepiej niż lista poleceń, bo agent sam ustali kolejność, a Ty ustaliłeś granice.

Indeksowanie kodu i skąd bierze się kontekst

To jest element, który najbardziej różnicuje narzędzia w tej kategorii i najmniej rzuca się w oczy.

Agent nie widzi całego repozytorium naraz, bo się nie mieści. Widzi to, co system wyszukiwania mu poda, więc jakość odpowiedzi zależy w dużej mierze od tego, czy właściwe pliki trafiły do kontekstu.

Przy dużym repozytorium warto o to zadbać samodzielnie. Wskazanie konkretnych plików w poleceniu daje lepszy wynik niż liczenie na to, że wyszukiwanie trafi. Podobnie działa opisanie, gdzie leży rzecz, o którą chodzi: nazwa katalogu w zdaniu zawęża poszukiwania skuteczniej niż dokładniejszy opis samego zadania.

Osobną warstwą są reguły projektu zapisane w pliku w repozytorium. To jest miejsce na konwencje nazewnicze, użyte biblioteki, wzorce, których zespół unika, i wersję języka. Bez tego agent pisze kod poprawny i niepasujący do reszty, a Ty poprawiasz to samo przy każdej zmianie.

Lokalizacja tych plików zmieniła się razem ze zmianą właściciela i warto o tym wiedzieć, bo starsze poradniki wskazują miejsce, które jest dziś wariantem zapasowym.

.devin/rules/            preferowane, ma pierwszenstwo, po jednym pliku md na regule
.windsurf/rules/         wariant zapasowy, nadal odczytywany
.windsurfrules           format historyczny, jeden plik w korzeniu repozytorium
AGENTS.md                reguly dla katalogu i jego podkatalogow, zawsze wlaczone
~/.codeium/windsurf/memories/global_rules.md    reguly globalne dla wszystkich projektow

Reguły dzielone na osobne pliki tematyczne działają lepiej niż jeden długi plik, bo limit wynosi dwanaście tysięcy znaków na plik reguły w katalogu i sześć tysięcy na plik globalny, a krótsza reguła rzadziej ginie w kontekście. Reguły katalogowe mają w nagłówku tryb aktywacji: zawsze, po decyzji modelu, dla plików pasujących do wzorca albo wyłącznie na żądanie. Reguły z .cursor/rules da się zaimportować.

# Warstwa danych

- Zapytania do API wylacznie przez src/api/client.ts
- Nie uzywamy fetch bezposrednio w komponentach
- Bledy sieciowe obsluguje wrapper, komponent dostaje juz Result
- Nowe endpointy dopisujemy razem z typem odpowiedzi w src/api/types.ts

Warto też wiedzieć, co wychodzi na zewnątrz. Kod z otwartego projektu trafia do modelu, więc przy repozytorium objętym umową o poufności trzeba sprawdzić warunki planu i ustawienia wykluczające pliki, zamiast zakładać, że domyślne są odpowiednie.

Co się zmienia, gdy edytor spotyka agenta zdalnego

Kierunek nadany przez nowego właściciela sprowadza się do połączenia dwóch trybów pracy, które dotąd istniały osobno, i warto rozumieć różnicę między nimi.

Praca w edytorze jest interaktywna. Widzisz zmiany, akceptujesz je po kolei, przerywasz, gdy agent idzie w złą stronę. Pętla zwrotna trwa sekundy, a Ty cały czas siedzisz przy tym zadaniu.

Praca agenta zdalnego jest odwrotna. Opisujesz zadanie, odchodzisz, wracasz po kilkudziesięciu minutach do gotowego zgłoszenia zmian. Pętla trwa dłużej, za to nie zajmuje Twojego czasu w trakcie.

Te dwa tryby pasują do różnych zadań i to jest rozróżnienie, które warto zrobić świadomie. Zmiana wymagająca decyzji co kilka kroków marnuje się w trybie zdalnym, bo agent podejmie te decyzje sam i połowa będzie nie po Twojej myśli. Zadanie mechaniczne, jak przeniesienie stu wywołań na nowy interfejs, marnuje Twój czas w trybie interaktywnym, bo siedzisz i klikasz akceptację.

Praktyczna droga wygląda tak: zadania, które umiesz opisać w trzech zdaniach razem z kryterium ukończenia, nadają się do trybu zdalnego. Wszystko, co wymaga oglądania po drodze, zostaje w edytorze.

Warto też mieć wspólny sposób sprawdzania wyniku. Agent pracujący bez nadzoru potrzebuje testów i sprawdzania typów jako warunku zakończenia, inaczej wynik trzeba przeglądać tak samo uważnie jak przy pracy interaktywnej, a wtedy zysk znika.

{
  "scripts": {
    "verify": "pnpm lint && tsc --noEmit && pnpm test --run"
  }
}

Jedno polecenie zbierające wszystkie sprawdzenia jest tu ważniejsze, niż wygląda. Agent, któremu w regułach napiszesz, że zadanie kończy się dopiero po przejściu tego polecenia, sam poprawia własne błędy zamiast oddawać kod, który się nie kompiluje. Projekt bez tej warstwy zwykle nie jest gotowy na tryb zdalny, niezależnie od tego, jak dobre jest samo narzędzie.

Koszt i jak nim sterować

Rozliczanie w tej kategorii narzędzi opiera się na zużyciu, a nie na liczbie osób, i to zmienia sposób pracy bardziej, niż wygląda.

Główna zasada jest prosta: zadanie zadane agentowi kosztuje tyle, ile wynika z liczby kroków i wielkości kontekstu. Polecenie odsyłające do konkretnych plików kosztuje mniej niż polecenie zmuszające do przeszukania repozytorium, bo agent nie musi czytać połowy projektu, żeby znaleźć punkt wyjścia.

Różnicę widać najlepiej na dwóch zapisach tego samego zadania.

Drogo:  napraw blad w koszyku, po dodaniu drugiej sztuki cena sie nie odswieza

Taniej: w src/cart/useCartTotals.ts cena nie przelicza sie po zmianie ilosci,
        sprawdz zaleznosci useMemo, test w src/cart/__tests__/totals.test.ts

Drugi zapis nie jest dłuższy przez uprzejmość, tylko dlatego, że zdejmuje z agenta etap szukania, który przy dużym repozytorium bywa droższy niż sama poprawka.

Druga zasada dotyczy modelu. Do zadań mechanicznych opłaca się słabszy i tańszy wariant, do zadań wymagających rozumowania mocniejszy. Używanie najmocniejszego do wszystkiego jest najczęstszym sposobem na wyczerpanie puli w połowie miesiąca.

Trzecia dotyczy długości sesji. Rozmowa prowadzona nad jednym zadaniem przez godzinę niesie ze sobą cały dotychczasowy kontekst, więc każdy kolejny krok kosztuje więcej niż poprzedni. Zamknięcie zadania i rozpoczęcie nowego bywa tańsze niż dalsze poprawianie w tej samej sesji.

Warto obejrzeć zużycie po pierwszym tygodniu pracy zespołu. Rozkład zwykle zaskakuje: kilka osób generuje większość kosztu, a przyczyną jest zwykle sposób formułowania poleceń, a nie liczba zadań.

Same plany po zmianie nazwy zostały te, które obowiązywały wcześniej:

Przydział odnawia się dziennie i tygodniowo, a nie jednym zastrzykiem na początku miesiąca, więc dzień z ciężkimi zadaniami nie zabiera całego okresu rozliczeniowego. Po wyczerpaniu przydziału na planie płatnym dokupujesz zużycie po stawkach API, więc praca się nie zatrzymuje, tylko przestaje być ryczałtem.

Windsurf kontra alternatywy

Pierwsze dwa wiersze są do siebie najbardziej podobne i wybór między nimi rzadko rozstrzyga się listą funkcji, bo obie rzeczy nadrabiają nawzajem co kilka miesięcy. Rozstrzyga zwykle to, w którym z nich agent lepiej trafia w kontekst Twojego konkretnego repozytorium, a to da się sprawdzić wyłącznie u siebie, w tydzień.

Czwarty wiersz warto rozważyć, jeśli zmiana edytora jest kosztem. Narzędzie działające w terminalu wpina się w każdy stos i nie zmusza do porzucenia konfiguracji, którą budowałeś latami. Traci się podpowiadanie w czasie pisania, zyskuje niezależność od jednego produktu.

Praktyka codziennej pracy

Kilka rzeczy zmienia skuteczność bardziej niż wybór narzędzia.

Pracuj małymi zmianami. Zadanie obejmujące trzy pliki da się przejrzeć, zadanie obejmujące trzydzieści przejrzy tylko ktoś bardzo zdeterminowany, a nieprzejrzana zmiana od agenta to zmiana, której nikt nie rozumie.

Trzymaj czyste drzewo pracy przed uruchomieniem agenta. Zmiany wprowadzane automatycznie mieszają się wtedy z Twoimi i cofnięcie jednych bez drugich staje się kłopotliwe.

Testy zmieniają całą dynamikę. Agent, który po zmianie uruchamia testy i widzi czerwony wynik, poprawia się sam. Agent bez testów zgłasza gotowość i zostawia Ci sprawdzanie. To jest najtańsza inwestycja w skuteczność tego typu narzędzi.

Czytaj to, co przechodzi. Kod wygenerowany wygląda na dopracowany i to jest jego najbardziej mylące działanie. Obsługa błędów, przypadki brzegowe i zachowanie przy pustych danych to miejsca, w których wygląd rozjeżdża się z zawartością najczęściej.

Ostatnia rzecz: nie każde zadanie nadaje się dla agenta. Poprawka jednej linijki, którą wiesz jak zrobić, zajmie Ci mniej czasu niż opisanie jej.

Warto też zapisywać polecenia, które zadziałały. Sformułowanie, po którym agent trafił za pierwszym razem, jest w tym samym repozytorium wielokrotnie użyteczne, a odtwarzanie go z pamięci po dwóch tygodniach zwykle się nie udaje. Kilka takich zapisów w pliku obok reguł projektu przyspiesza pracę całego zespołu bardziej niż jakiekolwiek ustawienie.

Typowe błędy

Pierwszy to ocenianie narzędzia na podstawie materiałów sprzed zmiany właściciela. Produkt przeszedł przez licencjonowanie technologii do Google, odejście kierownictwa, przejęcie przez Cognition i zmianę nazwy na Devin Desktop, więc porównania sprzed roku dotyczą innego etapu i innej nazwy w wynikach wyszukiwania.

Drugi to zadania obejmujące zbyt wiele plików naraz. Zmiana, której nie da się przejrzeć, trafia do repozytorium bez przeglądu i to jest dług, nie oszczędność.

Trzeci to brak pliku z regułami projektu. Bez niego agent pisze kod niezgodny z konwencjami zespołu, a Ty poprawiasz to samo w kółko.

Czwarty to uruchamianie agenta na brudnym drzewie pracy. Rozdzielenie własnych zmian od automatycznych staje się wtedy osobnym zadaniem.

Piąty to praca bez testów. Agent bez informacji zwrotnej z uruchomienia nie ma jak sam się poprawić i przerzuca całe sprawdzanie na Ciebie.

Szósty to pominięcie kwestii tego, co wychodzi na zewnątrz. Przy kodzie objętym umową o poufności warunki planu i wykluczenia plików trzeba ustawić świadomie.

Siódmy to prowadzenie jednej sesji przez godzinę zamiast domykania zadań. Kontekst rośnie z każdym krokiem, więc rośnie koszt, a skuteczność poprawek spada, bo agent gubi się we własnych wcześniejszych decyzjach.

Ósmy to zakładanie, że agent zna kontekst biznesowy. Wie, co widzi w plikach, i nic poza tym, więc reguła, która istnieje wyłącznie w głowach zespołu, zostanie złamana bez ostrzeżenia. To, co ma być przestrzegane, musi być zapisane w regułach projektu albo w teście.

FAQ

Kto jest właścicielem Windsurfa i jak się dziś nazywa?

Cognition, firma stojąca za autonomicznym agentem Devin. Przejęcie nastąpiło w 2025 roku, kilka dni po tym, jak Google wykupiło niewyłączną licencję na technologię i zatrudniło dyrektora generalnego oraz drugiego współzałożyciela wraz z częścią zespołu badawczego. Sam edytor od 2 czerwca 2026 roku nazywa się Devin Desktop; nazwa Windsurf została przy wtyczce do JetBrains.

Czym Windsurf różni się od Cursora?

Punktem wyjścia. Oba są edytorami z agentem czytającym projekt i zmieniającym wiele plików naraz, a różnice w funkcjach zacierają się co kilka miesięcy. Rozstrzygające jest zwykle to, który lepiej trafia w kontekst Twojego repozytorium, i sprawdzisz to tylko u siebie.

Czy Windsurf jest darmowy?

Jest plan darmowy z lekkim przydziałem i skróconą listą modeli. Plany płatne zaczynają się od dwudziestu dolarów miesięcznie za Pro, dwustu za Max, a zespołowy kosztuje osiemdziesiąt dolarów za zespół plus czterdzieści za każde pełne miejsce. Przydział odnawia się dziennie i tygodniowo, a po jego wyczerpaniu dokupujesz zużycie po stawkach API.

Czy mój kod trafia do modelu?

Tak, bo bez tego agent nie ma jak działać. Przy repozytorium objętym poufnością sprawdź warunki planu, ustawienia retencji oraz mechanizm wykluczania plików, zamiast zakładać, że domyślne wystarczą.

Czy trzeba zmieniać edytor?

Przy tym narzędziu tak, bo jest osobnym edytorem. Jeśli zmiana środowiska jest kosztem, Aider działa w terminalu i wpina się w istniejącą konfigurację, a GitHub Copilot instaluje się jako rozszerzenie.

Dokumentacja stoi dziś pod adresem docs.devin.ai, zmianę właściciela opisuje komunikat Cognition, a zmianę nazwy wpis o Devin Desktop.