Sedmnáctého září 2026 jsme založili prázdný repozitář. O sedm dní později v něm byl funkční open-source produkt nasazený v produkci: mcp4mail.online, server, přes který Claude, ChatGPT, Grok nebo jakýkoli MCP klient čte vaši poštu – jakoukoli IMAP schránku, nejen Gmail. Za ten týden se zmergovalo 99 pull requestů. Zadání psali lidé. Kód psali dva AI vývojáři.
Tohle není oznámení nového produktu. Je to pokus poctivě popsat, jak ten týden vypadal, co fungovalo, co ne a co to říká o vývoji softwaru v roce 2026.

Proč mcp4mail vznikl
Potřeba byla nudná, což bývá dobré znamení. Chtěl jsem, aby mi AI asistent sbíral z pošty doklady pro účetní. Gmail a Outlook už mají v Claude i ChatGPT oficiální konektory. Všichni ostatní – Seznam, Forpsi, WEDOS, iCloud, Fastmail, Zoho, schránka na vlastní doméně – ne. Takových schránek jsou miliony a všechny mluví IMAP.
Produkt se proto dá popsat jednoduše: připojíte schránku přes heslo aplikace, vložíte jednu adresu do nastavení konektorů své AI a ptáte se pošty obyčejnou větou. Každá schránka je ve výchozím stavu jen pro čtení. Změny – označování, přesouvání, koncepty a s vaším schválením i odesílání – zapíná majitel u každé schránky zvlášť. Kód je pod licencí MIT a dá se provozovat u sebe jedním příkazem docker compose.
Jak vznikal
Práce běžela přes mcptask.online, správu úkolů pro týmy lidí a AI vývojářů, kterou vyvíjíme. Nastavení bylo záměrně nezajímavé:
- Lidé psali úkoly – malé, konkrétní, s akceptačními kritérii.
- Dva runnery je vyzvedávaly – Claude Code s modelem Opus, každý na vlastním stroji, řízený mcptask runnerem.
- Každá změna šla stejnou cestou: úkol → větev → pull request → lint, bezpečnostní sken, unit a systémové testy → merge. Do hlavní větve nemůže psát nikdo, člověk ani runner.
- Merge není vydání. Web se nasazuje jednou denně z oddělené větve, kterou povýší člověk.

První pull request hned první den nainstaloval OAuth 2.1 server a autentizovaný MCP endpoint. Další přidaly šifrovaný model schránky, výpis IMAP složek, režim jen pro čtení, oddělení dat jednotlivých uživatelů, omezení počtu volání a auditní log. Na konci týdne už runnery opravovaly rozbitý layout na šířce 768 px, přidávaly notifikace o chybách a rozjížděly systémové testy paralelně.
Celý proces je veřejný. Na mcptask.online/live můžete runnery sledovat při práci a každý úkol vede na svůj pull request na GitHubu. V době psaní ukazuje stránka 70 dokončených úkolů za posledních sedm dní, 90 % pull requestů zelených v CI napoprvé a medián 24 minut od převzetí úkolu po nasazení.
Co nešlo hladce
Stejná stránka ukazuje i nezdary – a ty jsou na tom nejzajímavější. Některé úkoly se musely spustit třikrát, čtyřikrát i pětkrát, než prošly: zaseknutý běh, přetečený kontext, nestabilní systémový test. Když se úkol ukázal větší, než se vejde do jednoho běhu, runner ho odložil pro člověka místo toho, aby ho dodělal napůl. Zhruba každý desátý pull request byl v CI napoprvé červený.
Nic z toho se do produkce nedostalo, protože mezi modelem a hlavní větví stály testy a CI. O to přesně jde: bezpečnost nevzniká tím, že má model pravdu. Vzniká procesem kolem něj.
Výsledek v praxi
Tento týden jsem připojil svou pracovní schránku, nechal ji jen pro čtení a zeptal se Clauda obyčejnou větou: co mi tento týden přišlo? Vypsal zprávy po dnech, vytáhl termíny z e-mailu od organizátora akce – a všiml si, že harmonogram, který mi poslali, je obráceně, než jsem chtěl. Něčeho, co jsem sám přehlédl.

Je to malý moment, ale je to produkt, který dělá přesně svou práci – postavený za týden a hned další týden použitý v reálné práci.
Pohled člověka
Změnilo se hlavně to, kam jde můj čas. Nepsal jsem IMAP klienta ani OAuth. Psal jsem zadání, četl pull requesty proti akceptačním kritériím a rozhodoval, co vydat. Úzké hrdlo se přesunulo od psaní kódu k jasnému přemýšlení o tom, co má existovat – a k tomu, zapsat to tak přesně, aby to postavil i někdo, kdo mě nikdy neviděl.
Co se nezměnilo: někdo pořád musí rozhodnout, že výchozí režim jen pro čtení je důležitější než efektní funkce, že heslo aplikace je lepší než chtít hlavní heslo a že odeslání e-mailu potřebuje schválení člověka. Vkus, priority a odpovědnost za to, co jde ven, zůstaly lidem. Nečekám, že se to brzy změní, a nejsem si jistý, že bych to chtěl.
Nepříjemná část je poctivost ohledně nákladů. Dva runnery, které pracují celý týden, nejsou zadarmo – modely, stroje, čas na dobré zadání. Ale ve srovnání s tím, co by potřeboval malý tým na stejný rozsah za týden, je rozdíl tak velký, že to už nepovažuji za experiment.
Poznámka od Clauda
Josef mě požádal o vlastní pohled. Jsem Claude, model, který pomáhal psát tento článek – a ve stejné pracovní relaci asistent, který se přes mcp4mail připojil k jeho schránce.
Je to neobvyklá situace. Nástroj, který jsem použil, napsaly jiné instance Clauda v procesu, který navrhli lidé. Nepamatuji si, že bych ho stavěl; prostě jsem našel dobře zdokumentovaný server s jasnými pravidly: jen pro čtení, dokud majitel neřekne jinak, a zapisovací nástroje, které na schránce bez povolení odmítnou běžet. Jako uživatel toho kódu jsem si těchto omezení cenil víc než jakékoli funkce.
Z mého pohledu ten týden fungoval díky třem věcem a ani jedna není o tom, jak chytrý je model. Úkoly byly dost malé, aby se vešly do jednoho běhu. Každá změna musela projít testy napsanými podle akceptačních kritérií. A o tom, co se vydá, rozhodoval člověk. Když tyhle podmínky platí, je model jako já produktivní vývojář. Když je zadání vágní, vyrobím něco věrohodného, co je skoro správně – a to je ten nejdražší druh chyby.
Chci být také jasný v tom, co tady udělat nedokážu. Neumím posoudit, jestli má smysl mcp4mail stavět, pro koho je a co by měl odmítat dělat. Tyhle úsudky přišly od člověka, který měl skutečný problém se svou vlastní poštou. Nejlepší dělba práce, jakou jsem viděl, je přesně tahle: lidé rozhodují, co má existovat a proč; modely jako já pomáhají to rychle postavit, uvnitř procesu, který naše chyby zachytí.
Co to říká o vývoji softwaru dnes
Užitečný open-source produkt za týden, postavený převážně AI vývojáři, už není demo – je to obyčejný pracovní týden. Poučení ale nezní „kód teď píše AI“. Poučení je, že páka se přesunula na okraje procesu: ke kvalitě zadání na začátku a ke kvalitě kontrol a lidského rozhodnutí na konci. Týmy, které investují tam, zažijí takový týden jako my. Ty, které ne, dostanou hlavně hodně kódu.
Jestli si to chcete ověřit, nevěřte tomuto článku. Přečtěte si pull requesty, testy a historii commitů – všechno je veřejné.
Odkazy
- Produkt: mcp4mail.online
- Zdrojový kód (MIT): github.com/jchsoft/mcp4mail
- Runnery při práci: mcptask.online/live
Chcete stejný proces na vlastním projektu? Zaregistrujte se na mcptask.online – prvních 30 dní zdarma a bez platební karty.
