Aplikacja w jeden dzień.

Low-code oznacza budowanie aplikacji z użyciem gotowych komponentów i modeli, z możliwością dopisywania kodu. No-code ogranicza potrzebę samodzielnego programowania w obsługiwanym zakresie. Oba podejścia mają granice wynikające z konkretnej platformy.

Vibe coding opisuje sposób pracy: podaję AI oczekiwane zachowanie, sprawdzam rezultat i zlecam kolejne zmiany. Termin bywa używany szerzej, dlatego tutaj odróżniam go od pracy inżynierskiej, w której człowiek dodatkowo kontroluje architekturę, rozumie istotne fragmenty kodu i weryfikuje zabezpieczenia.

Te podejścia mogą występować razem. AI może zmieniać model aplikacji low-code, a kod wygenerowany w rozmowie może działać na zarządzanej platformie. Porównywałbym więc konkretną architekturę i sposób pracy zespołu, zamiast wybierać jedną z tych etykiet.

Power Apps code apps umożliwiają uruchamianie własnych aplikacji webowych na platformie Power Apps. Lovable pozwala przeglądać, edytować i pobierać kod projektu, a Bolt łączy budowanie przez rozmowę z wersjonowaniem w GitHubie. Firma może więc korzystać z wygody generatora, zachowując dostęp do kodu i historii zmian.

Oddzieliłbym dostępność funkcji od deklaracji o jej skuteczności. Informacja producenta, że agent potrafi zbudować aplikację, nie określa jeszcze kosztu jej dostosowania do naszego procesu. Ten koszt trzeba sprawdzić we własnej próbie.

Power Apps rozważyłbym przy formularzach i zadaniach operacyjnych w firmie pracującej w ekosystemie Microsoft. AppSheet sprawdziłbym przy podobnych potrzebach w środowisku Google i aplikacjach opartych na danych tabelarycznych. W obu przypadkach warunkiem jest dopasowanie do danych, uprawnień i sposobu pracy.

Bubble, Lovable, Bolt i Replit również warto rozpatrywać osobno. Różnią się sposobem budowania, hostingiem i możliwością dalszej pracy poza narzędziem. W dokumentacji Bubble eksport danych jest oddzielony od przeniesienia aplikacji: jej logikę po wyjściu z platformy trzeba odtworzyć. Taką zależność można zaakceptować, jeśli korzyści i warunki współpracy to uzasadniają.

Narzędzia takie jak Cursor, Claude Code, Codex i GitHub Copilot rozważyłbym w zespole rozwijającym własny kod. W takim modelu firma potrzebuje osób zdolnych ocenić zmiany, zdiagnozować błąd i przejąć utrzymanie. Samo posiadanie repozytorium jeszcze tego nie zapewnia.

To mój sposób wstępnej selekcji. Dopiero próba na rzeczywistym procesie pozwala ocenić dopasowanie konkretnego produktu. Nie zakładałbym, że narzędzie wewnętrzne jest automatycznie mało ryzykowne. Panel zmieniający parametry produkcji może wymagać większej kontroli niż publiczny formularz kontaktowy.

Najwięcej szans widzę w potrzebach, które są zbyt małe na osobny projekt, a jednocześnie pochłaniają czas kilku osób. Pracownik przepisuje dane między systemami, kierownik składa raport z różnych plików, zespół śledzi wyjątki w korespondencji. Ograniczona aplikacja może pomóc, jeżeli ma dostęp do właściwych danych i jasno określony zakres.

Osoba znająca proces może przygotować prototyp i szybciej pokazać, czego potrzebuje. IT ma wtedy lepszy materiał do rozmowy o integracjach i regułach. Warunkiem jest uzgodnienie, kiedy eksperyment wymaga już udziału osób odpowiedzialnych za technologię i dane. Piszę o tej współpracy również w artykule IT jako partner biznesu.

Nie każdą potrzebę warto jednak zamieniać w aplikację. W przykładzie ze zgłoszeniami usterek najpierw sprawdziłbym, czy takiej funkcji nie ma już używany system. Dodatkowe narzędzie może oznaczać kolejną listę użytkowników, kopię danych i integrację do utrzymania.

W próbie aplikacji do usterek zalogowałbym się jako pracownik każdego zakładu, kierownik i administrator. Sprawdziłbym odczyt oraz zmianę danych, także przy bezpośrednim wywołaniu operacji poza ekranem. Ukrycie przycisku nie zabezpiecza funkcji, jeżeli serwer nadal pozwala ją wykonać.

Platformy dostarczają mechanizmy ochrony, które trzeba poprawnie zastosować. Google zaznacza, że filtry bezpieczeństwa AppSheet nie stanowią kompletnego zabezpieczenia i wymagają ochrony operacji również na poziomie źródła danych. Replit opisuje dodatkowe obowiązki twórcy aplikacji, w tym autoryzację i ochronę sekretów. GitHub zaleca przegląd i weryfikację kodu przygotowanego przez agentów.

W aktualizacji benchmarku Veracode z jesieni 2026 opisano poprawę wyników bezpieczeństwa przy utrzymujących się słabościach. Badano 18 modeli, cztery języki i cztery kategorie podatności. To test określonych zadań generowania kodu, a nie pomiar odsetka niebezpiecznych aplikacji działających w firmach. Nie wyprowadzałbym z niego prawdopodobieństwa awarii naszego rozwiązania.

Test funkcjonalny uzupełniłbym więc sprawdzeniem uprawnień, obsługi błędów, zależności i odtwarzania. Przy operacjach zapisujących dane istotne są też ponowienia: przerwane połączenie nie powinno tworzyć drugiego zamówienia ani drugi raz zatwierdzać tej samej operacji.

Cena licencji lub liczba tokenów zużytych na prototyp daje tylko część obrazu. Do porównania potrzebuję kosztu uruchomienia, opłat bieżących i pracy związanej z utrzymaniem. Osobno sprawdzam koszt zmiany zakresu oraz wyjścia z rozwiązania.

Modele opłat są różne. Replit opisuje koszty publikacji zależne od wybranego sposobu uruchomienia i wykorzystania zasobów. Przy platformach sprawdzam również użytkowników, środowiska, dane i integracje. Funkcje administracyjne mogą wymagać innego planu niż ten użyty do próby. Uruchomienie własnego kodu poza generatorem oznacza z kolei obowiązek zapewnienia hostingu, aktualizacji i obsługi błędów.

Nie zakładam z góry, że własny kod będzie tańszy albo że platforma okaże się droższa. Porównanie powinno obejmować ten sam zakres, obciążenie i wymagania dostępności. Czas istniejącego zespołu wyceniam oddzielnie od dodatkowych wydatków, aby nie policzyć go dwukrotnie. Model budżetu IT pomaga zapisać te założenia.

Przed wyborem poprosiłbym o próbę przejęcia rozwiązania. Druga osoba dostaje dokumentację i odtwarza aplikację w uzgodnionym środowisku. Sprawdza dane, logowanie, integracje i sposób wdrożenia zmiany. Jeżeli firma planuje możliwość migracji, próba powinna objąć także zależności od usług dostawcy.

Własny kod może ułatwiać wyjście, ale pozostają baza danych, konta użytkowników, przechowywane pliki i usługi zewnętrzne. Eksport frontendu nie przenosi tych elementów automatycznie. Podobnie możliwość samodzielnego hostingu platformy nie oznacza niezależności od jej licencji i mechanizmów działania.

Aktualnym przykładem ryzyka zmiany produktu jest wycofywanie Power Apps Vibe. Microsoft podaje dostęp do tych aplikacji do 30 listopada 2026 i opisuje odbudowę aplikacji w innych narzędziach. Dotyczy to usługi Vibe, a nie całej platformy Power Apps. Opis migracji przewiduje ponowne sprawdzenie działania i połączeń z danymi.

Dlatego w planie wyjścia chciałbym zobaczyć konkretną procedurę i osobę odpowiedzialną. Ogólna deklaracja, że „mamy eksport”, pozostawia zbyt wiele pytań.

Spodziewam się dalszego łączenia generatorów AI, wizualnych modeli i własnego kodu. To moja ocena kierunku na podstawie obecnych produktów. Nie przesądza, który dostawca utrzyma przewagę ani jak szybko zmienią się koszty.

Firmom może to dać większą swobodę rozwijania narzędzi blisko procesu. Zespoły IT będą mogły przygotować wspólne elementy, na przykład dostęp do danych i kontrolowany sposób wdrażania, a biznes szybciej sprawdzi użyteczność rozwiązania. Potrzebna będzie również umiejętność zamykania aplikacji, które dublują funkcje lub nie przynoszą oczekiwanego efektu.

Nie przyjąłbym jednego procentu wzrostu produktywności do uzasadnienia takiego programu. METR w aktualizacji z 24 lutego 2026 zwrócił uwagę na problemy z doborem uczestników i pomiarem pracy przy użyciu nowych narzędzi AI. Wynik trzeba ocenić w warunkach własnego zespołu, razem z czasem weryfikacji i poprawkami.

Do aplikacji ze zgłoszeniami usterek wróciłbym więc z konkretnym planem. Najpierw ograniczona próba, potem sprawdzenie danych i uprawnień, uzgodnienie utrzymania oraz przejęcie rozwiązania przez drugą osobę. Jeżeli te warunki są spełnione, szybkie zbudowanie prototypu rzeczywiście skraca drogę do użytecznej aplikacji. Po uruchomieniu właściciel procesu nadal sprawdza jej efekt, a właściciel techniczny odpowiada za uzgodnione utrzymanie.

Dokumentacje i komunikaty producentów sprawdziłem 2 listopada 2026. Opisują funkcje i ograniczenia produktów; nie są niezależnym testem porównawczym. Veracode jest dostawcą narzędzi bezpieczeństwa, a jego benchmark obejmuje wskazany zakres. Przykład zgłoszeń usterek jest hipotetyczny. Wartości startowe modelu kosztów są założeniami, bez odniesienia do cenników dostawców.

Przed własną próbą możesz skorzystać z karty oceny zastosowania AI. Pomaga zapisać właściciela, miary i przesłanki decyzji o dalszej pracy. Jeżeli chcesz omówić konkretny proces, opisz obecny sposób działania i problem do rozwiązania.