# Mikroframeworki w Konsoli administratora > Konsola administratora Asany była gmatwaniną niestandardowej logiki – dopóki zespół nie opracował struktur deklaratywnych, które umożliwiły migrację wspomaganą przez sztuczną inteligencję. Przeczytaj, w jaki sposób udało im się wdrożyć rozwiązanie miesiąc Source: https://asana.com/pl/inside-asana/microframeworks-admin-console ## Mikroframeworki w Konsoli administratora Każde wdrożenie Asany ma konsolę administratora. To właśnie w niej administratorzy IT konfigurują sposób, w jaki ich firma korzysta z Asany, na przykład dostosowując wymagania dotyczące haseł, role i uprawnienia, określając, czy można dołączać pliki z usługi Dropbox, a także wskazując, kto domyślnie może zobaczyć nowy projekt. Wraz z rozwojem Asany w konsoli administratora gromadziły się przez lata niestandardowe rozwiązania logiczne i jednorazowe poprawki, co sprawiało, że tworzenie i utrzymywanie funkcji administracyjnych stawało się coraz bardziej kosztowne. Weźmy jedno ustawienie administracyjne: domyślne ustawienie prywatności dla nowych projektów. Administrator wybiera, czy nowy projekt ma być od początku widoczny dla całej organizacji, widoczny dla swojego zespołu, czy też prywatny dla zaproszonych członków. Łatwo to opisać, ale kryje się za tym wiele złożoności: - Czy ta funkcja jest dostępna w planie klienta? - Czy klient wcześniej za nią płacił, a potem przestał, przez co utknął w ustawieniu, którego nie może już zmienić? - Czy jest to klient objęty przepisami HIPAA lub FedRAMP, w przypadku którego tylko osoby z wyższymi uprawnieniami mogą edytować to ustawienie? - Czy jedna z opcji jest niedostępna z powodu innego ustawienia? - Czy należy wyświetlić baner informacyjny opisujący bieżące ograniczenia? Każdy zespół, który chciał dodać opcję administracyjną, musiał prawidłowo odpowiedzieć na wszystkie te pytania. Większość zespołów uznała, że nie jest to warte zachodu, i z biegiem czasu luka między tym, co Asana mogła zrobić, a tym, czym mógł zarządzać administrator, powiększyła się. Ilustruje to fakt, że niektóre opcje kontroli można skonfigurować wyłącznie na poziomie całej firmy, co utrudnia administratorom IT zastosowanie danej opcji kontroli tylko do wybranej grupy użytkowników. Oto fragment okna dialogowego ustawień prywatności projektu, służący do określenia, czy należy je wyłączyć i czy powinien zostać wyświetlony baner: Należy tu przeanalizować wiele elementów logicznych – licencjonowanie funkcji, zarządzanie, zastępowanie ustawień ze względu na strukturę wdrożenia oraz role użytkowników, zwłaszcza w przypadku osób sprawdzających. Aby wszystko dokładnie sprawdzić, trzeba byłoby odtworzyć w głowie macierz testową, aby ustalić, czy jest ona prawidłowa. A to dopiero okno dialogowe. O tym, czy wiersz w ogóle pojawi się na stronie ustawień, zadecydowano gdzie indziej, a także w sposób niespójny: Trzy wiersze, trzy mechanizmy, a warunki bramkowania nie zawsze znajdują się w tym samym pliku. Aby więc odpowiedzieć na pytanie „Jakie ustawienia faktycznie widzi ten klient?”, trzeba było nie tylko przeczytać każdy wiersz, ale także przejrzeć każdy komponent. To pytanie pojawia się dość często: obsługa klienta próbuje wyjaśnić, dlaczego dane ustawienie zniknęło dla klienta; menedżer produktu chce uzyskać konkretną odpowiedź, czy wprowadzenie nowego elementu sterującego to szybka zmiana, czy też zajmie to dwa tygodnie; nowy pracownik próbuje znaleźć to jedno miejsce, które decyduje o tym, co konkretny użytkownik może zobaczyć. Patrząc z szerszej perspektywy, cztery czynniki sprawiały, że praca w konsoli administratora była kosztowna: - **Kłopotliwy przegląd.** Logika znajdowała się tam, gdzie umieścił ją autor, więc PR mógł wprowadzić specjalne zachowanie, które nie było oczywiste dla osoby sprawdzającej, a poprawności nie dało się łatwo zweryfikować samą lekturą. - **Brak standaryzacji maskował błędy.** Mieliśmy długotrwałe błędy, które trudno było wykryć. Wiele z nich wynikało z rozbieżności między specyfikacją produktu a jego wdrożeniem, spowodowanych licznymi wdrożeniami dostosowanymi do konkretnych potrzeb. Zespoły podejmowały arbitralne decyzje, co skutkowało tym, że każdy element sterujący miał swoje własne specyficzne cechy. - **Wprowadzanie zmian było kosztowne.** Aby wprowadzić jedną zmianę dla użytkownika końcowego, trzeba było znaleźć każde miejsce, w którym dana reguła została zakodowana, a rzadko kiedy istniał jeden punkt definicji. - **Kosztowne testowanie.** Przygotowanie testów wymagało dogłębnej znajomości stanów zaplecza, a kompleksowe ręczne testowanie wdrożeń końcowych było niewykonalne ze względu na liczbę wzajemnie oddziałujących na siebie aspektów. ## Przedstawiamy struktury Utworzyliśmy deklaratywną strukturę dla kontroli administracyjnych, która ma służyć jako źródło prawdy w bazie kodu. Kontrolka teraz określa, czym jest: Każde pole tutaj odpowiada gałęzi z powyższego okna dialogowego: requiredAdminRole to kontrola HIPAA/superadministratora, upsellBehavior to dwie gałęzie dotyczące sprzedaży produktów z wyższej półki, a churnBehavior to przypadek utraconego klienta, który umożliwia mu przywrócenie ustawień domyślnych i niczego więcej. W ramach tego struktura udostępnia haki, których inżynierowie używają do wyodrębniania obliczonego stanu elementu sterującego. Zobacz, jak teraz wygląda to samo okno dialogowe dotyczące prywatności projektu: Łańcuch warunków „if” w banerze został zastąpiony jednym wspólnym komponentem sterowanym przez scentralizowany hook. Struktura obsługuje logikę kombinatoryczną wszystkich różnych scenariuszy, a eksperci merytoryczni odpowiedzialni za jej utrzymanie, którzy doskonale znają produkt administracyjny, mogą śmiało wprowadzać daleko idące zmiany. Obecnie stosujemy ścisłe typowanie, aby pomóc osobom wdrażającym w podawaniu obowiązkowych informacji wymaganych do prawidłowego wyświetlania ich ustawienia we wszystkich możliwych scenariuszach. Co najważniejsze, nie muszą rozumieć zawiłości tych scenariuszy ani tego, jak one na siebie wpływają. Te ustawienia są dostępne za pośrednictwem wierszy w interfejsie użytkownika konsoli administratora. Widoczność tych wierszy została potraktowana w ten sam sposób i w tym miejscu wkracza druga struktura. Wiersz w rejestrze ustawień nie opisuje własnych reguł widoczności, zamiast tego jest powiązany z reprezentującymi go elementami sterującymi: Tablica elementów sterujących stanowi wartość dodaną. Zawiera on ten sam obiekt ProjectDefaultPrivacy, który okno dialogowe przekazuje do funkcji useAdminConsoleControl, a rejestr przetwarza go przy użyciu tego samego źródła informacji, dzięki czemu strona i okno dialogowe nie mogą się ze sobą sprzeczać. Kiedyś było to obliczane osobno, więc rozbieżności mogły prowadzić do dwóch rodzajów błędów: wiersza, który jest widoczny, ale otwiera okno dialogowe, z którego nie można skorzystać, oraz ustawienia, za które klient płaci, ale nie ma wiersza, z którego można do niego dotrzeć. Centralizacja wyeliminowała tę kategorię błędów. Testy, w których zastosowano scentralizowane struktury, znacznie poprawiły komfort pracy osób sprawdzających PR. Weźmy na przykład testowanie widoczności wierszy, które odpowiada na pytanie „Jakie ustawienia są faktycznie widoczne dla tego klienta?” na pytanie zadane wcześniej. Zamiast kodu testowego scenariusz to po prostu dane: persona, stan domeny i strony, na których jest renderowany. A wiersz po prostu wymienia, w których nazwach scenariuszy musi się pojawić: Nie ma potrzeby pisania wywołania renderowania ani asercji. Dynamiczny pakiet testowy odczytuje katalog i porównuje każdy wiersz z każdym scenariuszem, w którym jest on wymieniony. Katalog jest teraz jedynym miejscem, w którym określone jest, co widzi klient, a co jest sprawdzane przez maszynę. Nie trzeba już polegać na sumiennym recenzencie kodu ani na autorze, aby prawidłowo zidentyfikować i napisać własne przypadki testowe. ## W świecie sztucznej inteligencji Rozpoczęliśmy te prace pod koniec 2025 roku, ponieważ przewidywaliśmy potrzebę umożliwienia inżynierom niebędącym ekspertami w danej dziedzinie pewnego tworzenia rozwiązań w konsoli administratora. W tamtym czasie celem nie była optymalizacja pod kątem wydajności LLM, ale jak się okazuje, standaryzacja i usprawnienie pracy inżynierów przynosi takie same korzyści w przypadku agentów AI. Zanim zbudowaliśmy te struktury, spróbowaliśmy rozwiązać problem migracji za pomocą sztucznej inteligencji, co technicznie zadziałało. Problem polegał na tym, że ani agent, ani osoba dokonująca przeglądu nie byli w stanie stwierdzić, czy testy były faktycznie poprawne, co skutkowało fałszywym poczuciem pewności i niewykrytymi lukami. AI nie rozwiązuje problemu braku struktury, a po prostu szybciej generuje więcej kodu w oparciu o istniejącą już strukturę. [Firma Google przedstawiła podobny argument dotyczący systemu typów języka Go w programowaniu wspomaganym przez sztuczną inteligencję](https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/): typy statyczne działają jak automatyczna siatka bezpieczeństwa, ponieważ LLM-y są podatne na halucynacje dotyczące właściwości i na niedopasowanie typów w różnych plikach. TypeScript nie jest tak rygorystyczny pod względem statycznym, jak Go, ale struktura może zapewnić taką samą gwarancję w oparciu o niego: zdefiniuj typ kontrolki raz na poziomie struktury, a każda implementacja musi do niego pasować w miejscu użycia. Gdy struktury były już gotowe, zaczęliśmy przygotowywać się do delegowania i pracy równoległej. Skorzystałem z naszego nowego narzędzia do programowania opartego na specyfikacjach [link placeholder: eng blog post on spec driven development[: Blog techniczny Asany – Programowanie oparte na specyfikacjach: zalety](/inside-asana/spec-driven-development)], aby stworzyć umiejętność, która wykonuje zadanie od początku do końca. Koduje ona całą konwersję: definiuje element sterujący, wywołuje hooka, zastępuje banery, aktualizuje fragmenty, dodaje nowe testy deklaratywne, a także automatycznie aktualizowaną listę kontrolną i dziennik nietypowych przypadków z poprzednich konwersji. Spośród wszystkich ~150 migracji 91% nie wymagało żadnych poprawek po przejrzeniu. Uruchomienie agenta do napisania PR-a nie wymaga dużego nakładu pracy, podobnie jak przegląd tego PR-a. Ponieważ wszystko jest zdefiniowane w przewidywalny sposób, osoby dokonujące weryfikacji nie muszą być ekspertami w dziedzinie administracji, aby sprawdzić, czy implementacja jest zgodna ze specyfikacją produktu. Co najważniejsze, dzięki temu pula osób kwalifikujących się do roli recenzentów obejmuje znacznie szerszą grupę inżynierów, co przyspiesza tempo pracy w większym stopniu niż samo poszerzenie lejka na górze procesu tworzenia PR-ów. Nie jesteśmy osamotnieni w procesie redefiniowania procesu weryfikacji w obecnych czasach: [GitHub przebudował własnego agenta weryfikacji Copilota, opierając go na ustrukturyzowanych dowodach dotyczących PR-u](https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/), aby pomóc osobom dokonującym weryfikacji szybciej formułować właściwe pytania, co pozwoliło obniżyć koszty weryfikacji o około 20%. Pierwotna migracja około 150 elementów obejmujących wiele struktur została zakwalifikowana jako jednorazowa praca inżynierska wykonywana ręcznie od początku do końca. Najpierw zbudowaliśmy struktury, a następnie powierzyliśmy migrację inżynierom monitorującym agentów. Dzięki temu udało nam się ukończyć całość prac ponad miesiąc wcześniej, niż przewidywał pierwotny plan. ## Co dalej? Tworzenie tych struktur nigdy nie było celem samym w sobie. Wynikło to z konieczności, z planu działania, który wymagał równoległego wykonywania zadań i skalowania, przy ograniczonym i zmieniającym się w trakcie realizacji zespole pracowników oraz bez wymogu, aby każda osoba zaangażowana w projekt była najpierw ekspertem w danej dziedzinie. Już zauważyliśmy, że działa ona poza zespołem, który ją zbudował: 18 z 66 kontroli w strukturze zostało utworzonych przez inżynierów z 8 różnych zespołów. Teraz szukamy kolejnego obszaru, w którym możemy dokonać tego rodzaju inwestycji. Jeśli już, to argumenty przemawiające za tym rozwiązaniem są teraz silniejsze niż przed rozpoczęciem prac: dobrze zaprojektowana, deklaratywna struktura nie tylko ułatwia weryfikację, ale także decyduje o tym, czy agent tworzy coś niezawodnego, czy tylko coś szybkiego. To także czynnik, który może sprawić, że autonomiczny przegląd stanie się możliwy: [firma Cloudflare zbudowała system, w którym recenzent-AI samodzielnie zatwierdza czysty kod i blokuje rzeczywiste problemy, a działa to tylko dlatego, że dane wejściowe są na](https://blog.cloudflare.com/ai-code-review/) tyle uporządkowane, iż recenzent może im zaufać. Kolejnym dobrym pytaniem jest to, czy nasze dane są wystarczająco uporządkowane, aby spróbować zrobić to samo. #### O autorze Leo Zhang jest inżynierem oprogramowania w zespole ds. podstawowych funkcji administracyjnych, który wspiera administratorów IT w zarządzaniu ich organizacjami. Obecnie pracuje nad poprawą środowiska programistycznego innych inżynierów produktu w Konsoli administratora, inwestując w struktury techniczne, które stanowią podstawę naszego produktu. #### Podziękowania dla zespołu Projektowanie, wdrażanie, testowanie i upowszechnianie tych zmian wymagało ogromnego nakładu pracy ze strony zespołu. Było to możliwe dzięki wkładowi innych inżynierów z zespołu Admin Foundations: Yunusa Rahbara, Maryam Booshehrian, Saverio Castelliego, Bronwyn Damm, Cindy Yu, Calvina Nortona i Jaxsuna McCarthy'ego Huggana. Walter Li z zespołu Tiger ds. sukcesu agentów w ogromnym stopniu pomógł w skonfigurowaniu odpowiednich narzędzi AI na potrzeby tych migracji. ### **Materiały referencyjne** - Lan Cheng, Emerson Murphy-Hill, Mark Canning, Ciera Jaspan, Collin Green, Andrea Knight, Nan Zhang i Elizabeth Kammer, „What Improves Developer Productivity at Google? Code Quality” („Co poprawia produktywność programistów w Google? Jakość kodu”), ESEC/FSE '22, listopad 2022 r. [https://doi.org/10.1145/3540250.3558940](https://doi.org/10.1145/3540250.3558940) - „Orchestrating AI Code Review at Scale” (Orkiestracja przeglądu kodu za pomocą sztucznej inteligencji na dużą skalę), blog Cloudflare, kwiecień 2026 r. [https://blog.cloudflare.com/ai-code-review/](https://blog.cloudflare.com/ai-code-review/) - Napalys Klicius, „Better tools made Copilot code review worse. Oto, w jaki sposób faktycznie go ulepszyliśmy”, blog GitHub, lipiec 2026 r. [https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/](https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/) - „Why Go is an Ideal Language for AI-Assisted Software Engineering” (Dlaczego Go jest idealnym językiem do inżynierii oprogramowania wspomaganej przez sztuczną inteligencję), blog Google Developers, sierpień 2026 r. [https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/](https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/) - [Microframeworks in the Admin Console](/pl/inside-asana/microframeworks-admin-console) inżynieria Każde wdrożenie Asany ma konsolę administratora. To właśnie w niej administratorzy IT konfigurują sposób, w jaki ich firma korzysta z Asany, na przykład dostosowując wymagania dot ... - [inżynieria](/inside-asana/engineering-spotlight)