Автор, какой у вас опыт в разработке? Если вы недавно (в последние 5 лет) "вкатились", мысли ваши понятны.
Если давно, то нет никакой конкуренции, нет никакого "заменяющего-всех" ИИ и "IT-рабства". Ну разве что кризис, санкции и т.п. Сложности, но не фатальные.
Когда говорим о коммерческой разработке, то каждый разработчик для бизнеса создаёт определённую добавленную ценность (допустим, усреднённую за год), и от ЧАСТИ этой ценности платится зарплата. Всё время работать в минус, заниматься благотворительностью НИКТО НЕ БУДЕТ.
На мой взгляд, проблема не в избытке "псевдо-программистов", а в недостатке толковых, способных разработчиков.
Они все уже где-то работают и менять работу не спешат. А многие с небольшим опытом, кто ищет работу, просто не вывозят. Вот и всё.
Раз автор всё логирует, то можно написать и "тренажёр мышечной памяти". Смотреть, что чаще всего спрашивал и делать llm кой заметки или тест на тему. Можно найти и не очевидные "общие узкие места", но кажется моделька должна быть помощнее чем qwen2.5:7b.
Я уже сказал, что это один из примеров, их можно найти ещё и для всего. На базе ANSI SQL 92 есть много чего, MySQL, PostgreSQL, MariaDB (кто не любит проприетарщину мускуля), Transact SQL и прочее. Это так, навскидку. Это примерно 90% всего интернета, на минуточку. Если вы лично с этим не пересекались, то вы в меньшинстве и нет гарантий, что не пересечётесь никогда. В любом случае, основная идея, что очень ограниченное владение английским будет делать ваш код хуже, менее читабельным и поддерживаемым. Или вы с этим тоже не согласны?
Насчёт того, как где принятно называть таблицы, это не истина в последней инстанции, а стандарты конкретного стека и команды/проекта. Например - как по мне - т.к. в условном мускуле нет many-to-many из коробки, надо использовать таблицу сопряжения (junction table) и вот там вполне можно использовать plural. Типа authors_to_books и т.п. А вот когда обычная сущность, лучше singular (единственное число), почему? Потому что если дальше у вас там будет какой нибудь DAO+ORM типа ActiveRecord, то и название класса будет не Customer допустим а Customers, и это странно, ведь на ООП уровне вы часто будете работать с одной конкретной сущностью, обзывая её множественным числом. В любом случае, это вопрос принятых стандартов, и "истины в последней инстанции" я в этом вопросе не наблюдаю.
Это просто пример, возможно в SAP есть такой стандарт и там это нормально. Во многих других проектах вы будете страдать, занимаясь экранированием этого слова в запросах (а где забудете - получите баги), ибо оно ключевое зарезервированное во многих СУБД.
В более широком смысле - лучшее владение английским позволяет более точно, более репрезентативно именовать сущности, классы, переменные, функции, методы и т.п. Делать код более понятным и поддерживаемым.
Утром — настройка окружения под конкретную задачу: какие MCP-серверы подключить, какие скиллы нужны агенту, какой контекст дать. Потом — декомпозиция фичи через speckit или подобный подход: разбить на атомарные задачи, выстроить зависимости, определить, что можно запустить параллельно. Дальше — запуск агентов. Не одного — пяти-семи, каждый со своей частью задачи. Мониторинг, валидация промежуточных результатов. Если агент застрял — разобраться почему
"Каша из топора" - сначала надо дофига всего настроить руками...
Синиоры-архитекторы — проверяют результат. Смотрят на архитектуру, интеграцию, соответствие бизнес-требованиям.
...а потом - дофига всего проверять, и - вуаля - ИИ "написал" нам проект! Программисты не нужны! 😂
А если серьезно, я вижу не столько сокращающуюся дистанцию между человеком и ИИ, сколько растущий разрыв между разработчиками и не-разработчиками. Не-разработчики часто уверены, что основная сложность разработки - это написание кода, и ЛЛМ эту проблему как бы "решает". Это большое заблуждение, а почему именно - см. ссылку.
Другой тревожный момент заключается в том, что менеджеры и прочие продажники пытаются всё подвести под метрики, высчитывать везде KPI и пр. Иногда это разумно, а иногда нет. И когда я слышу "теперь мы с AI пишем проекты в пять раз быстрее", мой следующий вопрос - какой ценой? За счёт чего? Эти проповеди напоминают рассказы изобретателей "вечного двигателя", мол мы возьмём энергию из ниоткуда и будем её использовать нахаляву.
Так это уже не бизнес, а политика и прочие корпоративные игры. Многие крупные организации этим страдают, т.к. у них большой "запас прочности" и накопленная инерция.
А теперь представьте, если какой-нибудь небольшой стартап вместо тестирования гипотез и поиска эффективых решений начнёт заниматься "кручением пустых циклов для достижения 80% утилизации CPU"... - что с этим стартапом вскоре станет...
Давайте конкретно, статья про разработку, а не "вообще всё IT". Так вот, разработчики НИКОГДА не "росли в тепличных условиях". Так может думать только человек, ни года не проработавший в коммерческой разработке. С точки зрения увлечённого, может немного даже фанатичного разработчика, разработка - это потрясающе интересно, хоть и требует огромных жертв.
НО!
С т.з. "нормального" человека (с разнообразными увлечениями, семьей, личной жизнью и т.п.), который реально пытался в разработку - это САМЫЙ НАСТОЯЩИЙ АД! "Тепличные условия" - наивняк от непросвещённых в теме...
выросло поколение разработчиков, которые привыкли, что их ценность — это код.
[...] либо застываешь в позиции «я просто пишу код»
Выросло поколение манагеров-не разработчиков (и не одно), которые думают, что сложность коммерческкой разработки - в коде... ТОТАЛЬНОЕ непонимание сути разработки...
С 2020-го пошло по-другому. Бизнес стал лучше понимать, за что он платит.
Я вас умоляю... Бизнес ВСЕГДА понимал, за ЧТО он платит. Даже так: бизнес - это ПЕРВЫЙ институт, который СЧИТАЕТ: СКОЛЬКО и за ЧТО он платит, и какие у этого риски и какие должны быть планы на будущее а-ля A, B, C...
Но цифры говорят обратное.
Вот здесь автор начинает оправдывать ожидания. Путает цифры и числа... Теперь всё сходится...
проще и дешевле развить нормального мидла, чем переучивать senior'а
А кто его будет "развивать", манагеры которые путают цифры и числа? Или он должен сам как-нибудь "саморазвиться? =DDDD
Это самое грустное, что я вижу последние годы...
Какая печаль и эмпатия! *смахиваю скупую мужскую слезу
Изначально я сослался на статью, которая более простым (человеческим) языком объясняет метод. Его латинское название - Ab Initio - и он намного более технический и прикладной, особенно в точных науках, чем многие могут подумать.
Автор, напишите куда звонить, хочется потестировать вашего "деда".
Автор, какой у вас опыт в разработке?
Если вы недавно (в последние 5 лет) "вкатились", мысли ваши понятны.
Если давно, то нет никакой конкуренции, нет никакого "заменяющего-всех" ИИ и "IT-рабства". Ну разве что кризис, санкции и т.п. Сложности, но не фатальные.
Когда говорим о коммерческой разработке, то каждый разработчик для бизнеса создаёт определённую добавленную ценность (допустим, усреднённую за год), и от ЧАСТИ этой ценности платится зарплата. Всё время работать в минус, заниматься благотворительностью НИКТО НЕ БУДЕТ.
На мой взгляд, проблема не в избытке "псевдо-программистов", а в недостатке толковых, способных разработчиков.
Они все уже где-то работают и менять работу не спешат.
А многие с небольшим опытом, кто ищет работу, просто не вывозят.
Вот и всё.
Хабр всё ещё торт.
Раз автор всё логирует, то можно написать и "тренажёр мышечной памяти". Смотреть, что чаще всего спрашивал и делать llm кой заметки или тест на тему. Можно найти и не очевидные "общие узкие места", но кажется моделька должна быть помощнее чем qwen2.5:7b.
Ой
Я уже сказал, что это один из примеров, их можно найти ещё и для всего. На базе ANSI SQL 92 есть много чего, MySQL, PostgreSQL, MariaDB (кто не любит проприетарщину мускуля), Transact SQL и прочее. Это так, навскидку. Это примерно 90% всего интернета, на минуточку. Если вы лично с этим не пересекались, то вы в меньшинстве и нет гарантий, что не пересечётесь никогда. В любом случае, основная идея, что очень ограниченное владение английским будет делать ваш код хуже, менее читабельным и поддерживаемым. Или вы с этим тоже не согласны?
Насчёт того, как где принятно называть таблицы, это не истина в последней инстанции, а стандарты конкретного стека и команды/проекта. Например - как по мне - т.к. в условном мускуле нет many-to-many из коробки, надо использовать таблицу сопряжения (junction table) и вот там вполне можно использовать plural. Типа authors_to_books и т.п. А вот когда обычная сущность, лучше singular (единственное число), почему? Потому что если дальше у вас там будет какой нибудь DAO+ORM типа ActiveRecord, то и название класса будет не Customer допустим а Customers, и это странно, ведь на ООП уровне вы часто будете работать с одной конкретной сущностью, обзывая её множественным числом. В любом случае, это вопрос принятых стандартов, и "истины в последней инстанции" я в этом вопросе не наблюдаю.
Это просто пример, возможно в SAP есть такой стандарт и там это нормально.
Во многих других проектах вы будете страдать, занимаясь экранированием этого слова в запросах (а где забудете - получите баги), ибо оно ключевое зарезервированное во многих СУБД.
В более широком смысле - лучшее владение английским позволяет более точно, более репрезентативно именовать сущности, классы, переменные, функции, методы и т.п. Делать код более понятным и поддерживаемым.
"Каша из топора" - сначала надо дофига всего настроить руками...
...а потом - дофига всего проверять, и - вуаля - ИИ "написал" нам проект! Программисты не нужны! 😂
А если серьезно, я вижу не столько сокращающуюся дистанцию между человеком и ИИ, сколько растущий разрыв между разработчиками и не-разработчиками. Не-разработчики часто уверены, что основная сложность разработки - это написание кода, и ЛЛМ эту проблему как бы "решает". Это большое заблуждение, а почему именно - см. ссылку.
Другой тревожный момент заключается в том, что менеджеры и прочие продажники пытаются всё подвести под метрики, высчитывать везде KPI и пр. Иногда это разумно, а иногда нет. И когда я слышу "теперь мы с AI пишем проекты в пять раз быстрее", мой следующий вопрос - какой ценой? За счёт чего? Эти проповеди напоминают рассказы изобретателей "вечного двигателя", мол мы возьмём энергию из ниоткуда и будем её использовать нахаляву.
Увы, халявы не будет.
Миллионы мух не могут ошибаться!
Так это уже не бизнес, а политика и прочие корпоративные игры. Многие крупные организации этим страдают, т.к. у них большой "запас прочности" и накопленная инерция.
А теперь представьте, если какой-нибудь небольшой стартап вместо тестирования гипотез и поиска эффективых решений начнёт заниматься "кручением пустых циклов для достижения 80% утилизации CPU"... - что с этим стартапом вскоре станет...
Давайте конкретно, статья про разработку, а не "вообще всё IT". Так вот, разработчики НИКОГДА не "росли в тепличных условиях". Так может думать только человек, ни года не проработавший в коммерческой разработке. С точки зрения увлечённого, может немного даже фанатичного разработчика, разработка - это потрясающе интересно, хоть и требует огромных жертв.
НО!
С т.з. "нормального" человека (с разнообразными увлечениями, семьей, личной жизнью и т.п.), который реально пытался в разработку - это САМЫЙ НАСТОЯЩИЙ АД! "Тепличные условия" - наивняк от непросвещённых в теме...
Выросло поколение манагеров-не разработчиков (и не одно), которые думают, что сложность коммерческкой разработки - в коде... ТОТАЛЬНОЕ непонимание сути разработки...
Я вас умоляю... Бизнес ВСЕГДА понимал, за ЧТО он платит. Даже так: бизнес - это ПЕРВЫЙ институт, который СЧИТАЕТ: СКОЛЬКО и за ЧТО он платит, и какие у этого риски и какие должны быть планы на будущее а-ля A, B, C...
Вот здесь автор начинает оправдывать ожидания. Путает цифры и числа... Теперь всё сходится...
А кто его будет "развивать", манагеры которые путают цифры и числа? Или он должен сам как-нибудь "саморазвиться? =DDDD
Какая печаль и эмпатия! *смахиваю скупую мужскую слезу
Тут вон под $100 млн только подписной бонус предлагали... На этом фоне $555 тыс./год - детский лепет...
Осталось понять, как они эту "продуктивность" считали...
Изначально я сослался на статью, которая более простым (человеческим) языком объясняет метод. Его латинское название - Ab Initio - и он намного более технический и прикладной, особенно в точных науках, чем многие могут подумать.
Спасибо LLM. Но инфа в общем толковая, статью плюсанул.
Похоже, кто-то переизобрёл метод первых принципов.
Если это правда, то Серёга К. крутой мужик. Солидарность.
Пойду "против течения" многих комментариев и скажу, что это великолепная, визионерская статья.
Зумеры открыли для себя помидорки.
Станцевать ритуальный танец, прыгнуть через горящий обруч, сказать "ку" два раза перед обладателями жёлтых штанов...
Евгений, а теперь покажите нам где в работе новополученные знания с литкода вам пригодились.