Low-code / No-code development z AI - poznaj aplikacje bez tradycyjnego developera i programowania

Każda branża zmienia się wraz z narzędziami

Z czasem każda branża się standaryzuje, a razem z nią zmieniają się sposoby realizacji usług – po to aby były szybsze i tańsze w realizacji. Kiedyś wszystkie meble tworzone były ręcznie na zamówienie, dzisiaj linie produkcyjne tworzą nam gotowe zestawy meblowe w kilka godzin, a wraz z wprowadzeniem systemów modułowych praktycznie dopasowane do naszych indywidualnych potrzeb.

Z reguły takie zmiany odbywają się w konkretnych obszarach biznesu w sposób ewolucyjny. Może się jednak okazać, że przy okazji niespodziewanych wydarzeń jak pandemia COVID-19, zmiana następuje w sposób rewolucyjny z dnia na dzień. Tak też było z naszymi zwyczajami zakupowymi: przed lockdownem pójście do sklepu w celu dokonania zakupu było oczywistością, ale w czasach pandemii sprzedaż musiała się przenieść do Internetu. Nastąpił wtedy nagły wysyp sklepów internetowych (e-commerce). Pandemia ustała, ale nasze zwyczaje konsumenckie polegające na kupowaniu online pozostały i stały się nowym standardem. Dzisiaj, żadna szanująca się marka czy to odzieżowa, RTV/AGD czy dowolna inna nie próbuje podbijać rynku bez wykorzystania kanałów online.

Zmiany w biznesie są nieuniknione i są podyktowane następującym ciągiem przyczynowo-skutkowym:

• wraz z popularyzacją usługi/produktu, zwiększa się ilość chętnych na skorzystanie z niej,
• wraz ze wzrostem popytu, podaż zaczyna nie nadążać za produkcją,
• gdy podaż nie nadąża, wzrastają ceny tychże produktów i usług,
• gdy ceny rosną coraz więcej firm wchodzi do branży – branża zaczyna narzekać na brak rąk do pracy i dużą konkurencje,
• aby zaadresować te braki firmy z branży zaczynają szukać nowych rozwiązań i narzędzi,
• wraz z powstaniem nowych narzędzi pojawiają się nowe stanowiska pracy, a stare odchodzą w zapomnienie (np. kowal),
• na początku nowe rozwiązania spotykają się z brakiem zaufania, potem z oporem samej branży, która widzi w nim zagrożenie, aż w końcu firmy dostrzegają, że aby przetrwać muszą się albo dostosować, albo zamknąć biznesy,
• w pewnym momencie branża adaptuje rozwiązanie i staje się ono nowym standardem,
• i wtedy cykl zaczyna się od nowa...

Historia cykli tradycyjnego programowania

Branża tworzenia oprogramowania przeszła przez wiele cykli ewolucji i rewolucji, napędzanych rosnącym zapotrzebowaniem na bardziej efektywne, szybsze i tańsze rozwiązania pozwalające opracowywać aplikacje i systemy. Każdy etap wprowadzał nowe narzędzia, zmieniał sposób pracy programistów i redefiniował standardy tradycyjnych metod. Oto przegląd kluczowych cykli w historii programowania, od kart perforowanych po współczesne platformy no-code/low-code (NCLC).

Karty perforowane i kod maszynowy (lata 40.–50. XX wieku)

Na samym początku programowanie było żmudnym, manualnym procesem. W latach 40. i 50. XX wieku programiści używali kart perforowanych do wprowadzania instrukcji bezpośrednio do komputerów, takich jak ENIAC. Kod był pisany w języku maszynowym, czyli sekwencjach zer i jedynek, specyficznych dla danej maszyny.

Popyt i problem: wraz z rozwojem pierwszych komputerów w instytucjach naukowych i rządowych pojawiło się zapotrzebowanie na bardziej złożone obliczenia. Jednak programowanie w języku maszynowym było czasochłonne, wymagało ogromnej precyzji i było podatne na błędy.

Rozwiązanie: wprowadzenie asemblerów w latach 50., które tłumaczyły bardziej czytelne instrukcje (mnemoniki) na kod maszynowy. To przyspieszyło proces programowania i zmniejszyło liczbę błędów.

Efekt: asemblery to innowacja cyfrowa, która stała się standardem, ale wciąż wymagała specjalistycznej wiedzy. Branża zaczęła odczuwać brak wykwalifikowanych programistów, co zapoczątkowało kolejny cykl.

Języki wysokiego poziomu (lata 50.–70. XX wieku)

Wraz z popularyzacją komputerów w biznesie i nauce pojawiła się potrzeba, aby wdrażać bardziej przystępne narzędzia programistyczne. Języki maszynowe i asemblery były zbyt skomplikowane dla rosnącej liczby użytkowników.

Popyt i problem: firmy, takie jak IBM, chciały tworzyć oprogramowanie szybciej i taniej, aby obsługiwać rosnące potrzeby biznesowe, np. systemy księgowe czy bazy danych. Programowanie w asemblerze nadal było zbyt wolne i wymagało specjalistycznej wiedzy.

Rozwiązanie: wprowadzenie języków wysokiego poziomu, takich jak Fortran (1957), COBOL (1959) czy C (1972). Języki te były bardziej abstrakcyjne, przypominały język naturalny i pozwalały programistom skupić się na logice zamiast na specyfice sprzętu.

Efekt: pisanie kodu w językach wysokiego poziomu zrewolucjonizowało branżę. Programowanie stało się bardziej dostępne, a liczba programistów wzrosła. Jednak wraz z rozwojem bardziej złożonych aplikacji pojawiły się nowe wyzwania, takie jak zarządzanie dużymi projektami i ich skalowalność.

Programowanie strukturalne i obiektowe (lata 70.–90. XX wieku)

W miarę jak oprogramowanie stawało się coraz bardziej skomplikowane, pojawiły się problemy z utrzymaniem kodu i zarządzaniem dużymi zespołami programistów.

Popyt i problem: w latach 70. i 80. aplikacje, takie jak systemy operacyjne czy oprogramowanie biznesowe, wymagały setek tysięcy linii kodu. Kod pisany w sposób chaotyczny (tzw. „spaghetti code”) był trudny do debugowania i modyfikowania. Rosnące koszty utrzymania oprogramowania stały się problemem.

Rozwiązanie: wprowadzenie paradygmatów programowania strukturalnego (np. Pascal, 1970) i obiektowego (np. Smalltalk, C++ w 1983, Java w 1995). Programowanie strukturalne promowało czytelność i modularność kodu, a obiektowe wprowadziło koncepcje klas i obiektów, ułatwiając ponowne użycie kodu i zarządzanie złożonymi systemami.

Efekt: paradygmaty te stały się standardem w edukacji i przemyśle. Jednak rozwój graficznych interfejsów użytkownika (GUI) i internetu w latach 90. zwiększył zapotrzebowanie na szybsze tworzenie aplikacji, co ujawniło ograniczenia tradycyjnego programowania.

Frameworki, narzędzia RAD, aplikacje mobilne i gotowe komponenty (lata 90.–2010)

Boom internetowy w latach 90. i rosnąca popularność aplikacji webowych (web development) stworzyły presję na jeszcze szybsze wdrożenia oprogramowania. Firmy chciały błyskawicznie wprowadzać nowe produkty na rynek, aby zdobyć przewagę konkurencyjną.

Popyt i problem: wdrażanie aplikacji na telefon czy stron internetowych od podstaw w takich językach jak Java czy C++ było zbyt czasochłonne. Programiści musieli pisać wiele powtarzalnego kodu, np. do obsługi interfejsów użytkownika czy komunikacji z bazami danych.

Rozwiązanie: pojawiły się frameworki (np. Ruby on Rails, 2004; Django, 2005) i narzędzia Rapid Application Development (RAD), takie jak Visual Basic czy Delphi oraz języki programowania aplikacji mobilnych (Apple Swift, Kotlin, ReactNative). Narzędzia te dostarczały gotowych komponentów i bibliotek, które przyspieszały rozwój i częściowo umożliwiały tworzenie aplikacji metodą „przeciągnij i upuść”.

Efekt: Frameworki i narzędzia RAD i mobile stały się standardem we wdrażaniu aplikacji desktopowych, mobilnych i projektowaniu stron. Jednak oferowana przez nie funkcjonalność nadal wymagała umiejętności programowania, co ograniczało dostępność pisania kodu dla nietechnicznych użytkowników.

Low-code i no-code development – kolejny cykl projektowania aplikacji

Czym jest no-code i low-code w tworzeniu oprogramowania?

Wraz z cyfryzacją biznesu, pandemią COVID-19 i rosnącym zapotrzebowaniem na aplikacje mobilne oraz e-commerce, zwiększył się nacisk na bardziej dostępne metody pozwalające na szybkie tworzenie funkcjonalnej aplikacji. Tradycyjne metody, nawet z użyciem frameworków, już nie nadążały za popytem.

Popyt i problem: małe i średnie firmy, startupy oraz nietechniczni użytkownicy (tzw. citizen developers) potrzebowali narzędzi, które pozwolą im automatyzować procesy biznesowe (przepływy pracy) i tworzyć aplikacje  bez konieczności wiedzy jak kodować. Jednocześnie działy IT w dużych firmach borykały się z zaległościami w realizacji projektów (tzw. backlog).

Rozwiązanie: platformy no-code/low-code (NCLC), takie jak Bubble, Webflow, czy Zapier, umożliwiają obecnie tworzenie aplikacji za pomocą wizualnych interfejsów, gotowych do użycia komponentów i minimalnej ilości kodu. No-code koncentruje się na użytkownikach nietechnicznych, oferując platformy no-code, które pozwalają użytkownikom tworzyć aplikacje bez pisania nawet jednej linijki kodu, podczas gdy low code przyspiesza pracę programistów, pozwala im budować aplikacje i systemy o większym stopniu złożoności,

Efekt: platformy NCLC rewolucjonizują rynek, demokratyzując tworzenie oprogramowania. W odróżnieniu do 2024, w 2025 roku szacuje się, że ponad 70% nowych aplikacji biznesowych będzie tworzonych przy użyciu tych technologii. Pandemia przyspieszyła ich adopcję, podobnie jak zmiany w zwyczajach zakupowych przyspieszyły rozwój e-commerce.

Automatyzacja NCLC i sztuczna inteligencja (AI)

Co więcej platformy NCLC można w łatwy sposób łączyć z modelami LLM (z ang. Large Language Model) takimi jak Claude czy ChatGPT, uzbrajając nasze aplikacje w potężne narzędzie analizowania danych i podejmowania decyzji. Coś co kiedyś wymagało tysięcy linii kodu tradycyjnego oprogramowania, zostaje obecnie zastąpione prostą integracją dwóch uzupełniających się rozwiązań. Jednakże z tak dużymi możliwościami wiąże się również ogromna odpowiedzialność.

Pomimo zalet platform no-code i low-code – jakie są wady tworzenia oprogramowania w technologii no-code?

Platformy no code/low code (NCLC) rewolucjonizują wdrażanie aplikacji i automatyzację procesów biznesowych jednak, jak w każdym cyklu z technologią, pojawiają się nowe wyzwania i obawy.

Cyberbezpieczeństwo a narzędzia no-code

No-code developerzy to z reguły użytkownicy nietechniczni więc tworzone przez nich aplikacje mogą być narażone na luki w zabezpieczeniach, takie jak niewłaściwe zarządzanie danymi, brak szyfrowania czy podatności w gotowych narzędziach no-code. Szybkość tworzenia aplikacji może prowadzić do pomijania dobrych praktyk bezpieczeństwa, a robienie ich bez nadzoru osób z IT często omija standardy bezpieczeństwa, zwiększając ryzyko cyberataków.

Przykładowo w jednym z naszych projektów dla klienta z branży produkcyjnej tworzyliśmy automatyzację ofertowania w ramach której wykorzystaliśmy platformę low-code n8n, aby ten proces zautomatyzować. Platforma posiadała integrację poprzez API (interfejs wymiany danych między aplikacjami - Application Programming Interface) z modelem sztucznej inteligencji, który z kolei był wyposażony w wiedzę ekspercką potrzebną do przeanalizowania danych wejściowych otrzymanych od klienta i przygotowania na tej podstawie wyceny prac. Jednakże klientowi zależało bardzo na tym, żeby wiedza ta, szczególnie informacje o cenach usług oraz o danych personalnych klientów, nie wypłynęła do osób spoza wąskiego grona działu handlowego. Z drugiej jednak strony, klient nie chciał korzystać z prywatnego modelu AI, przechowywanego na własnej infrastrukturze, ponieważ koszty związane z jego utrzymaniem były dla klienta nieakceptowalne. W związku z tym, aby zaadresować wymagania klienta wdrożyliśmy następujące mechanizmy zabezpieczające:

• anonimizacja danych - zanim automatyzacja wprowadzi dane otrzymane od klienta do modelu AI, następuje całkowita anonimizacja wszelkich danych personalnych, w taki sposób aby model nic o nich nie wiedział,
• algorytm obliczania wycen poza AI - model AI nie wie również ile faktycznie co kosztuje. Jego zadaniem jest jedynie przeanalizowanie danych wejściowych i wyciągnięcie z nich wartości wymaganych do przygotowania wyceny. Sama wycena robiona jest poza modelem, ale w oparciu o wyciągnięte przez AI dane,
• pentesty automatyzacji - przed udostępnieniem aplikacji klientowi przeprowadziliśmy dodatkowo testy bezpieczeństwa (tzw. testy penetracyjne) automatyzacji zgodne ze standardem OWASP TOP 10. Było to pewnego rodzaju finalną weryfikacją (tzw. sanity-check), upewniającym zarówno nas jak i klienta, że dane, których wycieku się obawiał, pozostają bezpieczne.  

Testowanie i zarządzanie QA w aplikacjach no-code / low-code

W branży no-code/low-code w większości przypadków korzysta się z graficznych edytorów WYSIWYG - What You See Is What You Get, szczególnie w rozwiązaniach no-code. Ukrywają on złożoność aplikacji przed jego twórcą. Przez to przeciętny entuzjasta no-code chcący zautomatyzować jakiś proces lub wykorzystać technologię no-code do stworzenia aplikacji nie napisze ani jednej linii kodu. Zamiast tego będzie tworzyć diagramy przepływów i konfigurować poszczególne akcje w edytorach WYSIWYG. Z tego też powodu, szczególnie wśród osób nietechnicznych, bardzo trudno jest przygotować aplikację w taki sposób, aby była łatwo testowalna. Z reguły wszystkie konfiguracje są w takich aplikacjach "zabite na sztywno" i przez to ciężko dbać o kontrolę jakości QA (z ang. Quality Assurance) lub wykonywać testy automatyczne upewniające nas, że nasza aplikacja cały czas działa bez zastrzeżeń.

W jednym z naszych projektów klient poprosił o to, aby aplikacja automatycznie przenosiła do bazy wiadomości e-mail wysłane przez klientów na adres podany na jego stronie internetowej. Jak się jednak okazało, w przypadku, gdy serwer pocztowy przechodził różnego rodzaju aktualizacje czy występowały przerwy serwisowe, następowało zerwanie połączenia pomiędzy aplikacją no-code umożliwiającą przenoszenie wiadomości, a serwerem. Jednak po wznowieniu pracy serwera połączenie nadal było zawieszone, w rezultacie mogło to skutkować tym, że klient gubiłby leady i nawet by o tym nie wiedział. Aby rozwiązać ten problem wprowadziliśmy następujące usprawnienia:

• zmiana konfiguracji serwera pocztowego – skonfigurowaliśmy serwer pocztowy tak, aby po otrzymaniu wiadomości to on powiadamiał system no-code o nadejściu nowego e-maila (mechanizm Z-Push), dzięki czemu nie potrzebował on już żadnego aktywnego połączenia z serwerem poczty,
• wdrożenie testów automatycznych – każdej nocy test z automatu wysyłał wiadomość e-mail na adres serwer pocztowy i sprawdzał czy system no-code go przeniesie. Niestety no-code to podejście, które czasami okazuje się niewystarczające i tak też było w tym przypadku, ponieważ domyślne rozwiązania NCLC nie pozwalały w środku procesu odpytywać serwer pocztowy, czekać określony czas i w przypadku braku otrzymania maila wykonać jakąś akcję, np. wysłania powiadomienia na Slack, że coś nie działa. Dlatego w celach testowych wykorzystaliśmy podejście low-code w którym brakujący fragment, nieobsługiwany przez gotowe komponenty, uzupełniliśmy fragmentem normalnego kodu programistycznego (tzw. full-code).

Skalowalność technologii no-code w firmach

Nawet w najlepszych aplikacjach no-code/low-code świetnie przygotowanych od strony biznesowej czy UX (tzw. User eXperience) mogą występować problemy związane ze skalowalnością i wydajnością. Powód jest bardzo często tożsamy z problemami dotyczącymi w/w wad, a mianowicie braku technicznego obeznania osób przygotowujących aplikacje w oparciu o NCLC.

Pewnego razu klient z branży e-commerce zgłosił się do nas z problemem migracji danych. Chciał przenieść dane ze starego systemu e-commercowego na nowy, który dla niego tworzyliśmy i początkowo zlecił przerzucenie tych danych osobie ze swojego działu Digital Sales, która już wcześniej zajmowała się tworzeniem prostych automatyzacji w ramach aktywności Sales & Marketing. Jednakże, jak się okazało przy próbie migracji danych, system bardzo szybko przestał być skalowalny i przerzucanie danych trwałoby po prostu za długo. Łącząc to z kolejnym problemem, jakim była niespójność i błędy w danych ze starego systemu, dochodziło do sytuacji, w którym import danych trwał kilka godzin, po czym przerywany zostawał błędem, który należało naprawić i ponownie wznowić import. Po 3 tygodniach bezskutecznych prób przerzucenia zakończenia importu klient poprosił nas o analizę problemu. W ramach naszych oględzin okazało się, że przerzucenie każdego rekordu odbywało się w osobnej transakcji bazodanowej. Z punktu widzenia edytora platformy no-code, z której korzystał dział Digital Sales, było całkowicie niewidoczne, że system każdorazowo otwierał transakcję bazodanową, wysyłał tam 1 rekord po czym zamykał transakcję i tak robił to kilkaset tysięcy razy w pętli. Po wykryciu głównej przyczyny zmodyfikowaliśmy automatyzację o rozwiązanie które przerzuca wszystkie dane w jednej transakcji, czyli otwiera transakcję, przerzuca setki tysięcy rekordów i dopiero na końcu raz  zamyka transakcje. W rezultacie zredukowało to czas migracji danych o ponad 90%.

Modele licencyjne platform no code

Jak wiele istnieje platform NCLC tak wiele istnieje modeli licencyjnych. Jedne platformy wykorzystują podejście Pay-As-You-Go (np. Zapier czy n8n) inne kwestie związane ze współdzieloną lub dedykowaną infrastrukturą (np. Xano), jeszcze inne rozliczają opłaty  opłaty per użytkownik i zestaw funkcjonalności (np. Airtable czy Clickup). I nawet w ramach jednego rodzaju rozliczeń, każda z platform robi to po swojemu. Dlatego przy doborze odpowiedniej technologii nie należy patrzeć wyłącznie przez pryzmat dostępnych w niej technologii, ale również poprzez ich modele licencyjne i przeprowadzić analizę TCO (z ang. Total Cost of Ownership) w ramach której oceniamy jakie są koszty:

• rozwojowe - związane z wytworzeniem oprogramowania,
• utrzymaniowe - związane z bieżącą obsługą rozwiązania (serwery, sys-admin, 1-3 linia wsparcia),
• licencyjne - związane z opłatami licencyjnymi.

Z reguły jest tak, że im wyższe są koszty rozwojowe i utrzymaniowe, tym mniejsze opłaty licencyjne i na odwrót, ale nie zawsze jest taka prawidłowość. Jednakże dobrze analizując wymagania klienta i znając cenniki poszczególnych platform, można sprytnie nimi manipulować. Tak też było w jednym z naszych projektów realizowanym dla dużej wyższej uczelni prywatnej. Tworzyliśmy system obsługi kursów uczelnianych, z którego mieli korzystać zarówno wykładowcy jak i studenci. Idealnym rozwiązaniem, które mogłoby być wykorzystane przez uczelnie wydawało się być Airtable, ale ze względu na dużą ilość użytkowników (wykładowcy i studenci), koszty licencyjne były dla klienta nieakceptowalne. Po głębszym przeanalizowaniu wymagań, udało nam się tak zaprojektować rozwiązanie, aby ograniczyć liczbę użytkowników uprzywilejowanych (tzw. editorów), mających dostęp do widoków z tabelami z opcjami edycji, zaledwie do kilku osób. Pozostałym użytkownikom udostępniliśmy specjalne interfejsy do odczytu oraz formularze do wprowadzania danych i tym samym mogli oni działać na kontach bezpłatnych, co w konsekwencji drastycznie zredukowało koszty licencyjne dla naszego klienta. Ponadto biorąc pod uwagę, że była to uczelnia wyższa, w Airtable przysługiwała firmie dodatkowa zniżka 50% co tym bardziej uatrakcyjniło ofertę. Na pierwszy rzut oka mogłoby się wydawać, że lepszym rozwiązaniem dla klienta byłoby skorzystanie z rozwiązań alternatywnych, które mogłyby wydłużyć prace rozwojowe, przy jednoczesnej redukcji kosztów licencyjnych. Jednak dzięki świadomej analizie faktycznych wymagań i planów cennikowych, można zwinnie lawirować redukując wszystkie 3 składniki kosztowe.

Czy Twoja firma potrzebuje programisty, czy tylko citizen developera?

Platformy no-code/low-code (NCLC) rewolucjonizują tworzenie oprogramowania, umożliwiając firmom dostarczanie wartości biznesowej szybciej i taniej niż tradycyjne metody programowania. Dzięki wizualnym interfejsom i gotowym komponentom, aplikacje powstają w ułamku czasu, a koszty rozwoju są znacząco niższe, co potwierdzają prognozy Gartnera, że w 2025 roku ponad 70% nowych aplikacji biznesowych będzie opartych na NCLC. Jednak, aby w pełni wykorzystać ich potencjał, nie można całkowicie rezygnować z wiedzy technicznej. Eksperci od serwerów, cyberbezpieczeństwa czy sztucznej inteligencji są niezbędni, by zapewnić skalowalność, bezpieczeństwo i optymalizację rozwiązań. Pragmatyczne podejście, oparte na analizie wymagań, doświadczenie w realizacji projektów zarówno full-code jak i no-code / low-code  i znajomość modeli licencyjnych platform NCLC, pozwala dobrać odpowiednią technologię, minimalizując koszty produkcyjne, utrzymaniowe i licencyjne. Przy wyborze agencji do realizacji projektów NCLC warto postawić na partnera, który łączy szybkość platform NCLC z techniczną precyzją, gwarantując aplikacje nie tylko efektywne, ale i bezpieczne oraz skalowalne.