Vibe coding a inżynieria agentowa: 21 pojęć porównanych
Vibe coding, czyli przyjmowanie kodu napisanego przez AI bez czytania go, wprowadził Andrej Karpathy 2 lutego 2025. Ta strona zestawia z nim 20 innych nazw pracy z AI przy tworzeniu oprogramowania: dyscypliny, metody, cykle życia, techniki i kategorię narzędzi. Każdą opisuje przez to, kto pisze kod i co go sprawdza.
Prezentacja dostawcy obiecuje programowanie sterowane przez AI. Notatka CTO żąda inżynierii agentowej. Polityka zakazuje vibe codingu, a programista, który wdraża funkcję, nazywa to kodowaniem wspomaganym AI. W grze są cztery nazwy, a dwie z nich nic nie mówią o tym, kto sprawdza kod. Strona jest dla tech leada albo CTO, który musi wpisać jedną z nich do polityki, i dla programisty, który ma wyjaśnić różnicę.
Co dają te 21 definicji
Dział zatytułowany „Co dają te 21 definicji”- Jedną tabelę, która umieszcza 21 nazw według rodzaju, pochodzenia i tego, czym każda różni się od vibe codingu, z linkiem do osobnej strony z definicją
- Pochodzenie każdej nazwy z datą oraz twierdzenia „wymyślone przez”, których datowane źródła nie potwierdzają
- Dosłowne zestawienie z vibe codingiem dla każdej nazwy albo oznaczenie, że to nasza analiza
- Nasze umieszczenie vibe codingu na drabinie autonomii wraz z najbliższymi źródłami pierwotnymi
- Trzy prompty do skopiowania, które klasyfikują, jak w twoim repozytorium weryfikuje się pętle
Czym 21 nazw różni się od vibe codingu?
Dział zatytułowany „Czym 21 nazw różni się od vibe codingu?”Daty to najwcześniejsze datowane użycia, jakie znalazł research, a nie dowiedzione pierwszeństwa. Każdy cytat poniżej prowadzi do strony, z której pochodzi. Cytaty zostają w oryginale, po angielsku, bo tylko tak można je sprawdzić. Gdy źródło nie zestawia nazwy z vibe codingiem, to zestawienie jest oznaczone jako „nasza analiza”.
| Nazwa | Rodzaj pojęcia | Kto nazwał lub spopularyzował | Czym różni się od vibe codingu |
|---|---|---|---|
| Vibe coding | Technika | Andrej Karpathy, 2 lut 2025 | Punkt odniesienia |
| Vibe engineering | Dyscyplina (nazwa, która przegrała) | Simon Willison zaproponował ją 7 paź 2025 | Ten sam pomysł co inżynieria agentowa, z celowo zachowanym słowem „vibe” |
| Kodowanie rozszerzone (augmented coding) | Praktyka osobista | Kent Beck, 18 kwi 2025 | Zależy ci na kodzie, nie tylko na zachowaniu systemu |
| Inżynieria agentowa | Dyscyplina | W użyciu od 2025; poparta przez Karpathy’ego 4 lut 2026 | Ci sami agenci, przeciwne podejście do odpowiedzialności |
| Kodowanie agentowe | Zdolność narzędzia | Brak jednego autora; najwcześniejsze znalezione użycie: Anthropic, 21 cze 2024 | Nazywa to, co robi narzędzie, a nie to, jak starannie z niego korzystasz |
| Kodowanie wspomagane AI | Kategoria nadrzędna | Brak autora; tytuł raportu DORA 2025, 23 wrz 2025 | Zbiór nadrzędny: według Willisona vibe coding to jego mniej odpowiedzialny podzbiór |
| Programowanie w parze z AI | Sposób ujęcia współpracy | GitHub Copilot, 29 cze 2021 (wcześniej: Codota, 2017) | Człowiek czyta każdą sugestię; w vibe codingu nie czyta żadnej |
| Agentowe tworzenie oprogramowania | Cykl życia | Brak autora; „agentic DevOps” Microsoftu, 19 maja 2025 | Zakres to cały cykl życia, a nie jedna sesja |
| Agentic SDLC (AI SDLC) | Cykl życia i model działania | Brak autora; w 2026 używają go Gartner, Forrester i Anthropic | Vibe coding nie ma etapów ani bramek |
| AI-DLC | Metodyka (AWS) | AWS, Raja SP, 31 lip 2025 | Zbudowana, żeby zatrzymać nawyk „accept all” (nasza analiza) |
| Programowanie AI-native | Paradygmat organizacyjny | Tessl, Guy Podjarny, 6 lip 2024 | Cecha procesu zespołu, a nie nawyk jednej osoby |
| Programowanie sterowane przez AI | Ogólny przymiotnik | Brak właściciela; „AI-Driven Development Lifecycle” AWS, 31 lip 2025 | „AI-driven” mówi, kto prowadzi; vibe coding mówi, czy ktoś czyta |
| Spec-driven development | Metoda | Brak jednego autora z ery AI; Kiro, 14 lip 2025; GitHub Spec Kit, 2 wrz 2025 | Dostawcy ustawiają je jako krok po vibe codingu |
| Compound engineering | Metoda i wtyczka | Kieran Klaassen, Every, 18 sie 2025 | Every traktuje vibe coding jako szybką ścieżkę wewnątrz swojego systemu |
| Inżynieria promptów | Technika | Brak autora; w użyciu wokół GPT-3 w 2020 | Inna oś: jakość wejścia, a nie przegląd wyniku |
| Inżynieria kontekstu | Dyscyplina | Spopularyzowali ją Tobi Lütke, 19 cze 2025, i Karpathy, 25 cze 2025 | Vibe coding niczego nie dobiera; inżynieria kontekstu dobiera to, co agent czyta |
| Inżynieria harnessu | Dyscyplina | Mitchell Hashimoto, 5 lut 2026; spopularyzował ją wpis OpenAI, 11 lut 2026 | Zastępuje czytanie wyniku automatycznymi kontrolami |
| Agenci kodujący AI | Kategoria narzędzi | Brak autora | To narzędzie; vibe coding to jeden ze sposobów korzystania z niego |
| Agentowe przepływy pracy | Podejście projektowe | Spopularyzował je Andrew Ng, mar 2024 | Inna oś: kontrola wewnątrz pętli, a nie usunięta po niej |
| Orkiestracja agentów | Technika i kategoria narzędzi | Brak autora; wzorzec orchestrator-worker Anthropic, 13 cze 2025 | Nie jest przeciwieństwem vibe codingu; jest nim weryfikacja |
| Inżynieria AI | Dyscyplina i rola zawodowa | Spopularyzował ją swyx, 30 cze 2023 | Inna oś: co się buduje, a nie jak powstaje kod |
Ostatnia kolumna to nasza analiza, z wyjątkiem kodowania wspomaganego AI, spec-driven development i compound engineering, gdzie opiera się na zestawieniu z samego źródła (cytaty w sekcji każdej nazwy poniżej).
Czym jest vibe coding i jakie nazwy wokół niego powstały?
Dział zatytułowany „Czym jest vibe coding i jakie nazwy wokół niego powstały?”Trzy nazwy wywodzą się z oryginalnego wpisu i sporu, który po nim nastąpił: sam termin, zaproponowany zamiennik oraz nazwa Kenta Becka, która zaczęła jako synonim, a stała się przeciwieństwem.
Czym jest vibe coding?
Dział zatytułowany „Czym jest vibe coding?”Andrej Karpathy wprowadził ten termin we wpisie na X z 2 lutego 2025: „There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists”. Ten sam wpis ustala zasadę przeglądu: „I ‘Accept All’ always, I don’t read the diffs anymore”, czyli zawsze akceptuję wszystko i nie czytam już diffów. Collins Dictionary uznał vibe coding za Słowo Roku 2025, co ogłosił 6 listopada 2025. Hasło w słowniku Merriam-Webster (zapis Wayback z 18 września 2026) definiuje go szeroko: „the act or practice of using an artificial intelligence system to generate computer code”. Simon Willison zachowuje sens wąski: „building software with an LLM without reviewing the code it writes” (19 marca 2025), czyli budowanie oprogramowania z LLM bez przeglądania napisanego przez niego kodu. Ta strona używa sensu wąskiego. Tekst Willisona podaje jako datę utworzenia terminu 6 lutego, ale oryginalny wpis ma znacznik czasu 2 lutego 2025 (23:17 UTC), a uwaga etymologiczna Merriam-Webster też mówi o 2 lutego 2025. Zobacz stronę słownika o vibe codingu.
Kto pisze kod, kto go sprawdza: Model pisze; nikt nie czyta diffa, człowiek ocenia zachowanie na oko.
Czym jest vibe engineering?
Dział zatytułowany „Czym jest vibe engineering?”Simon Willison zaproponował tę nazwę 7 października 2025 dla „the other end of the spectrum, where seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce”, czyli dla doświadczonych profesjonalistów, którzy przyspieszają pracę z LLM i pozostają odpowiedzialni za swoje oprogramowanie. Samych słów nie wymyślił: Sergey Tselovalnikov zatytułował wpis „There is no Vibe Engineering” 31 marca 2025, a wystąpienie Brendana O’Leary’ego „From Vibe Coding to Vibe Engineering” ma datę 29 kwietnia 2025. Willison przeciwstawia vibe coding temu, co nazywa „the fast, loose and irresponsible way of building software with AI—entirely prompt-driven, and with no attention paid to how the code actually works”. 23 lutego 2026 dopisał do tego samego wpisu: „It looks like the term ‘Agentic Engineering’ is coming out on top for this now”. Powód podał 4 lutego 2026 Addy Osmani: „the word ‘vibe’ carries too much baggage. It signals casualness.” Nasza analiza: to nazwa, która przegrała z inżynierią agentową w rywalizacji o miano tego samego pomysłu. Zobacz stronę słownika o vibe engineeringu.
Kto pisze kod, kto go sprawdza: Agenci piszą; odpowiedzialny profesjonalista sprawdza.
Czym jest kodowanie rozszerzone (augmented coding, AI-augmented development)?
Dział zatytułowany „Czym jest kodowanie rozszerzone (augmented coding, AI-augmented development)?”Dwie nazwy mają wspólne słowo, ale nie należy ich mieszać. Najwcześniejsze znalezione użycie „augmented coding” przez Kenta Becka pochodzi z 18 kwietnia 2025: „I have been doing a lot of vibe coding (which I call ‘augmented coding’ for reasons that will become clear)”. Już 25 czerwca 2025 przeprowadził granicę: „In vibe coding you don’t care about the code, just the behavior of the system. If there’s an error, you feed it back into the genie in hopes of a good enough fix. In augmented coding you care about the code, its complexity, the tests, & their coverage.” Po polsku: w vibe codingu liczy się tylko zachowanie systemu, w kodowaniu rozszerzonym także kod, jego złożoność i testy. Odrębna kategoria Gartnera, AI-augmented development, pojawia się w komunikacie z 16 października 2023: „the use of AI technologies, such as GenAI and machine learning, to aid software engineers in designing, coding and testing applications”. Zobacz stronę słownika o kodowaniu rozszerzonym.
Kto pisze kod, kto go sprawdza: „Dżin” pisze; programista sprawdza testami i projektem.
Które nazwy są najbliżej inżynierii agentowej?
Dział zatytułowany „Które nazwy są najbliżej inżynierii agentowej?”Cztery nazwy są najbliżej inżynierii agentowej, w różnym zakresie: dyscyplina, zdolność narzędzia, kategoria nadrzędna i sposób ujęcia współpracy. Tylko dyscyplina zakłada poprzeczkę jakości.
Czym jest inżynieria agentowa (agentic engineering)?
Dział zatytułowany „Czym jest inżynieria agentowa (agentic engineering)?”Wyrażenie funkcjonowało, zanim Andrej Karpathy je poparł. Mario Zechner pisał o „what people call ‘agentic engineering’” już 2 czerwca 2025, a Peter Steinberger zatytułował wpis „Just Talk To It - the no-bs Way of Agentic Engineering” 14 października 2025. Karpathy nazwał ją „personally my current favorite” 4 lutego 2026 i podał cel: „to claim the leverage from the use of agents but without any compromise on the quality of the software”, czyli czerpać korzyści z agentów bez kompromisu w jakości oprogramowania. Willison definiuje ją jako budowanie oprogramowania z agentami kodującymi, „where the defining feature is that they can both generate and execute code—allowing them to test that code and iterate on it independently of turn-by-turn guidance from their human supervisor” (23 lutego 2026).
Przeciwstawienie Addy’ego Osmaniego z 4 lutego 2026: „Vibe coding = YOLO. Agentic engineering = AI does the implementation, human owns the architecture, quality, and correctness.” Najkrótsza wersja jest w opublikowanym przez Karpathy’ego transkrypcie jego wystąpienia na Sequoia Ascent (30 kwietnia 2026; strona informuje, że LLM przygotował podsumowanie i oczyścił transkrypcję, a Karpathy je przeczytał): „Vibe coding raises the floor. Agentic engineering is about extrapolating the ceiling.” Zobacz stan inżynierii agentowej i stronę słownika o inżynierii agentowej.
Kto pisze kod, kto go sprawdza: Agenci piszą; człowiek odpowiada za jakość, sprawdzają testy i ewaluacje.
Czym jest kodowanie agentowe (agentic coding)?
Dział zatytułowany „Czym jest kodowanie agentowe (agentic coding)?”Nie ustalono jednego autora nazwy. Najwcześniejsze datowane użycie, jakie znalazł research, to ogłoszenie Claude 3.5 Sonnet firmy Anthropic z 21 czerwca 2024, w którym mowa o „an internal agentic coding evaluation”. Anthropic uczynił z tego kategorię produktu wraz z Claude Code 24 lutego 2025: „a command line tool for agentic coding”. Definicja akademicka, Sapkota, Roumeliotis i Karkee (26 maja 2025): „agentic coding enables autonomous software development through goal-driven agents capable of planning, executing, testing, and iterating tasks with minimal human intervention.” Hassan i współautorzy prowadzą granicę do dyscypliny: „elevating the practice from agentic coding to true agentic software engineering” (7 września 2025).
Nasza analiza: kodowanie agentowe i vibe coding nie są przeciwieństwami. Oryginalny vibe coding Karpathy’ego działał w edytorze z AI (Cursor Composer z modelem Sonnet) i nic nie stoi na przeszkodzie, żeby akceptować wszystko, co zrobi narzędzie do kodowania agentowego. Kodowanie agentowe mówi, co wykonuje pracę; vibe coding mówi, jak bardzo patrzysz na wynik. Zobacz stronę słownika o kodowaniu agentowym.
Kto pisze kod, kto go sprawdza: Agent w pętli pisz-uruchom-testuj; pojęcie milczy o sprawdzaniu.
Czym jest kodowanie wspomagane AI (AI-assisted coding)?
Dział zatytułowany „Czym jest kodowanie wspomagane AI (AI-assisted coding)?”To kategoria nadrzędna bez autora. Raport DORA z 2025 roku nosi tytuł „State of AI-Assisted Software Development” (23 września 2025), a artykuł w Wikipedii w wersji z 5 października 2026 definiuje tę dziedzinę jako „the use of large language models (LLMs) and AI agents to assist software developers in software development”. Tag Willisona brzmi: „Using AI tools such as Large Language Models to help write code. Vibe coding is the less responsible subset of this.” Willison tłumaczy, czemu ta nazwa nie sprawdziła się jako marka: „I’ve tried in the past to get terms like AI-assisted programming to stick, with approximately zero success.” Wyjaśnia też, co leży poza vibe codingiem, w definicji z 2025 roku: „If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development.” Drabina autonomii na tej stronie używa słowa „z asystą” węziej, dla poziomu 1. Zobacz stronę słownika o kodowaniu wspomaganym AI.
Kto pisze kod, kto go sprawdza: Człowiek, AI albo oboje; pojęcie nie mówi, kto sprawdza.
Czym jest programowanie w parze z AI (AI pair programming)?
Dział zatytułowany „Czym jest programowanie w parze z AI (AI pair programming)?”GitHub Copilot spopularyzował to wyrażenie w poście startowym z 29 czerwca 2021, „Introducing GitHub Copilot: your AI pair programmer”. Nie wymyślił go: strona główna Codoty już w zapisie Wayback z 15 czerwca 2017 miała nagłówek „Your AI Pair Programmer”. Krytyka pochodzi z wnętrza samej praktyki. Birgitta Böckeler napisała na martinfowler.com 10 sierpnia 2023: „The framing of coding assistants as pair programmers is a disservice to the practice”. Ogłoszenie agenta przez Microsoft z 19 maja 2025 mówi, że agent „levels up GitHub Copilot from a pair programmer to peer”.
Na drabinie praca w parze to poziom 2: Dan Shapiro pisze: „You are pairing with the AI like a colleague.” Nasza analiza: człowiek czyta każdą sugestię w chwili, gdy się pojawia, czyli stoi na przeciwnym końcu przeglądu niż vibe coding. Zobacz stronę słownika o programowaniu w parze z AI.
Kto pisze kod, kto go sprawdza: Człowiek prowadzi, AI podpowiada; człowiek czyta każdą sugestię.
Które nazwy opisują cykle życia i metody?
Dział zatytułowany „Które nazwy opisują cykle życia i metody?”Siedem nazw opisuje, jak praca przechodzi od intencji do wydania, od cyklu życia dostawcy po pętlę jednej osoby.
Czym jest agentowe tworzenie oprogramowania (agentic software development)?
Dział zatytułowany „Czym jest agentowe tworzenie oprogramowania (agentic software development)?”Diego Lo Giudice z Forrester, 8 czerwca 2026: „The new norm is agentic software development, where autonomous agents collaborate across the entire software development lifecycle (SDLC), toward more end-to-end automation.” Nie ustalono jednego autora nazwy. Microsoft pisał o „agentic DevOps” 19 maja 2025, a Hassan i współautorzy o „Agentic Software Engineering (SE 3.0)” 7 września 2025. Forrester umieszcza vibe coding na początku cyklu życia, a nie zamiast niego: „Product managers/owners vibe prototypes and features for the rest of the team to productize.” Nasza analiza: ci sami agenci w przeciwnym zakresie, czyli sesja jednej osoby, która kończy się, gdy „it mostly works” (Karpathy), wobec cyklu życia całej organizacji, który kończy się wydaniem z bramkami. Zobacz stronę słownika o agentowym tworzeniu oprogramowania.
Kto pisze kod, kto go sprawdza: Agenci w całym cyklu; potoki, inni agenci i ludzie przy bramkach.
Czym są agentic SDLC i AI SDLC?
Dział zatytułowany „Czym są agentic SDLC i AI SDLC?”Playbook AI-native SDLC firmy Anthropic (Louis Claxton, 21 sierpnia 2026) traktuje te etykiety jako jedno: „You’ll also hear this shift called the agentic SDLC, the AI SDLC, or simply agentic software development — the labels differ, but they describe the same thing.” Ta strona zostawia agentowe tworzenie oprogramowania jako osobne hasło, bo ma własną stronę w słowniku. Definicja z playbooka: „The AI-native SDLC is a reimagined process that combines the old control objectives with new enforcement. Instead of a linear flow, the process becomes a loop, and AI is embedded at each point.” Etykieta nie ma właściciela; streszczenie Gartnera z 23 czerwca 2026 mówi o liderach, którzy „transition to an agentic SDLC”.
Jet Anderson z GEICO, pisząc o aplikacjach tworzonych vibe codingiem we wpisie zaktualizowanym 2 czerwca 2026: „The failure is not that security tools did not catch the bugs. The failure is that nobody ran any security tools at all.” Nasza analiza: vibe coding nie ma etapów ani bramek, a agentic SDLC to właśnie bramki. Przewodnik po AI-native cyklu życia na tej stronie opisuje sześć etapów, z których każdy zapisuje artefakt. Zobacz stronę słownika o AI SDLC.
Kto pisze kod, kto go sprawdza: Agenci piszą pierwszy przebieg na każdym etapie; ludzie odpowiadają za bramki.
Czym jest AI-DLC?
Dział zatytułowany „Czym jest AI-DLC?”AI-DLC to nazwana metodyka AWS. Raja SP przedstawił ją 31 lipca 2025: „This is why we’re introducing the AI-Driven Development Lifecycle (AI-DLC), a new methodology designed to fully ingrain AI capabilities into the very fabric of software development.” Zastępuje sprinty „bolts” liczonymi w godzinach lub dniach, a epiki jednostkami pracy (Units of Work). Opis AWS z 2025 roku ma trzy fazy (Inception, Construction, Operations); otwartoźródłowy przepływ w awslabs/aidlc-workflows ma pięć faz i 33 etapy (README wersji v2.11.0, odczyt z 10 października 2026).
AWS nie używa słów „vibe coding” w żadnym z trzech wpisów o AI-DLC (sprawdzone 10 października 2026). Jego najbliższe zestawienie dotyczy „AI-autonomous development, where AI is expected to generate entire applications without human intervention”, a ogłoszenie wersji otwartoźródłowej z 29 listopada 2025 mówi, że rytuały mob „ensure that AI’s suggestions are not blindly accepted”. Nasza analiza: AI-DLC jest zbudowana, żeby zatrzymać nawyk „accept all”, który definiuje vibe coding. Zobacz stronę słownika o AI-DLC i porównanie AI-DLC na tej stronie.
Kto pisze kod, kto go sprawdza: AI pisze po zatwierdzeniu planu; zespół weryfikuje na sesjach mob.
Czym jest programowanie AI-native (AI-native development, AI-native engineering)?
Dział zatytułowany „Czym jest programowanie AI-native (AI-native development, AI-native engineering)?”Guy Podjarny z Tessl spopularyzował to określenie w odniesieniu do oprogramowania 6 lipca 2024: „We’re looking to define a new software development paradigm, AI Native Software Development, in which AI is built-in, not bolted on.” Patrick Debois uporządkował je w tekście „The 4 patterns of AI Native Dev” (19 marca 2025); nie on je wymyślił. Gartner przyjął „AI-native software engineering” w komunikacie z 1 lipca 2025. Przewodnik OpenAI o zespole AI-native (PDF zmieniony po raz ostatni 20 listopada 2025) opisuje role tak: „The agent becomes the first-pass implementer; the engineer becomes the reviewer, editor, and source of direction.”
Sama etykieta niewiele dowodzi. Cian Clarke z Nearform na blogu Tessl (6 stycznia 2026): „Many companies think enabling Copilot means they’re doing AI-native engineering. It doesn’t work that way.” Shapiro umieszcza „90% of ‘AI-native’ developers” na poziomie 2. Nasza analiza: AI-native to cecha procesu zespołu, a vibe coding to nawyk jednej osoby, więc zespół AI-native może zrobić prototyp vibe codingiem i mimo to wydawać kod przez bramki. Zobacz stronę słownika o programowaniu AI-native.
Kto pisze kod, kto go sprawdza: Agenci implementują pierwsi; inżynierowie odpowiadają za przegląd i merge.
Czym jest programowanie sterowane przez AI (AI-driven development)?
Dział zatytułowany „Czym jest programowanie sterowane przez AI (AI-driven development)?”To ogólny przymiotnik bez właściciela i bez kanonicznej definicji; Wikipedia nie ma o nim artykułu (sprawdzone przez jej API 10 października 2026). Najsilniejszym punktem odniesienia jest nazwa metodyki AWS, AI-DLC, z 31 lipca 2025. Wpis AWS dzieli dziedzinę na trzy: „AI-assisted development, where AI enhances specific tasks”, „AI-autonomous development” oraz własną trzecią drogę, w której „AI systematically creates detailed work plans, actively seeks clarification and guidance, and defers critical decisions to humans.” McKinsey też pisze o „AI-driven software development” w artykule z 3 listopada 2025, który radzi: „Avoid weak proxies like the percentage of code generated by AI, which offer little insight into real productivity.”
Żadne źródło nie zestawia go z vibe codingiem. Nasza analiza: „AI-driven” mówi, kto prowadzi, a vibe coding mówi, czy ktoś czyta. Zespół może być AI-driven i zdyscyplinowany albo AI-driven i niedbały, a samo słowo nie podpowiada CTO, który to przypadek. Zobacz stronę słownika o programowaniu sterowanym przez AI.
Kto pisze kod, kto go sprawdza: AI prowadzi; pojęcie nie wskazuje, kto sprawdza.
Czym jest spec-driven development (programowanie sterowane specyfikacją)?
Dział zatytułowany „Czym jest spec-driven development (programowanie sterowane specyfikacją)?”Dla ery AI nie ustalono jednego autora nazwy. Wyrażenie ma akademicki pierwowzór w artykule z 2004 roku Ostroffa, Makalsky’ego i Paige’a. W erze AI użył go Kiro 14 lipca 2025, a GitHub Spec Kit poszedł za nim 2 września 2025. Definicja Birgitty Böckeler (15 października 2025): „Spec-driven development means writing a ‘spec’ before writing code with AI (‘documentation first’). The spec becomes the source of truth for the human and the AI.”
Dostawcy, którzy wprowadzili ten termin, zestawiają go z vibe codingiem. GitHub: „This ‘vibe-coding’ approach can be great for quick prototypes, but less reliable when building serious, mission-critical applications or working with existing codebases.” Nasza analiza: ustawiają go jako krok po vibe codingu, a nie jego wroga. Przewodnik o spec-driven development na tej stronie jest bardziej rygorystyczny niż definicja branżowa: jeden autorytatywny spec.md i delta specyfikacji w każdym pull requeście zmieniającym zachowanie. Zobacz stronę słownika o spec-driven development.
Kto pisze kod, kto go sprawdza: Agenci piszą; ludzie przeglądają specyfikację, plan i zadania; testy pilnują wyniku.
Czym jest compound engineering?
Dział zatytułowany „Czym jest compound engineering?”Kieran Klaassen z Every nazwał je 18 sierpnia 2025, najpierw jako „compounding engineering”: „building self-improving development systems where each iteration makes the next one faster, safer, and better.” Dan Shipper był współautorem artykułu z 11 grudnia 2025, w którym nazwa brzmi już compound engineering; nie on ją wymyślił. Rdzeń idei: „each unit of engineering work should make subsequent units easier—not harder.”
Every nie przeciwstawia tego vibe codingowi. Jego przewodnik (bez daty; ta sama sekcja jest w artykule z 2025 roku) daje vibe codingowi miejsce wewnątrz systemu: „Vibe code to discover what you want, then spec to build it properly.” Nasza analiza: vibe coding optymalizuje bieżącą zmianę, a compound engineering następną, bo zapisuje każdą lekcję w plikach, które czyta kolejny przebieg. Zobacz przewodnik o compound engineering na tej stronie i stronę słownika o compound engineering.
Kto pisze kod, kto go sprawdza: Agenci piszą; sprawdzają agenci recenzujący, potem człowiek.
Jak układają się warstwy inżynierii promptów, kontekstu i harnessu?
Dział zatytułowany „Jak układają się warstwy inżynierii promptów, kontekstu i harnessu?”Lipcowa taksonomia Alexeya Grigoreva z 2026 roku przypisuje każdej warstwie osobne pytanie: „Prompt engineering - what we say when we interact with the agent”, „Context engineering - what the agent knows before it starts”. Jej pozostałe warstwy to inżynieria pętli i inżynieria grafowa. Nasza analiza: inżynieria harnessu pyta o to, co ogranicza i sprawdza agenta.
Czym jest inżynieria promptów (prompt engineering)?
Dział zatytułowany „Czym jest inżynieria promptów (prompt engineering)?”Nie ustalono jednego autora nazwy. Artykuł OpenAI o modelu CLIP, złożony 26 lutego 2021, już odwołuje się do „the ‘prompt engineering’ discussion around GPT-3”. Wpis Karpathy’ego z 24 stycznia 2023 rozpowszechnił tę ideę: „The hottest new programming language is English”. Dokumentacja OpenAI definiuje ją jako „the process of writing effective instructions for a model, such that it consistently generates content that meets your requirements.” Streszczenie Gartnera z 28 lipca 2025 przedstawiło ją jako wypieraną: „Context engineering is in, and prompt engineering is out.”
Żadne źródło nie zestawia jej z vibe codingiem. Nasza analiza: leżą na różnych osiach. Inżynieria promptów dotyczy jakości wejścia; vibe coding to brak przeglądu wyniku. Prompt, który nazywa własną kontrolę, przestaje być vibe codingiem. Zobacz stronę słownika o inżynierii promptów.
Kto pisze kod, kto go sprawdza: Model pisze z promptu; człowiek czyta wynik.
Czym jest inżynieria kontekstu (context engineering)?
Dział zatytułowany „Czym jest inżynieria kontekstu (context engineering)?”Tobi Lütke i Andrej Karpathy ją spopularyzowali, ale żaden jej nie wymyślił. Ankur Goyal użył jej 20 kwietnia 2025, a Walden Yan z Cognition 12 czerwca 2025. Lütke, 19 czerwca 2025: „I really like the term ‘context engineering’ over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.” Karpathy, 25 czerwca 2025: „+1 for ‘context engineering’ over ‘prompt engineering’.” Definicja Anthropic (29 września 2025): „the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference”.
Źródła różnią się w ocenie relacji do promptowania. Anthropic nazywa inżynierię kontekstu „the natural progression of prompt engineering”, a LangChain twierdzi, że „prompt engineering is a subset of context engineering”. Najbliższe zestawienie z vibe codingiem to sponsorowany tekst Thoughtworks w MIT Technology Review (5 listopada 2025): „the transition from vibe coding to what’s being termed context engineering shows that while the work of human developers is evolving, they nevertheless remain absolutely critical.” Nasza analiza: vibe coding niczego nie dobiera, a inżynieria kontekstu dobiera to, co agent czyta, i nic nie mówi o przeglądzie tego, co napisał. Zobacz stronę słownika o inżynierii kontekstu.
Kto pisze kod, kto go sprawdza: Agent pisze; pojęcie milczy o sprawdzaniu.
Czym jest inżynieria harnessu (harness engineering)?
Dział zatytułowany „Czym jest inżynieria harnessu (harness engineering)?”W najwcześniejszym użyciu dokładnego wyrażenia, jakie znalazł research, Mitchell Hashimoto napisał 5 lutego 2026: „I’ve grown to calling this ‘harness engineering.’ It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.” Dodał: „I don’t need to invent any new terms here; if another one exists, I’ll jump on the bandwagon.” Sześć dni później wpis OpenAI Ryana Lopopolo umieścił to wyrażenie w tytule i termin się rozpowszechnił; Wikipedia zapisuje autorstwo jako sporne. Definicja LangChain (11 marca 2026): „A harness is every piece of code, configuration, and execution logic that isn’t the model itself.”
Wpis OpenAI opisuje tę pracę tak: „a software engineering team’s primary job is no longer to write code, but to design environments, specify intent, and build feedback loops that allow Codex agents to do reliable work.” Nasza analiza: inżynieria harnessu zastępuje czytanie wyniku automatycznymi kontrolami. Inżynieria kontekstu decyduje, co agent widzi; inżynieria harnessu decyduje, co go sprawdza i ogranicza. Böckeler zagnieżdża harness w inżynierii kontekstu (2 kwietnia 2026), a artykuł Wikipedii „Agent harness” umieszcza inżynierię kontekstu wewnątrz harnessu; żadne z tych zagnieżdżeń nie jest rozstrzygnięte. Dex Horthy argumentuje, że to za mało (22 lipca 2026): „no amount of harness engineering or loopsmaxxing can solve what is fundamentally a model-training issue.” Zobacz przewodnik o harnessie i stronę słownika o inżynierii harnessu.
Kto pisze kod, kto go sprawdza: Agent pisze; sprawdzają kontrole mechaniczne i agenci recenzujący.
Jak łączą się agenci kodujący, agentowe przepływy pracy i orkiestracja?
Dział zatytułowany „Jak łączą się agenci kodujący, agentowe przepływy pracy i orkiestracja?”Definicje Anthropic z 19 grudnia 2024 dają topologię: „Workflows are systems where LLMs and tools are orchestrated through predefined code paths.” Agenci „dynamically direct their own processes and tool usage”. Nasza analiza: orkiestracja to trzeci krok, czyli kilku agentów koordynowanych przez agenta prowadzącego albo przez skrypt.
Czym są agenci kodujący AI (AI coding agents)?
Dział zatytułowany „Czym są agenci kodujący AI (AI coding agents)?”To kategoria narzędzi bez autora nazwy. Przewodnik Willisona definiuje ją wprost: „What are coding agents? They’re agents that can both write and execute code.” (rozdział bez daty; przewodnik zaczęto 23 lutego 2026). Dostawcy zmieniają nazwę kategorii: changelog GitHuba z 1 kwietnia 2026 mówi „Copilot cloud agent (formerly known as Copilot coding agent)”. W porównaniu narzędzi na tej stronie Cursor, Claude Code i Codex to agenci kodujący, którzy wykonują tę samą pętlę: czytają bazę kodu, planują zmianę w wielu plikach, edytują je, uruchamiają kontrole projektu i poprawiają wynik, dopóki kontrole nie przejdą. Macierz funkcji pokazuje, że wszystkie trzy mają subagentów, worktree, skille, hooki, MCP, tryb headless, SDK i zaplanowane uruchomienia (komórki Claude Code i Codexa sprawdzono 26 września 2026, komórki Cursora 28 sierpnia 2026).
Zestawienie Willisona z tego samego przewodnika: „Vibe coding is more useful in its original definition - we need a term to describe unreviewed, prototype-quality LLM-generated code that distinguishes it from code that the author has brought up to a production ready standard.” Nasza analiza: agent kodujący to narzędzie, a vibe coding to jeden ze sposobów korzystania z niego. Zobacz stronę słownika o agentach kodujących AI.
Kto pisze kod, kto go sprawdza: Agent pisze; sprawdzają jego własne uruchomienia testów, potem człowiek.
Czym są agentowe przepływy pracy (agentic workflows)?
Dział zatytułowany „Czym są agentowe przepływy pracy (agentic workflows)?”Andrew Ng spopularyzował to wyrażenie w marcu 2024; żadne źródło nie pokazuje, że je wymyślił. Jego list z 20 marca 2024 mówi o „agent workflows”. List z 27 marca 2024 jako pierwszy używa tego wyrażenia i je definiuje: „Instead of having an LLM generate its final output directly, an agentic workflow prompts the LLM multiple times, giving it opportunities to build step by step to higher-quality output.” Pojęcie jest szersze niż tworzenie oprogramowania, a agenci kodujący to tylko jedno z jego zastosowań. Nie myl go z produktem GitHuba, GitHub Agentic Workflows, który jest w technical preview od 13 lutego 2026.
Żadne źródło nie zestawia go z vibe codingiem, a listy Nga są starsze niż ten termin. Nasza analiza: agentowy przepływ pracy przenosi kontrolę do wnętrza pętli (refleksja, testy), a vibe coding usuwa kontrolę człowieka po pętli. Zobacz stronę słownika o agentowych przepływach pracy.
Kto pisze kod, kto go sprawdza: Model iteruje; sprawdzają refleksja, testy albo agent krytyk.
Czym jest orkiestracja agentów (agent orchestration, multi-agent development)?
Dział zatytułowany „Czym jest orkiestracja agentów (agent orchestration, multi-agent development)?”„Orkiestracja” to stare słowo z dziedziny systemów i nie ustalono jednego autora jej agentowego sensu. List Nga z 17 kwietnia 2024 wymienia współpracę wielu agentów jako wzorzec projektowy. Wpis Anthropic o systemie badawczym z 13 czerwca 2025 opisuje „an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel” i ostrzega, że „most coding tasks involve fewer truly parallelizable tasks than research”. Według macierzy funkcji na tej stronie Claude Code, Codex i Cursor mają subagentów (sprawdzono 26 września 2026 dla Claude Code i Codexa, 28 sierpnia 2026 dla Cursora).
Autor jednego z orkiestratorów wiąże go z vibe codingiem wprost. Steve Yegge o Gas Town w tekście Welcome to Gas Town (1 stycznia 2026): „It’s also 100% vibe coded. I’ve never seen the code, and I never care to, which might give you pause.” Nasza analiza: orkiestracja mnoży dyscyplinę przeglądu, jaką ma człowiek. Z sędzią, testami i bramką przed merge to fabryka oprogramowania; bez nich to vibe coding w skali floty. Orkiestracja nie jest przeciwieństwem vibe codingu, jest nim weryfikacja. Zobacz wzorce orkiestracji i stronę słownika o orkiestracji agentów.
Kto pisze kod, kto go sprawdza: Agenci wykonawczy piszą; sprawdza agent sędzia i kontrole deterministyczne, na końcu człowiek przy merge.
Dlaczego inżynieria AI to inna praca niż wszystko powyżej?
Dział zatytułowany „Dlaczego inżynieria AI to inna praca niż wszystko powyżej?”Pułapka tego słownictwa to nazwa, która brzmi jak reszta, a znaczy co innego.
Czym jest inżynieria AI (AI engineering)?
Dział zatytułowany „Czym jest inżynieria AI (AI engineering)?”swyx (Shawn Wang) spopularyzował tę rolę w tekście „The Rise of the AI Engineer” 30 czerwca 2023: „The emerging (and least cringe) version of this role seems to be: AI Engineer.” Nie on to zapoczątkował: „I am calling attention to this trend rather than starting it.” Książka Chip Huyen, wydana w O’Reilly, z pierwszym wydaniem 4 grudnia 2024, definiuje tę dziedzinę jako „the process of building applications with readily available foundation models”. Inżynieria AI to więc praca o tym, co się buduje: AI wewnątrz produktu.
Pułapką jest sens luźny. Klaassen z Every użył „AI engineering” 18 sierpnia 2025 w znaczeniu kodowania wspomaganego AI: „Typical AI engineering is about short-term gains. You prompt, it codes, you ship.” Nasza analiza, bo żadne źródło nie porównuje obu pojęć: inżynieria AI opisuje to, co się buduje, a inżynieria agentowa opisuje, jak powstaje dowolne oprogramowanie z agentami. Nakładają się tylko wtedy, gdy AI engineer używa agentów kodujących, a vibe coder może zbudować aplikację bez żadnego AI w środku. Zobacz stronę słownika o inżynierii AI.
Kto pisze kod, kto go sprawdza: Piszą inżynierowie; produkt sprawdzają potoki ewaluacji.
Na którym szczeblu drabiny autonomii jest vibe coding?
Dział zatytułowany „Na którym szczeblu drabiny autonomii jest vibe coding?”Drabina Dana Shapiro tego nie mówi. Jego wpis z 23 stycznia 2026 ani razu nie używa słowa „vibe”, omówienie Simona Willisona z 28 stycznia też nie, a strona Karpathy’ego o Sequoia Ascent nie wspomina o poziomach ani o ciemnej fabryce (przeszukanie pełnego tekstu 10 października 2026). Poniższe umieszczenie to nasza analiza, zbudowana z najbliższych źródeł pierwotnych.
| Źródło | Co mówi | Data |
|---|---|---|
| Karpathy, oryginalny wpis | „I ‘Accept All’ always, I don’t read the diffs anymore.” Warunek zatrzymania: „it mostly works” | 2 lut 2025 |
| Simon Willison o zespole z poziomu 5 | Zespół „implementing what Dan Shapiro called the Dark Factory level of AI adoption, where no human even looks at the code the coding agents are producing” (źródło) | 7 lut 2026 |
| StrongDM, zespół wskazany przez Willisona | „Code must not be reviewed by humans”; walidacja opiera się na scenariuszach „often stored outside the codebase (similar to a ‘holdout’ set in model training)” oraz „We use the term satisfaction to quantify this validation” (źródło) | 6 lut 2026 |
| Simon Willison | „as the coding agents get more reliable, I’m not reviewing every line of code that they write anymore, even for my production level stuff.” (źródło) | 6 maja 2026 |
Nasza analiza: vibe coding i poziom 5 mają jedną wspólną cechę, czyli nikt nie czyta diffa. Różni je to, co zastępuje czytelnika. W vibe codingu nic go nie zastępuje; człowiek obserwuje zachowanie, aż „it mostly works”. Na poziomie 5 zastępuje go warstwa weryfikacji sprawdzalna maszynowo: scenariusze wstrzymane poza kodem (holdout) i wynik zadowolenia (satisfaction). Vibe coding to przepływ pracy z poziomu 5 bez wyroczni weryfikacyjnej. Uwaga Willisona z 2026 roku, że oba podejścia „have started to blur”, to ta sama teza widziana z drugiej strony: granica nie przebiega tam, gdzie ktoś czyta, tylko tam, gdzie widać, co zastąpiło czytanie.
Dwie z 21 nazw mapują się na drabinę wprost. Programowanie w parze z AI to szczebel poziomu 2, a inżynieria agentowa to dyscyplina, która zdobywa każdy stopień powyżej (nasza analiza). Cel drabiny, fabryka oprogramowania, to poziom 5, opisany w Poziomie 5: prowadzisz fabrykę oprogramowania i na stronie słownika o fabryce oprogramowania.
Prompty do skopiowania, które umieszczą twoją pracę na tej mapie
Dział zatytułowany „Prompty do skopiowania, które umieszczą twoją pracę na tej mapie”Uruchom je na repozytorium, z którego wdrażasz. Każdy działa bez zmian w Claude Code, Codeksie i Cursorze, a każdy kończy się raportem, który weryfikujesz, otwierając trzy z cytowanych plików lub pull requestów.
Co psuje się, gdy zespół zmienia nazwę vibe codingu?
Dział zatytułowany „Co psuje się, gdy zespół zmienia nazwę vibe codingu?”To nasza analiza wzorców porażek, a nie zmierzone odsetki. Każdy ma krok naprawczy.
- Przemianowanie vibe codingu na inżynierię agentową bez dodania kontroli. Nowa nazwa zmienia to, jak praca się nazywa, a nie to, co dzieje się z diffem. Słownik OpenSSF (ostatnia zmiana 20 marca 2026) wyznacza granicę przeglądem: „If there is human review of the AI-generated code, then it is not vibe coding.” Zespół, który przyjmuje każdą zmianę agenta bez czytania, robi vibe coding, cokolwiek mówi jego polityka. Opublikowany transkrypt Karpathy’ego jest w tej sprawie stanowczy: „You are not allowed to introduce vulnerabilities because of vibe coding.” Naprawa: napisz kontrolę, która padnie, gdy kod jest błędny, zanim zmienisz nazwę pętli.
- Przyjęcie rytuałów cyklu życia bez jego weryfikacji. AWS opisuje porażkę, której mają zapobiegać jego rytuały: „Developers, excited by automation, often drift into passive execution—allowing AI to ‘decide everything.’” Bolts i Units of Work to słownictwo; sesje Mob Elaboration i Mob Construction to miejsca, w których sugestii nie przyjmuje się na ślepo. To samo dotyczy diagramu AI SDLC: etapy bez bramek to etykiety. Naprawa: nazwij bramkę i osobę, która za nią odpowiada, dla każdego etapu.
- Traktowanie granicy jako stałej. 6 maja 2026 Willison napisał: „Weirdly though, those things have started to blur for me already, which is quite upsetting.” oraz „There’s an element of the normalization of deviance here”. Zespół, który co miesiąc czyta mniej linii i nie dokłada kontroli, dryfuje w stronę vibe codingu, zachowując słownictwo. Naprawa: zapisz dla każdej pętli, co zastąpiło czytelnika: test, walidator albo scenariusz holdout.
- Powtarzanie twierdzenia o autorstwie, któremu przeczą daty. Zechner i Steinberger użyli „agentic engineering” przed poparciem Karpathy’ego. Willison zaproponował „vibe engineering” po wcześniejszych użyciach. Goyal użył „context engineering” przed Lütkem i Karpathym. Hashimoto zastrzega, że nie wymyślił „harness engineering”, a swyx o inżynierii AI zastrzega: „I am calling attention to this trend rather than starting it”. Naprawa: pisz „spopularyzował”, „poparł” albo „użył” i linkuj datowane źródło.
- Czytanie „inżynierii AI” jako inżynierii z AI. Rola i książka oznaczają budowanie produktów na modelach bazowych. Polityka, która mówi „inżynieria AI”, musi napisać, o który sens chodzi, bo dwa kręgi czytelników, do których się zwraca, to różni ludzie.
Dokąd dalej ze słownictwem wokół vibe codingu
Dział zatytułowany „Dokąd dalej ze słownictwem wokół vibe codingu”Najczęstsze pytania
Czym różni się vibe coding od inżynierii agentowej?
Vibe coding to przyjmowanie kodu napisanego przez AI bez czytania go; termin wprowadził Andrej Karpathy 2 lutego 2025. Inżynieria agentowa korzysta z podobnych agentów, ale pod poprzeczką jakości: 4 lutego 2026 Karpathy nazwał ją swoją obecnie ulubioną nazwą dla czerpania korzyści z agentów „without any compromise on the quality of the software”. Różnica leży w tym, co sprawdza kod, a nie w tym, które narzędzie go pisze.
Kto wymyślił vibe coding i kiedy?
Andrej Karpathy wprowadził ten termin we wpisie na X z znacznikiem czasu 2 lutego 2025. Własny tekst Simona Willisona podaje datę 6 lutego, ale wpis i uwaga etymologiczna Merriam-Webster mówią o 2 lutego. Collins Dictionary uznał vibe coding za Słowo Roku 2025.
Kto wymyślił inżynierię agentową?
Nie ustalono jednego autora nazwy. Mario Zechner użył tego wyrażenia 2 czerwca 2025, a Peter Steinberger umieścił je w tytule wpisu 14 października 2025. Andrej Karpathy poparł je jako „personally my current favorite” 4 lutego 2026, a 23 lutego 2026 Simon Willison napisał, że nazwa „coming out on top”.
Czy inżynieria AI to to samo co inżynieria agentowa?
Nie. swyx spopularyzował rolę AI engineera w czerwcu 2023, a Chip Huyen definiuje inżynierię AI jako budowanie aplikacji na modelach bazowych. Inżynieria agentowa to budowanie dowolnego oprogramowania z agentami kodującymi. Oba pojęcia nakładają się tylko wtedy, gdy AI engineer używa agentów kodujących. To rozróżnienie jest analizą tej strony, bo żadne źródło nie porównuje ich wprost.
Na którym szczeblu drabiny autonomii jest vibe coding?
Drabina Dana Shapiro go nie umieszcza, a jego wpis nie używa tego słowa. Nasza analiza: vibe coding ma wspólną cechę z poziomem 5, czyli nikt nie czyta diffa, ale nic nie zastępuje czytelnika, podczas gdy na poziomie 5 robi to warstwa weryfikacji sprawdzalna maszynowo.