Запит від команди
Робота починається з команди: операційний відділ і продажі приносять те, з чим стикаються клієнти, продукт вирішує, що це означає, і результат фіксується як задача — призначена розробнику або агенту.
Проблема
Агенти зробили написання коду швидким. Рішення про те, що будувати, залишилось ручним.
ШІ-агенти програмування роблять написання коду швидким. Вони не полегшують рішення про те, що робити, які правила проєкту застосовуються, чи як фіксується результат. Контекст губиться між сесіями чату, розрізненою історією терміналу й нотатками задач, що не мають постійного місця. Сьогоднішнє вузьке місце — не генерація коду, а контроль контексту.
Як це працює
Один цикл: запит від команди, ціль, затверджений план, окреслена задача, сесія агента, зафіксований результат.
Розробка, керована специфікацією — це порядок, який задає цей цикл: спочатку пишеться й затверджується специфікація, далі з неї виводяться задачі, і лише потім агент реалізує їх відповідно до цієї специфікації, а не до промпту.
Ціль
Ви описуєте ціль у чаті уточнення цілей — він завантажує поточний стан задач, архітектурні знання проєкту та попередній контекст.
Затвердження плану
Чат перетворює ціль на одну або кілька окреслених задач. Людина затверджує план, перш ніж щось будується.
Окреслена задача
Задача містить затверджену специфікацію, залежності, пріоритет і потрібні фрагменти бази знань проєкту.
Сесія агента
Агент запускається в сесії терміналу, попередньо налаштованій із MCP-сервером проєкту, і реалізує задачу.
Результат зафіксовано
Коментар про результат, оновлена архітектурна документація та дані про токени й вартість повертаються до задачі. Дошка рухається далі.
Дошка задач
Запис задачі, який агент читає й записує, а не картка, якої він не бачить.
Дошка, беклог і спринт-подання походять з одного запису задачі — того самого, який агент читає через MCP і в який записує результат після завершення роботи. Залежності й пріоритет визначають, що агент братиме далі; кожна задача несе потрібні фрагменти бази знань проєкту.
Розділи лендингу L1–L15
Дошка → Беклог → Спринт 12
landing-page
css
tt-website-laravel
Виконання ШІ-агентами
Агенти запускаються із задачі після того, як людина затвердить план.
Ціль проходить через чат планування, перш ніж торкнутися коду, — людина затверджує план, а не лише ціль. Після затвердження Claude Code і Codex запускаються із задачі в сесії терміналу з уже підключеним MCP-сервером проєкту. Інші агенти отримують той самий контекст задачі через REST API.
Розробка, керована специфікацією — ось що робить цей етап затвердження значущим: затверджений план є письмовою специфікацією, вона лишається на задачі, яку агент читає через MCP, а коментар про результат, що повертається, можна звірити з нею.
$ $ tipatask session start TPT68
план затверджено — запуск сесії агента
$ $ update_task TPT68 status=in_progress
коментар про результат опубліковано — status=completed
Спринти
Спринти визначають порядок, у якому агенти беруть роботу.
Пріоритет, залежності й статус визначають, що далі. Послідовність, якої дотримується агент у сесії терміналу, та сама, яку людина бачить на дошці спринту.
Спринт 11 — завершено
Спринт 12 — активний
Створити каркас окремого сайту на Laravel
Розділи лендингу L1–L15
Багатопроєктний робочий простір
Один десктопний застосунок для всіх проєктів, з якими ви працюєте.
Сьогодні постачається як десктопний застосунок для macOS. Він працює поруч із репозиторіями, якими керує, і дає єдине міжпроєктне подання всіх проєктів, з якими ви працюєте.
tipatask
6 активних
apppixies-site
2 активні
internal-tools
1 активна
MCP і архітектурна пам’ять
Архітектурна документація, яку ваші агенти викликають через MCP.
MCP (Model Context Protocol) дає змогу агенту напряму викликати інструменти проєкту, замість того щоб вручну вставляти контекст у промпт. Задачі, коментарі й архітектурна документація Tipatask доступні саме так. Кожна завершена задача записує свої архітектурні нотатки назад через той самий MCP-сервер, з якого читає агент наступної задачі.
$ $ mcp call pull_knowledge
→ архітектурний документ отримано
$ $ mcp call push_knowledge
→ документацію оновлено для наступного агента
Чим ми відрізняємось
Створено навколо роботи, яку виконують агенти, а не доопрацьовано під неї.
Обидва контрасти зводяться до однієї дисципліни: розробка, керована специфікацією. Одиницею роботи є специфікація, яку людина затвердила до виконання, — саме це робить результат перевірюваним: рецензент звіряє реалізацію зі специфікацією, а специфікацію — з ціллю, з якої її виведено.
На відміну від типових конструкторів ШІ-застосунків
Інструменти «промпт → застосунок» оптимізовані на швидке отримання чогось працездатного, тоді як сама робота лишається здебільшого невидимою — без стійкого плану, без запису про те, що пробували й відхилили. Tipatask керує тим, як реальна, поточна робота планується, виконується й переглядається, задача за задачею, з коментарем про результат, оновленою архітектурною документацією та даними про вартість для кожної.
На відміну від хмарних дошок задач і ШІ-робочих просторів
Більшість інструментів для задач створювались для координації людей із людьми, а ШІ додали пізніше як функцію чату. Tipatask починається із самого запису задачі: він спроєктований так, щоб агент міг читати й діяти з ним напряму через MCP, а архітектурний контекст та історія виконання — повноцінні поля, а не додаток збоку.
Для кого це
Для розробників, які вже щодня працюють з агентами.
Соло-розробники
Контекст губиться між сесіями чату, розрізненою історією терміналу й нотатками задач без постійного місця. Tipatask пам’ятає проєкт між сесіями — план, що вже пробували, архітектуру — без робочого процесу, важчого за саму роботу.
Технічні лідери
Специфікації задач, які агент справді може виконати, а не лише людина прочитати, плюс видимість того, що саме зробила робота за участю агента — коментарі, нотатки про результат і оновлена архітектурна документація, які роблять її перевірюваною так само, як і роботу, виконану людиною.
Засновники ШІ-стартапів
Єдиний простір для цілей, архітектурного контексту й виконання — не корпоративний інструмент робочого графа для великої організації і не звичайний планувальник, який нічого не каже про код.
Відгуки
Що кажуть люди
Знаєте, нічого з того більше не знадобилося б.
Легше легкого!
Командна робота — ось у чому секрет.
Делегування — це насамперед довіра.
Жодних задач, що висять над головою.
Обожнюю дивитися на все з висоти пташиного польоту.
Дорожня карта
Спершу Windows і Linux, далі — ізольоване виконання та мобільний застосунок.
Заплановано — ще не випущено
Зараз
Повна підтримка поза macOS — найбільша перешкода для впровадження в командах, які працюють не лише на одній платформі.
Далі
Робота агента всередині ізольованого контейнера, щоб він міг діяти з меншою кількістю ручних підтверджень без ризику для основної машини — а також мобільний застосунок для видимості й дистанційного керування цією роботою.
Згодом
Багатша структура задач для більших проєктів — розгалужені задачі та вкладені піддошки — далі керований хмарний хостинг і згодом власне управління Git-репозиторіями, вбудоване в робочий процес.