#рынок_труда
Как изменилась конкуренция на рынке труда в ИТ за 2025 год. По джунам мидлам и синьорам.
Если коротко - джунам стало в два раза тяжелее за год, конкуренция среди синьоров изменилась не значительно.
Автор: @aiscepticism
Как изменилась конкуренция на рынке труда в ИТ за 2025 год. По джунам мидлам и синьорам.
Если коротко - джунам стало в два раза тяжелее за год, конкуренция среди синьоров изменилась не значительно.
Автор: @aiscepticism
👍2🎄2🤔1
Современная "охота на ведьм"
Если ты придумал, как делать свою работу быстрее без потери качества — это не должно никого волновать. Важно не как ты сделал работу, а за что ты отвечаешь.
Последнее время всё чаще возникает ощущение, что все вокруг пытаются друг друга уличить в использовании нейросетей.
Авторов статей критикуют за длинные тире, дизайнеров — за гиперреалистичность, разработчиков — за вылизанный код, а соискатели с HR’ами соревнуются, кто быстрее задетектит, что с ним общается AI-агент, а не человек.
Можно долго спорить, хорошо это или плохо. Но важнее другое: это уже наша новая реальность.
Некоторые люди впадают в синдром самозванца и стараются скрывать, что используют инструменты автоматизации на базе AI — как будто это что-то неловкое, потому что качественная работа теперь всё чаще вызывает вопросы.
Но почему бы не относиться к этому просто как к инструменту?
Совершенно не важно, как ты сделал свою работу, если ты добился результата. Важно другое — что ты декларируешь и за что отвечаешь.
Если ты опубликовал текст, созданный с помощью нейросети, и выдаёшь его как своё мнение — значит, ты за него отвечаешь. Не важно, что сформулировать мысль помог AI, важно, что это твоя позиция и ты выбрал правильный инструмент, чтобы её донести.
Не важно, если резюме составлено нейросетью — важнее, что оно отражает реальный опыт.
Точно так же не важно, что код, вынесенный на ревью, был сгенерирован нейросетью. Гораздо важнее — кто за него отвечает.
А ложь — это отдельный вопрос. Люди врали и до изобретения нейросетей, этого не изменить.
Программист, как и любой специалист, — это в первую очередь про ответственность.
А если ты придумал, как делать свою работу быстрее без потери качества — это не должно никого волновать.
#мысли #ai
Если ты придумал, как делать свою работу быстрее без потери качества — это не должно никого волновать. Важно не как ты сделал работу, а за что ты отвечаешь.
Последнее время всё чаще возникает ощущение, что все вокруг пытаются друг друга уличить в использовании нейросетей.
Авторов статей критикуют за длинные тире, дизайнеров — за гиперреалистичность, разработчиков — за вылизанный код, а соискатели с HR’ами соревнуются, кто быстрее задетектит, что с ним общается AI-агент, а не человек.
Можно долго спорить, хорошо это или плохо. Но важнее другое: это уже наша новая реальность.
Некоторые люди впадают в синдром самозванца и стараются скрывать, что используют инструменты автоматизации на базе AI — как будто это что-то неловкое, потому что качественная работа теперь всё чаще вызывает вопросы.
Но почему бы не относиться к этому просто как к инструменту?
Совершенно не важно, как ты сделал свою работу, если ты добился результата. Важно другое — что ты декларируешь и за что отвечаешь.
Если ты опубликовал текст, созданный с помощью нейросети, и выдаёшь его как своё мнение — значит, ты за него отвечаешь. Не важно, что сформулировать мысль помог AI, важно, что это твоя позиция и ты выбрал правильный инструмент, чтобы её донести.
Не важно, если резюме составлено нейросетью — важнее, что оно отражает реальный опыт.
Точно так же не важно, что код, вынесенный на ревью, был сгенерирован нейросетью. Гораздо важнее — кто за него отвечает.
А ложь — это отдельный вопрос. Люди врали и до изобретения нейросетей, этого не изменить.
Программист, как и любой специалист, — это в первую очередь про ответственность.
А если ты придумал, как делать свою работу быстрее без потери качества — это не должно никого волновать.
#мысли #ai
🔥11💯6
Стоит ли переходить из разработки в лиды?
На эту тему меня попросили поделиться мнением для статьи на Хабре. Всего было два вопроса, и в статье приведена очень короткая цитата, так как она больше про общий сборник советов и список курсов. Но тут я приведу ответы полностью.
1. Какие качества должны быть у тимлида, чтобы расти в карьере и эффективно управлять командой?
Сильнейшее качество тимлида, на мой взгляд, — защита фокуса команды. Это базовая функция. Тебе нужно следить за тем, чтобы не разрастались лишние созвоны, фильтровать ложные пожары, резать бюрократию и не давать внешним людям ломать ваши приоритеты без внятной ценности. Ты должен следить, чтобы команда не выгорала и не было переработок, а значит, сроки должны быть реалистичными, с проговорёнными рисками. Нужно научиться говорить «нет» заказчикам и предлагать компромиссы. Также важной частью работы тимлида является ответственность за развитие людей как системный процесс. Например, если все вокруг пользуются новыми инструментами — ты должен быть уверен, что в твоей команде у ребят есть время на то, чтобы их изучить. И лучше быть в этом первым, чтобы не сбавлять темпов и оправдывать ожидания без пинка сверху. Ну и результат: нужно не забывать подсвечивать достижения, «продавать» успехи команды наверх и постоянно выравнивать ожидания стейкхолдеров.
2. Как понять, что быть тимлидом — твоё? А когда стоит уходить в экспертизу, а не в менеджмент?
Начать хочется с того, что тимлид — это не следующий грейд разработчика. Это переход из технической роли в управленческую. Будет совсем по-новому, и сильные технические навыки не обязательно помогут справиться с управлением командой. В первую очередь ты перестаёшь думать за себя и начинаешь думать и нести ответственность за всю команду. Любое неверное решение другого человека становится твоей проблемой. Это, кстати, верно и в эпоху AI-агентов, когда не так важно, кто пишет код — гораздо важнее, кто несёт за него ответственность.
Проведите мысленный эксперимент: насколько вам комфортно достигать успеха через других? Если удовольствие приносит не «я закоммитил», а «команда стала сильнее и стабильно делает результат» — это хороший сигнал в сторону менеджмента. Если же драйвит личная глубина, решение сложных техзадач и влияние через архитектуру/экспертизу, а «людские» задачи вы выносите на силе воли — лучше остаться в техническом русле.
Самая частая проблема, с которой сталкиваются лиды, — вопрос: «а что я сегодня сделал?». Иногда ответ очень размытый: «какие-то встречи, двигал таски, что-то обсуждал, и 0 строк кода. А ведь мог спокойно писать себе код и не отвлекаться на это всё!». При этом рынок зарплат часто солидарен и предлагает за такую неявную работу совсем небольшую прибавку.
Возможность защищать команду, выбирать вектор развития, изучать управленческие подходы — несомненно приятный бонус. Но если вы постоянно компенсируете роль через «я сам сделаю быстрее», если раздражают 1:1 и работа с мотивацией, если вам неприятно принимать кадровые решения или если вы чувствуете, что перестали расти как инженер/архитектор и вас это фрустрирует, — тогда лучше честно продолжить рост в технической экспертизе, где влияние достигается не властью, а техническим лидерством.
#teamlead #career
На эту тему меня попросили поделиться мнением для статьи на Хабре. Всего было два вопроса, и в статье приведена очень короткая цитата, так как она больше про общий сборник советов и список курсов. Но тут я приведу ответы полностью.
1. Какие качества должны быть у тимлида, чтобы расти в карьере и эффективно управлять командой?
Сильнейшее качество тимлида, на мой взгляд, — защита фокуса команды. Это базовая функция. Тебе нужно следить за тем, чтобы не разрастались лишние созвоны, фильтровать ложные пожары, резать бюрократию и не давать внешним людям ломать ваши приоритеты без внятной ценности. Ты должен следить, чтобы команда не выгорала и не было переработок, а значит, сроки должны быть реалистичными, с проговорёнными рисками. Нужно научиться говорить «нет» заказчикам и предлагать компромиссы. Также важной частью работы тимлида является ответственность за развитие людей как системный процесс. Например, если все вокруг пользуются новыми инструментами — ты должен быть уверен, что в твоей команде у ребят есть время на то, чтобы их изучить. И лучше быть в этом первым, чтобы не сбавлять темпов и оправдывать ожидания без пинка сверху. Ну и результат: нужно не забывать подсвечивать достижения, «продавать» успехи команды наверх и постоянно выравнивать ожидания стейкхолдеров.
2. Как понять, что быть тимлидом — твоё? А когда стоит уходить в экспертизу, а не в менеджмент?
Начать хочется с того, что тимлид — это не следующий грейд разработчика. Это переход из технической роли в управленческую. Будет совсем по-новому, и сильные технические навыки не обязательно помогут справиться с управлением командой. В первую очередь ты перестаёшь думать за себя и начинаешь думать и нести ответственность за всю команду. Любое неверное решение другого человека становится твоей проблемой. Это, кстати, верно и в эпоху AI-агентов, когда не так важно, кто пишет код — гораздо важнее, кто несёт за него ответственность.
Проведите мысленный эксперимент: насколько вам комфортно достигать успеха через других? Если удовольствие приносит не «я закоммитил», а «команда стала сильнее и стабильно делает результат» — это хороший сигнал в сторону менеджмента. Если же драйвит личная глубина, решение сложных техзадач и влияние через архитектуру/экспертизу, а «людские» задачи вы выносите на силе воли — лучше остаться в техническом русле.
Самая частая проблема, с которой сталкиваются лиды, — вопрос: «а что я сегодня сделал?». Иногда ответ очень размытый: «какие-то встречи, двигал таски, что-то обсуждал, и 0 строк кода. А ведь мог спокойно писать себе код и не отвлекаться на это всё!». При этом рынок зарплат часто солидарен и предлагает за такую неявную работу совсем небольшую прибавку.
Возможность защищать команду, выбирать вектор развития, изучать управленческие подходы — несомненно приятный бонус. Но если вы постоянно компенсируете роль через «я сам сделаю быстрее», если раздражают 1:1 и работа с мотивацией, если вам неприятно принимать кадровые решения или если вы чувствуете, что перестали расти как инженер/архитектор и вас это фрустрирует, — тогда лучше честно продолжить рост в технической экспертизе, где влияние достигается не властью, а техническим лидерством.
#teamlead #career
👍5🔥5💯3
Как не деградировать, работая с нейросетями?
Последнее время кажется, что я деградирую, доверяя всё больше и больше написание кода и ресёрч нейросетям.
Начал замечать, что какие-то вещи уже не «на кончиках пальцев»: названия, boilerplate, конструкции. Раньше нужно было разбираться самому, а сейчас — описал промпт, и всё готово. И в какой-то момент появляется ощущение, что тупеешь.
Но я для себя сформулировал так: если знания можно восстановить за пару минут, их не обязательно держать в голове постоянно. Важно понимать принцип. Да, и вспомнить проще, чем учить с нуля. И тогда это уже не деградация, а перераспределение когнитивной нагрузки — освобождается место для более важных решений.
Экспертность ведь не в объёме выученного. Она в способности брать ответственность и принимать решения в условиях неопределённости. ИИ может ускорить, но последствия всё равно разгребать мне.
Выделил для себя несколько мысленных маркеров, которые помогают отличить признаки деградации от упрощения:
— «оно работает», но я не понимаю, что происходит
— принимаю ответ без проверки
— не могу объяснить решение своими словами
— не могу отдебажить, когда агент уткнулся в ошибку
— избегаю погружения в сложные задачи только потому, что «ИИ же сделает»
Если финальные решения всё ещё принимаю я — значит, это не деградация, а адаптация.
(Полная статья в блоге)
А как вы сдерживаете деградацию знаний?
#coding #ai
Последнее время кажется, что я деградирую, доверяя всё больше и больше написание кода и ресёрч нейросетям.
Начал замечать, что какие-то вещи уже не «на кончиках пальцев»: названия, boilerplate, конструкции. Раньше нужно было разбираться самому, а сейчас — описал промпт, и всё готово. И в какой-то момент появляется ощущение, что тупеешь.
Но я для себя сформулировал так: если знания можно восстановить за пару минут, их не обязательно держать в голове постоянно. Важно понимать принцип. Да, и вспомнить проще, чем учить с нуля. И тогда это уже не деградация, а перераспределение когнитивной нагрузки — освобождается место для более важных решений.
Экспертность ведь не в объёме выученного. Она в способности брать ответственность и принимать решения в условиях неопределённости. ИИ может ускорить, но последствия всё равно разгребать мне.
Выделил для себя несколько мысленных маркеров, которые помогают отличить признаки деградации от упрощения:
— «оно работает», но я не понимаю, что происходит
— принимаю ответ без проверки
— не могу объяснить решение своими словами
— не могу отдебажить, когда агент уткнулся в ошибку
— избегаю погружения в сложные задачи только потому, что «ИИ же сделает»
Если финальные решения всё ещё принимаю я — значит, это не деградация, а адаптация.
(Полная статья в блоге)
А как вы сдерживаете деградацию знаний?
#coding #ai
❤5👍5
Немного освежил личный сайт и блог. Сделал ещё проще! (куда уже!)
- На сайте добавил ссылки и краткую информацию обо мне, добавил тёмную тему
- В блоге поменял сборщик страниц с неповоротливого Hugo на шустрый Astro.JS + мелкие правки
Конечно, странно сейчас в 26 году вести личный сайт. Но яж могу, а значит почему бы и нет! 😛
Если найдёте ошибки - присылайте.
https://henrydev.me
https://blog.henrydev.me
#site
- На сайте добавил ссылки и краткую информацию обо мне, добавил тёмную тему
- В блоге поменял сборщик страниц с неповоротливого Hugo на шустрый Astro.JS + мелкие правки
Конечно, странно сейчас в 26 году вести личный сайт. Но яж могу, а значит почему бы и нет! 😛
Если найдёте ошибки - присылайте.
https://henrydev.me
https://blog.henrydev.me
#site
henrydev.me
Henry Developer
Personal website of Henry Babenko.
👍5🔥5
А у меня хорошие новости! 12 марта я буду выступать с докладом на PHP митапе в Лимассоле на Кипре. Все кто может - приходите меня поддержать! Буду рад встретиться лично!
Вот анонс:
BeerPHP Cyprus, собираемся на офлайн митап!
Beer PHP MeetUp Cyprus при поддержке Mayflower — неформальная встреча для шеринга опыта и общения.
🗓 Когда: 12 марта, сбор гостей 17:30, старт 18:00
📍 Где: Gerrard’s Kitchen Bar, Amathountos 70, Agios Tychon 4532, Cyprus
✅ Регистрация обязательна, количество мест ограничено: https://mayflower-funtech.space/
Программа:
18:00–18:40 — SQLite Index Visualization — Антон Сухачев
18:40–19:20 — AI для PHP-разработчика: где уже точно помогает — Ринат Ахмадеев, Владимир Цаплин, Николай Киселёв
19:20–19:40 — перерыв
19:40–20:20 — Сервисная архитектура на PHP — Генри Бабенко
20:20–21:00 — Realtime продуктовая аналитика на основе Clickhouse — Александр Маничев
#event
Вот анонс:
BeerPHP Cyprus, собираемся на офлайн митап!
Beer PHP MeetUp Cyprus при поддержке Mayflower — неформальная встреча для шеринга опыта и общения.
📍 Где: Gerrard’s Kitchen Bar, Amathountos 70, Agios Tychon 4532, Cyprus
✅ Регистрация обязательна, количество мест ограничено: https://mayflower-funtech.space/
Программа:
18:00–18:40 — SQLite Index Visualization — Антон Сухачев
18:40–19:20 — AI для PHP-разработчика: где уже точно помогает — Ринат Ахмадеев, Владимир Цаплин, Николай Киселёв
19:20–19:40 — перерыв
19:40–20:20 — Сервисная архитектура на PHP — Генри Бабенко
20:20–21:00 — Realtime продуктовая аналитика на основе Clickhouse — Александр Маничев
#event
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍1
IQ-тест на собеседовании — это ред флаг 🚩
Недавно, меня позвали на собес, где предложили пройти IQ-тест. Первая мысль: в компанию, где такое дают всерьёз, я не пойду. Но любопытство победило. Захотелось понять, зачем это вообще и что таким способом пытаются проверить.
Я согласился и прошёл тест. Результат оказался не таким высоким, как я ожидал. И это зацепило. Уже после собеса я решил разобраться, что именно такие тесты вообще измеряют?
Один умный человек сказал: «IQ-тест показывает в первую очередь то, насколько хорошо ты умеешь проходить IQ-тесты, а не реальный уровень интеллекта». Стало любопытно, что вообще значит «уметь проходить IQ-тесты»?
Если приглядеться, в таких задачах, как и в программировании, действительно есть повторяющиеся паттерны. В основе обычно логика, математика и немного геометрии. У меня были задачи на фигуры. Если очень коротко: сначала важно понять, фигуры одинаковые или разные. Если одинаковые — смотришь на параметры: цвет, количество, положение. Если разные — ищешь комбинации, преобразования, повороты, исключения. Связи стоит проверять по строкам, по столбцам, а иногда даже по диагонали.
То есть такие тесты действительно можно проходить лучше, если понимать, как они устроены. Это не только про «интеллект», но и про навык замечать типовые схемы. Когда я разобрался, результат получился на 20% лучше.
Но гораздо интереснее для меня оказался другой вопрос: зачем вообще давать IQ-тест на собеседовании?
И тут я вижу как минимум два возможных объяснения.
🍀 Первое — это элемент стресс-интервью. У меня позиция была связана с менеджментом, в том числе с работой в меняющихся обстоятельствах. И такая просьба действительно может выбить из колеи именно своей неожиданностью. Для кого-то это повод раздражаться, а мне стало интереснее понять, что именно здесь проверяют.
🍀 Второе — и это меня даже немного удивило, такой формат может быть защитой от прохождения собеседований с помощью нейросетей. В задачах на фигуры они до сих пор часто ошибаются, особенно в реальном времени. Некоторые вопросы для них работают почти как капча: человек видит часть признаков сразу, а модель может их пропустить.
В итоге я вынес из этой истории вполне полезную мысль о себе. С годами я привык, в первую очередь, искать простое и практичное решение. А уже потом усложнять, если это действительно нужно. В реальной работе – это полезный скилл. Просто IQ-тест проверяет немного другое.
А вы бы стали проходить IQ-тест на собеседовании или это уже перебор?
#hiring
Недавно, меня позвали на собес, где предложили пройти IQ-тест. Первая мысль: в компанию, где такое дают всерьёз, я не пойду. Но любопытство победило. Захотелось понять, зачем это вообще и что таким способом пытаются проверить.
Я согласился и прошёл тест. Результат оказался не таким высоким, как я ожидал. И это зацепило. Уже после собеса я решил разобраться, что именно такие тесты вообще измеряют?
Один умный человек сказал: «IQ-тест показывает в первую очередь то, насколько хорошо ты умеешь проходить IQ-тесты, а не реальный уровень интеллекта». Стало любопытно, что вообще значит «уметь проходить IQ-тесты»?
Если приглядеться, в таких задачах, как и в программировании, действительно есть повторяющиеся паттерны. В основе обычно логика, математика и немного геометрии. У меня были задачи на фигуры. Если очень коротко: сначала важно понять, фигуры одинаковые или разные. Если одинаковые — смотришь на параметры: цвет, количество, положение. Если разные — ищешь комбинации, преобразования, повороты, исключения. Связи стоит проверять по строкам, по столбцам, а иногда даже по диагонали.
То есть такие тесты действительно можно проходить лучше, если понимать, как они устроены. Это не только про «интеллект», но и про навык замечать типовые схемы. Когда я разобрался, результат получился на 20% лучше.
Но гораздо интереснее для меня оказался другой вопрос: зачем вообще давать IQ-тест на собеседовании?
И тут я вижу как минимум два возможных объяснения.
В итоге я вынес из этой истории вполне полезную мысль о себе. С годами я привык, в первую очередь, искать простое и практичное решение. А уже потом усложнять, если это действительно нужно. В реальной работе – это полезный скилл. Просто IQ-тест проверяет немного другое.
А вы бы стали проходить IQ-тест на собеседовании или это уже перебор?
#hiring
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍3🔥3😁2
Генри / IT-пространство
А у меня хорошие новости! 12 марта я буду выступать с докладом на PHP митапе в Лимассоле на Кипре. Все кто может - приходите меня поддержать! Буду рад встретиться лично! Вот анонс: BeerPHP Cyprus, собираемся на офлайн митап! Beer PHP MeetUp Cyprus при поддержке…
Вышло видео с моей презентацией. Зацените кто не видел.
https://youtu.be/_Da3qpMpVas
Описание:
Как команда пришла к мультисервисной архитектуре на PHP для работы с множеством источников данных и API. Речь пойдёт о том, как объединять данные из разных систем в одном интерфейсе, стандартизировать контракты, добавлять адаптеры и конвертеры для legacy-источников, управлять правами доступа, а также выстраивать наблюдаемость, мониторинг и логирование. Отдельно разбирается, почему для этой задачи выбрали PHP/Laravel, как устроен слой совместимости и как такая архитектура помогает быстрее внедрять новые функции и подключать новые системы.
В докладе:
— проблемы старых панелей и разрозненных API
— единый контракт на метаданные и действия
— адаптеры и конвертеры для legacy
— агрегация данных и разрешение конфликтов
— дочерние источники и сборка “красивой картинки”
— permissions, security & compliance
— мониторинг, логирование и отладка
— передача ответственности продуктовым командам
#speech #event
https://youtu.be/_Da3qpMpVas
Описание:
Как команда пришла к мультисервисной архитектуре на PHP для работы с множеством источников данных и API. Речь пойдёт о том, как объединять данные из разных систем в одном интерфейсе, стандартизировать контракты, добавлять адаптеры и конвертеры для legacy-источников, управлять правами доступа, а также выстраивать наблюдаемость, мониторинг и логирование. Отдельно разбирается, почему для этой задачи выбрали PHP/Laravel, как устроен слой совместимости и как такая архитектура помогает быстрее внедрять новые функции и подключать новые системы.
В докладе:
— проблемы старых панелей и разрозненных API
— единый контракт на метаданные и действия
— адаптеры и конвертеры для legacy
— агрегация данных и разрешение конфликтов
— дочерние источники и сборка “красивой картинки”
— permissions, security & compliance
— мониторинг, логирование и отладка
— передача ответственности продуктовым командам
#speech #event
YouTube
Сервисная архитектура на PHP — Генри Бабенко // BeerPHP Cyprus meetup #4
В этом докладе Генри Бабенко рассказывает, как команда пришла к мультисервисной архитектуре на PHP для работы с множеством источников данных и API. Речь пойдёт о том, как объединять данные из разных систем в одном интерфейсе, стандартизировать контракты,…
🔥11👍4
На сколько глубоко Продакт должен разбираться в системном дизайне?
С нейросетями, проектирование становится важнейшей частью работы над проектом. Чтобы ИИ лучше понял, что от него требуется, нужно самому иметь представление что хочется получить.
Написал список основных тем по System Design, на которые стоит обратить внимание начинающему ПМ-у, чтобы улучшить понимание системного дизайна.
С нейросетями, проектирование становится важнейшей частью работы над проектом. Чтобы ИИ лучше понял, что от него требуется, нужно самому иметь представление что хочется получить.
Написал список основных тем по System Design, на которые стоит обратить внимание начинающему ПМ-у, чтобы улучшить понимание системного дизайна.
👍2🔥2
Вчера Nvidia представила RTX Spark — новый процессор для ПК, точнее SoC: систему на чипе.
Интересно наблюдать, как индустрия ПК постепенно меняется. Десятилетиями рынок настольных компьютеров практически полностью принадлежал x86-процессорам, но сейчас приходят ARM-системы и новые форматы AI PC. Также как Apple Silicon и AMD Ryzen AI - RTX Spark объединяет CPU, GPU и AI-ядра на одном кристалле, что делает такие решения эффективнее старых.
Забавный факт. В конце 80-х Sun Microsystems создала SPARC (Scalable Processor ARChitecture) — один из символов эпохи RISC-процессоров. Спустя почти 40 лет Nvidia выпускает ARM-чип RTX Spark. ARM и SPARC выросли из одной RISC-идеи. Совпадение названий выглядит символично — как будто индустрия отдаёт дань уважения инженерам прошлого!
#Мысли #Nvidia #RTXSpark #ARM #SPARC #RISC #AI #ComputerHistory
Интересно наблюдать, как индустрия ПК постепенно меняется. Десятилетиями рынок настольных компьютеров практически полностью принадлежал x86-процессорам, но сейчас приходят ARM-системы и новые форматы AI PC. Также как Apple Silicon и AMD Ryzen AI - RTX Spark объединяет CPU, GPU и AI-ядра на одном кристалле, что делает такие решения эффективнее старых.
Забавный факт. В конце 80-х Sun Microsystems создала SPARC (Scalable Processor ARChitecture) — один из символов эпохи RISC-процессоров. Спустя почти 40 лет Nvidia выпускает ARM-чип RTX Spark. ARM и SPARC выросли из одной RISC-идеи. Совпадение названий выглядит символично — как будто индустрия отдаёт дань уважения инженерам прошлого!
#Мысли #Nvidia #RTXSpark #ARM #SPARC #RISC #AI #ComputerHistory
🔥5
Путешествие в прошлое скоро станет возможным! Просто не так, как мы себе представляли.
Недавно мы семьёй пересматривали мой любимый фильм — «Назад в будущее». И у нас возникла дискуссия о природе времени и возможности путешествия в нём.
А что, если я скажу вам, что все технологии, необходимые для погружения в прошлое, уже существуют! Более того, всё складывается так, что эффект бабочки в этом случае нам не страшен.
Осталось дело за малым — собрать достаточно данных.
Сегодня мир постоянно записывает сам себя. Смартфоны, камеры наблюдения, видеорегистраторы, экшн-камеры, стримы, 360-видео, архивы, фотографии, карты улиц (*). Некоторые люди уже снимают себя и окружающий мир почти весь день. Появляются проекты, где обычным людям платят за съёмку бытовых действий (*): как они готовят, убираются, ходят, берут предметы, взаимодействуют с реальным миром. Потому что искусственному интеллекту нужны данные о жизни, а роботам — данные о физическом поведении человека в реальной среде.
Дальше всё складывается почти идеально. 3D-реконструкция уже умеет превращать (*) фото и видео в объёмные сцены. Игровые движки в реальном времени создают картинку, которая всё ближе к реальности. VR-шлемы позволяют в эту сцену войти (VR пол от Disney), а хаптик-устройства — не только смотреть, но и ощущать виртуальный мир (*).
Через 20–30 лет мы сможем, надеть очки виртуальной реальности, и погрузиться в 100% воссозданное событие прошлого! Уже сейчас есть все технологии, необходимые для этого, осталось только собрать достаточно данных.
Если данных не хватает, нейросети умеют достраивать недостающие части. Они могут восстановить то, чего не видно в кадре, дорисовать окружение, предположить движение, собрать сцену из разных источников. (*)
То есть путешествие в прошлое уже перестаёт быть фантастикой. Оно просто будет не физическим, а цифровым.
Повлиять, конечно, на ход событий невозможно, но можно быть наблюдателем и присутствовать практически при любом событии, снятом на цифровые носители.
Да, нейронки ещё не идеальны, да, качество картинок ещё не идеально, да, железо для воспроизведения всего этого пока дорогое и передовое. Но это уже возможно.
С эпохами, где не было фото и видео, будет ещё интереснее. Там реконструкция будет строиться на текстах, картинах, чертежах, археологии, описаниях и свидетельствах. И да, это будет не документальная запись, а версия. Но ведь и сейчас наше представление о прошлом основано на источниках и интерпретациях. Никто из нас не видел Древний Рим, средневековый рынок или первое плавание Колумба. Мы доверяем записям, рисункам, находкам и реконструкциям. А значит, для нас такая достаточно качественно воссозданная картина будет неотличима от реальной.
И мне чертовски приятно жить в момент, когда фантастика становится реальностью!
А в какое время или событие прошлого вы бы хотели попасть?
Недавно мы семьёй пересматривали мой любимый фильм — «Назад в будущее». И у нас возникла дискуссия о природе времени и возможности путешествия в нём.
А что, если я скажу вам, что все технологии, необходимые для погружения в прошлое, уже существуют! Более того, всё складывается так, что эффект бабочки в этом случае нам не страшен.
Осталось дело за малым — собрать достаточно данных.
Сегодня мир постоянно записывает сам себя. Смартфоны, камеры наблюдения, видеорегистраторы, экшн-камеры, стримы, 360-видео, архивы, фотографии, карты улиц (*). Некоторые люди уже снимают себя и окружающий мир почти весь день. Появляются проекты, где обычным людям платят за съёмку бытовых действий (*): как они готовят, убираются, ходят, берут предметы, взаимодействуют с реальным миром. Потому что искусственному интеллекту нужны данные о жизни, а роботам — данные о физическом поведении человека в реальной среде.
Дальше всё складывается почти идеально. 3D-реконструкция уже умеет превращать (*) фото и видео в объёмные сцены. Игровые движки в реальном времени создают картинку, которая всё ближе к реальности. VR-шлемы позволяют в эту сцену войти (VR пол от Disney), а хаптик-устройства — не только смотреть, но и ощущать виртуальный мир (*).
Через 20–30 лет мы сможем, надеть очки виртуальной реальности, и погрузиться в 100% воссозданное событие прошлого! Уже сейчас есть все технологии, необходимые для этого, осталось только собрать достаточно данных.
Если данных не хватает, нейросети умеют достраивать недостающие части. Они могут восстановить то, чего не видно в кадре, дорисовать окружение, предположить движение, собрать сцену из разных источников. (*)
То есть путешествие в прошлое уже перестаёт быть фантастикой. Оно просто будет не физическим, а цифровым.
Повлиять, конечно, на ход событий невозможно, но можно быть наблюдателем и присутствовать практически при любом событии, снятом на цифровые носители.
Да, нейронки ещё не идеальны, да, качество картинок ещё не идеально, да, железо для воспроизведения всего этого пока дорогое и передовое. Но это уже возможно.
С эпохами, где не было фото и видео, будет ещё интереснее. Там реконструкция будет строиться на текстах, картинах, чертежах, археологии, описаниях и свидетельствах. И да, это будет не документальная запись, а версия. Но ведь и сейчас наше представление о прошлом основано на источниках и интерпретациях. Никто из нас не видел Древний Рим, средневековый рынок или первое плавание Колумба. Мы доверяем записям, рисункам, находкам и реконструкциям. А значит, для нас такая достаточно качественно воссозданная картина будет неотличима от реальной.
И мне чертовски приятно жить в момент, когда фантастика становится реальностью!
А в какое время или событие прошлого вы бы хотели попасть?
❤4🔥4
Субагенты.
Я тут решил выяснить, чего все так носятся с субагентами для параллельной работы над одним проектом.
С высоты опыта, мне видется это как два кодера, которые одновременно льют правки в проект по FTP. Или как SVN, где простой мерж был отдельным адом.
Вобщем попробовал. Сделал координатора, запустил двух субагентов на малосвязанных задачах.
Итог: один удивился правкам в другой части файла и попытался их откатить. Второй тупо сдался, потому что не понял, почему кроме его правок что-то ещё меняется.
Обычно при разработке с нейросетями для кода я жёстко разделяю git-ветки под задачи. С субагентами это становится ещё веселее: каждый агент либо переключает проект на свою ветку, либо останавливается, поняв, что правит не в той ветке.
Но, есть Git Worktree. Технически он может помочь: разные ветки, разные папки. Но тогда вся простота пропадает. Нужно следить за папками, ветками, правами, потом всё проверять и склеивать обратно. И ещё молиться, чтобы координатор ничего не перепутал.
Ну не могут несколько разработчиков нормально работать в одной папке проекта! Агенты тоже не могут. Один другому всегда будет мешать.
В итоге выигрыш от параллельной работы легко съедается конфликтами, проверками и восстановлением контекста.
Мой вывод: субагенты полезны для исследования, анализа кода, ревью и планов, там где не нужно одновременно править код. Но как параллельные разработчики, они чаще усложняют работу, чем ускоряют её.
А если я всё равно сам должен раздать задачи, следить за ветками, проверять результат и склеивать всё обратно, то проще запустить две обычные сессии и контролировать процесс самому.
Можно начинать кидаться в меня камнями)
(на скрине ответ Grok, в рекламе котрого рьяно продвигается работа с субагентами)
Я тут решил выяснить, чего все так носятся с субагентами для параллельной работы над одним проектом.
С высоты опыта, мне видется это как два кодера, которые одновременно льют правки в проект по FTP. Или как SVN, где простой мерж был отдельным адом.
Вобщем попробовал. Сделал координатора, запустил двух субагентов на малосвязанных задачах.
Итог: один удивился правкам в другой части файла и попытался их откатить. Второй тупо сдался, потому что не понял, почему кроме его правок что-то ещё меняется.
Обычно при разработке с нейросетями для кода я жёстко разделяю git-ветки под задачи. С субагентами это становится ещё веселее: каждый агент либо переключает проект на свою ветку, либо останавливается, поняв, что правит не в той ветке.
Но, есть Git Worktree. Технически он может помочь: разные ветки, разные папки. Но тогда вся простота пропадает. Нужно следить за папками, ветками, правами, потом всё проверять и склеивать обратно. И ещё молиться, чтобы координатор ничего не перепутал.
Ну не могут несколько разработчиков нормально работать в одной папке проекта! Агенты тоже не могут. Один другому всегда будет мешать.
В итоге выигрыш от параллельной работы легко съедается конфликтами, проверками и восстановлением контекста.
Мой вывод: субагенты полезны для исследования, анализа кода, ревью и планов, там где не нужно одновременно править код. Но как параллельные разработчики, они чаще усложняют работу, чем ускоряют её.
А если я всё равно сам должен раздать задачи, следить за ветками, проверять результат и склеивать всё обратно, то проще запустить две обычные сессии и контролировать процесс самому.
Можно начинать кидаться в меня камнями)
(на скрине ответ Grok, в рекламе котрого рьяно продвигается работа с субагентами)
👍4🔥3💯3
Дядюшка Боб Мартин, автор фундаментальных книг по программированию, например Clean Code и принципов SOLID, заявил, что больше вообще не читает код, написанный агентами. Вместо этого он строит вокруг них систему ограничений: тесты, метрики качества и другие автоматические проверки.
Мы вступаем в новую эпоху разработки, где главным навыком становится уже не написание кода и не code review, а проектирование экосистемы агентов, способной стабильно производить качественный код.
Писать код становится задачей агентов. Ответственность за систему, которая этот код рождает, остаётся за инженером. Поэтому на собеседованиях пора спрашивать не SOLID, а умение построить такую экосистему и отвечать за результат её работы.
Мы вступаем в новую эпоху разработки, где главным навыком становится уже не написание кода и не code review, а проектирование экосистемы агентов, способной стабильно производить качественный код.
Писать код становится задачей агентов. Ответственность за систему, которая этот код рождает, остаётся за инженером. Поэтому на собеседованиях пора спрашивать не SOLID, а умение построить такую экосистему и отвечать за результат её работы.
🔥5👍3👎1💯1