Jeszcze kilka lat temu własne oprogramowanie dla działu kadr było projektem. Specyfikacja, oferta, agencja, kolejne rundy uwag, w końcu wdrożenie, a potem umowa serwisowa. Dziś ktoś z HR opisuje w trzech zdaniach, czego potrzebuje, a AI buduje z tego działającą aplikację. To właśnie vibe coding: oprogramowanie powstaje z opisu w zwykłym języku, a kod pisze AI.
Uważamy, że to jedna z najlepszych wiadomości dla działów merytorycznych od dawna. I sądzimy, że większość firm dyskutuje o tym teraz w niewłaściwym miejscu.
Kto zna proces, ten powinien budować oprogramowanie
Kierowniczka działu płac wie, kiedy umowa kończy się po okresie próbnym, a kiedy nie. Kierownik zakupów wie, od jakiej kwoty potrzebna jest druga akceptacja. Do tej pory ta wiedza musiała przejść przez kilka tłumaczeń: z działu do zgłoszenia, ze zgłoszenia do specyfikacji, ze specyfikacji do kodu. Przy każdym tłumaczeniu coś się gubiło.
Vibe coding skraca ten łańcuch. Kto zna proces, sam go opisuje. To nie jest atak na IT, tylko odciążenie: IT nie musi już zamieniać każdego arkusza Excela w projekt, którego na końcu i tak nikt do końca nie chciał.
Prawdziwym problemem nie jest budowanie
Dyskusja często kręci się wokół pytania, czy kod wygenerowany przez AI jest wystarczająco dobry. To mniejsze pytanie. Większe brzmi: gdzie aplikacja działa następnego dnia?
Aplikacja zbudowana w narzędziu AI często ląduje na czyimś prywatnym koncie. Udostępnianie oznacza przekazanie linku. Nikt wprost nie ustala, kto co może widzieć. Testów nie ma, a gdy kolejna zmiana coś zepsuje, nie ma drogi powrotu. IT dowiaduje się o tym na końcu, jeśli w ogóle.
Nic z tego nie wynika ze złej woli. To po prostu luka między „działa na moim ekranie” a „działa w firmie”. Kiedyś przykrywał ją długi proces wytwarzania oprogramowania. Teraz, gdy budowanie idzie szybko, widać ją jak na dłoni.
Co konkretnie znaczy „w firmie”
Aplikacja, z którą pracuje zespół, potrzebuje kilku rzeczy, które nie mają nic wspólnego z jej właściwym celem:
- Logowania kontami firmowymi, żeby nikt nie utrzymywał osobnych haseł do każdej aplikacji, a osoby odchodzące traciły dostęp.
- Uprawnień według roli, które obowiązują przy każdym dostępie do danych, a nie tylko w interfejsie.
- Sprawdzenia przed wdrożeniem, żeby drobna zmiana nie odsłoniła przy okazji wynagrodzeń.
- Wersji i drogi powrotu, gdy coś okaże się błędne.
- Jasnej własności: kod i dane należą do firmy, a nie do jednego konta.
To nie są dodatki. To różnica między prototypem a narzędziem, na którym zespół może polegać. I to dokładnie to, czego jedna osoba z narzędziem AI nie powinna budować przy okazji.
Barierki zamiast zakazów
Wiele firm reaguje na nowe możliwości zakazami albo procedurami akceptacji, które trwają tyle, ile kiedyś trwało samo wytwarzanie. Jedno i drugie prowadzi do tego samego: ludzie i tak budują, tylko gdzie indziej.
My wierzymy w inną drogę. Barierki należą do środowiska, a nie do głowy każdej osoby. Jeśli każda aplikacja automatycznie działa z firmowym logowaniem, jest automatycznie sprawdzana i automatycznie wersjonowana, nikt nie musi o tym pamiętać. I nikt nie może o tym zapomnieć.
Tak zbudowany jest Openbase.one. Opisujecie własnymi słowami, co aplikacja ma robić i kto co może widzieć. Agent ją buduje, a Openbase.one zadaje wam tylko pytania merytoryczne, na przykład: „Czy umowa kończy się automatycznie z końcem okresu próbnego?” Każda wersja jest budowana i otwierana w prawdziwej przeglądarce jako każda osoba testowa: jako przełożony, który nie widzi wynagrodzeń, i jako HR, który widzi wszystkie. Na produkcję trafia dopiero po pozytywnym sprawdzeniu.
Kod aplikacji działa w izolacji, bez dostępu do sieci, a każdy dostęp do danych jest sprawdzany względem workspace, aplikacji i uprawnień. Każda wersja zostaje zachowana, a poprzednia wraca jednym kliknięciem. Kod każdej waszej aplikacji leży jako repozytorium Git w waszym workspace.
Czego vibe coding nie zastąpi
Uczciwie mówiąc: sprawdzenie może wykazać, że przełożony nie widzi wynagrodzeń. Nie rozstrzygnie jednak, czy wasze zasady urlopowe są merytorycznie poprawne. To pozostaje waszą decyzją i tak powinno być. Nikt poza wami nie wie, jak działa wasza firma.
Zmienia się rola działów merytorycznych. Nie stają się programistami. Pozostają tym, kim są, tyle że ich wiedza zamienia się teraz bezpośrednio w oprogramowanie. Nie muszą rozumieć baz danych, ale muszą umieć jasno sformułować swoje reguły. Kto napisał kiedyś dobry opis procesu, poradzi sobie.
A jeśli chcecie wsparcia, nie zostajecie sami. Wsparcie platformy jest w cenie każdego planu. Przy waszych własnych aplikacjach pomagają umowy wsparcia, a Premium obejmuje przegląd nowych aplikacji, zanim trafią na produkcję.
Pozwolenie na budowanie, bezpieczne działanie
Ostatecznie vibe coding w firmie nie jest kwestią technologii. To kwestia pozwolenia. Czy ludzie, którzy znają procesy, powinni budować dla nich oprogramowanie? Naszym zdaniem tak, pod warunkiem że wynik działa tam, gdzie firma może go zobaczyć, sprawdzić i wycofać.
Nie wszystko trzeba budować samemu. Gotowe aplikacje pochodzą z App Store, który stale rośnie: Pliki, Poczta i telefon, Meet, Bank, Płace, Strona WWW i Wiki działają już dziś. Po instalacji działa opublikowana, sprawdzona wersja, bez budowania i bez kosztów AI. Czego brakuje, budujecie sami.
Wypróbujcie za darmo
Openbase.one kosztuje za workspace, a nie za użytkownika, i każda aplikacja jest w cenie. Zaczynacie z kredytem AI 15 € i bez karty kredytowej. Wszystkie plany i umowy wsparcia znajdziecie na stronie z cennikiem.
Opiszcie swoją pierwszą aplikację i zobaczcie, jak sprawdzona trafia na produkcję.
Zacznij za darmo