Команда AI for Devs подготовила перевод статьи о том, как меняется программирование с приходом ИИ. Автор делится опытом: в его проекте уже 90% кода пишется агентами, но вся ответственность за архитектуру и продакшен остаётся на нём. По мнению автора, это не далёкий прогноз — это уже реальность, просто распределённая неравномерно.
«Я думаю, что через три-шесть месяцев мы придём к тому, что ИИ будет писать 90% кода. А ещё через год — к миру, где ИИ пишет фактически весь код».
В нашей компании в процессе разработки frontend‑приложений мы иногда сталкиваемся с одной из следующих ситуаций (или с обеими сразу):
Когда мы имеем достаточно объемную и часто меняющуюся спецификацию API. Тут нам поможет генерация кода на основе этой спецификации.
Когда нам нужно работать с функционалом, отвечающим за обработку обращений к различным эндпойнтам, но сами запросы не работают по каким‑либо причинам. Эту проблему можно решить подстановкой в соответствующих местах mock‑объектов.
В .Net больше нет Swashbuckle. То есть из коробки больше нет Swagger UI чтобы тестировать свеженаписанные API.
Microsoft поддерживают собственный пакет Microsoft.AspNetCore.OpenApi для генерации OpenAPI спецификации из кода (Code First подход), а для тестирования предлагают использовать .http файлы и Endpoints Explorer встроенный в Visual Studio. Postman и NSwag всё ещё с нами, не говоря о том что можно и сам Swashbuckle установить, только перспективы его поддержки весьма туманны.
Активно развивающейся альтернативой Swagger UI является Scalar, который можно удобно интегрировать с .Net и ещё дюжиной популярных стеков.
При разработке современных приложений важнейшую роль играет качество клиент-серверного взаимодействия. Для достижения стабильной связи между мобильными и веб приложениями и серверной частью необходимо стремиться к созданию надежного и эффективного механизма обмена данными. Это подразумевает создание устойчивого API, которое трудно сломать даже при изменениях в архитектуре сервера, а также легкость интеграции новых клиентов.
OpenAI запустила свою Академию — десятки видеолекций. Полезно, но много. Если вы разработчик или аналитик, которому нужны технические детали и практические руководства по API, моделям и их оптимизации, смотреть всё подряд — не вариант.
Я изучил доступные материалы и сделал выжим из только технических материалов. Этот гайд проведет по 10 ключевым лекциям вышедшим на сегодня, которые помогут разобраться в Function Calling, RAG, Fine-tuning, Evals и других важных темах. Мы не будем здесь касатьсяЧитать полностью »
Привет! Меня зовут Данил, я Frontend разработчик, живу в Питере, работаю в компании Unistory. Решил рассказать на Хабре, как автоматизировать один нудный процесс.
Привет! Начну с главного - я лентяй. Я очень-очень ленивый разработчик. Мне приходится писать много кода - как для бэка, так и для фронта. И моя лень постоянно терзает меня, говоря: Ты мог бы не писать этот код, а ты пишешь... Так и живем.
Но что делать? Как можно избавиться от необходимости писать хотя бы часть кода?
Есть много подходов к решению этой проблемы. Давайте посмотрим на некоторые из них.
В этом материале я приведу практический пример реализации архитектуры API First с применением спецификации OpenAPI. А именно, сначала расскажу о том, как создал определение API, а затем — о том, как, на основе этого определения, создал серверную и клиентскую части приложения. В процессе работы у меня возникли некоторые сложности, которых я тоже коснусь в этом материале.
Два года назад я начал разработку еще одного свободного кодогенератора из OpenAPI Specification v3 в TypeScript (он доступен на Github). Изначально, я задался целью сделать эффективную генерацию примитивных и сложных типов данных в TypeScript, с учетом различных возможностей JSON Schema, таких как oneOf/anyOf/allOf и т.п. (у родного решения от Swagger с этим были некоторые проблемы). Другая идея заключалась в том, чтобы использовать схемы из спецификаций для валидации на фронте, бэке и в других частях системы.
