Poznaj, jak AMP – przełomowy agent kodujący Sourcegraph – przekształca krajobraz rozwoju AI, stawiając na szybkie iteracje, autonomiczne rozumowanie i agentów wywołujących narzędzia – i dlaczego tradycyjne narzędzia programistyczne stają się przestarzałe.
Rynek agentów kodujących AI przeżywa bezprecedensowe zamieszanie. To, co pół roku temu było szczytem nowoczesności, dziś uznawane jest za przestarzałe. GitHub Copilot, niegdyś złoty standard programowania wspomaganego AI, został przyćmiony przez nowsze narzędzia. Cursor zdominował rynek jako najszybciej rozwijający się startup wszech czasów, by następnie stanąć w szranki z jeszcze bardziej zaawansowanymi rozwiązaniami. W tym błyskawicznie zmieniającym się ekosystemie Sourcegraph podjął odważną decyzję strategiczną: zamiast stopniowo ulepszać istniejący produkt Cody, stworzyli AMP – zupełnie nowego agenta kodującego, zaprojektowanego od podstaw pod kątem najnowszych możliwości AI.
W tym artykule omawiamy filozofię, architekturę techniczną i strategię biznesową stojącą za AMP, czerpiąc z rozmów z zespołem odpowiedzialnym za to rewolucyjne narzędzie. Przyjrzymy się, dlaczego tradycyjne podejścia do rozwoju produktu zawodzą w erze gwałtownego postępu AI, jak agenci wywołujący narzędzia fundamentalnie różnią się od wcześniejszych asystentów kodowania AI i jak wygląda przyszłość autonomicznego rozwoju. Co najważniejsze, zrozumiemy, dlaczego “cesarz jest nagi” – dlaczego ugruntowane produkty z pozornie niezachwianą pozycją rynkową mogą stać się nieistotne niemal z dnia na dzień, gdy zmienia się technologia u podstaw.
{{ youtubevideo videoID=“b4rOVZWLW6E” provider=“youtube” title=“AMP: Cesarz jest nagi – dlaczego agenci kodujący AI wywracają narzędzia deweloperskie” class=“rounded-lg shadow-md” }}
Ewolucja rozwoju oprogramowania wspomaganego AI przebiegała według wyraźnej trajektorii – każda generacja budowała na poprzedniej, ale fundamentalnie zmieniała sposób, w jaki deweloperzy współpracują ze sztuczną inteligencją. Aby zrozumieć znaczenie AMP, musimy najpierw wyjaśnić, czym agent kodujący różni się od wcześniejszych form wsparcia AI. Podróż zaczęła się od GitHub Copilot, który wprowadził podpowiadanie i uzupełnianie kodu bezpośrednio w edytorach deweloperów. Copilot był rewolucyjny, bo w nieinwazyjny sposób wprowadził AI do codziennego procesu pracy, oferując sugestie podczas pisania kodu. Jednak Copilot miał zasadnicze ograniczenia – mógł sugerować kod, ale nie był w stanie wykonywać złożonych, wieloetapowych zadań ani współdziałać z szerszym środowiskiem programistycznym.
Następna generacja przyniosła narzędzia takie jak Cursor i Windsurf, które podeszły inaczej – tworząc forki IDE z głębiej zintegrowaną AI. Pokazały one, że częściowo agentowe możliwości – gdzie AI może wykonywać bardziej złożone operacje w IDE – wyraźnie zwiększają produktywność deweloperów. Udowodniły, że deweloperzy są gotowi zmienić całe środowisko pracy, jeśli możliwości AI będą wystarczająco zaawansowane. Jednak nawet te narzędzia działały w ograniczonym zakresie: były interaktywne, wymagały zgody dewelopera na każdym etapie i nie działały w pełni autonomicznie.
Agent kodujący to zupełnie inna architektura. Składa się z trzech kluczowych komponentów: modelu językowego (najczęściej z najwyższej półki, np. Claude 3.5), promptu systemowego, który definiuje zachowanie i ograniczenia agenta, oraz zestawu narzędzi z własnymi promptami opisującymi ich funkcje. Krytyczna różnica polega na tym, że agenci mogą działać z wyraźnymi uprawnieniami do interakcji z systemami zewnętrznymi – systemami plików, edytorami kodu, systemami kontroli wersji itd. Oznacza to, że agent może samodzielnie rozumować nad problemem, decydować, jakich narzędzi użyć, uruchamiać te narzędzia, obserwować wyniki i iterować aż do ukończenia zadania. To fundamentalnie potężniejsze niż dotychczasowe podejścia, bo pozwala na prawdziwie autonomiczne zachowanie, a nie tylko ulepszone sugestie lub interaktywną pomoc.
Krajobraz technologiczny wszedł w fazę bezprecedensowej niestabilności. To, co było szczytem techniki osiemnaście miesięcy temu, dziś uchodzi za prymitywne. GitHub Copilot, wydany w 2021, był autentyczną rewolucją – pierwszą masową aplikacją dużych modeli językowych do programowania. Dziś wielu deweloperów nie zalicza go już nawet do czołówki narzędzi AI. Nie dlatego, że Copilot się pogorszył – podstawowa technologia rozwinęła się tak szybko, że cała kategoria przesunęła się do przodu. To rodzi poważne wyzwanie dla ugruntowanych firm: jak utrzymać sukces produktu, gdy grunt pod nogami nieustannie się przesuwa?
Tradycyjny rozwój produktu zakłada względnie stabilne podstawy. Znajdujesz dopasowanie produktu do rynku, skalujesz produkt, wdrażasz dobre praktyki inżynieryjne, dodajesz funkcje korporacyjne, zawierasz długoterminowe kontrakty z klientami. Ten schemat działał przez dekady, bo technologia zwykle ewoluowała stopniowo. W obecnej erze AI to podejście jest wręcz szkodliwe. Optymalizując produkt pod kątem skali i stabilności, stajesz się powolny. Jeśli jesteś powolny, przegapisz kolejną falę możliwości. Zanim dodasz funkcje korporacyjne i zgodność z normami bezpieczeństwa, pojawi się nowy model, który uczyni twoje podejście przestarzałym.
Sourcegraph stanął dokładnie przed takim dylematem z Cody. Cody był udanym produktem z klientami korporacyjnymi, wieloletnimi umowami i znaczącymi przychodami. Ale Cody był ściśle zintegrowany z platformą Sourcegraph, a więc ograniczony jej cyklami wydawniczymi. Platforma miała własną infrastrukturę, własny harmonogram wdrożeń i własne ograniczenia. Gdy pojawił się Claude 3.5 Sonnet i zespół zorientował się, że mogą zbudować coś fundamentalnie innego – agenta wywołującego narzędzia z autonomicznym rozumowaniem – mieli wybór: próbować zaadaptować te możliwości do Cody albo zacząć od zera z nowym produktem. Wybrali to drugie, co pokazuje kluczowy wgląd w rywalizację na rynkach o szybkim tempie zmian.
Najważniejsza była świadomość, że nie da się utrzymać modelu subskrypcji za 20 dolarów dla agenta wywołującego narzędzia. Koszty obliczeniowe są nieporównywalne. Asystent czatowy taki jak Cody może działać wydajnie na umiarkowanej infrastrukturze. Agent wywołujący narzędzia, rozumujący nad kodem, uruchamiający narzędzia i iterujący autonomicznie, wymaga znacznie większych zasobów. To nie tylko kwestia ceny, ale sygnał, że produkt jest fundamentalnie inny i wymaga odmiennego modelu biznesowego, innych oczekiwań klientów i innej strategii wejścia na rynek. Tworząc AMP jako osobny produkt i markę, Sourcegraph mógł całkowicie zresetować te oczekiwania. Mogli powiedzieć klientom: “To nie jest Cody 2.0. To zupełnie coś innego. Kosztuje więcej, bo robi więcej. Działa inaczej, bo opiera się na innej architekturze.”
By w pełni docenić, dlaczego AMP jest zmianą paradygmatu, trzeba poznać architekturę techniczną agentów wywołujących narzędzia. Agent wywołujący narzędzia to nie tylko model językowy z dostępem do funkcji. To architektura znacznie bardziej zaawansowana i potężniejsza. System zaczyna się od modelu językowego z czołówki – w przypadku AMP to Claude 3.5 Sonnet – wytrenowanego do skutecznego używania narzędzi. Model otrzymuje prompt systemowy określający jego rolę, ograniczenia i cele. Co ważne, prompt systemowy to nie luźna instrukcja, ale starannie zaprojektowany prompt, kształtujący sposób rozumowania modelu i podejmowania decyzji o wyborze narzędzi.
Obok promptu systemowego każde narzędzie ma własny prompt, opisujący co robi, jakie parametry przyjmuje, co zwraca i kiedy powinno być użyte. To kluczowe, bo model językowy musi rozumieć nie tylko, że narzędzie istnieje, ale również do czego służy i kiedy jest właściwe. Przykładowo, agent może mieć narzędzia do odczytu plików, zapisu plików, wykonywania kodu, uruchamiania testów i zatwierdzania zmian. Każde narzędzie ma szczegółowy opis, pomagający modelowi rozumować, którego użyć w danej sytuacji. Model może wtedy autonomicznie zdecydować o użyciu narzędzi, obserwować rezultaty i iterować w oparciu o uzyskaną wiedzę.
Moc tej architektury widać, gdy zobaczymy, co agent potrafi. Programista może zadać agentowi zadanie: “zaimplementuj nową funkcję dodającą uwierzytelnianie użytkownika do tego repozytorium”. Agent samodzielnie: przegląda kod, by zrozumieć architekturę, identyfikuje miejsce integracji, pisze kod, uruchamia testy, poprawia błędy, a na końcu zatwierdza zmiany. Wszystko bez udziału człowieka. Agent rozumuje nad problemem, decyduje o wyborze narzędzi i iteruje w oparciu o otrzymane wyniki.
To zasadniczo różni się od wcześniejszych narzędzi AI. Copilot może sugerować kod, ale nie wykona wieloetapowego procesu. Cursor potrafi więcej, ale wymaga ludzkiej akceptacji na każdym kroku. Agent może działać autonomicznie, mając wyraźne uprawnienia. To nowa kategoria możliwości, o rzędy wielkości potężniejsza. Ale to także nowe wyzwania: autonomiczni agenci mogą popełniać błędy na dużą skalę, mogą wykonać szkodliwe operacje, jeśli nie są odpowiednio ograniczeni. Wymagają starannego projektowania promptów systemowych. Dlatego architektura i podejście AMP są tak istotne.
Gdy zespół AMP rozpoczął prace, podjął fundamentalną decyzję: głównym celem optymalizacji będzie szybkość i iteracja. Wszystko inne miało z tego wynikać. To oznaczało porzucenie wielu praktyk, które przyniosły Sourcegraph sukces z Cody. Brak formalnych code review. Brak długich cykli planowania. Brak żmudnych checklist bezpieczeństwa i zgodności, które trwają miesiącami. Zamiast tego: mentalność projektu osobistego – push na main, wdrożenia 15 razy dziennie, ciągłe używanie własnego produktu i iteracja na bazie rzeczywistego wykorzystania.
To podejście brzmi chaotycznie – i według tradycyjnych standardów inżynierii oprogramowania takie jest. Ale to właśnie odpowiednia strategia dla produktu funkcjonującego na czele postępu AI. Powód jest prosty: czołówka się przesuwa. Co kilka miesięcy pojawia się nowy model. Co kilka tygodni – nowe możliwości. Co kilka dni – nowe techniki prompt engineeringu lub projektowania narzędzi. W takim środowisku zdolność szybkiego iterowania jest cenniejsza niż zdolność niezawodnego skalowania. Produkt, który wdraża się 15 razy dziennie, może wchłonąć nowe możliwości modeli w ciągu godzin. Produkt z tradycyjnym cyklem wydań będzie miesięcy w tyle.
Struktura zespołu odzwierciedla tę filozofię. Zespół AMP jest mały – ok. 8 osób – znacznie mniej niż w dużych organizacjach inżynieryjnych. To celowe: umożliwia szybkie decyzje i eliminuje koszty komunikacji. Każdy ma duże doświadczenie, więc nie trzeba formalnych code review. Wszyscy używają produktu na co dzień, błyskawicznie wyłapują problemy i doskonale rozumieją potrzeby użytkowników. Nie tworzą produktu dla każdego dewelopera, lecz dla tych, którzy chcą działać równie szybko i być na czele rozwoju AI.
To pozycjonowanie jest kluczowe. AMP nie chce być GitHub Copilotem dla wszystkich. Nie celuje w miano domyślnego narzędzia AI dla każdego dewelopera. Zamiast tego pozycjonuje się jako narzędzie dla tych, którzy chcą działać szybko i zawsze być na czele. To znacznie mniejszy rynek niż “wszyscy deweloperzy”, ale taki, który jest gotów zapłacić znacznie więcej za przewagę. Model biznesowy to odzwierciedla: zamiast subskrypcji za 20 dolarów miesięcznie, klienci AMP płacą setki dolarów miesięcznie. Niektóre zespoły mają roczne przychody liczone w setkach tysięcy dolarów. To możliwe, bo wartość jest ogromna dla tej grupy docelowej.
Zasady, które kierują rozwojem AMP – szybka iteracja, pozycjonowanie na czele, autonomiczne rozumowanie – mają bezpośrednie zastosowanie w szerszej automatyzacji procesów. FlowHunt, jako platforma do budowy i automatyzacji złożonych przepływów, stoi przed podobnymi wyzwaniami i szansami. Tak jak AMP przygotowuje się na kolejną generację AI, tak FlowHunt pozwala organizacjom budować przepływy odporne na gwałtowne zmiany technologiczne. Dzięki elastyczności, szybkim iteracjom i zdolności szybkiego włączania nowych narzędzi i możliwości FlowHunt pozwala zespołom wyprzedzać konkurencję.
Najważniejszy wniosek: w szybko zmieniającym się środowisku technologicznym zdolność do szybkiej adaptacji jest cenniejsza niż optymalizacja pod obecne warunki. Dotyczy to zarówno budowania agenta kodującego AI, jak i automatyzacji procesów biznesowych. Podejście FlowHunt – umożliwienie szybkiego tworzenia, testowania i iterowania przepływów – doskonale wpisuje się w tę filozofię. Zespoły mogą budować przepływy z najnowszymi możliwościami AI, szybko je testować i poprawiać na podstawie wyników. Gdy pojawiają się nowe modele i narzędzia, przepływy można błyskawicznie zaktualizować bez konieczności długotrwałych przeróbek. Przyszłość automatyzacji to nie statyczne, zoptymalizowane procesy, lecz dynamiczne, adaptacyjne przepływy, które ewoluują wraz z technologią.
Rynek agentów kodujących AI to fascynujące studium tego, jak szybko zmienia się pozycja lidera. Na początku 2024 roku Cursor uchodził za króla narzędzi AI do kodowania. Był najszybciej rozwijającym się startupem wszech czasów. Deweloperzy masowo przesiadali się na Cursor. Rynek wydawał się ustabilizowany. Potem, w ciągu kilku miesięcy, wszystko się zmieniło. Pojawiły się nowe narzędzia. Możliwości się poprawiły. Deweloperzy zaczęli zadawać inne pytania. W połowie 2024 roku wielu programistów nie wskazywało już Cursor jako najlepszego narzędzia AI. Rynek zmienił się tak szybko, że dawny lider przestał być wyraźnym numerem jeden.
Ten wzorzec nie dotyczy tylko agentów kodujących. To fundamentalna cecha rynków, na których technologia błyskawicznie się rozwija. Na takich rynkach zdolność do szybkiego działania i adaptacji liczy się bardziej niż bieżący udział w rynku. Firma z 30% udziałem, która potrafi szybko iterować i wdrażać nowe możliwości, z czasem prześcignie firmę z 50% udziałem, która działa wolno. Dlatego decyzja Sourcegraph o stworzeniu AMP jako osobnego produktu była tak trafna. Oddzielając AMP od Cody, uwolnili się od ograniczeń, które by ich spowalniały. Mogli działać szybko, iterować błyskawicznie i pozycjonować się na czele.
Szersza lekcja brzmi: na rynkach o szybkim tempie zmian cesarz często jest nagi. Ugruntowane produkty, które wydają się dominujące, mogą stać się przestarzałe zaskakująco szybko. Nie dlatego, że się pogarszają – technologia się zmienia i nie nadążają z adaptacją. Firmy, które odnoszą sukces, to te, które rozumieją tę dynamikę i odpowiednio się pozycjonują. Nie optymalizują pod kątem obecnych warunków – optymalizują zdolność do adaptacji w przyszłości. Nie próbują obsłużyć każdego klienta – koncentrują się na tych, którzy cenią szybkość i innowacje. Nie stosują tradycyjnych praktyk rozwoju produktu – wdrażają praktyki umożliwiające szybkie iteracje i uczenie się.
Dyskusja o AMP odsłania ważny wgląd w przyszłość agentów AI: kolejny duży przełom to przejście od agentów interaktywnych do asynchronicznych. Obecnie większość agentów kodujących AI działa interaktywnie. Programista uruchamia agenta w edytorze lub CLI, agent wykonuje operacje, a programista widzi wyniki. Zazwyczaj działa jeden agent na raz, synchronicznie – programista czeka na zakończenie pracy. To duży postęp względem ręcznego kodowania, ale to nie jest ostateczna forma rozwoju opartego na agentach.
Kolejny przełom to agenci asynchroniczni, działający 24/7 w tle, równolegle. Zamiast jednego agenta na raz, możesz mieć 10, 50 lub 100 agentów pracujących jednocześnie nad różnymi zadaniami. Jeden agent refaktoryzuje kod w jednej części projektu, drugi pisze testy do innego komponentu, trzeci analizuje wydajność i sugeruje optymalizacje. Wszystko bez udziału człowieka, wszystko równolegle. Skutki są ogromne: 10- do 100-krotne zwiększenie ilości wykonywanej pracy, fundamentalna zmiana w pracy zespołów programistycznych i całkowicie nowe możliwości rozwoju wspomaganego AI.
To przejście przyniesie poważne wyzwania: wzrost kosztów wnioskowania, nowe sposoby organizacji pracy zespołów, redefinicję roli dewelopera. Pojawią się też nowe wyzwania dotyczące jakości, bezpieczeństwa i zapobiegania błędom czy lukom powstającym na dużą skalę. Ale potencjał jest olbrzymi. Zespoły, które skutecznie wykorzystają asynchronicznych agentów, zrobią w kilka dni to, co kiedyś zajmowało tygodnie. Dlatego właśnie tak ważne jest pozycjonowanie się do szybkiego działania i adaptacji. Firmy, które pierwsze opanują budowę skutecznych agentów asynchronicznych, zyskają ogromną przewagę.
Podstawowa zasada podejścia AMP to budowanie na niepewność. Zespół nie wie, dokąd dokładnie podąży technologia – ale wie, że się zmieni. Nie wie, które możliwości będą najważniejsze – ale wie, że pojawią się nowe. Nie wie, jak będzie wyglądał rynek za pół roku – ale wie, że się zmieni. W tej niepewności racjonalnym podejściem jest optymalizacja pod kątem zdolności adaptacji, nie optymalizacji. Oznacza to elastyczny kod, szybkie wdrożenia, bliskość czołówki AI i gotowość na porzucanie rozwiązań, które przestają działać.
Ta zasada dotyczy również struktury zespołu, modelu biznesowego i strategii klienta. Zespół jest mały i doświadczony, co pozwala na szybkie decyzje. Model biznesowy elastyczny, bez sztywnych cen i modeli użytkownika, co pozwala na szybkie dostosowanie do zmian rynkowych. Strategia klienta to deweloperzy chcący działać szybko – naturalnie dopasowana do możliwości firmy. Wszystko wynika z kluczowej zasady: budować na niepewność i optymalizować zdolność adaptacji.
To radykalnie odmienne podejście od tradycyjnego rozwoju produktu, gdzie przewidujesz przyszłość, budujesz pod skalę i optymalizujesz pod stabilność. W rynku, gdzie technologia gwałtownie się rozwija, tradycyjne podejścia wręcz szkodzą – spowalniają, zamykają w przestarzałych decyzjach i uniemożliwiają adaptację. Firmy, które wygrywają na takich rynkach, to te, które akceptują niepewność, optymalizują zdolność adaptacji i działają szybciej niż konkurencja.
{{ cta-dark-panel heading=“Przyspiesz swój workflow z FlowHunt” description=“Przekonaj się, jak FlowHunt automatyzuje Twoje treści AI i przepływy SEO — od badań i generowania treści po publikację i analitykę — wszystko w jednym miejscu.” ctaPrimaryText=“Umów demo” ctaPrimaryURL=“https://calendly.com/liveagentsession/flowhunt-chatbot-demo" ctaSecondaryText=“Wypróbuj FlowHunt za darmo” ctaSecondaryURL=“https://app.flowhunt.io/sign-in" gradientStartColor="#123456” gradientEndColor="#654321” gradientId=“827591b1-ce8c-4110-b064-7cb85a0b1217” }}
Zdolność do wdrażania 15 razy dziennie nie jest przypadkowa – to efekt świadomych decyzji architektonicznych. Pierwsza kluczowa decyzja to całkowite odłączenie AMP od platformy Sourcegraph. Cody był ściśle zintegrowany z Sourcegraph, więc podlegał jej cyklom wydawniczym i ograniczeniom infrastruktury. AMP powstał jako samodzielny produkt z własną infrastrukturą, własnym pipeline’m wdrożeniowym i własnym harmonogramem wydań. To odłączenie jest kluczowe, bo eliminuje narzut koordynacyjny spowalniający większe systemy. Zmiany w AMP nie wymagają koordynacji z platformą. Wdrożenia nie czekają na wydania platformy.
Druga decyzja to minimalizacja procesu code review. Zespół wysyła kod na main i wdraża często. Jeśli coś się popsuje, szybko naprawiają. Brzmi ryzykownie, ale działa, bo zespół jest mały, doświadczony i ciągle korzysta z własnego produktu. Szybko wykrywają błędy, bo sami z niego korzystają. Szybko je naprawiają, bo kod mają świeżo w pamięci. Iterują szybko, bo nie czekają na akceptację code review. W dużej organizacji byłoby to niebezpieczne, ale w małym, doświadczonym zespole działa doskonale.
Trzecia decyzja to agresywne korzystanie z własnego produktu (dogfooding). Zespół używa AMP do budowy AMP. Tworzy to ścisłą pętlę zwrotną – wszelkie problemy i ograniczenia wychodzą natychmiast. Zespół ciągle odkrywa nowe przypadki użycia i możliwości. Używając własnego produktu do jego rozwoju, szybko dowiadują się, co działa, a co nie. Poznają przypadki brzegowe, których nie wykryłby tradycyjny testing. Zyskują intuicję, jakie funkcje są najważniejsze. Dlatego dogfooding jest tak potężny przy szybkich iteracjach.
Czwarta decyzja to prostota i elastyczność kodu. Zamiast budować złożony, zoptymalizowany system, zespół postawił na łatwość modyfikacji i rozbudowy. Dzięki temu można szybko dodawać nowe możliwości – gdy pojawia się nowy model, łatwo go zintegrować; nowa technika prompt engineeringu – można szybko ją wypróbować; lepsze podejście do problemu – refaktoryzacja bez obaw o skomplikowane zależności. Prostota i elastyczność są cenniejsze niż optymalizacja w szybko zmieniającym się rynku.
Model cenowy AMP ujawnia ważne spostrzeżenia na temat tworzenia wartości w rozwoju wspomaganym AI. Już na początku zespół uznał, że nie da się utrzymać subskrypcji za 20 dolarów miesięcznie dla agenta wywołującego narzędzia. To nie tylko kwestia ceny – to sygnał, że produkt jest fundamentalnie inny i wymaga odmiennego modelu biznesowego. Asystent czatowy jak Cody działa wydajnie na umiarkowanej infrastrukturze. Agent wywołujący narzędzia, rozumujący nad kodem i iterujący autonomicznie, wymaga znacznie większej mocy obliczeniowej. Same koszty infrastruktury uzasadniają wyższą cenę.
Ale model cenowy odzwierciedla także wartość. Dla programisty lub zespołu, który skutecznie wykorzysta AMP, zyski produktywności są ogromne. Agent, który może samodzielnie implementować funkcje, pisać testy i refaktoryzować kod, oszczędza godziny lub dni pracy tygodniowo. Dla zespołu programistów to znaczna wartość. Jeśli AMP oszczędzi zespołowi 10 godzin tygodniowo, a godzina programisty kosztuje 100 dolarów, to AMP generuje wartość 1000 dolarów tygodniowo. Pobieranie setek dolarów miesięcznie to ułamek tej wartości. Dlatego niektóre zespoły mają roczne przychody liczone w setkach tysięcy dolarów – wartość jest tak duża, że cena to okazja.
Model biznesowy podkreśla też strategiczne pozycjonowanie. Pobierając znacznie wyższe opłaty niż tradycyjne narzędzia, AMP sygnalizuje, że to inna kategoria produktu. Nie konkuruje ceną, lecz możliwościami i wartością. Przyciąga klientów, którzy cenią możliwości i wartość, a odstrasza tych, którzy kierują się głównie ceną. To idealna segmentacja dla produktu na czele rozwoju AI – chcesz klientów, którzy rozumieją i cenią przewagę, gotowych za nią zapłacić. Nie chcesz tych, którzy szukają najtańszej opcji, bo szybko ją porzucą dla kolejnej.
Jednym z najciekawszych aspektów podejścia Sourcegraph jest zarządzanie napięciem między innowacją a stabilnością. Sourcegraph to udany, dochodowy biznes z Cody i szerszą platformą Sourcegraph. Te przychody finansują śmiałe eksper
AMP to przełomowy agent kodujący stworzony przez Sourcegraph, który wykorzystuje zaawansowane modele językowe z możliwością wywoływania narzędzi do autonomicznego rozumowania i wykonywania zmian w kodzie. W przeciwieństwie do Cody, który był ściśle zintegrowany z platformą Sourcegraph i ograniczony jej cyklami wydawniczymi, AMP działa niezależnie na własnej infrastrukturze, co pozwala na ponad 15 wdrożeń dziennie i szybkie iterowanie nowych możliwości modelu.
Sourcegraph stworzył AMP jako osobny produkt, by nie zakłócać istniejących kontraktów korporacyjnych i oczekiwań klientów dotyczących Cody. Przejście od asystenta czatowego do agenta wywołującego narzędzia to fundamentalna zmiana sposobu interakcji deweloperów z AI. Dzięki nowej marce i produktowi Sourcegraph mógł zresetować oczekiwania, działać szybciej bez obciążeń przeszłości i uplasować się na czele rozwoju AI bez zrażania dotychczasowych klientów.
Agenci wywołujący narzędzia to systemy AI łączące model językowy, prompt systemowy i zewnętrzne narzędzia do wykonywania autonomicznych zadań. W przeciwieństwie do tradycyjnych chatbotów, tacy agenci mogą wchodzić w interakcję z systemami plików, edytorami kodu i innymi systemami zewnętrznymi z wyraźnymi uprawnieniami. Umożliwia im to autonomiczne wykonywanie złożonych, wieloetapowych przepływów pracy, co czyni ich znacznie potężniejszymi w zadaniach związanych z rozwojem oprogramowania.
AMP rośnie o ponad 50% miesiąc do miesiąca, a niektóre zespoły osiągają roczne przychody liczone w setkach tysięcy dolarów. Produkt osiągnął dodatnią marżę brutto przy utrzymaniu tego tempa wzrostu. Sourcegraph strategicznie koncentruje się na deweloperach, którzy chcą działać szybko i pozostawać na czele rozwoju modeli, zamiast próbować przekonać każdego dewelopera w korporacji.
W dyskusji podkreślono, że to asynchroniczni agenci działający 24/7 w tle zdominują kolejną fazę rozwoju AI. Zamiast interaktywnych agentów uruchamianych pojedynczo w edytorze, zespoły będą jednocześnie uruchamiać 10-100 autonomicznych agentów, co da 10-100x wzrost wydajności i wnioskowania. Kluczem do sukcesu będzie pozycjonowanie produktu tak, by mógł szybko się rozwijać i dostosowywać w miarę pojawiania się nowych modeli i możliwości co kilka miesięcy.
Arshia jest Inżynierką Przepływów Pracy AI w FlowHunt. Z wykształceniem informatycznym i pasją do sztucznej inteligencji, specjalizuje się w tworzeniu wydajnych przepływów pracy, które integrują narzędzia AI z codziennymi zadaniami, zwiększając produktywność i kreatywność.
Przekonaj się, jak FlowHunt pomaga zespołom szybciej budować, testować i wdrażać przepływy pracy oparte na AI niż kiedykolwiek wcześniej.
Dowiedz się, jak Ona (dawniej Gitpod) rewolucjonizuje rozwój oprogramowania dzięki agentom programistycznym AI działającym w w pełni skonfigurowanych, odizolowa...
Poznaj przełomowe możliwości Claude Sonnet 4.5, wizję Anthropic dotyczącą agentów AI oraz to, jak nowe Claude Agent SDK zmienia przyszłość rozwoju oprogramowani...
Poznaj nowości z OpenAI DevDay 2025, w tym Apps SDK, Agent Kit i Model Context Protocol. Dowiedz się, dlaczego promptowanie jest ważniejsze niż kiedykolwiek prz...
Zgoda na Pliki Cookie
Używamy plików cookie, aby poprawić jakość przeglądania i analizować nasz ruch. See our privacy policy.
