Codex w Wasmer ułatwił budowę Node.js dla środowiska brzegowego

Inżynierowie Wasmer dokonali w tym roku przełomu: opracowali sposób uruchamiania obciążeń Node.js w środowisku izolowanym WebAssembly, dzięki czemu programiści mogą uruchamiać aplikacje JavaScript, MCP i agenty bez Dockera. Bez Codex ten wysiłek zająłby rok, ale z Codex zajął dwa tygodnie. Teraz są pierwszym dostawcą usług w chmurze, który oferuje pełny Node.js w warstwie brzegowej.

Wasmer to młoda firma z niewielkim zespołem i dużym celem: rozwoju platformy brzegowej, która skaluje się w środowiskach lokalnych i globalnych bez ograniczeń platformowych.

„Projekty, których się podejmujemy, są niezwykle ambitne, a bez AI ich realizacja zajęłaby nam całe wieki” — mówi Syrus Akbary Nieto, założyciel i CEO. „Teraz wszystko jest znacznie prostsze i szybsze”.

Ta prostota i szybkość przełożyły się bezpośrednio na przełomowy projekt: Edge.js⁠(otwiera nowe okno), środowisko uruchomieniowe JavaScript, które może obsługiwać obciążenia Node.js dla AI i przetwarzania brzegowego.

To projekt, którego zespół od dawna chciał się podjąć, ale nie zawsze miał na to zasoby. „Wszyscy tutaj są bardzo, bardzo techniczni, ale po prostu nie mieliśmy czasu, by poświęcić się tym projektom. A teraz możemy wprowadzać na rynek nowe produkty, które wcześniej byłyby niemożliwe do zrealizowania” — wyjaśnia Nieto.

Dzięki Codex inżynierowie Wasmer mogą zwielokrotnić swoje wysiłki. „Zwiększyliśmy szybkość rozwoju co najmniej 10–20 razy” — mówi Nieto.

Podobnie jak wiele zespołów, inżynierowie Wasmer początkowo podchodzili sceptycznie do AI. „Na początku nie ufaliśmy zbytnio wynikom AI” — wyjaśnia Nieto. Kiedy jednak zespół zaczął eksperymentować, wyniki przekroczyły ich oczekiwania. „Przez ostatni rok, a zwłaszcza przez ostatnie kilka miesięcy, pracowaliśmy z Codex, a wyniki były naprawdę, naprawdę dobre”.

W miarę rozwoju zdolności rozumowania Codex inżynierowie Wasmer poświęcają coraz mniej czasu na prowadzenie go za rękę. „Tak naprawdę wychodzimy poza samo IDE i nie dotykamy już kodu tak często. Po prostu wskazujemy mu kierunek, w którym ma podążać” — mówi Nieto.

Zespół używał Codex od samego początku projektu aż do jego końca — od budowania początkowych elementów architektury po dopracowanie produktu końcowego. Przez cały ten czas Codex pomagał zespołowi znajdować błędy i identyfikować ich pierwotne przyczyny.

„Były pewne błędy, których nie spodziewaliśmy się napotkać, a gdy tylko zaczęliśmy je odkrywać, Codex od razu przechodził do debugowania” — mówi Nieto. „Największe wrażenie zrobiło na nas to, jak szybko przechodził od debugowania do znalezienia pierwotnej przyczyny i wskazania rozwiązania”.

Zwykle, jak wyjaśnia Nieto, deweloperzy potrzebowaliby specjalistycznej wiedzy, aby znaleźć wiele z tych błędów. Ale Codex, mówi Nieto, „potrafił opanować logi konsoli do śledzenia wywołań oraz niskopoziomowy debugger, taki jak LLD, który uzyskuje dostęp do rzeczy na poziomie asemblera. Codex może zejść bardzo nisko i zobaczyć, co dzieje się pod kodem”.

Przed Edge.js, jak wyjaśnia Nieto, korzystanie z JavaScript w środowisku brzegowym nie było możliwe. A przed Codex zespół Wasmer nie mógłby podjąć się projektu o takiej ambicji i w takim harmonogramie.

„Codex umożliwił małej firmie osiągnięcie rzeczy, które były możliwe tylko w dużych przedsiębiorstwach. Ten projekt dosłownie byłby bez niego niemożliwy do zrealizowania” — mówi Nieto.

Ośmielony w swoich ambicjach zespół Wasmer patrzy teraz w stronę jeszcze większych projektów. „Teraz mamy w zasięgu ręki, które wcześniej nie były możliwe. Musimy przyjrzeć się jeszcze trudniejszym problemom” — mówi Nieto.