The post has been translated automatically. Original language: Russian
I have a technical and architectural education, an MBA in investment project management, and years of practical experience in construction. I've never been a programmer. And the further I built Planix AI, the more convinced I became — perhaps that's why the product turned out the way the market really expects it, and not the way a developer who has never stood on a construction site imagines it.
Working in the industry, I have seen the same picture over and over again: there is no single source of truth on any major project. The estimate lives in one table, the graph lives in another, the risks are kept in the foreman's head, and by the time a cash gap or a breakdown of a critical path becomes visible, it's too late to fix it, and it's already expensive.
It's a familiar situation if you were working on a construction site: the contractor promises to meet the deadline, but no one sees in advance that parallel work is physically impossible to finish at the same time. The budget seems to be kept within the limits, but in fact the reserve has already been used up by half with the facility being ready at ten percent. The supervisor learns about the problem at the planning meeting after the fact, and not a week before it has become irreversible.
A development engineer with no industry experience would have built a user-friendly interface for data entry. I knew exactly which questions the system should ask, which contradictions in the source documents were really critical, and which were just noise. Mastery of pain turned out to be more important than mastery of syntax.
This is how Planix AI appeared. You upload an estimate, a work schedule, or just describe the project in words — the system builds a calendar plan with dependencies between tasks, calculates the critical path, predicts the movement of money and where a cash gap may form. Then you can just talk to her: ask her what the risks are in terms of deadlines, ask her to postpone the task, and the system itself will recalculate everything that depends on her before really changing anything. Separately, she herself, without reminders, monitors the project — if the task is overdue, the contractor is overloaded with several jobs at the same time, or the contract expires with ongoing work — a notification arrives, and not silence until the moment when the problem has already happened.
This is a fundamental point of architecture for me: all financial and calendar calculations — the critical path, cash flow, and workload of performers — are performed by a separate deterministic computing core, ordinary verifiable mathematics, and not a language model. The same source data always gives the same result — without "fantasies" and without the risk that the figure in the report will turn out to be plausible but incorrect. The AI in the system does only what it really does well: reads documents of any format and conducts a dialogue in natural language. I consciously drew this line between "where mathematics counts" and "where the language model helps" from the very beginning — it is this line that distinguishes a tool that can be trusted with numbers from a beautifully designed chatbot.
An important detail: the system is not initially tied only to the construction site. It is based on a universal project management model — tasks, deadlines, budget, risks, participants — applicable to any project-oriented activity. I've tested it on event management, production launches, and IT development-wherever there's a schedule, budget, and cost of error when deviating from the plan, the logic works the same way. Construction has been chosen as a priority simply because the cost of one missed problem is usually the highest there.
I had to write the code at the same time — I built the entire product alone using modern AI-assisted development tools. But that wasn't the most difficult part, it was forcing the system to be honest: so that it wouldn't invent numbers where there was no data, could say "I don't know" directly instead of a beautiful but incorrect answer, and really caught logical contradictions in the source data, rather than just answering them smoothly. This is where the industry's flair came in handy, not the technical one. I knew exactly what kind of error the system was supposed to catch, because I had seen how it cost the company money.
The product has now been tested on real objects of various scales, from apartment repairs to a pharmaceutical factory and a premium villa in Turkey. A certificate of registration with Kazpatent has been received, negotiations are underway with developers on the implementation.
У меня техническое и архитектурное образование, MBA по управлению инвестиционными проектами и годы практического опыта в строительстве. Программистом я никогда не был. И чем дальше я строил Planix AI, тем больше убеждался — возможно, именно поэтому продукт получился таким, каким его действительно ждёт рынок, а не таким, каким его представляет себе разработчик, никогда не стоявший на стройплощадке.
Работая в отрасли, я снова и снова видел одну и ту же картину: на любом сколько-нибудь крупном проекте нет единого источника правды. Смета живёт в одной таблице, график — в другой, риски держатся в голове у прораба, а к моменту когда становится виден кассовый разрыв или срыв критического пути — исправлять уже поздно, и это уже дорого.
Знакомая ситуация, если работали над стройкой: подрядчик обещает уложиться в срок, но никто заранее не видит, что параллельно идущие работы физически невозможно закончить одновременно. Бюджет вроде бы держится в рамках, а на деле резерв уже израсходован наполовину при готовности объекта в десять процентов. Руководитель узнаёт о проблеме на планёрке постфактум, а не за неделю до того как она стала необратимой.
Инженер-разработчик без опыта в отрасли построил бы удобный интерфейс для ввода данных. Я же точно знал, какие именно вопросы должна задавать система, какие противоречия в исходных документах на самом деле критичны, а какие — просто шум. Владение болью оказалось важнее владения синтаксисом.
Так появился Planix AI. Загружаете смету, график работ или просто описываете проект словами — система сама строит календарный план с зависимостями между задачами, считает критический путь, прогнозирует движение денег и то, где может образоваться кассовый разрыв. Дальше с ней можно просто разговаривать: спросить какие риски по срокам, попросить перенести задачу — и система сама пересчитает всё, что от неё зависит, прежде чем что-то менять по-настоящему. Отдельно она сама, без напоминаний, следит за проектом — если задача уходит в просрочку, исполнитель оказывается перегружен на нескольких работах одновременно, или истекает срок контракта при продолжающихся работах — приходит уведомление, а не тишина до момента когда проблема уже случилась.
Здесь принципиальный для меня момент архитектуры: все финансовые и календарные расчёты — критический путь, кассовый поток, загрузка исполнителей — выполняет отдельное детерминированное вычислительное ядро, обычная проверяемая математика, а не языковая модель. Одни и те же исходные данные всегда дают один и тот же результат — без «фантазий» и без риска, что цифра в отчёте окажется правдоподобной, но неверной. AI в системе занимается только тем, что действительно умеет хорошо: читает документы произвольного формата и ведёт диалог на естественном языке. Эту границу между «где считает математика» и «где помогает языковая модель» я провёл осознанно с самого начала — именно она отличает инструмент, которому можно доверять цифры, от красиво оформленного чат-бота.
Важная деталь: система изначально не привязана только к стройке. В основе лежит универсальная модель управления проектом — задачи, сроки, бюджет, риски, участники, — применимая к любой проектно-ориентированной деятельности. Я тестировал её и на организации мероприятий, и на производственных запусках, и на IT-разработке — везде, где есть график, бюджет и цена ошибки при отклонении от плана, логика работает одинаково. Строительство выбрано приоритетным направлением просто потому, что там цена одной пропущенной проблемы обычно самая высокая.
Код при этом писать пришлось — весь продукт я построил один, используя современные инструменты AI-ассистированной разработки. Но самым сложным было не это, а заставить систему быть честной: чтобы она не выдумывала цифры там, где данных нет, умела прямо сказать «не знаю» вместо красивого, но неверного ответа, и действительно ловила логические противоречия в исходных данных, а не просто гладко на них отвечала. Здесь как раз и пригодилось не техническое, а отраслевое чутьё — я точно знал, какую ошибку система обязана поймать, потому что сам видел, как она стоит компании деньги.
Сейчас продукт протестирован на реальных объектах самого разного масштаба — от ремонта квартиры до фармацевтического завода и премиальной виллы в Турции. Получено свидетельство о регистрации в Казпатенте, идут переговоры с застройщиками о внедрении.
