The post has been translated automatically. Original language: Russian
Generative AI has already changed the cost of a line of code, the speed of a prototype, and the composition of a team. The question is not whether programmers will be "fired," but which roles will no longer be paid according to the old model, and who in Kazakhstani IT companies will have time to rebuild the process before the market.
What has really changed in development
Until recently, the "idea—prototype—release" cycle was about people. We needed a separate contractor for the boiler plate, a separate one for the tests, a separate one for the draft documentation, and another for the initial analysis. Now part of this circuit is closed in hours, not in a sprint.
AI confidently takes over the generation and refactoring of sample code, drafts of unit and API tests, description of endpoints, bug reports, primary decomposition of the task, and comparison of architecture options "on a napkin". The code review has also shifted: the model finds obvious holes and stylistic noise, the person checks the meaning, the boundaries of the system and the price of the error in the product.
The most noticeable effect is not the "magic of auto—completion", but the compression of the early stage. What previously required two middle developers for two weeks, a team of strong senior and AI gathers in a few days. The entry threshold for template CRUD, landing, admin panel, integration with one external API has dropped sharply. There is no threshold of responsibility.
This is important for Astana Hub residents. In the foreign market, the customer increasingly pays not for the amount of labor, but for the speed of output of the working version. A company that sells "a team of eight people for three months" starts losing out to a company that sells the same result with a team of three — with comparable quality control.
Where the staff is really shrinking
A reduction almost never looks like a massive layoff of "all developers." It's quieter more often: the vacancy is not opened, the probation period is not extended, the junior stream is narrowed, and the contract for simple tasks is not extended.
The roles where value was measured by the amount of work being repeated were the first to be hit.:
- junior on template tasks without domain complexity;
- a separate entry-level documentarian who designed the already known;
- part of manual regression QA on predictable scenarios;
- an inflated middle layer that covered the same type of CRUD, screen migrations, and "another sample service."
This can be seen faster in outsourcing than in a product. The client compares the "480 hours" estimate with that of a competitor whose AI is already embedded in the pipeline, and does not understand why he is paying for the extra 200 hours. In internal development, the same effect manifests itself as a hiring freeze: the product is growing, but the headcount is not.
Those who are responsible for the entire system are less likely to be cut. A senior and staff engineer, an architect, a person who understands integration, data, security, load limits, and the price of a bug in a product do not disappear. They simply stop being surrounded by a large number of performers "on the lines".
The main market shift is this: companies don't necessarily lay off 30 percent of their staff. They don't hire the next five to ten people and raise the output for the employee. For reporting purposes, this looks like an increase in productivity. For the labor market— it is like a compression of demand for a certain profile.
Where the staff is not being reduced, but is being reassembled
The code has become cheap. Setting the task, the taste for quality, and the ability to tell the model "this is wrong" and bring the result to production have become expensive.
Therefore, strong teams do not destroy the development, but change its composition. Fewer people who "write from scratch according to the TOR". There are more people who know how to decompose, assemble a system from pieces, review other people's and machine code, keep standards and be responsible for the consequences.
It's not so much high-profile posts that appear, but rather new functions within the old roles.:
- A developer who works as an AI director and editor, not as a codesetter.;
- the person responsible for the internal rules for using models: what can be generated, what can not be uploaded without checking, what data is not sent to external services;
- An AI code quality specialist is essentially an enhanced review, not a separate "industrial engineer for the sake of an industrial engineer."
A practical example. A product team of seven people created a typical internal portal for three sprints. After implementing AI assistants in the IDE, generating tests and documentation templates, four people closed the same volume. Two of them weren't fired right away — they just didn't get their project workload extended. But there is a new burden on lida: now he not only designs, but also cleans up the model's system errors, which junior had not even noticed before.
The second example. The customer reduced the assessment for the outsourced contractor to an analyst "for documents". The documents really began to appear faster. A month later, something else came up: the requirements were carefully generated, but past the real limitations of accounting and integration. The savings at the start turned into a rework in the middle. The AI accelerated the text. He has not replaced the person who understands the subject.
The conclusion is simple. It's not the developer's profession that is shrinking. The "many performers into repeatable chunks" model is being reduced.
What risks does this pose for IT companies in Kazakhstan?
The first risk is the illusion of economy. The generation rate is growing faster than the maturity of the control. Teams begin to measure success by the number of files created and tasks closed. After a quarter, it turns out that the hidden technical debt has grown, the same type of vulnerabilities and pieces of code have appeared that "work", but no one can safely change them.
The second risk is the disruption of the junior's school. If you stop taking the younger ones, because "AI already writes simple things," in two or three years there will be nowhere to take the middle. The market already feels this: there are few seniors, there are many juniors, but a jun without the skill of working with AI and without a mentor costs less and needs less.
The third risk is dependence on external models and APIs. For an Astana Hub resident, this is not an abstraction. The price, limits, data policy, model quality are changing — and with them the speed of the team. If the whole process is tied to one tool, the company gets not efficiency, but a point of failure.
The fourth risk is identical products. When everything is generated by one class of tools, the difference in packaging and basic implementation disappears. Competitive advantage goes where AI is powerless: into customer understanding, domain, data, distribution, trust, and responsibility.
The fifth risk is personnel rush. It's easier to reduce people than to build a new outline: rules for using AI, mandatory review, prohibition of posting untested code, quality metrics, and team training. A company that cuts staff ahead of the process does not become lean. She's becoming fragile.
What to do for Astana Hub residents
Except for the phrase "we implemented AI and reduced two people." Consider another phrase a victory: "we produce the same value faster, cheaper, and with fewer defects on the product."
Practical steps:
- Measure not the number, but the economics of the feature: the time to MVP, the cost of a unit of functionality, the proportion of AI-generated code that has passed human review, and the number of defects after release.
- Rebuild the hiring profile. Less of a "write CRUD from scratch" question. More questions """"how do you decompose the model's task", ""how do you catch an error in the generated code", ""how do you bring it to the prod".
- Do not close the junior pipeline. Take fewer people, but immediately put them in a "mentor + AI" bundle. Otherwise, it will be even more expensive to buy a senior in two years.
- Protect the roles that hold the system together: architecture, security, integrations, owners of critical circuits, and people with domain expertise.
- Enter the internal rules for using AI right now: what data cannot be sent to external models, what must be reviewed, and what cannot be measured without tests.
- Assign an AI process owner within the team. This is not a separate department. This is the responsibility of the team leader or staff engineer for the quality of the new way of working.
- Sell the customer not a watch, but a manageable result. If your commercial model is based only on man-hours, AI will hit it sooner than engineers.
For companies within the Hub ecosystem, it is also a matter of export competitiveness. The external client does not have to understand why the Kazakh team still evaluates simple improvements as if there are no assistants. It compares time, price, and predictability.
The main thesis
AI does not cancel out an IT company. It reverses an inefficient design in which too many people are engaged in repetitive work, and responsibility is smeared. The winners are not those who have cut staff the fastest, and not those who pretend that nothing has changed. Teams that produce a product with a smaller but stronger group win — and at the same time raise people who can control AI, rather than hide behind it.
Генеративный ИИ уже изменил стоимость строки кода, скорость прототипа и состав команды. Вопрос не в том, «уволят ли программистов», а в том, какие роли перестанут оплачиваться по старой модели — и кто в казахстанских IT-компаниях успеет пересобрать процесс раньше рынка.
Что реально изменилось в разработке
Ещё недавно цикл «идея — прототип — релиз» упирался в людей. Нужен был отдельный исполнитель на бойлерплейт, отдельный — на тесты, отдельный — на черновик документации, ещё один — на первичную аналитику. Сейчас часть этого контура закрывается за часы, а не за спринт.
ИИ уверенно берёт на себя генерацию и рефакторинг типового кода, черновики unit- и API-тестов, описание эндпоинтов, баг-репорты, первичную декомпозицию задачи, сравнение вариантов архитектуры «на салфетке». Code review тоже сместился: модель находит очевидные дыры и стилистический шум, человек проверяет смысл, границы системы и цену ошибки в проде.
Самый заметный эффект — не «магия автодополнения», а сжатие ранней стадии. То, что раньше требовало двух middle-разработчиков на две недели, команда из сильного сеньора и ИИ собирает за несколько дней. Порог входа на шаблонный CRUD, лендинг, админку, интеграцию с одним внешним API резко упал. Порог ответственности — нет.
Это важно для резидентов Astana Hub. На внешнем рынке заказчик всё чаще платит не за объём трудозатрат, а за скорость вывода рабочей версии. Компания, которая продаёт «команду из восьми человек на три месяца», начинает проигрывать компании, которая продаёт тот же результат командой из трёх — при сопоставимом качестве контроля.
Где штат действительно сжимается
Сокращение почти никогда не выглядит как массовое увольнение «всех разработчиков». Чаще происходит тише: вакансию не открывают, испытательный не продлевают, junior-поток сужают, подряд на простые задачи не продлевают.
Первыми под ударом оказываются роли, где ценность измерялась объёмом повторяемой работы:
- junior на шаблонных задачах без доменной сложности;
- отдельный документалист начального уровня, который оформлял уже известное;
- часть ручного регрессионного QA на предсказуемых сценариях;
- раздутый middle-слой, который закрывал однотипный CRUD, миграции экранов и «ещё один сервис по образцу».
В аутсорсе это видно быстрее, чем в продукте. Клиент сравнивает оценку «480 часов» с оценкой конкурента, у которого ИИ уже встроен в пайплайн, и не понимает, за что платит лишние 200 часов. Во внутренней разработке тот же эффект проявляется как заморозка найма: продукт растёт, а headcount — нет.
Реже сокращают тех, кто несёт ответственность за систему целиком. Senior и staff engineer, архитектор, человек, который понимает интеграции, данные, безопасность, нагрузочные пределы и цену бага в проде, не исчезают. Их просто перестают окружать большим числом исполнителей «на строках».
Главный сдвиг рынка такой: компании не обязательно увольняют 30 процентов штата. Они не нанимают следующие пять-десять человек и поднимают выход на сотрудника. Для отчётности это выглядит как рост производительности. Для рынка труда — как сжатие спроса на определённый профиль.
Где штат не сокращается, а пересобирается
Дешёвым стал код. Дорогими стали постановка задачи, вкус к качеству, умение сказать модели «это неправильно» и довести результат до продакшена.
Поэтому сильные команды не уничтожают разработку, а меняют её состав. Меньше людей, которые «пишут с нуля по ТЗ». Больше людей, которые умеют декомпозировать, собирать систему из кусков, ревьюить чужой и машинный код, держать стандарты и отвечать за последствия.
Появляются не столько громкие должности, сколько новые функции внутри старых ролей:
- разработчик, который работает как постановщик и редактор ИИ, а не как наборщик кода;
- человек, отвечающий за внутренние правила использования моделей: что можно генерировать, что нельзя выкладывать без проверки, какие данные не отправляются во внешние сервисы;
- специалист по качеству AI-кода — по сути усиленный review, а не отдельный «промпт-инженер ради промпт-инженера».
Практический пример. Продуктовая команда из семи человек делала типовой внутренний портал три спринта. После внедрения ИИ-ассистентов в IDE, генерации тестов и шаблонов документации тот же объём закрыли четыре человека. Двух не уволили сразу — им просто не продлили проектную загрузку. Зато появилась новая нагрузка на лида: он теперь не только проектирует, но и вычищает системные ошибки модели, которых junior раньше даже не замечал.
Второй пример. Аутсорсному подрядчику заказчик сократил оценку на аналитика «под документы». Документы действительно стали появляться быстрее. Через месяц всплыло другое: требования были сгенерированы аккуратно, но мимо реальных ограничений учётки и интеграций. Экономия на старте превратилась в переделку на середине. ИИ ускорил текст. Он не заменил человека, который понимает предметку.
Вывод простой. Сокращается не профессия разработчика. Сокращается модель «много исполнителей на повторяемые куски».
Какие риски это создаёт для IT-компаний в Казахстане
Первый риск — иллюзия экономии. Скорость генерации растёт быстрее, чем зрелость контроля. Команды начинают мерить успех количеством созданных файлов и закрытых задач. Через квартал выясняется, что вырос скрытый техдолг, появились однотипные уязвимости и куски кода, которые «работают», но никто не может безопасно менять.
Второй риск — обрыв школы junior’ов. Если перестать брать младших, потому что «ИИ и так пишет простое», через два-три года неоткуда будет брать middle. Рынок это уже чувствует: сеньоров мало, джунов много, но джун без навыка работы с ИИ и без наставника стоит дешевле и нужен меньше.
Третий риск — зависимость от внешних моделей и API. Для резидента Astana Hub это не абстракция. Меняется цена, лимиты, политика данных, качество модели — и вместе с ними скорость команды. Если весь процесс завязан на один инструмент, компания получает не эффективность, а точку отказа.
Четвёртый риск — одинаковые продукты. Когда все генерируют одним классом инструментов, исчезает различие в упаковке и базовой реализации. Конкурентное преимущество уходит туда, где ИИ бессилен: в понимание клиента, домен, данные, дистрибуцию, доверие и ответственность.
Пятый риск — кадровая спешка. Сократить людей проще, чем выстроить новый контур: правила использования ИИ, обязательный review, запрет выкладки непроверенного кода, метрики качества, обучение команды. Компания, которая режет штат раньше процесса, не становится lean. Она становится хрупкой.
Что делать резидентам Astana Hub
Не считать победой фразу «мы внедрили ИИ и сократили двух человек». Считать победой другую фразу: «мы выпускаем ту же ценность быстрее, дешевле и с меньшим числом дефектов на проде».
Практические шаги:
- Измеряйте не численность, а экономику фичи: время до MVP, стоимость единицы функциональности, долю AI-сгенерированного кода, прошедшего человеческий review, число дефектов после релиза.
- Пересоберите профиль найма. Меньше вопроса «напишешь CRUD с нуля». Больше вопросов «как декомпозируешь задачу модели», «как поймаешь ошибку в сгенерированном коде», «как доведёшь это до прода».
- Не закрывайте junior-конвейер. Берите меньше людей, но сразу ставьте их в связку «наставник + ИИ». Иначе через два года купить сеньора будет ещё дороже.
- Защищайте роли, которые держат систему: архитектура, безопасность, интеграции, владельцы критичных контуров, люди с доменной экспертизой.
- Введите внутренние правила использования ИИ уже сейчас: какие данные нельзя отправлять во внешние модели, что обязано проходить review, что запрещено мержить без тестов.
- Назначьте внутри команды владельца AI-процесса. Это не отдельный департамент. Это ответственность тимлида или staff-инженера за качество нового способа работы.
- Продавайте заказчику не часы, а управляемый результат. Если ваша коммерческая модель держится только на объёме человеко-часов, ИИ ударит по ней раньше, чем по инженерам.
Для компаний внутри экосистемы Хаба это ещё и вопрос экспортной конкурентоспособности. Внешний клиент не обязан понимать, почему казахстанская команда всё ещё оценивает простую доработку так, будто ассистентов не существует. Он сравнивает срок, цену и предсказуемость.
Главный тезис
ИИ не отменяет IT-компанию. Он отменяет неэффективную конструкцию, в которой слишком много людей заняты повторяемой работой, а ответственность размазана. Выигрывают не те, кто быстрее всех сократил штат, и не те, кто делает вид, что ничего не изменилось. Выигрывают команды, которые выпускают продукт меньшей, но более сильной группой — и при этом растят людей, способных управлять ИИ, а не прятаться за ним.
Share
