Názory k článku
Rozhorel sa boj o moderné IDE: agentické vývojové prostredia nastupujú

Prosím, vzbuďte mě, až doiterují k pluginu pro [neo]vim ;)

Pluginy uz existuju. https://www.google.com/search?q=neovim+ai+plugins

Já vím, ale pořád to nějak není ono. Copilot dobrý, ale jinak je ta integrace taková nepohodlná, a to jsem s tím strávil víc času, než bych si představoval.

Já mám rozchozenej joe s grok-code-fast-1 ;-) Takže BUDÍČÉÉÉK

Škoda, že tyhle nástroje člověka okradou o tu zábavnou část - psaní kódu a možnost se něco naučit a procvičit mozek.

Naopak mu nechají tu nudnou pasivní část - review cizího kódu.

12. 1. 2026, 09:21 editováno autorem komentáře

Ta radost z psani kodu v cistem C se neda nicim nahradit. Kdyz koukam na komunitu kolem arduino mam pocit ze nejsem sam.

V procviceni mozku vam nic nebrani. Muzete si procvicit mozek treba spravnou formualci pozadavku a zadani. Spravna analyza a popis problemu je zaklad uspechu :)

To bezpochyby. Ovšem je třeba si uvědomit, že velká část vývojářů kvůli tomuhle vyvíjet nešla. Není to dobře ani špatně, ale řekl bych, že kočí se u většiny obvykle taky nepřeškolili na strojvůdce parních lokomotiv a obvykle nejspíš ani na řidiče ne.

Ámen. Strašně mě to štve. Hlavně nejhorší je, že musím dělat review AI co mi posílají ostatní lidi. Začíná to být peklo, protože i junior udělá konstrukce, kterým vůbec nerozumí, nedokáže je vysvětlit a musím pak luštit proč to vůbec funguje a proč je to tak uděláno.

"JetBrains na poli agentických nástrojov zatiaľ zaostáva"
Nezdá se mi. Junie je naprostá bomba, funguje skvěle, téměř nedělá chyby a chat v ide je taky super. Je to opravdu hóóódně muziky s top modely za nízkou cenu.

Prosim kde je ten vyvoj ? To ze teraz vsetci idu podporovat buzzword AI cez volania rest/json api nejakeho ai modelu nie je zrovna skod v IDE. Mame tu JetBrains IDEcka postavene na Jave (tym je povedane vsetko). MS ktory extremne pomaly chape ze ich Visual Studio od prechodu k C# hybridu v ktorom to maju zlatane, ze to nebola dobra volba (je to cele pomale, zabugvane a vobec pri vacsom projekte je to utrpenie ale bohuzial moc alternativ nie je). No a potom tu mame Electronovu mladez ktora je nadsena z editoru napisanom v javascripte. Ehm.. Nejake rychle nativne prostredie, so slusnou podporov jazykov, pluginov a aj AI clovek vlastne ani nenajde. A nie patlat sa mesiac s nastavenim Vim "OS" alebo Emacs "OS" sa mi uz viac nechce. To je asi ako skvele mutli Eclipse prostredie na vsetko. Oblubena to platforma rozny entreprise korporatnych rieseni. A to uz nehovorim o db nastrojoch postavenych nad javou. Lebo mat tabulku s milionom zaznamvo je asi pri db vynimka, preto je idealne postavit db gui tool nad javou ktora vobec nema problem s pametou. Alebo potom ta zaplava bodland/delphi db gui kde sa to memory leakmi len tak prasi (o db editoroch stavenych nad Electronom sa ani radsej nebudem zmienovat, to je neschopne otvorit vacsiu tabulku a naimporotvat par tisic zaznamov z csv suboru).

"Lebo mat tabulku s milionom zaznamvo je asi pri db vynimka, preto je idealne postavit db gui tool nad javou ktora vobec nema problem s pametou."

A ten problém je jako kde?

Jste si v podstatě vystřílel úplně všechno. Škoda, že se za vámi někdo za posledních 30 let nepřišel poradit, v čem to má napsat a co je vlastně důležité... :)

Jinak jsou i nové editory (nebo IDE, ta hranice se trochu stírá), co jsou víc optimalizované, napadá mě teď z hlavy třeba Zed. Ale jestli vám bude vyhovovat i v jeho jiných aspektech je samozřejmě další věc.

U těch zmíněných databází zas nevím, jestli na obecný nástroj typu IDE/editor nemáte přehnané nároky. Pokud budete standardně vyvíjet aplikace, ladit nějaké uložené procedury atp. Stačí vám nějaký inteligentní paging v tom UI, abyste viděl, co se děje. A tohle funguje to i s velkými tabulkami/data­bázemi. Nedá se předpokládat, že pokud si budu chtít natáhnout statisíce řádků do nějakého editovatelného datagridu nebo i kontinuálního obrovského result setu, tak to nezabere hodně paměti, a to vcelku nezávisle na používaném jazyce.
Otázkou pak je, jak často s tímhle opravdu potřebuju manipulovat. Za sebe - velice zřídka. Když potřebuju importovat velké datasety z něčeho jako XML nebo CSV, tak buď použiju specifický nástroj k dané DBMS, nebo si prostě napíšu malý program (v podstatě na pár řádků), kde můžu navíc dělat s daty libovolné úpravy, ovládat commitování dle libosti atp.
U editování velkých SQL dumpů zas použiju vhodné nástroje na nějaké proudové zpracování (sed třeba, přičemž regex si odladím na kousku bokem) - zas nepřijde mi úplně divné, že obecný editor nebude úplně happy, pokud v něm otevřu 30GB dump, bude si řešit zvýraznění synaxe, undo atp.

Pretoze za poslednych 20-30 rokov v IDE v zasade nejaky velky vyvoj nebol, ale to je uhol pohladu. So zmenenym pristupom prislo Delphi s ich RAD sposobom vyvoju. Nebudem hodnotit ci to bolo pozitivum alebo negativum. Dnes sa vsetko patla cez rozne znackovacie textove formaty alebo rovno sa pouzivaju webove technologie na vyvoj a podla toho vyzeraju aj IDE.

Zed som skusal. Prve verzie boli dost nestabilne aj ked je to postavene na Ruste co ma byt prave zaklinadlo stability a bezpecnosti. Dnes uz asi bezi lepsie ale, na pluginy pouzivaju webassembly ?!@? Mam viac menej navitny editor aby som v nom pouzival pluginy postavene povodne pre web/browser sandbox ? Nehovoriac ze dnes prakticky kazdy editor ktory podporuje LSP vecinou na pozadi aj tak spusti node s nejakym js kodom a potom je uz skoro jedno na com je postavene gui ked to cele stoji na zahltenom LS.

SQL je tak isto programovaci jazky, zvlast v procedurach. Nehovorim uplne o obecnom ide, ale ide pre databazy. Casto krat nefunguje poriadne ani ten paging. Ak je nastroj spusteny dlhsie , typicky java based ide, tak to zacne zrat pamet a nemysilm tym ze mam result s milionom zaznamov ale nie je vynimocne pracovat s db kde su tabulky jednotkami az stovkami tisic zaznamov a po case zacne ide dochadazat pamet alebo sviznost. A otazka je preco by IDE nemalo byt schopne pracovat z 10-20GB dumpom alebo logom ? Mame dnes vykonne procesory, GB pameti a toto je problem. Ved si moze zistit velkost suboru a vypnut formatovanie, zvyraznie syntaxe a poodbne. VScode sa o nieco aj snazi ale vecisnou to nezafunguje.

Je tu ješně někdo, kdo si užívá psaní kódu bez těchto agentů?

V práci to musíme používat, prej to zvyšuje efektivitu, i když já mám pocit, že to jen bezdůvodně zvyšuje počet řádků a vzniká titul "fixing AI generated code" :) Ale pro vlastní věci to používat nechci.

Ja to mám naopak. V práci to používať nesmieme, ale keď si chcem zbúchať niečo pre seba doma, tak používam AI z lenivosti.

E: Ja si užívam programovanie bez AI, keď ide o algoritmizáciu a také to old school programovanie. Našťastie ešte aj také je potrebné. Lepenie hotového kódu si neužívam :)

12. 1. 2026, 12:28 editováno autorem komentáře

Spousta lidí. Teď jsem třeba byl v jedné poměrně velké agentuře dělající zakázkový vývoj a ti jasně říkali, že není důvod AI nepoužívat ale AI zatím obecně opravdu není ve stavu, aby si mohli dovolit její výstup předat klientovi jako výsledek své vlastní práce. A zkušenosti s ní mají obecně smíšené.

Kdyby mi někdo říkal, co musím a nemusím v tomto smyslu používat, to je jako by mi nařizoval jakou si mám vzít lopatu. Buď nechť přide s konkrétními daty nebo asi moc nemá smysl abych pro něj dál pracoval. Protože přesně tak: jestli lze něco na kódu generovaném AI (a to i kvalitními modely) velmi dobře vysledovat, je to zcela typicky výrazná ukecanost a mizerná spravovatelnost.

Ano. Baví mě ta "1st gen" LLM funkcionalita, kdy to funguje jen jako lepší našeptávač rozepsaného řádku podle kontextu, protože to většinou navrhne něco co bych psala tak jako tak a ušetří mi to psaní. To používám i v Jetbrains mimo práci. Ale hádat se s agentem a dělat mu code review mě fakt nebaví.

Zajímavé - já strávím nejvíc času přemýšlením, takže to datlování mě nikdy nezdržovalo a napsat for cyklus prostě umím z hlavy no :)

Tak neříkám že to nějak zvlášť zdržuje, ale i normální autocomplete je příjemný, když třeba doplní jméno metody, a tady jde ten našeptávač ještě dál a doplní i parametry.

Jeste je tu skupina lidi co se zivi necim jinym nez programovanim, ale programovani k praci potrebuji. Treba ja zpracovavam spousty ruznych namerenych dat, vyvijim merici systemy, a uzivam si jednak UI naseptavace, jednak UI agenty, protoze mi to urychluje praci s kodem a je tak vic casu na tu zajimavou cast.

Přesně! Dělám výpočetní chemii. Napsat si logiku, co mi dělá samotný výpočet, není problém. Napsat wrappery / pipeliny, co si v CLI předávají vstupy a výstupy těch výpočtů a zpracovávají data, není problém. Ale jakmile mám psát pro tohle nějaký (web)GUI, bo lidé od nás ne vždycky preferují CLI? Strašný oser. S LLM to mám rychle hotový, odškrtnu si bod a všichni jsou spokojení. To samý třeba generování grafů s výsledky => pomocí LLM si vyzvracím šablonu a dál tuním ručně.

Pokud někdo nemá kódování jako primární obživu, odemykají mu LLM další možnosti, jak efektivně pracovat a rozšířit svůj projekt, aniž by na tom spálil tunu času navíc (na úkor primární práce), nebo musel shánět další lidi. V tomhle mi dost připomínají nástup GUI / desktopu. Desktop taky plně nenahradil CLI, ale doplnil ho a rozšířil možnosti počítačů i pro další lidi.

No, vzhledem k tomu, ze 99% kodu pisu bud v M$ Visual studio 6.0 (pod Win32) a nebo v MCEdit +make (Linux), tak asi ja? ;-)

Vy ste člen nejakej retro komunity? Pri všetkej averzii k microsoftu, VS 6.0 bolo ozaj dobré + k tomu bola obsiahla dokumentácia (MSDN?) na pár cd-čkach.

12. 1. 2026, 16:15 editováno autorem komentáře

To nie je problém, Rovnaký projekt môžeš mať otvorený vo VS aj v Cursore, v cursore robiť len plánovanie a AI generovanie/e­ditáciu kódu a vo VS kompilovať/de­bugovať, ja to robím tak.

bez agentu prosim. ale mozna to je nejaka diagnoza ,protoze mi vadi jakejkoliv autocorrect nebo prediktivni klaviatury a spol.

> Je tu ješně někdo, kdo si užívá psaní kódu bez těchto agentů?

Jo jo, je ;) Zalezi co delam. Na neco je to dobre, na neco ne.

> V práci to musíme používat, prej to zvyšuje efektivitu, i když já mám pocit, že to jen bezdůvodně zvyšuje počet řádků a vzniká titul "fixing AI generated code" :) Ale pro vlastní věci to používat nechci.

Vcerejsi firemni prezentace: "All engineers will embrace AI-assisted coding and transition into an AI-first approach to work. You will write code manually only as a fallback." Dokonce vcera pristalo PR od CEO (neni programator), ktere optimalizuje SQL dotazy (DISTINCT -> GROUP BY) + vygenerovany pamflet jako PR description proc. Rejected. Zacina se tlacit na adopci, zacina se sledovat kdo co a jak udelal (abacus, lide se predhani v tom kolik $ utratili, CTO to sleduje a podporuje). Az nezdrave se to vsude cpe. PR description se nedaji cist (vygenerovane, dlouhe, misto par radku k veci). Chce to cas, musi se najit spravny balanc, lidi se to musi naucit pouzivat, apod. Ale tenhle push za kazdou cenu je mi cizi.

Už ta věta: "All engineers will embrace AI-assisted coding and transition into an AI-first approach to work." Už ta představa, že všichni rozhodně ocení to, pro co já se rozhodnu, že je to skvělé (nebo to potřebuju prodat). Ježkovy voči...