Высокотехнологичный процессы производства требуют ПО. Это не только SCADA и МЕS системы, но специалиризованное ПО. Без него производство невозможно и порой по сложности это намного сложнее в разработке и поддержке чем "перекладывание JSONовЭ, сайтов и проч.
Сейчас, в наше время, нейронка дает любой код и проблема в собеседовании не код писать, а проверить способность системного мышления кандидата и наличие просто опыта программирования и работы в команде. Неплохо и узнать какие задачи решал кандидат и на каком уровне. Этого вполне достаточно,имхо.
В Робинзоне довольно простой язык по моим ощущениям. А вот к примеру в Грозовой перевал или еще круче в Алая буква Готорна там вообще мрак с языком местами.
Не знаю насчет агентов, это все требует денег, а в конторе подписок нет и денег на это не дадут, приходится пользоваться браузерными ИИ и чатом. Как разработчик я в общем много чего создал в конторе без всякого ИИ (есть статья об одной моей системе в профиле), но тут повесили на меня задачу другого плана - автоматизацию сбора и рассылки показаний счетчиков из различных географических мест компании, как своих так и арендаторов. Ну короче, часть счетчиков живет на своем сервере в своей БД, часть живет на сайте , туда и передает. Человек заходит на сервер или сайт, формирует отчет средствами сайта и сервера и отсылает по почте. Решил повайбкодить, так как такими задачами не занимался раньше. Начал с СHatgpt, который склонил меня к Pyton\Fast Api. В какой-то момент понял что это не то что нужно, да и работа в чате стала невозможной из за постоянных блокировок. В общем перешел на gemini и POWERshell и на удивление работа пошла. PowerShell оказался тут на своем месте. Быстро мне ИИ наваял скриптов сборщиков показаний из сайта через API и сервера через SQL ( SQL запросы делал я сам ) с шифрованными логинами и прообраз моей БД. Единственное, пришлось некоторые вещи ему подсказывать, как делать правильно. Далее скрипты генерации отчетов в виде файлов и скрипты рассылки через SMTP почту. Естественно с логами и проверками на корректность данных. PowerShell оказался идеально подходящим для такой задачи. Мощная и стабильная система. Тестировал сам, ошибки были но не очень много. Все скрипты далее были оркестрованы в задачи SQL Agent. И вот все готово и первый месяц отработало почти идеально. Я подстраховался и добавил в задания SQL Agent специальный PowerShell скрипт шага, который тормозил задание на 2 часа перед рассылкой ожидая отмашки после проверки отчета. В общем все получилось быстро и вручную это бы заняло у меня полгода вместо 3 недель через чат. Вот и думай, использовать вайбкодинг через ИИ или нет. Я думаю можно, если ИИ это инструмент. Только на поводу у инструмента не стоит идти. Тут нужно системное мышление, так как ИИ склонен к оверинжинирингу, как было сначало у меня с Pyton\FastApi.
Это может быть и сработает для относительно свежих произведений, но если вы возьмете английскую классику 19 века то такой метод будет сильно пробуксовывать, По своему опыту пишу. Там большие сложности в пониманием даже для не новичка в языке, Множество прилагательных, которое сложно реально запомнить и специфических для того времени вещах и понятиях. Если говороить про собственный опыт, то изучение язывка по методу Франка лично мне помогло сильно. Специально там не нужно запоминать, все происходит естественным путем во время чтения.
Недавно решал задачу автоматизации сбора данных по счетчикам и почтовой рассылки показаний для предприятия , которое имеет производство и офис в разных частях города и там тоже есть арендаторы. Но везде установлены счетчики как DLMS так и СпоДЕС ( интервальный учет), тот же Меркурий к примеру есть один и подключение всех счетчиков через GSM модемы на сайт Яэнергетик так и на выделенный сервер для сбора данных с DLMS счетчиков. Раньше оператор заходил на сайт и на сервер , вручную снимал показания и рассылал файлы контрагентам и снабжающей организации.. Я решил не меняя формы отчетов и модели работы сделать автоматизацию c использованием имеющегося сервера SQL,PowerShell скриптов сбора показаний, формирования отчетов и почтовой рассылки. Заняло месяц работы и месяц отладки скриптов с использованием как API к сайту так и прямого зашифрованного доступа к серверу. Для оркестрации всех разработанных скриптов использовал SQL Agent MSSQL. Счетчиков не так много для учета и арендаторов тоже несколько, поэтому в общем такая модель вполне себя оправдала и не потребовались какие-то материальные затраты на оборудование, так как инфрастуктура уже была сделана до меня. Все работает стабильно, но есть иногда проблемы со стабильностью сбора показаний через радиоканал и это требует иногда ручного досбора данных со счетчиков на сайте и на сервере. В принципе эту задачу можно было решить и с помощью контроллера, но это было бы намного дольше и затратнее. Задача решена уже в имеющейся инфраструктуре и в кратчайший срок.
Когда-то давно, в начале 2000-x я реализовал стандартную модель работы дилера по полному циклу - CRM контактами и с историей общения, заказы, расценка как предложение, счет на оплату, ведомость комплектации для снабжения, чего не хватает с учетом складских запасов с учетом сборочных позиций , комплектация с приоритетами и возможностью изменения приоритета и распределения заказных позиций с учетом складских остатков и менее приоритетных закзаов , учет частичных отгузок заказа, ценоообразование с учетом введенных формул, складской учет без остатков ( вычисляемый остаток от прихода, расхода и резервирования под приоритет заказа), ну и формирование отгрузочных документов, накладных и счетов фактур, импорт в 1С Бухгалтерию ( тогда была только бухгалтерия). Ничего подобного тогда не могла обеспечить ни 1С ни другая система, ну может только импортные ERP да и то не все и для небольшой компании это было недоступно. Система прожила 10 лет почти и умерла потому что мне не было возможности ее поддерживать. Хотя поддержки почти не требовалость, так как реализация была на SQL в хранимых процедурах с клиентом DELPHI. Все работало в рамках модели работы компании почти безупречно. Не было тогда никакого ИИ и все делал руками. А еще реализовал хранилище на C# в MSSQL по типу файловой системы ( это типа Filetables на MSSQL).
ИИ это инструмент и не более. Он им и останется. Как любой инструмент в руках профессионала он дает много профессионалу. Это же инструмент в руках непрофессионала даст на порядок меньше и некачественнее. Ну и не стоит забывать, что ИИ часто галюцинирует и дает то чего нет на самом деле и склонен к оверинжинирингу. Много раз убеждался в этом. Так что не все так просто пока.
Использование даже браузерного ИИ помогает в программировании и доработке уже написанного, но не более. В SQL к примеру он частенько косячит, если контекст в мельчайший деталях до него не донести. Иногда придумывает то чего нет. Но главное - часто наводит на мысль, которая в голову не приходит или из той области, которую ты знаешь по наслышке но до нее руки не доходили. Вот это ценно. Но для этого вы должны быть специалистом в той области, в которой используете ИИ. Иначе это бесполезно, если только не ставится цель обучения. Да и то тут есть тоже натяжки. Рефакторинг кода можно делать и это делается как правило неплохо. Платный или бесплатный ИИ все равно остается пока, имхо, инструментом и не более. Нет смысла приписывать ему интеллект, как нет смысла приписывать интеллект шахматному движку, к примеру.
Вы пишете инструкции для инструмента и тут нужна точность, он неспособен работать в нестандартной или неясной ситуации. Для человека пишут с учетом что разберется если очень надо. Вот и ответ на ваше почему.
Пытался один глюк в программе устранить с помощью браузерной LLM. К сожалению потраченное время не увенчалось успехом. Глюк был сложный и все что предлагала модель не работало. Я вспомнил что в этой программе после замены драйвера БД были некоторые изменения и подумал что первоначальный вариант после замены был протестирован и глюка не было. Так и оказалось. В первоначальном варианте из git почти все работало без проблем. кое что подправил и запустил в тестирование. Все работало. Модель ответила стандартным что это было наслоение багов последующих изменений. Но последующие изменения к глюкам не имели отношения. Вот и верь после этого ИИ.
Знаю по себе - это так и есть. Опыт и системное мышление в молодости не очень распостранены. После 40 - 50 это все начинмет работать если есть база знаний.
В области разработки десктопных приложений в связке с SQL ( SQL SERVER, SQLite ) использую и DELPHI и Labview. Нужна быстрая разработка интерфейса системы, скорость и стабильность работы с оборудованием и мониторинг.
Да, вот есть цех где стоят климатические камеры и в них происходит технологический процесс. Но как только температура в цехе превышает плюс 30 с небольшим - все камеры отключаются. Китайские потому что да и сами генерят тепло. Требуется охлаждение немаленького цеха летом и отопление зимой, так как высокотехнологичное оборудование в стойках и сами камеры не расчитаны на работу при минусовых температурах. Надо полагать что сделать климат в огромном цехе не такая уж легкая и низкая по стоимости задача с учетом надежности и обслуживания климатического оборудования.
Нейронка не панацея.Ее еще правильно направлять надо. Вот совсем недавно - решил оптимизировать хранимую процедуру. Немного тормозила, но работала на клиенте. А в студии жутко зависала на минуту и больше. А тормозить не должна была, количество записей небольшое. Индексы все были. Скормил нейронке и пошло-поехало. Итерации за итерацией, но результат еще хуже, потом пошли такие дебри что я сказал стоп. Давай вернемся к началу и проверим все по частям. По отдельности запросы в процедуре, содержащей CTE и select работают ведь мгновенно, а в комплексе - процедура зависает на минуту. И только тут нейронка сообразила что проблема не в коде, который она довела до к полной жести - проблема в Parameter Sniffing и предложила простое лечение - переназначение входной переменной в локальную и вставка в конец процедуры OPTION RECOMPILE. Небольшие правки в четырех частях процедуры и все. Все 20 тыс. строк стали выводится за миллисекунды и в студии и на клиенте. Достаточно редкий случай этот Parameter Sniffing , но он произошел. Я честно говоря подозревал что дело в разных планах выполнения, но столкнулся с таким первый раз и не знал о существовании такой проблемы. Нейронка помогла, но только под правильным руководством нашла верный ответ. Человек без опыта и чутья с этой задачей возможно бы и не справился. Так что польза от нейронок есть, но уповать на них полностью - глупо.
Смотря где они будут не нужны. В крупных корпорациях наверно не нужны. В средних производственных приборостроительных компаниях к примеру, программисты и встроенный софт пишут, и производственный и сервисный, они там сейчас и в будущем будут нужны. Там нет такого кастового разделения как в ПРОГРАММИСТСКИХ КОНТОРАХ.
Даже с навыками программирования не всегда можно сделать быстро и эффективно с использованием нейросети. Недавно хотел подправить код в одном своем сложном приложении в качестве работы с техническим долгом. Думал с нейронкой быстро. Ан нет, забыл контекст этого приложения, уже год не открывал исходники. Полдня потратил с нейронкой на замену части кода, не работает почему-то. Надо разбираться, заново все тестировать, неизвестно еще где что вылезет. К концу дня понял что игра не стоит свеч. Сейчас все привыкли к интерфейсу, проблем нет. Потом будут недовольные и вопросы почему изменилось и т п. Оставил так как есть. Лучшее враг хорошего.
Насколько я понял по себе при игре на гитаре - все верно насчет осознания аппликатуры при изучении новой пьесы. Но сама процедура изучения предполагает, что мозг запоминает мелодию одновременно с постановкой апликатуры пальцев и их движением. Я заметил что если пока не можешь проиграть мелодию внутренним слухом, то и паттерны аппликатуры не запоминаются хорошо. Все взаимосвязано, мышечная и звуковая память. Одно без другого не работает. Особенно это касается не очень простых гитарных произведений.
Это да. Использую электрорубанки Макита уже много лет. Один раз точил ножи у большого рубанка. Кабели все поменял только на более длинные и морозостойкие.
Высокотехнологичный процессы производства требуют ПО. Это не только SCADA и МЕS системы, но специалиризованное ПО. Без него производство невозможно и порой по сложности это намного сложнее в разработке и поддержке чем "перекладывание JSONовЭ, сайтов и проч.
Сейчас, в наше время, нейронка дает любой код и проблема в собеседовании не код писать, а проверить способность системного мышления кандидата и наличие просто опыта программирования и работы в команде. Неплохо и узнать какие задачи решал кандидат и на каком уровне. Этого вполне достаточно,имхо.
В Робинзоне довольно простой язык по моим ощущениям. А вот к примеру в Грозовой перевал или еще круче в Алая буква Готорна там вообще мрак с языком местами.
Не знаю насчет агентов, это все требует денег, а в конторе подписок нет и денег на это не дадут, приходится пользоваться браузерными ИИ и чатом. Как разработчик я в общем много чего создал в конторе без всякого ИИ (есть статья об одной моей системе в профиле), но тут повесили на меня задачу другого плана - автоматизацию сбора и рассылки показаний счетчиков из различных географических мест компании, как своих так и арендаторов. Ну короче, часть счетчиков живет на своем сервере в своей БД, часть живет на сайте , туда и передает. Человек заходит на сервер или сайт, формирует отчет средствами сайта и сервера и отсылает по почте. Решил повайбкодить, так как такими задачами не занимался раньше. Начал с СHatgpt, который склонил меня к Pyton\Fast Api. В какой-то момент понял что это не то что нужно, да и работа в чате стала невозможной из за постоянных блокировок. В общем перешел на gemini и POWERshell и на удивление работа пошла. PowerShell оказался тут на своем месте. Быстро мне ИИ наваял скриптов сборщиков показаний из сайта через API и сервера через SQL ( SQL запросы делал я сам ) с шифрованными логинами и прообраз моей БД. Единственное, пришлось некоторые вещи ему подсказывать, как делать правильно. Далее скрипты генерации отчетов в виде файлов и скрипты рассылки через SMTP почту. Естественно с логами и проверками на корректность данных. PowerShell оказался идеально подходящим для такой задачи. Мощная и стабильная система. Тестировал сам, ошибки были но не очень много. Все скрипты далее были оркестрованы в задачи SQL Agent. И вот все готово и первый месяц отработало почти идеально. Я подстраховался и добавил в задания SQL Agent специальный PowerShell скрипт шага, который тормозил задание на 2 часа перед рассылкой ожидая отмашки после проверки отчета. В общем все получилось быстро и вручную это бы заняло у меня полгода вместо 3 недель через чат. Вот и думай, использовать вайбкодинг через ИИ или нет. Я думаю можно, если ИИ это инструмент. Только на поводу у инструмента не стоит идти. Тут нужно системное мышление, так как ИИ склонен к оверинжинирингу, как было сначало у меня с Pyton\FastApi.
Это может быть и сработает для относительно свежих произведений, но если вы возьмете английскую классику 19 века то такой метод будет сильно пробуксовывать, По своему опыту пишу. Там большие сложности в пониманием даже для не новичка в языке, Множество прилагательных, которое сложно реально запомнить и специфических для того времени вещах и понятиях. Если говороить про собственный опыт, то изучение язывка по методу Франка лично мне помогло сильно. Специально там не нужно запоминать, все происходит естественным путем во время чтения.
Недавно решал задачу автоматизации сбора данных по счетчикам и почтовой рассылки показаний для предприятия , которое имеет производство и офис в разных частях города и там тоже есть арендаторы. Но везде установлены счетчики как DLMS так и СпоДЕС ( интервальный учет), тот же Меркурий к примеру есть один и подключение всех счетчиков через GSM модемы на сайт Яэнергетик так и на выделенный сервер для сбора данных с DLMS счетчиков. Раньше оператор заходил на сайт и на сервер , вручную снимал показания и рассылал файлы контрагентам и снабжающей организации.. Я решил не меняя формы отчетов и модели работы сделать автоматизацию c использованием имеющегося сервера SQL,PowerShell скриптов сбора показаний, формирования отчетов и почтовой рассылки. Заняло месяц работы и месяц отладки скриптов с использованием как API к сайту так и прямого зашифрованного доступа к серверу. Для оркестрации всех разработанных скриптов использовал SQL Agent MSSQL. Счетчиков не так много для учета и арендаторов тоже несколько, поэтому в общем такая модель вполне себя оправдала и не потребовались какие-то материальные затраты на оборудование, так как инфрастуктура уже была сделана до меня. Все работает стабильно, но есть иногда проблемы со стабильностью сбора показаний через радиоканал и это требует иногда ручного досбора данных со счетчиков на сайте и на сервере. В принципе эту задачу можно было решить и с помощью контроллера, но это было бы намного дольше и затратнее. Задача решена уже в имеющейся инфраструктуре и в кратчайший срок.
Когда-то давно, в начале 2000-x я реализовал стандартную модель работы дилера по полному циклу - CRM контактами и с историей общения, заказы, расценка как предложение, счет на оплату, ведомость комплектации для снабжения, чего не хватает с учетом складских запасов с учетом сборочных позиций , комплектация с приоритетами и возможностью изменения приоритета и распределения заказных позиций с учетом складских остатков и менее приоритетных закзаов , учет частичных отгузок заказа, ценоообразование с учетом введенных формул, складской учет без остатков ( вычисляемый остаток от прихода, расхода и резервирования под приоритет заказа), ну и формирование отгрузочных документов, накладных и счетов фактур, импорт в 1С Бухгалтерию ( тогда была только бухгалтерия). Ничего подобного тогда не могла обеспечить ни 1С ни другая система, ну может только импортные ERP да и то не все и для небольшой компании это было недоступно. Система прожила 10 лет почти и умерла потому что мне не было возможности ее поддерживать. Хотя поддержки почти не требовалость, так как реализация была на SQL в хранимых процедурах с клиентом DELPHI. Все работало в рамках модели работы компании почти безупречно. Не было тогда никакого ИИ и все делал руками. А еще реализовал хранилище на C# в MSSQL по типу файловой системы ( это типа Filetables на MSSQL).
Это оверинжиниринг в большинстве случаев.
ИИ это инструмент и не более. Он им и останется. Как любой инструмент в руках профессионала он дает много профессионалу. Это же инструмент в руках непрофессионала даст на порядок меньше и некачественнее. Ну и не стоит забывать, что ИИ часто галюцинирует и дает то чего нет на самом деле и склонен к оверинжинирингу. Много раз убеждался в этом. Так что не все так просто пока.
Использование даже браузерного ИИ помогает в программировании и доработке уже написанного, но не более. В SQL к примеру он частенько косячит, если контекст в мельчайший деталях до него не донести. Иногда придумывает то чего нет. Но главное - часто наводит на мысль, которая в голову не приходит или из той области, которую ты знаешь по наслышке но до нее руки не доходили. Вот это ценно. Но для этого вы должны быть специалистом в той области, в которой используете ИИ. Иначе это бесполезно, если только не ставится цель обучения. Да и то тут есть тоже натяжки. Рефакторинг кода можно делать и это делается как правило неплохо. Платный или бесплатный ИИ все равно остается пока, имхо, инструментом и не более. Нет смысла приписывать ему интеллект, как нет смысла приписывать интеллект шахматному движку, к примеру.
Вы пишете инструкции для инструмента и тут нужна точность, он неспособен работать в нестандартной или неясной ситуации. Для человека пишут с учетом что разберется если очень надо. Вот и ответ на ваше почему.
Пытался один глюк в программе устранить с помощью браузерной LLM. К сожалению потраченное время не увенчалось успехом. Глюк был сложный и все что предлагала модель не работало. Я вспомнил что в этой программе после замены драйвера БД были некоторые изменения и подумал что первоначальный вариант после замены был протестирован и глюка не было. Так и оказалось. В первоначальном варианте из git почти все работало без проблем. кое что подправил и запустил в тестирование. Все работало. Модель ответила стандартным что это было наслоение багов последующих изменений. Но последующие изменения к глюкам не имели отношения. Вот и верь после этого ИИ.
Знаю по себе - это так и есть. Опыт и системное мышление в молодости не очень распостранены. После 40 - 50 это все начинмет работать если есть база знаний.
В области разработки десктопных приложений в связке с SQL ( SQL SERVER, SQLite ) использую и DELPHI и Labview. Нужна быстрая разработка интерфейса системы, скорость и стабильность работы с оборудованием и мониторинг.
Да, вот есть цех где стоят климатические камеры и в них происходит технологический процесс. Но как только температура в цехе превышает плюс 30 с небольшим - все камеры отключаются. Китайские потому что да и сами генерят тепло. Требуется охлаждение немаленького цеха летом и отопление зимой, так как высокотехнологичное оборудование в стойках и сами камеры не расчитаны на работу при минусовых температурах. Надо полагать что сделать климат в огромном цехе не такая уж легкая и низкая по стоимости задача с учетом надежности и обслуживания климатического оборудования.
Нейронка не панацея.Ее еще правильно направлять надо. Вот совсем недавно - решил оптимизировать хранимую процедуру. Немного тормозила, но работала на клиенте. А в студии жутко зависала на минуту и больше. А тормозить не должна была, количество записей небольшое. Индексы все были. Скормил нейронке и пошло-поехало. Итерации за итерацией, но результат еще хуже, потом пошли такие дебри что я сказал стоп. Давай вернемся к началу и проверим все по частям. По отдельности запросы в процедуре, содержащей CTE и select работают ведь мгновенно, а в комплексе - процедура зависает на минуту. И только тут нейронка сообразила что проблема не в коде, который она довела до к полной жести - проблема в Parameter Sniffing и предложила простое лечение - переназначение входной переменной в локальную и вставка в конец процедуры OPTION RECOMPILE. Небольшие правки в четырех частях процедуры и все. Все 20 тыс. строк стали выводится за миллисекунды и в студии и на клиенте. Достаточно редкий случай этот Parameter Sniffing , но он произошел. Я честно говоря подозревал что дело в разных планах выполнения, но столкнулся с таким первый раз и не знал о существовании такой проблемы. Нейронка помогла, но только под правильным руководством нашла верный ответ. Человек без опыта и чутья с этой задачей возможно бы и не справился. Так что польза от нейронок есть, но уповать на них полностью - глупо.
Смотря где они будут не нужны. В крупных корпорациях наверно не нужны. В средних производственных приборостроительных компаниях к примеру, программисты и встроенный софт пишут, и производственный и сервисный, они там сейчас и в будущем будут нужны. Там нет такого кастового разделения как в ПРОГРАММИСТСКИХ КОНТОРАХ.
Даже с навыками программирования не всегда можно сделать быстро и эффективно с использованием нейросети. Недавно хотел подправить код в одном своем сложном приложении в качестве работы с техническим долгом. Думал с нейронкой быстро. Ан нет, забыл контекст этого приложения, уже год не открывал исходники. Полдня потратил с нейронкой на замену части кода, не работает почему-то. Надо разбираться, заново все тестировать, неизвестно еще где что вылезет. К концу дня понял что игра не стоит свеч. Сейчас все привыкли к интерфейсу, проблем нет. Потом будут недовольные и вопросы почему изменилось и т п. Оставил так как есть. Лучшее враг хорошего.
Насколько я понял по себе при игре на гитаре - все верно насчет осознания аппликатуры при изучении новой пьесы. Но сама процедура изучения предполагает, что мозг запоминает мелодию одновременно с постановкой апликатуры пальцев и их движением. Я заметил что если пока не можешь проиграть мелодию внутренним слухом, то и паттерны аппликатуры не запоминаются хорошо. Все взаимосвязано, мышечная и звуковая память. Одно без другого не работает. Особенно это касается не очень простых гитарных произведений.
Это да. Использую электрорубанки Макита уже много лет. Один раз точил ножи у большого рубанка. Кабели все поменял только на более длинные и морозостойкие.