Здравствуйте, mogadanez, Вы писали: M>Здравствуйте, bnk, Вы писали: bnk>>Сорри я про жиру условно написал, чтобы понятно было понятно о чем речь. bnk>>Сам сейчас ее не использую. M>ну условная жира, просто интересно как он там может там авторизоватся
В Az CLI есть команда az login (один раз), после этого все последующие выполняются без авторизации (оно тебя запоминает).
Поскольку агент может пользоваться терминалом (от моего имени), этого достаточно.
Выглядит как-то так футуристично
Содержимое (релевантный кусок) copilot-instructions чтобы это работало (system prompt по сути)
под катом
## Azure DevOps CLI Configuration
The project uses Azure DevOps for work item tracking and project management.
# Query assigned work items in current iteration
az boards query --wiql "SELECT [System.Id], [System.Title], [System.State], [System.WorkItemType], [System.IterationPath] FROM WorkItems WHERE [System.AssignedTo] = @Me AND [System.IterationPath] = @CurrentIteration('[XXXX]\XXXX Team') AND [System.State] <> 'Closed' AND [System.State] <> 'Removed' ORDER BY [System.ChangedDate] DESC" --org https://dev.azure.com/xxxx --project "XXXX" --output table
# Query all assigned work items (any state except Closed/Removed)
az boards query --wiql "SELECT [System.Id], [System.Title], [System.State], [System.WorkItemType] FROM WorkItems WHERE [System.AssignedTo] = @Me AND [System.State] <> 'Closed' AND [System.State] <> 'Removed' ORDER BY [System.ChangedDate] DESC" --org https://dev.azure.com/xxxx --project "XXXX" --output table
# Add a comment to a work item (visible in Discussion tab)
# Use System.History field with HTML formatting for proper visibility in the UI
# IMPORTANT: Do NOT use "Fixed:" prefix as it auto-closes items. Use "Resolved:" instead.
# Items should go to "Resolved" state for test team verification, not directly to "Fixed/Closed"
# CRITICAL: Always write comments in NON-TECHNICAL language that testers can understand
# Focus on what was broken, what was fixed, and how to test it — avoid implementation details
az boards work-item update --id <work-item-id> --org https://dev.azure.com/xxxx --fields "System.History=<html-formatted-comment>"
# Example with proper formatting (non-technical language):
az boards work-item update --id 725 --org https://dev.azure.com/xxxx --fields "System.History=Resolved: Fixed the issue where XYZ was not working.<br/><br/><b>What was broken:</b><br/>Description of the problem from user perspective<br/><br/><b>What was fixed:</b><br/>Description of the solution from user perspective<br/><br/><b>How to test:</b><br/>1. Step-by-step testing instructions<br/>2. What to verify<br/><br/>Commit: abc1234"
# Note: Using --discussion parameter does NOT create visible comments in the UI
# Always use System.History field for comments that should appear in the Discussion tab
# Workflow: Development -> Resolved (for testing) -> Closed/Fixed (after verification)
# Use "Resolved:" prefix so test team can verify before marking as "Fixed"
```
Да, это он сам себе такую инструкцию написал, я ему просто скзал написать себе инструкцию чтобы коннектиться к DevOps.
Возможно с жирой так же прокатит.
Вообще думаю скоро появится что-то более промышленное (MCP коннекторы напишут или типа того, чтобы он не страдал с вызовами API из командной строки), но пока вот так пользую, "собрано на коленке".
Если еще не появилось конечно. Загуглил и вот что нашлось
Здравствуйте, elmal, Вы писали:
E>Ну, всякие вики это на деле стандарт. Но на деле — идет текучка в том числе и руководства, новый оказывается не в курсах и т.д что там и почему, на документирование времени нет и начинается.
Тут возможны варианты. Кто-то в команде в курсе. Мне, когда я к проекту подключился, кто-то из коллег ссылку прислал.
Времени на локументирование всего и вся, естественно, нет. Но базовые вещи в нашем проекте были описаны. Во всяком случае, не надо было, если что возникало, искать по всей системе. А это по крайнем мере для меня на начальном этапе было важно. Хоть я к тому времени уже не был зелёным новичком. Даже логи читать умел.
E>Во всех местах, где доводилось — начальник всегда работал в интересах подчиненных. Основная задача — максимально избавить непосредственных исполнителей от бюрократии.
Сильно зависит от многих факторов.
Видел я двух тимлидов. Девушка, помню, и в проекте разбиралась, и код ревью могла провести, и нагрузки как-то равномерно распределяла, и сама пару полезняшек очень неплохо сделала. А парень, долго рвавшийся в тимлиды, фактически был тупым каналом связи между разработчиками, более высоким начальством, службой поддержки. Он не всегда знал, кому переадросовать то или иное мыло.
E>Так или иначе это пытаются делать вообще все без исключения, ибо работать то кто то должен. Но чем больше становится контора, тем больше становится согласований, взаимодействий с другими отделами.
Не контора. Проект. Новые свистелки фичи в него не от фонаря добавляют. И иногда обсуждение таких новых фич может занимать недели. И выясняется, что где-то писатель документа что-то пропустил, а чего-то заказчик не учёл, а чего-то ответственный исполнитель не знает.
E>И вот в реальности начальство нужно именно чтоб не допускать подобный дурдом, чтоб когда из за подобных инициатив все блокируется — вопить на всю контору до самого верха, вынося всем мозг! Достав всех так, что ему дают особые полномочия в виде исключения, в результате чего работа не блокируется никогда. Такое начальство никакие нейросетки никогда не заменят. И такое начальство в интересах собственника конторы, но зачастую руководители пониже собственника делают все, чтобы вот таких изжить, и поставить на место тех, кто бучу не наводит относительно того, сколько времени и денег просираются впустую.
Такое начальство безусловно нужно. В суровой реальности всё немного хуже. Вот тот проект, о котором я выше упомянул, делался на базе некоего фреймворка. Команда разработчиков первым делом принялась этот фреймворк переписывать, и промерно две трети кода в нём поменяла. В результате преокт вышел на 2.5 года позже запланированного срока. Правда, я в это время тянул старый проект. Точнее, сначала нас осталось там двое, а потом меня бросили.
Здравствуйте, bnk, Вы писали:
bnk>- Как правило не работает для фич, которые я сам не знаю как сделать (требующих какого-то исследования). bnk>То есть, если мне допустим ясно, как задачу делать, или ее можно сделать "по аналогии", можно отдавать ИИ. bnk>Если нет — у него так же будут проблемы.
Во! Я тоже заметил — если что-то хорошо знаешь — и оно вроде может сделать. Если не знаешь — то и оно не поможет.
=сначала спроси у GPT=
Re: Про вайбкодинг - пределы, применимость, ограничения
Здравствуйте, Shmj, Вы писали:
S>Уже давно практикую это дело, пока можно сказать новый зверь и никто толком не знает шо оно такое.
вот для примера навайбкодил https://calc.investments/ — зачем вопрос отдельный просто объяснял сыну как сложный процент работает
все с нуля в пустой папке
cursor pro подписка
по затратам времени:
* в сумме 2.5 часа на написание промптов, тестирование и написание промптов опять. из них 15 минут на промпт по адаптации terraform-деплоя( это не с нуля, а адаптация существующего )
* все полностью завайбкодить не получилось, 2 часа в расслабленном формате на самостоятельное решение 1 проблемки которую он никак не мог сам решить и только закапывался глубже
* полчаса на ревью
по качеству кода — большая часть вполне сносна, часть откровенное говно но работающее, совсем выдающегося ничего нет
