Miért nem elég a Chat a projekttervezéshez?

Ha most azt gondolod, hogy ez csak egy újabb "AI mindent megold" eszköz, nem, nem az. És pont ez a lényeg.

A helyzet az, hogy a legtöbbünk még mindig úgy tervez projektet, ahogy öt éve: írsz egy gyors jegyzetet, megnyitod a Notion-t, vagy elkezdesz írni egy Slack threadet, ami aztán szépen elmerül a csevegéstörténetben. Aztán fogod ezt a félig kész sugalmazást, és átadod az AI ügynöknek, hátha valami értelmes kijön belőle.

A probléma nem az, hogy az AI ügynkök rosszul kódolnak. A probléma az, hogy strukturált információt várnak el tőlünk, amit mi ritkán adunk meg – és amikor ők maguk töltik ki ezeket a hiányosságokat, nem marad nyoma annak, hogy MIÉRT hoztak egy bizonyos döntést.

Az a dokumentum, ami visszanéz rád

Itt jön képbe az inplan. A lényege egyszerű: egy Markdown szerkesztő, amit kifejezetten ember és AI kódoló ügynök közös tervezésére terveztek. Olyan, mint egy közös digitális tábla, ahol mindkét fél dolgozhat ugyanazon a tervdokumentumon.

De ami igazán érdekes, az nem maga a szerkesztő – hanem a kommentrendszer. Bármelyik mondatot kijelölheted, és indíthatsz ott egy beszélgetést. Megkérdezheted, miért javasolta az ügynök azt az architektúrát. Rákérdezhetsz egy feltételezésre. Döntést hozol. És mindez a sorhoz van kötve, tehát később bármikor visszakeresheted.

Ez az úgynevezett "környezeti régészet" problémáját kezeli, amiről kevesen beszélnek. Gondolj csak bele: három hónap múlva az ügynök hozott egy döntést valahol. De miért? Hol a dokumentáció? Az inplan-ban ez nyomon követhető.

Ellenőrzés, mielőtt változtatsz

Van egy minta, amit túl gyakran látunk: otthagyod az AI ügynököt dolgozni, visszajössz, és a terv csendben átalakult. Lehet, hogy jobb lett. Lehet, hogy valami fontos elveszett. Nehéz megmondani.

Az inplan megfordítja ezt. Amikor az ügynök módosítani akarja a tervet, nem csendben írja felül a dokumentumot – hanem generál egy diff-et, amit te ellenőrzöl és alkalmazol. Pontosan látod, mi változott. Jóváhagyhatod, elutasíthatod, vagy tovább finomíthatsz, mielőtt bármi rögzülne.

Ez a "humán a hurokban" megközelítés fontosabb, mint amennyire hangzik. Az ügynökből végrehajtóból valódi collaborator lesz – némi papírmunkával.

Hogyan próbáld ki?

A tool Claude Code skillként telepíthető (Codex és mások támogatása a tervek között). Egy egyszerű "plan X" prompt megnyitja a szerkesztőt, és már indulhatsz is. AGPL-3.0 open source, és teljesen local fut npm-en keresztül.

Ha csapatban dolgoztok, van hosted opció az inplan.ai-n. A demó sem igényel fiókot, ami meglepően jó pont egy SaaS terméktől.

Hol még döcög a szekér

Egyik eszköz sem tökéletes. Az Electron asztali appként fut – működik, de nehezebb, mint egy webes szerkesztő. A diff mechanizmus sor-alapú, ami durvának érződhet finomhangolt változtatásoknál. És a mentális modell egyetlen tervdokumentum köré épül. Ha több egymással összefüggő specifikációt kezelsz, más eszközökhöz is nyúlnod kell majd.

A csapat transzparens ezekkel a korlátokkal, ami bíztató. Több-dokumentumos támogatás és gazdagabb ügynök-interakció a roadmapen van.

Miért számít ez a "vibe coding" korban?

A "vibe coding" – amikor az AI-ra bízod az implementációt, és te irányítod a víziót – egyre népszerűbb. De van egy piszkos titka: ha nincs világos irányítás, akkor az eredményt azokhoz a szándékokhoz méred vissza, amiket soha nem fogalmaztál meg rendesen.

Az inplan és hasonló eszközök egy másik jövőt vetítenek előre. Nem csak "gyorsabban kódolunk", hanem "világosabban gondolkodunk". A tervezési fázis valódi együttműködéssé válik az AI partnereddel, ami olyan dokumentumokat eredményez, amik a mostani feladathoz és a jövő karbantartóihoz (köztük a jövőbeli magadhoz) is szólnak.

Hogy az inplan lesz-e a te workflow-d, az a saját toleranciádtól függ az Electron appokkal és az egy-dokumentumos modellel szemben. De az alapötlet – strukturált, kommentelhető, ember által ellenőrzött AI együttműködés – azt mutatja, hogyan fogunk dolgozni a kódoló ügynökökkel, ahogy azok egyre képesebbé válnak.

A kérdés nem az, hogy az AI írja-e majd a kódunkat. A kérdés az, hogy építünk-e elegendő alapot ahhoz, hogy az a kód érthető maradjon.

Kipróbálnád? npm i -g inplan