Kategoria: Aktualności techniczne

  • OpenCode Wzmacnia Stabilność i Usprawnia Sesje w Aktualizacji v1.2.27

    OpenCode Wzmacnia Stabilność i Usprawnia Sesje w Aktualizacji v1.2.27

    Popularny, open-source'owy asystent kodowania AI, OpenCode, doczekał się nowej wersji, która koncentruje się głównie na poprawie stabilności rdzenia aplikacji oraz usprawnieniu zarządzania sesjami deweloperskimi. Zamiast wprowadzać wyłącznie głośne nowości, zespół skupił się na solidnych fundamentach, naprawiając kluczowe błędy, które mogły utrudniać codzienną pracę programistów.

    Kluczowe poprawki stabilności systemu

    Sercem aktualizacji są poprawki eliminujące uciążliwe błędy. Jedną z najważniejszych zmian jest naprawa logiki w VCS watcher, czyli mechanizmie monitorującym system kontroli wersji. Błąd ten mógł prowadzić do problemów z wykrywaniem zmian w repozytorium Git, co jest podstawą interakcji asystenta z kodem. To udoskonalenie zapewnia teraz bardziej niezawodną integrację z narzędziami VCS.

    Dodatkowo przeprowadzono refaktoryzację w obszarze zarządzania sesjami i uprawnieniami, w tym usprawnienia związane z InstanceState ALS. W tle wykonano też inne prace porządkowe, takie jak czyszczenie zawieszonych wpisów po anulowaniu zapytań do AI czy usunięcie niepotrzebnego handlera sygnału SIGHUP.

    Lepsza trwałość sesji i zarządzanie pracą

    Dla użytkowników pracujących na wielu gałęziach (worktrees) czy gałęziach typu orphan, jedna poprawka będzie szczególnie istotna. Zespół wyeliminował problem polegający na utracie sesji przy przechodzeniu między różnymi kontekstami pracy. Dzięki wkładowi społeczności stan rozmowy z asystentem AI jest teraz prawidłowo utrzymywany, co znacząco poprawia płynność pracy w złożonych projektach.

    W obszarze wewnętrznej architektury QuestionService został przepisany z wykorzystaniem efektów (effects), co wpisuje się w szerszy trend modernizacji kodu OpenCode w kierunku bardziej przewidywalnego i łatwiejszego w utrzymaniu paradygmatu. Co ciekawe, zwiększono również domyślny limit czasu na przetworzenie fragmentu (chunk timeout) z 2 do 5 minut. Zmiana ta, wprowadzona po wcześniejszym wyłączeniu limitu z powodu problemów w specyficznych przypadkach użycia, ma zapobiegać przedwczesnemu przerywaniu długich operacji.

    Dopracowanie interfejsu desktopowego

    Aktualizacja przynosi także subtelne, ale ważne usprawnienia w interfejsie aplikacji desktopowej. Wprowadzono między innymi poprawki związane z przełączaniem obszarów roboczych, aby wyeliminować efekt migotania, oraz usprawnienia w nawigacji po projektach. Drobne zmiany w UI poprawiają ogólne wrażenia użytkownika (UX).

    Warto zaznaczyć, że za poprawki w tej wersji odpowiedzialnych było kilku contributorów ze społeczności, co podkreśla zaangażowanie użytkowników w rozwój tego otwartego projektu. OpenCode konsekwentnie ewoluuje, reagując na feedback. Te poprawki stabilizacyjne bezpośrednio odpowiadają na postulaty społeczności dotyczące potrzeby stabilnych wydań i niezawodnych aktualizacji, często zgłaszane w dyskusjach na GitHubie.

    Podsumowanie: Krok w stronę dojrzałości

    To wydanie OpenCode może nie oszałamia liczbą nowych funkcji, ale takie aktualizacje świadczą o dojrzałości projektu. Skupienie się na podstawach – stabilności systemu kontroli wersji, niezawodności sesji i wygładzaniu interfejsu – bezpośrednio przekłada się na produktywność i komfort pracy programistów. To strategiczne podejście, w którym solidny fundament pozwala na bezpieczniejsze i szybsze wprowadzanie innowacji w przyszłości. Dla obecnych użytkowników jest to przede wszystkim aktualizacja, dzięki której narzędzie będzie działać lepiej, szybciej i z mniejszą liczbą frustrujących niespodzianek.

    Źródła

  • Kimi Code CLI 1.21.0: głębsza kontrola nad agentem i lepsze zarządzanie sesjami

    Kimi Code CLI 1.21.0: głębsza kontrola nad agentem i lepsze zarządzanie sesjami

    Wersja 1.21.0 narzędzia Kimi Code CLI przynosi zmiany, które wielu użytkowników nazywa przełomowymi. Nie chodzi tu o nowe, błyskotliwe funkcje, ale o solidną pracę nad fundamentami – sposobem, w jaki współpracujemy z asystentem AI w terminalu. To aktualizacja, która sprawia, że rozmowa z agentem przestaje być monologiem z przerwami na ładowanie, a zaczyna przypominać płynną, dynamiczną wymianę zdań z partnerem, który naprawdę słucha.

    Głównym autorem wszystkich kluczowych zmian w tej wersji jest użytkownik GitHub o nicku @RealKai42, którego serie pull requestów znacząco przeprojektowały interakcję z agentem.

    Sterowanie agentem w locie: koniec biernego oczekiwania

    Najważniejsza nowość to inline running prompt. Wcześniej, gdy agent (np. model AI) rozpoczął generowanie odpowiedzi czy wykonywanie zadania, użytkownik musiał cierpliwie czekać na zakończenie całej tury. Każda chęć doprecyzowania, zmiany kierunku lub odpowiedzi na pytanie agenta wymagała przerwania procesu lub oczekiwania na jego koniec.

    Wersja 1.21.0 burzy ten schemat. Teraz output agenta renderowany jest bezpośrednio w obszarze promptu, a użytkownik może w dowolnym momencie wpisać i wysłać kolejną wiadomość – tak zwaną komendę sterującą (steer). Może to być uzupełnienie instrukcji („zamiast tego użyj biblioteki X”), odpowiedź na pytanie agenta („tak, zatwierdzam usunięcie tego pliku”) lub całkowita zmiana kontekstu.

    Co kluczowe, dzieje się to bez przerywania generowania bieżącej odpowiedzi. Agent otrzymuje nasz nowy input i dynamicznie dostosowuje do niego swoje dalsze działanie. Mechanizm został przeprojektowany – zamiast sztucznych, „syntetycznych” wywołań narzędzi, nasze komunikaty sterujące są teraz dołączane jako zwykłe wiadomości użytkownika. To rozwiązanie eleganckie i bardziej kompatybilne z systemem wizualizacji oraz zapisywaniem kontekstu.

    W praktyce oznacza to, że jeśli agent zaczyna iść w niepożądanym kierunku, nie musimy już czekać, aż skończy, by to skorygować. Możemy od razu interweniować. To kolosalna różnica dla płynności pracy.

    Trwałe prompty systemowe i lepszy kontekst

    Kolejna istotna poprawka dotyczy zarządzania kontekstem sesji. Do tej pory prompt systemowy – czyli początkowe instrukcje definiujące rolę i sposób działania agenta – był traktowany jako coś ulotnego. Po restarcie sesji czy podczas jej analizy w narzędziach wizualizacyjnych ta kluczowa informacja mogła zostać utracona lub stać się nieczytelna.

    W 1.21.0 prompt systemowy jest na stałe zapisywany jako pierwszy wpis w pliku context.jsonl. Ma to dwie ogromne zalety. Po pierwsze, narzędzia do wizualizacji sesji (jak kimi vis) mogą teraz odczytać pełny kontekst konwersacji, łącznie z pierwotnymi założeniami. Po drugie, gdy sesja jest wznawiana, agent odzyskuje dokładnie te same początkowe instrukcje, zamiast próbować je odtwarzać lub działać bez nich. Zapewnia to znacznie większą spójność i przewidywalność działań agenta w dłuższym horyzoncie czasowym.

    Wizualizacja i zarządzanie sesjami bez wychodzenia z terminala

    Wizualizacja i zarządzanie sesjami bez wychodzenia z terminala

    Panel wizualizacji (kimi vis) również otrzymał przydatne ulepszenia. Dodano skróty do katalogów sesji bezpośrednio ze strony podglądu sesji. Użytkownik może teraz jednym kliknięciem otworzyć folder bieżącej sesji w eksploratorze plików swojego systemu (obsługa zarówno macOS, jak i Windows) lub skopiować ścieżkę do schowka (akcja „Copy DIR”).

    To może wydawać się drobnostką, ale dla deweloperów, którzy często analizują logi, ślady wykonania czy zapisane konteksty, jest to ogromne ułatwienie. Nie trzeba już ręcznie nawigować przez ukryte foldery w ~/.kimi/ – dostęp jest natychmiastowy.

    Dopracowanie szczegółów: logowanie, powiadomienia i replay sesji

    Dopracowanie szczegółów: logowanie, powiadomienia i replay sesji

    Reszta zmian w tej wersji to dopracowanie istniejących funkcji, które razem tworzą znacznie lepsze doświadczenie użytkownika (UX).

    • Lepsze logowanie: Proces konfiguracji klucza API został usprawniony. Podczas weryfikacji klucza wyświetlany jest teraz animowany spinner, a w przypadku błędu (np. wybrania złej platformy) system wyświetla bardziej pomocne komunikaty. Po udanym logowaniu pojawia się jasne podsumowanie konfiguracji.
    • Naprawione powiadomienia: Komenda aktualizacji wyświetlana w powiadomieniach typu „toast” jest teraz pobierana z jednej, stałej wartości, co eliminuje niespójności.
    • Ulepszony replay sesji: Mechanizm odtwarzania zapisanych sesji został poprawiony, aby poprawnie wyświetlać komunikaty sterujące (steer messages) wysłane podczas pracy agenta. Filtruje też wewnętrzne, techniczne komunikaty systemowe, przez co odtworzona konwersacja jest czystsza i bardziej zrozumiała.
    • Echo wpisanego tekstu: W trybie agenta, po wysłaniu wiadomości, prompt i nasz tekst są teraz wyświetlane (echo) w terminalu. Dzięki temu zapis rozmowy jest bardziej przejrzysty i przypomina naturalną wymianę zdań.

    Kimi Code CLI: kontekst dla deweloperów

    Dla tych, którzy nie mieli wcześniej styczności z tym narzędziem, warto przypomnieć, czym jest Kimi Code CLI. To open-source'owy agent AI działający w terminalu, stworzony przez MoonshotAI i wydany na licencji Apache 2.0. Jego filozofia opiera się na transparentności i kontroli – agent pomaga w zadaniach programistycznych (pisanie, edycja i analiza kodu, operacje shellowe, automatyzacja), ale cały jego proces myślowy, wywołania narzędzi i podjęte działania są widoczne dla użytkownika.

    CLI obsługuje integrację z IDE przez Agent Client Protocol (ACP) – można je skonfigurować np. w edytorze Zed. Posiada też tryb shell, w którym można wykonywać zwykłe polecenia systemowe, oraz wsparcie dla MCP (Model Context Protocol), co pozwala na rozszerzanie jego możliwości o zewnętrzne narzędzia i serwisy.

    Podsumowanie: ewolucja w kierunku płynnej współpracy

    Wersja 1.21.0 Kimi Code CLI nie rzuca się w oczy nowym sloganem czy marketingowym szumem. To aktualizacja dla praktyków – deweloperów, którzy na co dzień używają AI jako partnera w terminalu. Główne zmiany – sterowanie agentem w locie, trwały kontekst i usprawnienia wizualizacji – mają jeden wspólny mianownik: zmniejszają dystans i opóźnienia między intencją użytkownika a działaniem agenta.

    Dzięki temu praca z narzędziem staje się bardziej dynamiczna, interaktywna i w końcu przypomina prawdziwą współpracę, a nie asynchroniczne rzucanie zadań w próżnię. Te ulepszenia fundamentów są często ważniejsze niż kolejna nowa, choćby i spektakularna funkcja. Pokazują też dojrzałość projektu, który skupia się na jakości doświadczenia użytkownika, a nie tylko na rozbudowie listy możliwości.

  • Antigravity 1.20.5: rozszerzone wsparcie agentów i poprawa wydajności — ale rzeczywistość weryfikuje entuzjazm

    Antigravity 1.20.5: rozszerzone wsparcie agentów i poprawa wydajności — ale rzeczywistość weryfikuje entuzjazm

    Ostatnia aktualizacja Google Antigravity, oznaczona numerem wersji 1.20.5, oficjalnie skupia się na poprawie stabilności i interfejsu użytkownika. Wokół tego wydania narosło jednak sporo kontrowersji. Z jednej strony mówi się o rozszerzonym wsparciu dla agentów AI, choćby przez możliwość odczytu reguł z pliku AGENTS.md obok istniejącego GEMINI.md, oraz o przyspieszeniu ładowania długich konwersacji. Z drugiej, społeczność użytkowników zgłasza poważne problemy z wydajnością agentów i kompatybilnością modeli, które zdają się przeczyć tym obietnicom.

    Wersja 1.20.5 została wydana 9 marca 2026 roku i jest stopniowo udostępniana użytkownikom. Jej oficjalny changelog jest dość lakoniczny, co już na wstępie może budzić pewne wątpliwości. Czym tak naprawdę jest Antigravity w kontekście pracy dewelopera? To narzędzie oparte na Electronie, pełniące funkcję środowiska IDE napędzanego AI, gdzie kluczową rolę odgrywają agenci asystujący w kodowaniu. Dlatego każda zmiana w jego działaniu ma realny wpływ na codzienne workflow programistów.

    Oficjalne zapowiedzi a relacje z frontu

    Zgodnie z informacjami przekazywanymi przez entuzjastów, aktualizacja 1.20.5 miała wprowadzić kilka konkretnych usprawnień. Poza wspomnianym już rozszerzeniem wsparcia dla plików konfiguracyjnych agentów, miała również poprawić kontrast kolorów w menedżerze agentów oraz naprawić błąd w rozliczaniu tokenów, który mógł przedwcześnie zakańczać rozmowy. Teoretycznie brzmi to jak solidny zestaw poprawek, który powinien usatysfakcjonować użytkowników.

    Niestety, rzeczywistość okazała się bardziej skomplikowana. Na forach i w społecznościach internetowych odnotowano lawinę zgłoszeń dotyczących błędów wykonania agentów. Użytkownicy otrzymywali komunikaty typu „Error Unknown: Agent execution terminated due to error”, które zapętlają się nawet przy użyciu różnych modeli, takich jak Gemini 3.1 Pro czy Flash. W logach często pojawia się informacja „UNAVAILABLE (code 503): No capacity available”, sugerująca problemy po stronie infrastruktury lub integracji.

    Co gorsza, prawdopodobnie nie naprawiono jednego z bardziej uciążliwych błędów dotyczącego rozliczania tokenów, który wcześniej mógł blokować konta Pro na siedem dni. Zamiast tego niektórzy użytkownicy zaczęli obserwować nowy błąd: „could not convert a single message before hitting truncation”. Inni testowali model Claude 3.6 Sonnet, który działał jedynie przez krótki czas, po czym zgłaszał przekroczenie limitu („quota over”).

    Problemy z automatyzacją i metody ratunkowe

    Kolejnym punktem zapalnym stał się system automatycznych aktualizacji. Wielu użytkowników krytykuje go za brak opcji wyboru, co zmusza do przyjmowania potencjalnie niestabilnych wersji. To ważny aspekt z punktu widzenia DevOps — wymuszony rollout wadliwego oprogramowania może poważnie zakłócić procesy produkcyjne, zwłaszcza gdy narzędzie jest integralną częścią pipeline’u deweloperskiego.

    W odpowiedzi na te problemy społeczność szybko opracowała metody ratunkowe. Jedną z nich jest blokowanie aktualizatora przez usunięcie cache (~/Library/Caches/com.google.antigravity.ShipIt), ustawienie folderów jako tylko do odczytu lub zmianę ustawienia na "update.mode": "none". To wyraźny sygnał, że zaufanie do płynnego procesu aktualizacji zostało nadszarpnięte.

    Co robią użytkownicy, gdy nowa wersja zawodzi? Często decydują się na powrót do starszej, stabilniejszej wersji. W środowisku PowerShell można to zrobić za pomocą polecenia winget install Google.Antigravity --version 1.19.6 --force. Wersja 1.19.6 z 28 lutego 2026 roku, oznaczona etykietą „Account Remediation Pathway”, okazuje się często bardziej niezawodna niż jej następczyni. To dość wymowne, że stabilność oferuje starsze wydanie.

    Dlaczego to ważne dla web developera i zespołów AI?

    Dlaczego to ważne dla web developera i zespołów AI?

    Kontekst jest tu kluczowy. Antigravity nie jest jedynie ciekawostką. Dla wielu profesjonalistów to narzędzie pracy, które integruje się z modelami językowymi (LLM) i automatyzuje części procesu tworzenia kodu. Wsparcie dla plików takich jak AGENTS.md czy GEMINI.md wskazuje na trend konfigurowalnych, specyficznych dla projektu agentów, którzy mogą operować na konkretnych zasadach i wiedzy.

    Gdy takie narzędzie zaczyna niedomagać, skutki są bardzo realne. Opóźnienia w projektach, niespodziewane błędy podczas generowania kodu, przerwy w pracy — wszystko to przekłada się na produktywność i koszty. Problemy z kompatybilnością modeli (Gemini, Claude) dodatkowo komplikują sprawę, zmuszając do testowania i szukania alternatyw w czasie, który mógłby być poświęcony na rozwój.

    Warto zauważyć, że system limitów, który przyczynia się do błędów „quota over”, został wprowadzony przez Google pod koniec 2025 roku. Jest to celowa zmiana wprowadzająca dwa jednoczesne limity: sprint 250 jednostek resetujący się co 5 godzin oraz tygodniową bazę 2800 jednostek. Ten system istniał już przed wydaniem wersji 1.20.5 i nie jest jej bezpośrednim skutkiem.

    Sama dystrybucja aktualizacji przez różne kanały (Chocolatey, Arch AUR, Ubuntu, oficjalna strona) pokazuje również złożoność ekosystemu. Zalecenie z niektórych źródeł, aby stosować tryb ręcznej aktualizacji i pozostawać przy starszych wersjach, to przyznanie się do problemów z jakością nowszych wydań.

    Podsumowanie: wymagany ostrożny optymizm

    Wydanie Antigravity 1.20.5 to klasyczny przykład rozdźwięku między oficjalnymi komunikatami a doświadczeniami użytkowników. Oficjalnie to aktualizacja skupiona na stabilności i UI, ale społeczność zgłasza poważne problemy z działaniem agentów i kompatybilnością modeli. Pokazuje to, jak ważne jest testowanie w różnych środowiskach i analiza feedbacku.

    Dla deweloperów, którzy polegają na tym narzędziu, kluczowe jest teraz zachowanie ostrożności. Znajomość metod ratunkowych, takich jak blokowanie aktualizacji czy powrót do wersji 1.19.6, może uratować dzień pracy. Równocześnie istotne będzie obserwowanie dalszych komunikatów od Google, aby zrozumieć, czy problemy są tymczasowe, czy wynikają z głębszych zmian w architekturze lub strategii.

    Ostatecznie historia wersji 1.20.5 przypomina, że nawet w świecie zaawansowanej automatyzacji i AI, zdrowy rozsądek i umiejętność ręcznego obejścia problemów pozostają bezcenne. Czas pokaże, czy kolejne wydania zdołają odbudować zaufanie, czy też użytkownicy na dobre przeniosą się do bardziej przewidywalnych alternatyw.

  • Kimi Code CLI zyskuje lepszą obsługę schowka, sesji i integracji z API

    Kimi Code CLI zyskuje lepszą obsługę schowka, sesji i integracji z API

    Ostatnie aktualizacje Kimi Code CLI – terminalowego agenta AI od MoonshotAI – to nie tylko rutynowe łatanie błędów. Rozwój tego open-source'owego narzędzia dla programistów wyraźnie przyspieszył, a wersje oznaczone numerami powyżej 0.40 wprowadzają konkretne ulepszenia w codziennej pracy. Chodzi o trzy kluczowe obszary: niezawodność interakcji w terminalu, zarządzanie sesjami i głębszą integrację z API. To drobne, na pozór techniczne zmiany, które realnie wpływają na płynność korzystania z AI jako asystenta kodowania.

    Stabilizacja podstawowych interakcji w terminalu

    Jednym z praktycznych obszarów ulepszeń jest stabilizacja interakcji w powłoce (shell). Wcześniejsze wersje, jak v0.40, kładły podwaliny pod tę niezawodność: dodano klawisz ESC do przerywania długich działań agenta, poprawiono debugowanie (/debug), renderowanie Markdown czy obsługę przerwania (Ctrl-C). Takie usprawnienia podstawowych mechanizmów są kluczowe dla narzędzi, które mają być używane intensywnie i bez frustracji.

    Obecne zmiany idą o krok dalej, usprawniając już nie samo działanie agenta, ale jakość interakcji i odporność na zakłócenia. To solidna inżynieria, która buduje zaufanie. Gdy programista powierza agentowi automatyzację zadań, musi mieć pewność, że narzędzie jest stabilne i przewidywalne.

    Sesja, która przetrwa: automatyczne ponawianie i zachowanie kontekstu

    Drugi filar aktualizacji to znacznie inteligentniejsze zarządzanie sesjami. Problemy z połączeniem sieciowym (WebSocket) to zmora każdej aplikacji działającej w czasie rzeczywistym. Wcześniej, po ponownym połączeniu (reconnect), użytkownik mógł stracić wpisane, ale jeszcze niewysłane polecenia z ukośnikiem (slash commands), takie jak /plan czy /debug.

    Teraz to się zmienia. CLI zachowuje te polecenia podczas ponownego łączenia, więc nie ma już irytujących przerw w działaniu czy potrzeby ponownego wpisywania komend. Może wydawać się to drobiazgiem, ale w praktyce oznacza płynniejszą pracę bez zbędnego rozpraszania uwagi.

    Dodano też automatyczną logikę ponawiania (retry) przy inicjalizacji sesji. Jeśli coś pójdzie nie tak podczas startu, narzędzie spróbuje ponownie, zamiast od razu przerywać pracę i wymagać interwencji użytkownika. To kolejny krok w stronę niezawodności, która jest niezbędna, gdy chcemy polegać na asystencie przy poważniejszych, wieloetapowych zadaniach.

    Głębsza integracja: identyfikator sesji trafia do API

    Trzecia istotna zmiana dzieje się pod maską, ale ma znaczenie dla rozwoju całej platformy. Rdzeń (core) Kimi Code CLI został ulepszony pod kątem integracji z API MoonshotAI, które jest jego głównym backendem. Takie usprawnienia w warstwie komunikacji świadczą o dojrzewaniu projektu i dbałości o szczegóły infrastrukturalne.

    Warto przypomnieć, że Kimi Code CLI jest zaprojektowany do pracy z rodziną modeli Kimi (np. potężnym Kimi K2.5), ale jego architektura pozwala na integrację z różnymi backendami. Dbałość o solidną i pełniejszą komunikację z modelem AI jest kluczowa dla spójności i możliwości audytu dłuższych interakcji.

    Kontekst rozwoju: agent, który czyta, pisze i planuje

    Kontekst rozwoju: agent, który czyta, pisze i planuje

    Żeby zrozumieć wagę tych aktualizacji, trzeba pamiętać, czym właściwie jest Kimi Code CLI. To nie jest kolejny chatbot w terminalu. To autonomiczny agent kodujący, który potrafi czytać i edytować pliki w całym projekcie, wykonywać polecenia systemowe, przeszukiwać internet (w zależności od konfiguracji) i samodzielnie planować wieloetapowe zadania.

    Jego siła leży w trybach Agent i Agent Swarm modelu Kimi, gdzie AI może zaplanować workflow (np. zbudowanie landing page'a), wybierając framework, generując kod i zarządzając zależnościami. W takim scenariuszu stabilność sesji oraz solidna integracja z backendem AI są po prostu niezbędne.

    Podsumowanie: małe kroki ku większej niezawodności

    W świecie narzędzi deweloperskich napędzanych przez AI, gdzie konkurencja jest duża (wspomnijmy choćby Cline, Cursor czy Windsurf), o przewadze często decydują detale. Ostatnie aktualizacje Kimi Code CLI skupiają się właśnie na nich: na tym, żeby problemy z siecią nie resetowały naszej pracy i żeby komunikacja z modelem AI była pełniejsza.

    To nie są „przełomowe innowacje” z pierwszych stron gazet, ale solidna inżynieria, która buduje zaufanie użytkownika.

    Rozwój Kimi Code CLI, sądząc po tempie wydawania wersji i konkretnej treści list zmian (changelogs), zmierza w dobrym kierunku – łączenia potężnych zdolności agentowych AI z dopracowaną, bezproblemową interakcją w terminalu. A to właśnie w terminalu wielu programistów wciąż spędza większość czasu.