AI Hard Fork: Вайб-кодинг: программисты не нужны?! — Самат Галимов

Вот. А у нас следующий доклад от Самата

Галимова, тоже нашего товарища партнёра

про вайпкодинг. Самат, с нами ли ты,

чтобы мы тебе передали эфир.

>> Всем привет. А

у меня 6:00 вечера. Я думаю, что

большинства уже 7:00 вечера, а у кого-то

совсем поздно. А-э, поэтому я слышал, на

самом деле слушал последние несколько

докладов и, э, коллеги дают очень много

хардовый информации, поэтому и во многом

она пересекается с нашим опытом. Поэтому

я, наверное, попробую сделать

побольше такого наблюдения.

А там, где

мне покажется важным, я прямо расскажу

какие-то истории из своей практики, а в

остальном, я думаю, что доклад будет

довольно короткий, и у нас постанется

больше времени на вопросы, тем более,

что дискуссия очень живая. Может быть,

получится какой-то диалог ещё построить.

Если Коль ты останешься, то, мне

кажется, вполне может что-то намутить

общее. Вот спонтанная панелька.

>> А презентация называется программисты не

нужны с вопросительным знаком. Меня

зовут Самат Галимов. Я основатель и

технический директор Фанс разработки.

Это просто бутиковая студия аутсорса.

Ещё я делаю подкаст запус завтра. А,

погодите, у меня же ещё есть вот такой

слайд. Вот. А вообще я технический

директор. Я делал много разных проектов

из известных. Это Медуза Букмейт,

который сейчас Яндекс книги. и dating

Pure. А ещё я веду очень популярный

подкаст Запуск завтра. Подписывайтесь.

Очень надеюсь, что он вам нравится, если

вы слушате. А ещё я владелец бутикового

аутсорса. У нас 25 разработчиков, и мы

уже довольно давно этим занимаемся, 7

лет. А

я хочу поделиться вот этим мыслью, что

программисты больше не нужны, что теперь

можно, а, проекты делать.

просто продуктом, предпринимателем, типа

взял, сделал. Это же компьютер же

делают, всё за тебя теперь чат GPT. А и

начать с этой простой идеи, а потом её

покрутить немножечко уже в сторону,

которая может быть интересна

программистам, даже тем, кто активно

этим пользуется. Какой наш опыт? Но

начнём с чего-то простого. А в целом вот

эта фраза типа, что программисты больше

не нужны теперь, типа компьютер сам всё

делает. В принципе, да, простые штуки,

там ндосы или там очень простые MVP,

можно вайпкодить. А вайпкодить, в

смысле, ты прямо

сейчас мы, сейчас я расскажу, как мы это

делаем, но

в целом, да, типа не надо сидеть

программировать там день, дни или даже

недели, как раньше. ты прямо берёшь и за

несколько часов в одно лицо можешь

сделать прямо полноценную

полноценный Windows или полноценный

маленький.

А как я считаю, что это не совсем

разработка, на самом деле это скорее

такой мм такое ТЗ. А раньше вообще жутко

не люблю слово ТЗ, потому что от него

пахнет нафтолином и ГОСТом. А когда я

прошу, чтобы мне описали задачу, я

обычно говорю: "Блин, давай варфреймы

нарисуем". То есть там на доске

маркером, там можно на цифровой доске, а

просто крупными блоками, типа какие есть

экраны и какие между ними есть переходы.

А и вот это для меня лично гораздо более

качественная документация документация,

чем там в 99% случаев это гораздо более

подходящий формат документации, чем

какие-то текстовые описания. Потому что

текстовое описание лично мне сложно

парсить.

А есть задачи, в которых, конечно, нужен

именно текст, но там в большинстве

случаев варфреймы

мне нравятся больше, мне кажется более

эффективными, потому что а когда, ну,

меньше разногласий, меньше такого, что я

прочитал в документе в одно место

посмотрел внимательно, а клиент

посмотрел в другое и потом у нас мисмчик

оказался, когда у нас варфреймы, там

довольно мало где можно друг друга

неправильно понять. То есть я считаю,

что варфреймы - это такой типа более

продвинутые ТЗ. Так вот, MVP

кликабельный,

может быть даже ещё и интерактивный. То

есть MVP

это по сути то, что делают вот то, что

можно вайп-кодить, это такой следующий

апгрейд

этого самого ТЗ, этих самых варфреймов.

В этом плане это совершенно магическая

штука.

приходит клиент, и сейчас это уже часто

происходит. Или, например, вот совсем

недавно ко мне пришёл знакомый дизайнер,

очень крутой, и он говорит: "Сама, у

меня есть идея стартапы, там, типа, хочу

делать сделать маленький продукт, там

должен делать вот это". Раньше бы что я

сделал? Я бы сказал: "Давай Warframe

накидаем". Потом бы я прикинул, сколько

это стоит разработать. А так я ему

говорю: "Так, смотри, я пошарил ему

экран, открываю типа cloudкод и говорю:

"Вот, типа, описываем то, что ты хочешь.

Я сейчас добавлю пару строк своих

уже моих технических мыслей. Ну вот вот

вот что у нас получилось. И там через

полчаса в течение там вот этого зумвонка

у нас рождается прототип. Прототип

продукта, о котором а говорил мой

собеседник. Это довольно магическое

ощущение. Мне кажется, что это супер

круто. Этим нужно пользоваться.

А,

а при этом ти правила типа как я этим

пользуюсь. Во-первых, мне кажется, очень

важно, самое, мне кажется, ключевое. Я

тут просто отсортировал по порядку. А

мне кажется, самое главное - это

использовать State of the Art модель. Их

типа не очень много. Ну, там основных,

мне кажется, три. Это cloudкод от

Антропика, кодекс от Open и Антигравити

от Гугла. Берёте любую, они чуть-чуть

отличаются, но если вы типа не

находитесь на острие прогресса, то

типа не не задро не как бы

если вам не так интересно сам

инструмент, а важный результат, то мне

кажется любой из этих трёх инструментов

подойдёт под 99% задач. А плюс там во

всех этих моделях можно выбирать типа

умную и медленную и дорогую или дешёвую

и быструю. Дешёвую и быструю

и и глупенькую. Так вот, если вы не

сильно разбираетесь, берёте самую

дорогую всегда и не ошибётесь,

скорее всего вы не потратите все эти

токены, которые которых она это стоит.

Не так уж это и дорого. А вторая, второй

важный пункт - это если вы технарь и вы

там мы, например, у себя в организации

очень любим View вместо Реакта. Так вот,

к сожалению,

популярны некоторые фреймворки лучше

подходят для моделей на текущий момент,

чем другие. Например, React по

результатам независимых тестов гораздо

лучше, чем VJS. Ну, так случилось, как

бы, учитывая, что мы делаем MVP, как бы

можно взять что-то, может, не такое

знакомое, зато то, с чем модели будет

проще. Плюс есть AI ready стартер киты,

когда уже типа нормальная какая-то

минимальная архитектура в проекте есть,

но это, мне кажется, такой уже advanced

штука. А для старта вот берёте

сотомодель, берёте гото стандартный

харness стандартный

убреж, то, что называется для этой

нейросети. Это вот либо Cloud Code, либо

кодекс, либо antiravity, и у вас всё

работает. Если хочется как бы

поэкспериментировать, есть Open Code,

есть пай, можно собрать что-то своё

гораздо более интересное. Мне кажется,

что если вот вы проживали, а можете и

сейчас пользусь там Емаксом или Вимом, и

он у вас под себя настроен. Вот если вы

такой тип человека, то, скорее всего,

Open CД или P вам очень хорошо зайдут.

Там тоже можно настроить вообще всё что

угодно. Если вы любите там Visual Studio

CД, а то один из этих трёх настроен.

О'кей.

Ещё маленькая штука. Мм, я, когда

готовил этот доклад, потом рассказывал

его своему бизнес-партнёру Феде Борщёва,

Феди мне сказала, что самат, кажется,

современной модели уже всё это умеют

сами, но я, может быть, просто уже

устарел за эти несколько недель. А мне

кажется, что модели всё-таки чуть лучше

работают, если ты вместо того, чтобы

сказать: "Сделай хорошо, типа, сделай

мне

сделай мне прототип вот такого вот

продукта". Дальше описание продукта, а

не делай ошибок, как бы это один подход,

мне кажется, он не очень эффективный. По

моему опыту гораздо прикольнее сказать

неросетей, типа, задай мне

исчерпывающие, уточняющие вопросы, если

тебе что-то непонятно. Типа, не делай

предположения, а скорее задай мне

вопросы. Честно говоря, на самом деле

последнее время модели сами умеют это

делать, но если вы прямо это спросите,

хуже точно не будет. Дальше можно

попросить модель описать, как он понял,

как она поняла задачу и что она сделает

в результате, какие шаги она собирается

выполнять, какие действия она собирается

делать. И потом уже сказать ей: "А вот

теперь по этому плану всё выполнено".

Читаете план, проверяете, что всё о'кей,

и тогда говорите и сделать. Очень

простая идея, что код читать сложнее,

чем текстовое описание того, что она

собирается делать. Я это всё рассказываю

и чувствую себя немножко глупо, потому

что то, что рассказывали преж предыдущие

докладчики, было гораздо более

продвинутого уровня. Но я надеюсь, что

не все супер хардкорные я и пользователи

и такой

такие вводные штуки тоже будут полезны.

А что дальше?

Ну, как бы, о'кей, мы научились делать

деньги пишки, но вот по моему опыту, а

это, не знаю, 20% а той работы, которой

мы занимаемся каждый день. А

потому что 80% работы - это другое. И

вот сейчас обсудим, что это такое. Но в

целом я бы это описал как стабильность и

масштабируемость разработки. И обычно,

когда говорят стабильность,

масштабируемость, имеет в виду, что там

под нагрузкой там вот то, что RPS

request per second, как бы сколько там

тысяч человек в минуту приходит на твой

сервис, что он не падает. Я не про это.

Я про то, что а вот у нас там проект, а

давайте я вам сейчас просто расскажу,

как обычно происходит. А 99% проектов

развивается по следующей траекторией. Э

сначала есть конфетно-букетный период,

видите, он даже розового цвета экран. А

в начале всё вообще идеально.

Программисты пришли. Это ещё до AI, как

бы с AI сейчас раска расскажу, как

поменялось, но до AI, как а бизнесмены,

предприниматели находят программистов, а

программисты говорят, что у вас задача,

те рассказывают в каком-то формате, там

ТЗ пишут или там сидят, разговаривают. В

результате рождается какоя-то идея

продукта. Программисты садятся, её

программируют супербыстро. Обычно первый

прототип там получается уже за несколько

недель заказчик видит, что вот ничего не

было, вдруг оно начинает появляться.

Супер. Все радостные, очень круто. 01

как бы вот это всё. Все счастливы.

Видите розочки, как бы конкретно

букетный период разработок. За супер

короткое время программистам удаётся

сделать большую часть того, что хотел

заказчик.

Но дальше этот период, он может как бы

продолжаться там 2 месяца, две несколько

недель, месяц. Обычно полгода, год

иногда там 2-3 года

становится всё очень плохо. Это как в

браке, знаете, когда познакомился,

познакомились, всё хорошо, а там через

несколько лет хочется разводиться. Вот

тут похожая ситуация.

отношения портятся,

потому что даже маленькая доработка,

типа бизнес говорит: "Добавь мне

кнопку". У нас буквально был такой кейс,

к нам пришёл клиент, говорит: "Типa мы в

нашей системе, они там образованием

занимались, типа не можем сделать

сквозную аналитику. Мы типа вот просим

одну рекламную штуку вставить, чтобы её

потракать, и не можем". Типа нам

разработку говорит, что это полгода надо

всё переписать. А, ну очевидно, что,

наверное, там можно как-то хакнуть и

ставить это побыстрее, но и у разработки

уже тоже накопилось как бы бэклок, и уже

накопилось какое-то непонимание и

раздражение клиентам. Короче, там всё в

коме, но

результат такой, типа, то, что раньше

занимало неделю, то, что раньше занимало

несколько часов, теперь занимает недели,

если не месяца. А почему это происходит?

Я бы назвал это одним словом Legacy. А

что такое? Ну, Legy типа наследство. То

то, что тебя осталось в наследство от

кого-то. На самом деле, а Legacy - это

то, когда у тебя никто не понимает, как

этот код работает, как эта система

устроена под капотом. То есть есть

какой-то артефакт. Вот прямо сейчас мы

работаем над системой, которой там,

чтобы не соврать. Ну, короче, больше 25

лет она до девяностых годов уже её, то

есть до 2000 года её начали пробовать. А

и у неё там это типа огромный артефакт,

система работает, бизнес работает, но

никто вообще не понимает, ээ э не

понимает, как оно устроено до конца.

Люди, которые это сделали, уже давно

уволились, ушли в отпуск, ушли, э, на

пенсию и вот это всё. И это, кстати, не

только про вот такие длинные проекты.

Такое происходит и с проектами, которым

там несколько лет или там год или

полгода ты уже нет человека, который бы

держал эту всю системку, картинку в

голове. А вторая частая проблема - это

то, что в одном месте ты что-то чинишь,

что-то добавляешь какую-то

функциональность, в другом месте что-то

вообще, казалось бы, совершение не

связанное отваливается.

Обычно это происходит потому, что нет

тестов, то есть нет автоматизированных

тестов, которые проверяют

работоспособность программы, поэтому ты

не можешь гарантировать отсутствие

ошиствие ошибок при редактировании

программы. А обычно с этим идёт в

комплекте, это вот типа четыре вещи,

которые обычно идут в комплекте. А

обычно нет культуры постановки, задачи

принятия результата. То есть бизнес

говорит: "Нам срочно нужно вот это вот

как бы завтра и и чтобы всё хорошо

работало". Что значит хорошо работало?

Почему именно завтра? А что, а какую

задачу мы вообще пытаемся решить? Нет,

типа, вы там кнопку сделаете и всё. Это,

конечно, не помогает программистам

планировать свою работу и не помогает,

а,

поддерживать какую-то картинку

полноценную того, что как у нас устроен

бизнес и и как у нас устроен наш софт,

типа, насколько он хорошо мапится.

Обычно опять же вот как бы такой

троэффект совершенно злющие.

Обычно с этим в комплекте идёт то, что

плохой девопс, а то, что невозможно

спокойно, быстро задеплоить исправление.

Обычно нет классного стейджинга, когда

ты можешь что-то попробовать поломать и

не потерять продакш, ну, не сломать

продакшн. А обычно и что ещё про DevOps?

Невозможно прогнать тест

автоматизированно. Невозможно сделать

два бранча параллельно, чтобы

посмотреть, как они, как они, чем они

отличаются. И невозможно накатить. Нет

типа базы на типа стейджинг есть, но

база на нём там 10 пользователей, в то

время как на самом деле у нас их 10 млн.

Ну как бы ценность такого стейджинга

сомнительная.

Вот это ситуация, в которую часто

приходят проекты через там полгода, год,

полтора года разработки.

А как здесь

помогает искусственный интеллект?

Искусственный интеллект спидранит этот

процесс. Я не знаю, играть ли в

компьютерные игры. Я вот в своё время

всадил, наверное, часов

600, наверное, в игру Zelda The Breath

of the Wild. А, очень классная игрушка,

рекомендую на Nintendo Switch. И вот тут

как бы чувак, а игра как бы если её

просто нормально проходить, ну, часов на

200, чтобы вы понимаете, от начала до

конца 200 часов. Тут чуваки её проходят

за 23 минуты. И вот тут момент самый

эпический, как он, а, как чуваки там,

чтобы вы понимали, это вот начальное

место расположения. Это огромная страна

Хайрол. Там вот вдалеке, видите, есть

какая-то какие-то горы. И вдалеке есть

замк. И в замке сидит чудовище, которое

надо убить и спасти принцессу.

Обычно поход отсюда до замка - это ты

200 часов игрового времени. Ты там

проходишь горы, снега, моря, как бы

получаешь всякую экипировку. Здесь вот

этот игрок, он делает немножко

по-другому. Давайте посмотрим минуту

клипа. Это поможет как-то подчеркнуть

то, что происходит с искусственном

телефони,

то, что он сейчас делает, выглядит

просто. На самом деле там типа есть два

кадра, то есть типа двечед

секунды, в которой нас

вот он успел их нажать.

Теперь он летит просто на всей

за типа 20 секунд он долетит до запада,

которым надо будет идти 200 часов.

Это просто глюк в игре, как бы если ты

вовремя что-то сделаешь, попадаешь

баг. Вот так вот. И искусственный

интеллект помогает также заспидранить

Legacy. Если у тебя, если раньше для

того, чтобы сделать проект, в котором

никто не разбирается, непонятно, что

вообще происходит, нужно было там

полгода и там, не знаю, 100.000 долларов

и там три разработчика, то теперь ты

можешь это сделать за несколько часов.

Ну, о'кей, за несколько дней точно можно

сделать. Так что проект станет большой,

что-то будет делать, но управляемости

будет ноль. Это

это то, что позволяет сделать

искусственный интеллект. А, ну есть

дополнительные бонусы. А проекты,

которые пишут люди обычно, ну, там как

бы если они сделали большой сложный

проект, то в нём хоть что-то про

безопасность они подумали. Вот не знаю,

почему так люди устроены. А тут

искусственный интеллект может прямо вот

спокойно сделать сервис, в котором типа

есть страница логина, но заходить на неё

не обязательно. Ты просто как бы можешь

адрес написать и попадёшь сразу во

внутреннюю админку.

SQL инвекции, короче, там просто тон

обычно вайпкодиные проекты - это тон

уязвимости. К счастью, это меняется. Я

думаю, что уже очень скоро это всё будет

встроено в модели, и они перестанут

такие ошибки допускать. Но прямо сейчас

пока А

как, э,

как сделать так, чтобы вот этой проблемы

Legacy не возникало? А, ну там всё на

самом деле довольно скучно и понятно, но

я всё-таки перечислю. Нужна нормальная

модульная архитектура. То есть код

должен быть устроен так, что он то, что

называется,

он не сильно связанный, чтобы разные

части там бизнес обычно состоит из

разных предметных областей, разных

поддоменов. Там, например, если это

образовательный сервис, то в нём есть

часть, которая там про курсы, есть та

часть, которая продажу этих курсов

отдельно, есть там часть про

пользователей. И вот эти штуки не должны

быть жёстко связаны, так чтобы мы могли

спокойно подредактировать там что-то про

пользователь и вообще не трогать ничего

про

курсы образовательные. Это называется

модульная архитектура.

Какое-то время был хайп, наверное, все

слышали про микросервис, но на самом

деле совершенно не обязательно делать

микросервис, скорее даже вредный в

большинстве случаев. Но разбить внутри

своего монолита, внутри своей программы,

разбить её как-то на логические части и

не перемешивать эти части между собой,

это довольно важно на для любого

программиста.

А нормальный devops должен быть настроен

CCD, должны быть стейджинги. На этих

стейджингах должны быть нормальные

данные прикатываться из продакшна. Это

всё тоже довольно такие старые понятные

вещи. Тут, например, из практического,

вдруг кто-то не слышал, есть такая

штука, называется 12 Factor App. 12

Factor Application. Двенадцатифакторное

приложение. Это то, как нужно

упаковывать приложения, как надо их

писать для того, чтобы их было удобно

деплоить. А вот вы просто не поверите.

Тут в кому, наверное, коллеги, вы

слушаете это, думаете: "Господи, да все

это знают, всё очевидные вещи". Я как ко

мне часто приходят клиенты, которые

нормальный бизнес, всё у них классно с

точки зрения бизнеса, а с точки зрения

разработки, ну, типа там, не знаю,

больше половины случаев. Вот если просто

взять и там двенадцатифакторное

приложение даже просто спросить типа: "А

у вас есть 12 факторов?" И там больше

половины скажут, что у них 12 факторов

нет, и и спросят: "А что это такое?"

Поэтому не стоит недооценивать, а то,

насколько на самом деле индустрия у нас

такая медленная и насколько там всё

часто печально. А и остальные вещи, про

которые я скажу, они больше, а, больше

про отношения и про процессы. чем проход

коход. Но они тоже очень важны. Мне

кажется, они одинаково важны. Типа

нельзя сказать, что правая нога важнее

левый или наоборот. Обе нужно, чтобы

ходить. А вот навык, давайте выполнять

обещание, он, мне кажется, ключевой и

самый сложный, на самом деле. Как его

передать, как его даже объяснить, что

это значит. Но идея простая. А

когда программист тебе говорит, что он

что-то сделает, это значит он должен это

сделать. Не в смысле там типа код

написал, а в смысле принёс пользу

бизнесу. Тут, наверное, многие со мной

не согласятся, но мне кажется, это,

наверное, самое важное, что отличает

хорошего программиста от плохого такого

бизнесового, не олимпиадника или не там

алгоритмиста какого-то, а вот именно

человека, который решает бизнес-задачи.

И я можем про это чуть подробнее

поговорить, но мне кажется, это такая

немножко параллельный трек к

искусственному интеллекту. Но в целом, а

это, наверное, основной критерий, по

которому мы, например, выбираем себе

сотрудников. Потому что код можно

научить написать легко, мы такое делали,

а вот научить человека быть

ответственным и отвечать за свои слова -

это очень сложно. Поэтому м мы мы у нас

на самом деле не получилось с Федей за 7

лет там мы пытались сделали несколько

попыток это сделать но мы не мы сдались

и теперь просто фильтруем тех людей

которые умеют так делать

среда в которой это поощряется дело в

том, что очень часто у нас в разработке

я сейчас начал говорить мне даже честно

говоря жарко стало сниму а я сейчас

потому что скажу вещь которые наверное

пусть все заагрятся но или многие за

вещь с которой многие не согласны.

Мы считаем, что задачи должны быть, что

неважно, сколько часов занимает та или

иная задача, важно то есть мы пытаемся

создать такую среду, в которой

программист может сказать: "Я за эту

неделю сделаю типа для бизнеса 1 2три".

Добавлю там какую-то фичу, сделаю так,

чтобы куда-то перестало там ломаться или

что-нибудь такое. То есть бизнесовое,

что-то осмысленное для бизнеса, не

техническое, а именно бизнесовое. И то,

сколько он часов на это потратит, это

его типа личное дело. Понятно, что,

ну, и на самом деле нам хочется, чтобы

программист тратил меньше времени,

придумать какие-то более элегантные и

более простые решения. К сожа это вот

то, что называется среда, в которой

поощряется навык давать и и выполнять

обещания. Потому что очень часто я вижу

в разработке немножко другой подход.

Вообще с другого конца к этому подходит.

программистов спрашивают, типа, сколько

займёт эта задача, слово часов займёт

эта задача. А, и программист говорит там

какое-то количество часов, а дальше

он как бы он не даёт обещания, что он

что-то доставит бизнесу. Он просто сказа

типа я заработал над задачей. Сколько

там типа на сколько на про? Короче, вот

это, блин, как же это даже сказать, это

очень сложно передаваемо, но мне

кажется, у нас часто в разработке важно

просто,

сколько человек условно кодом написал.

Ну, наверное, таким уже никто не

страдает, да? Все понимают, что

количество кода - это не не метрика

производительности программиста, но типа

достаточно близко к этому. э-э построить

систему, в которой будет наоборот, в

которой будет важен результат, мне

кажется, гораздо сложнее, но гораздо

интереснее и эффективнее. А и, наконец,

наверное, самое сложное, даже сложнее,

чем первые два навыка, это навык или

даже не то, что сложнее, просто

параллельный тоже, это не

взаимосключающие вещи. Это умение пушить

бизнес, а чтобы фичи красиво ложились в

код. Что это значит? Э, часто, когда мы

программисты и к нам приходит бизнес и

говорят: "Я хочу там сделать рекламную

кампанию, чтобы

о, я хочу рефералку, наприметь, я хочу

сделать реферальную программу, типа

каждый, кто приведёт друга, получит там

шорты бесплатно. А сделай мне так, чтобы

у меня там бесплатные секунды

добавлялись, когда там в наш аккаунт там

бесплатные дни пользования сервисом

добавлялись, когда он другу приведёт.

И ты и программист на это смотрит,

думает: "Блин, у меня там эти секунды,

короче, завязаны на парад покупки.

Бабабаба, это типа сделать нормально,

займёт, не знаю, месяц. А, и вот тут

есть два радикально разных подхода. Один

он такой аутсорсерский, типа ты

говоришь: "Ну, типа, помните, как в этом

в Варкрафте, типа, хозяин, да, хозяин,

как бы, и пошёл делать". А другой

подход, он более партнёрский. Ты

говоришь бизнесу: "Блин, идея классная,

понимаю, что рефералки - это бомба, но в

секунду добавлять нам очень неудобно.

Давай мы вместо этого будем типа днями

добавлять, как бы, да, мы немножечко,

может, потеряем там плюс-минус день, но

это вроде не не влияет на бизнес, зато

мы это запрогаем за две или за типа за

полчаса прямо сделаем, всё заработаем".

И вот этот навык

предлагать бизнесу немножечко другие

бизнес-решения, которые сильно экономят

в разработке, мне кажется очень важным.

А к чему я это всё рассказываю? К тому,

что искусственный интеллект пока что вот

этих важных вещей делать не умеет. А,

и это вот мем про то, что типа не умеет

же, да? И вот это он на тебя так

смотрит. Мне кажется, что а все

руководители ведущих лабораторий, типа

Альтман, Амадей и вот эти все, они вот

таким взглядом на нас смотрят, и мы все

такие типа точно точно не умеют. Ну пока

что не умеет, по моему опыту.

Я уже, очевидно, то есть пока что машина

в основном себя ведёт как плохой

аутсорсер, который говорит типа: "Да,

всё будет сделано. Сейчас мы тебе всё

перефигачим, как бы ради ради того,

чтобы были секунды в твоих рефералках".

А и пофиг, что там всё сломается и

дальше я не смогу этот кодбейс

поддерживать. А, ну и про обещание

ответственность я, извините, плохо

подготовил презентацию. Тут должен быть

быть слайд компании IBM. Помните там, э,

вот эту картинку знаменитую семьдесят

четвёртого года, где написано типа

компьютер не может нести

ответственности, поэтому компьютер не

должен принимать решения. Все решения

должны приниматься человеком. Тебе

важное решение. А как сделать так, чтобы

компьютеру было хотелось как бы

придумать out of the box решение, потому

что он уже обещал бизнесу, что он за

неделю что-то сделает? Я я не знаю.

Есть, конечно, всякие способы смешные,

когда, а, знаете, слышали, наверное, что

если от нейросети, что там кто-то умрёт,

если это не получится или там или как

там дети в Уганде будут умирать, то он

лучше работает, типа, и неросите можно

таким образом заставлять качественнее

думать. Но мне кажется, скорее скорее

прикол, чем то, что можно использовать.

О'кей. Мм,

а что можно делать? Вот типа делать

нельзя, это типа строить э строить

какие-то системы, в которых люди ведут

себя определённым образом. А нельзя

машине, к сожалению, пока что отдать на

строку CD. Она может сделать какие-то

части, но вот самую идею типа как это

сделать и как это раздеплоить и чтобы

оно работало, чтобы данные приезжали с

продакшн. Это всё инженерные работы,

которые пока что очень плохо

автоматизируется, к сожалению. То есть

программистов мы там автоматизируем и

там автоматизируют на пускай будет,

давайте от балды назову там 40%, а с с

админами этот процент гораздо ниже, мне

кажется, там в два-три раза хуже. А всё

пока с задержкой идёт. Нормальную

модульную архитектуру в теории машина

знает, но на практике пока с этим очень

туго у нас, честно говоря, пока не

получается. А может быть там просто

отсталые уже часто так говорят, что если

ты что-то не можешь сделать с помощью

искусственного интеллекта, просто типа

скил слишё, ты просто не умеешь этим

пользоваться. Ну и, наконец, умение

говорить бизнесу, типа давай попроще

придумаем вариант. Я думаю, что это в

теории можно сделать с помощью промтов,

но пока что я таких эффективных качеств

промтов и такого эффективного

использования пока что не видим. А что

можно делать?

По нашему опыту, искусственный интеллект

супер классно помогает во время аудитов.

Если вам нужно разобраться в чужом,

старом сходном коде, в том самом Leg, то

искусственный интеллект может быть

отличным собеседником, что ты им не

говоришь сделать всё хорошо, а говоришь

там: "Объясни мне, как это устроено,

покажи мне кусочек, в котором я типа я

до я уверен, что здесь где-то есть

авторизация. помоги мне найти место, где

авторизация, например. А другая очень

важная такая high impact пространство,

если ты пишешь новый код или если ты

переделываешь старый код, а Иишка очень

хорошо пишет тесты. Мы писали тесты, мы

всю жизнь жили по TDD, Test Driven

Development, и часто страдали, потому

что тебе нужно там объяснить клиенту,

почему ты на 30% больше времени тратишь

на те же самые задачи, что и другие

разработчики. Просто потому, что мы

всегда пишем тесты. И мы, безусловно,

объясняем, что типа, знаете,

краткосрочно вы немножко потеряете,

долгосрочно выиграете, но всё равно это

какая-то сложная продажа. А в случае

искусственным интеллектом он, в

принципе, довольно хорошо пишет тесты,

но ту важно, а, во-первых, это

внимательно самому читать, потому что

часто искусственный интеллект проверяет

не то, что тебе надо, он типа что-то

проверяет, но не основную бизнес-логику.

Тут важно ему подсказать, в чём эта

основная бизнес-логика, чтобы он это

сделал. Я, кстати, очень сильно верю,

что в тот момент, когда у нас будет

нормальная,

когда у нейросетей появится лучше,

более, когда у нас появится более

хорошие инструментарии для того, чтобы

неросети видели контекст, типа, как была

поставлена бизнес-задача, чтобы доступ к

там был к трекеру и к обсуждению

последующему, и потом к промту, который

программист написал. И вот когда не

российски может вот это всё типа весь

контекст если неё скормить, то мне

кажется, она может и очень хороший тест

писать. Но это пока довольно много

работы для того, чтобы этот контекст

собрать. А вот таких систем, чтобы это

всё было из коробки удобно сделано, я

пока ещё не знаю. Я думаю, что их а

можно собрать самому руками. Б я уверен,

что есть там десятки стартапов, которые

скоро что-то подобное сделают.

А, итак, разбираться в коде с помощью

искусственного интеллекта, мне кажется,

это супер классная штука. И тесты

писать, мне кажется, с появлением

хорошейшечки вот за последние там

полгода

нет причин не делать нормальный диди.

Это как бы совсем теперь это сильно

дешевле, и при этом ты получаешь все

бонусы того, что

софт не падает просто. Так, а полчаса я

уже говорю, скоро уже закончу и будут

временные вопросы.

как программировать. Ну, типа мои просто

такие микросоветы. Опять же, я чувствую

немножко себя странно, потому что

коллеги, мне кажется, говорят гораздо

более глубокие штуки. Но если вы там

супер ультранормес, как бы, э, очень

полезно показывать примеры реализации.

Типа мы у мы у нас в проекте делаем вот

так, типа, вот пример того, как мы

сделали. Это всё можно укладывать в agd

или в cloud mdм

инструментом пользуетесь. Но если вы это

в каком месте нормально опишете, то

нейросеть будет вести себя так, как

так, как вёл бы себя хороший

программист, который познакомился с

проектом, ведёт себя и и пытается

следовать канонам вот этого вашего

монастыря. А

план билд опять же кажется это всё

становится менее важно с развитием

университе до сих пор по моему опыту и

поту моих коллег а сначала планировать

работу потом говорить а теперь по этому

плану выполняем кажется более эффективно

чем просто говорить сделай что-то

классное при этом билдшак в принципе

можно попытаться использовать более

дешёвую более простую модель хотя по

моему путу лучше всегда использовать

самую дорогую и будут хорошие результаты

Может быть, я не так много программирую,

просто поэтому я могу себе это

позволить.

Ещё очень важный пункт - это вам может

показаться смешным, но очень многие

программисты экономят токены. И мы,

кстати, замечали,

у нас корпоративный аккаунт, есть, типа,

который мы даём разработчикам, и там в

организации типа можно посмотреть, кто

сколько потратит. Там есть ребята,

которые очень мало тратят. Мы уже в

какой-то мо думаем, блин, может они

использут не не пользуются искуственным

интеллектом. Это странно. И оказалось,

что ребята сами себе покупают подписку

личную и её используют. В общем,

рекомендую присмотреться, если вы

руководитель, присмотреться к тому,

сколько токенов жгут ваши сотрудники.

Это число, мне кажется, это хорошая

метрика для максимизации

в разумных пределах.

М стесняться этого точно не стоит. То

есть почему-то вот у

у меня такого стеснения не возникает, но

некоторые ребята реально пытаются их

экономить. Мне кажется, это

контрпродуктивно. Потому что время

программистов гораздо дороже, чем, а,

самые дорогие подписки даже даже в нашей

текущей экономической ситуации.

А если подводить итог, то мне кажется,

что в вот этом режиме YOLO, you only

leave ones, когда типа не расеть, просто

отпускаешь и она делает всё, что хочет,

можно делать только совсем какие-то без,

ну, маленькие временные штуки на выброс.

Пишечки,

демки какие-то, ндосики. Вот там можно

как бы просто сказать: "Не расти, сделай

хорошо". И она сделает вот каким-то

набором правил, которые мы обсудили. А

если ты хочешь делать что-то

долгосрочное,

то, к сожалению, это очень похоже на то,

когда ты пытаешься сделать большой,

сложный, важный продукт с помощью

джунов.

Если вы предприниматель, вы, наверное,

уже обжигались. Мне кажется, все рано

или поздно обжигались. Все, все, все,

кто долго на этом рынке, обжигались тем,

что типа говорят: "Ду вроде нормальные

ребята, как бы что они сейчас сядут,

напробуют". Но они вначале нормально

напробуют, но потом это поддерживать не

смогут. Вот с Несетий примерно та же

история. Очень большой энтузиазм, очень

быстро делают и не спорят совсем, но

поддерживать это невозможно. Поэтому тут

нужно быть старшим товарищем, который

внимательно ревьют весь этот код и

отправляет его на доработку или там

объясняет, как выстроить архитектуру,

подсказывает, как выстроить архитектуру.

А, то есть в каком-то смысле это работа

для программистов, просто для

программистов не начинающих, а там

более-менее опытных. Что будет с

джунами? Это типа вообще отдельный

вопрос. Мне кажется, у нас достаточно

времени, можем это сейчас обсудить. Но

вот этот, ну, если отвечать на тезис, на

вопрос, который название моего доклада,

типа, нуж программисты больше не нужны,

ну, типа джуны, наверное, для того,

чтобы сделать пишку, больше не нужны. А,

а вот для всего остального всё так же

нужны все те же самые скилы. Типа ничего

не изменилось на самом деле, кроме того,

что теперь можно гораздо быстрее писать

код. Ну, мне кажется, ключевые вещи

навыки. навык задавать бизнесу вопросы,

убеждаться, что им нужно именно это,

предлагать другие решения. Это же всё

софт skills, которые никуда, они,

кажется, даже просто стали важнее,

потому что вот этот умение просто тупо

писать код, оно сейчас, мне кажется,

постепенно будет обесцениваться, а вот

всё остальное, 90%, даже скажу, не 80, а

90% работы программиста, это всё

остаётся как есть.

А мне кажется, это мой предпоследний

слайд. Последний вот такой. Спасибо вам

большое. А буду рад, если вы задаёте мне

вопросики.

Надеюсь, не слишком про не слишком

базовый контент. Тогда

>> тогда простите. Кодушно готов ответить

на вопросы в ходе дебатов.

>> Самат, спасибо большое. Вот классный

доклад и очень манера импонирует.

Коллеги, задавайте вопросы. Я какие-то

вопросы себе утащил Фейлик, чтобы потом

передать Самату, как всем нашим

спикерам. У нас был, знаешь, какой

любопытный вопрос про ответственность.

Вот, потому что многие спикеры про это

говорили. А что ты вкладываешь вот в

понятие ответственность разработчика?

>> А,

прости, пожалуйста, я понял, что я

последний картинку ещё не показал. Я

обязательно сейчас отвечу на вопросы.

>> Я просто покажу.

Если вы читаете мой канал, то вы,

наверное, видели эту картинку, а или в

твиттере как бы подписаны на модные

аккаунты. А это реклама, это это газета

из журнал из девяносто первого года. Это

как тогда у нас как у нас сейчас

Telegram-каналы, тогда были журналы,

короче. И тут вот, видите, говорят, что

объектно ориентированно

программирование, типа всё, теперь

вашему оно может помочь вашему бизнесу

запробовать что угодно, и даже ребёнок

может пробогать. Мне кажется, это супер

похоже на то, что сейчас говорят про

искусственный интеллект.

>> Так, прости, пожалуйста. Саша, ты

спросил про ответственность.

>> Картинка кайф. Да, про ответственность.

>> Ответственность. Мне кажется, во что я в

это сейчас я верну обратно тот слайд,

чтобы никого не смущать. А,

ответственность.

Ух,

ну смотри, базово, а я просто опишу, как

у нас процесс устроен. Мне кажется, так

будет проще. А у нас в начале недели все

программисты говорят, типа, я сделаю за

эту неделю там какую-то фичу.

Желательно, чтобы бизнес понял, что это

такое. То есть сказать бизнесу: "Я

отрефакторую модуль XYZ", как бы, и

никто не понимает, что это значит.

Плохой плохой плохое обещание. А, а

хорошее обещание - это типа появится

кнопочка, по которой можно будет вот это

сделать, чтобы можно было оценить,

получилось это или нет, и можно было

принять эту работу. Ээ и вот

ответственный человек - это тот,

который, э, если он типа доделал, он

просто принёс результат. Но скорее всего

там большие случае вы же, ну, как бы все

знают, что что-то всегда, что что-то

вообще идёт не так. И что-то не так надо

как бы пойти передоговориться.

Вот безответственный программист, он как

бы сидит, ждёт, пока к нему придут, а в

конце недели говорит, типа, ну я там

типа сделал, а потом что-то не

получилось, как бы я не могу сделать,

как бы, и всё.

И что ты как бы сделаешь? уже пятницы,

как бы уже ничего не сделать, уже ничего

нельзя, как бы просто продолбали дедлайн

сти продолбали результат нет, бизнес

вперёд не двинулся. Ответственный

программист, он приходит к тебе во

вторник и говорит: "Так, я проделал там

предварительный ресarch, вот это, вот

это сделать не получается. Я подумал,

мне кажется, что можно сделать вот так.

Это будет проще, но тоже решить

бизнес-задачу". И вот я это понимаю под

ответственностью, а не что-то там такое,

что надо перерабатывать по ночам. Мне

кажется, это умение вот именно давать

обещания и выдерживать их. Это как вот я

уже повторяю это пятый раз, и может быть

я типа не совсем доношу смысла этой суть

этого предложения, но для меня это прямо

ультраважно, потому что для меня это

отличает

Есть такая фраза ещё у нас в индустрии,

навернока слышали, типа есть low

maintenance чуваки, есть highance

чуваки. Типа есть люди, за которыми надо

присматривать, а есть, которые

самостояте, которые о есть люди, которые

создают проблемы, есть, которые их

решают. Вот я пытаюсь типа находить тех

программистов, которые решают больше

проблем, чем создают, а из которых не

надо пости. О, вот это ещё фраза мне

дико не нравится. Это типа как пости

котов, да, блин, надо нанимать людей,

которых не надо пости, которые сами типа

бизнес пользу приносят. Надеюсь как-то

не

>> Да, да, да, спасибо. Помним такую книгу,

да.

>> Очень очень сильно плюсую в последней

фразе.

>> Слушай, а вот вопрос такой от

Александра. Какие само у тебя ожидания

от дальнейшего развития е-системы? Как

быстро он сможет забрать на себя все

остальные функции? Что думаешь?

>> У меня есть вот ээ те позитивный исход,

негативный исход. позитивный исход

будет. То же самое, что вот я картинку

пошарил, помните, только что показал,

где ребёнок как бы на унитазе сидит, на

горшке сидит и как бы с помощью объектно

ориентированного программирования меняет

мир. Вот как бы тут сейчас происходит то

же самое, только вместо объектно

ориентированного программирования у нас

как бы и программирование, да, оно,

безусловно, мощнее, это круче, чем

объектноориентированный, я не спорю с

этим, но мы типа уже видали. Я уверен,

что если бы были такие айтишные журналы,

там в шести в семидесятые, то были бы

фразы типа был аслер, стал фартран, как

бы фартран всё как бы everything. Теперь

как бы бизнес может А, ну про SQL.

SQL-то придумали как язык, чтобы без

программистов аналитики могли сами типа

обращаться к базе данных. Похожий на

английский язык, между прочим, тоже. Ну

как бы знаем, куда всё это зашло. Как бы

всё равно программисты это SP долго

напишут. А я к тому, что

если всё вот типа один сценарий, один

консервативный, я бы его сказал, назвал,

это сценарий, по которому и станет

умнее, но не радикально. И вот эти все

штуки про а пушбэк в первую очередь,

когда бизнес тебе что-то хочет, ты им

говоришь: "Блин, сложная штука, давай

так не делать". первое архитектуру

глобально и сисадминские их будут

продолжать делать люди, безусловно,

гораздо эффективнее и быстрее, но будут

продолжать. Второй сценарий, я бы назвал

его негативным, хотя он типа позитивный,

типа лучше будет получать свой

искусственный интеллект, но мне кажется,

если машина научится это делать прямо

полный цикл, то это будет означать, что

машины могут делать, в принципе, то, что

делает человек. И тогда

они заменят людей не только в

программировании, но и в других

областях. И тогда как бы вопрос, что

делать с программированием будет вообще

типа настолько низко наше списка

приоритетов, потому что там начнутся

проблемы экономические, социальные, люди

без смысла, как будут жить, как как бы

за как нам распределять еду, что так,

раз люди не нужны, вот это всё. И там

как бы будут проблемы, где спички найти,

соль, патроны, как бы вот это всё. Мне

кажется, проблема типа что делается с

программированием будет типа неважная. И

мне, конечно, хотелось бы, чтобы был

первый сценарий, но я так вот не знаю,

когда, ну, типа по я не исключаю

второго, но ко второму подготовиться не

никак не подготовишься. Поэтому в целом

вот говорят, что все эти создатели

искусственных интеллектов, кстати,

выкопали себе бункеры. Типа они говорят,

конечно, о том, что у нас ждёт райские

сады, но при этом типа строят бункеры

>> на всякий случай. Дада. Да,

>> на вся на вся. Вот так вот как бы

решили. Мне кажется, важнее смотреть на

дела, чем на слова. В этом плане, как

бы, я им доверяю. Но я подготовлюсь пока

к первому сценарию. Я бункер строю. Я

скорее, а, просто пытаюсь не то, чтобы

быть на санстрее, мне это не супер

интересно, но типа вот не пользоваться

сейчас современным сотомоделью,

современным харнесом и не делать уже там

субагенты или как это вот называется,

когда много параллельно работают, это

уже немножечко типа ээ вот если этого не

делать, то тогда у меня вопрос, как бы

ты что, совсем что не следишь? Это же

дико интересно. Но при этом, а, тут, мне

кажется, мы, мы с вами сейчас вот все,

сколько у нас сейчас человек здесь? 719

человек. Вот, типа, все, кто здесь

сидят, 100% знают гораздо больше, чем в

среднем по индустрии. Просто, чтобы вы

понимали, большинство, там недавно был

опрос, что больше полови 70. там

какие-то безумно высокие цифры

программистов в хинтехе, то есть людей,

которые в банках программируют, они типа

не слышали про это, не пользуются

искусственным интеллектом для

программирования.

То есть мы находимся вам может, ну, у

меня иногда тоже возникает чувство, что

я отстаю, но мы отстающие в авангарде,

как бы мы, э, ну, знаете, когда этот

Ладно, очень много говорю. Саша, задавай

следующий вопрос. Нене не меня,

как ты сказал бы, в вангарде

>> отстающего

отстающего в вангарде, как бы, да,

впереди нас кто-то есть, но, блин,

основная масса там сильно сзади, как бы

можно в этом плане можно так очень

сильно не напрягаться. Дада. Да, это

хорошо, коллеги. Вопросы, потому что

часть вопросов я взял, но они, мне

кажется, какие-то узкоспециальные. Вот.

Есть ли какие-то вопросы ещё к Самату?

Давайте что-нибудь спросим, вот, и будем

спикера отпускать.

Как найти?

А,

>> давай,

>> смотрите, у нас есть,

>> блин, ладно, я уж всех как-то раскрою. У

нас есть тестовое задание. Если чувак

опытный, то ты у него просто

спрашиваешь, какие проекты он сделает.

Тут как бы всё понятно. А вот если это

условно, ну, это новичок или человек,

который не может ничего публичного

показать, исходник почитать, ты его не

можешь, то можно дать ему тестовое. Ну

и, наверное, он как бы нормально должен

к этому отнестись, развему нечего

показать.

И это тестовое, тут как бы прикол, как

ты его сформулируешь. Если дашь ему

задачу, которая чисто программистская,

то он, безусловно, её сделает отлично.

Не рассетить за него это абсолютно 100%

сделать. Но у нас, ну, я сейчас приведу

просто пример задачи, а вы наверняка

сможете придумать себе такую сами в

своём бизнесе. У Феди есть школа для

программистов, школа сильных

программистов, где типа из медлов делают

синьоров. Ну неважно. У него, короче,

есть образовательная система. В этой

образовательная система люди

регистрируются, может даже платят

деньги, а потом не пользуются. Логично,

что таким людям стоит послать email

письмо, чтобы они типа вспомнили об

этом, зашли и там попользовались. А и

вот у тебя есть кодс, в котором всё

сделано, но нет этой функциональности.

Типа на тебе не присылается письмо. И ты

говоришь человеку, типа, сделай,

пожалуйста, такую функциональность. И

смотришь, что он сделает.

Люди ведут себя очень по-разному. Кто-то

типа просто делает штуку, которая каждый

день отправляет по одному письму или

отправляет одно письмо и всё, и говорят:

"Я сделал". Есть люди, которые

отправляют каждый день по одному письму.

Такие письма, ну, очень часто, очень

быстро ты попадаешь в спам, как бы, и и

твой рейтинг падает. Это, короче, вообще

опасная штука. Первых не берём,

во-вторых, тоже не берём. А есть люди,

которые такие типа: "Ну, я не совсем

понял, что нужно делать". Таких тоже не

берём. А, а есть люди, которые приходят

и говорят: "Так, очевидно, типа, одно

письмо отправлять нельзя, каждый день

тоже нельзя. Давай придумаем, давай

сделаем. Типа есть опытный человек,

который говорят: "Тутко, как бы первый

день, третий день, седьмой день, больше

не пишем". Или там какую-то схему,

короче, предлагают. Есть люди, которые

типа просто сделают по такой вот на

адекватной схеме и перенесут результат.

Это, в принципе, о'кей. Зависит от

вашего бизнеса. Кому-то такое прямо

совсем хорошо, а кому-то лучше, чтобы

разработчик пришёл и сказал: "Я вот

такую схему придумал, тебе как?" Типа

нормальный бизнесовыва, давай делать. Ну

вот вот эти последние два варианта, они

хорошие, как бы таких берём. Это признак

ответственности. То, что человек

подумал, что нужно сделать. А и ещё если

он там пропал на 2 недели и потом тот

пришёл ждать, тоже как-то стрёмно. Если

он там типа, ну, в общем, такие просто

человеческие штуки, мне кажется. Вот мы

так, мы так делаем. А ещё можно на 2

недели сделать тест-драйв. Мы так часто

делаем, когда мы просим людей поработать

с нами 2 недели и даём им реальные

задачи из какого-нибудь не

супероопасного проекта. Мне кажется,

Николай именно про это тоже говорил, что

типа надо давать людям ошибаться. А мне

кажется, это не только про искусственный

интеллект, но и просто про разработке.

>> Да, само можешь

>> Коль, давай,

>> Саш, извини, я тут быстренько ворвусь.

Просто очень интересная тема. Я не стал

вставлять вот это в мои предсказания про

рынок, но мне кажется, что вот эта штука

тоже будет распространяться, кроме

обычных тестовых заданий, да, ещё и

тестовый период. Самат, вот подскажи,

как ты продаёшь эту идею? Условно

периода

>> другим людям и буквально кандидатам,

потому что многие люди прямо боятся

почему-то так делать.

>> А, ну идея такая, типа, тебе может всё в

нас нравится, и нам вроде тоже в тебе

всё нравится, но, ну, пока мы типа

вместе, а вам сказать, нельзя

материться. А не материться, пока вместе

говна не подимка.

>> Это в чате нельзя. В чате нельзя.

Докладчикам иногда можно. Аэ, как пока

вместе говна не поешь, как бы человека

не узнаешь. И нам нужно вместе как бы

попробовать что-нибудь сделать. Э-э, и

обычно люди о'кей, потому что, смотрите,

если он работает сейчас на работе, то

он, наверное, может как бы 2 недели

выделить. Если он у него нет работы, то

тогда уж совсем как бы очевидно, в чём

типа в чём для него минусы. Кажется,

минусов нет. Тем более, что мы за это

заплатим. А, мы за это, безусловно,

платим.

>> И платим нормально, в смысле, просто по

обычной зарплата.

А если чувак прямо сильно, ну я просто

не очень, ну, в смысле, это предмет, это

на самом деле тоже поверхность для

разговора, типа, а почему он не

почтливый? Это же интересно. Ты про

чувака узнаёшь, может быть, он тебе так

как бы объяснит, что ты такой: "Ну

>> и тогда нам не стоит работать вместе".

>> Да, да, я ещё коротко тут докопаюсь. Э-

консёрн, короче, есть. Ты вот сказал,

что если человек на работе, то, ну, он

может поработать. Но как он может

поработать?

Как вы менеджрите? Во, во. Я я я тоже

обычно так советую.

>> Интересно. Во-первых,

>> да.

>> А партайм пробуете?

На работе своей работаешь? Мы мы так

очень не любим, потому что

мне кажется, что основная ценность на

самом деле человека, она в том, что

человек может выбрать себе очень много

контекста и потом удивительными образами

из него что-то синтезировать. И вот если

чувак, вот это, кстати, про этот, есть

же сейчас такой феномен, что люди по

неско на нескольких работах сразу

работают, да? И мне кажется, что здесь

стрёмн в том, что ты, ну, вот никак я

мне сложно представить человек, который

может в себя вгрузить контекст

нескольких футайм работ, нескольких

организаций, нескольких бизнесов,

а, и причём на таком уровне, на такой

глубине погружения, чтобы быть полезным

как программист, как менеджер, может

быть, как руководитель технический,

наверное, может быть, но вот на уровне

программиста, чтобы прямо как бы вот

прямо на пачиков пальцев это держать,

Мне кажется, это невозможно. И в этом

плане, если типа ты не замечаешь, что у

тебя человек работает на трёх работах

просто по его аутпу, это значит как бы

туда тебе и дорога в том плане, что ты

ты как бы ты оцениваешь не то, в чём

человек ценен, а ты оцениваешь какие-то

там строчки кода, как бы. А вот отличить

человека, который реально думает над

проектом, довольно ну легко. просто по

тому, типа как он с тобой общается,

сколько он делает, не общается, да, это

плохое слово, потому сколько он приносит

пользы в проекте, потому что А я,

кстати,

добавлю, мне кажется, что может быть, то

есть я не уверен, что это уникальная

человеческая способность. Мне кажется, у

нас очень хороший, ну, весь мир построен

для нас, чтобы нам было удобно контекст

впитывать. Если типа неросети дать

возможность этот контекст

вссать и у него достаточно будет памяти,

возможно, у него тоже будет вот этот

синтез как бы происходить. Я не знаю,

это вот проentржентное

свойство. Я не знаю.

>> Я вообще очень сильно согласен со всем,

что ты тут говоришь. Ну давай передавать

Саше слово отсму вопросом. 5 минут у

него забрал из доклада.

>> Не, не, всё, всё нормально. Да, Коль,

спасибо, что включился. Мне кажется,

очень тема. Самат, спасибо тебе

огромное, что нашёл возможность к нам

заглянуть. Коллеги, давайте

аплодисментами спикера проводим. Вот все

немедленно подписываемся на канал, если

ещё не там.

>> Всё, Самат, спасибо тебе большое. Давай.

>> Спасибо вам.

>> Отпускаем, отпускаем.

>> Пока-пока, Самат.