Угадай, кто написал код: ИИ или человек?

Если удалить комметарией, которые написал ИИ, то уже трудно будет отличить - нужно будет вчитываться в код и видеть алгоритм. Знать стиль человека.

А можно ещё ИИ попросить писать как конкретный разработчик в компании, хаха))

Угадай, кто написал код: ИИ или человек?

Почему в "И как же быть?" не добавлен блок, чтобы были разными моделями ИИ, которые пишут и проверяют код?

Это одно из решений.

На практике, возможно, ещё не налажен удобный механизм для такого разделения, но подходы такие есть.

Например, мы пишем в Cursor, используем модель Composer 2 или Auto режим иногда для кода. А на ci/cd идёт проверка ботом от ChatGPT.


Также не указан случай, когда MR очень большой (50, 200, 1000 файлов изменений). И кто писал - человек или ИИ не известно. Возможно вместе.
В таком случае человеку трудно будет проверить такой код глазами (хотя мы так делаем). Но и ИИ ревью тоже помогает, может найти критические ляпы в коде или посоветовать, на что обратить внимание.

Один скилл, четыре модели — что может пойти не так

Можно, пожалуйста, в сравнение добавить Cursor модели - Composer 2 и режим auto?

Cursor очень популярен - интересно увидеть, на каком уровне модели

Cruzo — минималистичный UI-фреймворк без лишней сложности

Для полного сравнения примера счётчиками интересно было бы видеть их реализацию на чистом JS, vue и $mol )

Утекли исходники Claude Code

А завтра 1 апреля....

Новости фронтенда

Один Vite 8 перекрывает все остальные новости)

Как я перестал бояться Claude Code и научил его не ломать мои проекты

Спасибо за статью.
До Claude пока ещё не добрался, но на Cursor хотелось бы видеть аналогичный подход. Может со временем он появится)

5 ключевых IT-трендов 2026 года: от ИИ-агентов и Zero Trust до суверенных облаков

Эти люди - продавцы "франшиз", которые "внедряют" успешно на 70%

Мой справочник по Feature-Sliced Design

да

И снова упал Cloudflare

Это уже вайп-кодинг получается

Атрофия межушного ганглия Товарищи, нам с вами надо...

Надо дождаться, когда PR будет проверять ИИ)

Каким получился обновленный DeepSeek — скорость и дешевизна вместо бенчмарков

Скорость ответа в режиме рассуждений и с включенным интернет поиском действительно быстрая.
Приятно пользоваться

CEO Surge Эдвин Чен: ИИ создаёт сотрудников, чья производительность в сто раз выше среднестатистической

ИИ забывает какие главные герои

Вроде как эта известная проблема - что забывает героев, лица, контекст.
Думаю, когда эта проблема будет решена - а она скорее всего будет решена (может быть в БД будет ИИ героев записывать), то ИИ шагнёт далеко вперёд и сможет написать книгу, острый сюжет. А автор уже доведёт эту рыбу до ума

CEO Surge Эдвин Чен: ИИ создаёт сотрудников, чья производительность в сто раз выше среднестатистической

Крестьянин того времени не знал, как починить машину, какую таблетку купить в аптеке, как установить windows. Да даже перевести по СБП он не мог, только голубиной почтой

Верните непрерывную интеграцию разработчикам

Попробуйте поднять версию MUI4 на MUI5/6/7 или React 17 на 18/19.

У компаний уходят на это месяцы и то не факт, что получается с первого раза

Количество просмотров на Rutube за год увеличилось в 7,5 раза, всего с начала года в сервисе просмотрено 26 млрд роликов

На рутубе куча пиратки - аниме, сериалы, фильмы. Зайти туда и посмотреть что-то порой уже легче, чем искать фильмы/сериалы на пиратских сайтах

Почему разработка через тестирование (TDD) не приводит к плохому коду

Нужно задать вопрос - как часто нужно TDD и тестирование в целом?

На примере фронта - компоненты из ui-библиотеки тестировать смысла практически нет, свои простые компоненты можно и на мой взгляд лучше тестировать визуально через Storybook (если нужно, там есть функционал play для тестирования), сетевой код особо не протестируешь.

Остаётся небольшой класс задач типа utils - работа со временем, величинами, различными приведениями. Их можно и нужно тестировать. Но они занимают крайне малый объём кода относительного всего проекта с компонентами и большая часть уже протестирована в библиотека date-fns, ramda и т.п.

Отсюда был сделан вывод для нашего проекта - тестируются только utils функции, которые лежат в library. А написать небольшие тесты через TDD методологию или просто написать тесты становится совсем некритичным.

Zod v4: Стал в 17 раз медленнее? (и почему это важно)

Понял, спасибо. Не знал этого

Google представила ИИ-генератор видео Veo 3

Слушаю книги с телефона в Яндекс Браузере. Скачиваешь книгу, закидываешь в Читалке, нажимаешь на наушники и всё - аудикнига готово. На выбор озвучка Алиса и мужской голос. Мне больше нравится мужской - он более спокойный.

Есть галлюцинации, но порой они делают книги веселее)

Тестовые идентификаторы: как и где расставлять правильно

Полуавтомтический data-test-id='clients-search__SearchClientInput-lastName--item'

У нас nx-монорепозиторий. Есть соглашение, что в каждом модуле (1-2 страницы со своим api) вложенность компонентов только на 1 уровне - т.к. нет components/a/b/c.

Делюсь рабочим простым, но эффективным рабочим кодом по генерации test-id. Его положили модуль library.

const getString = (text: string | number | null, divider: string) => (text?.toString() ? `${divider}${text}` : '');

export const getTestId =
  (module?: string | null) =>
  (component: string, componentId: string | number | null = '') =>
  (element: string | null = '', modifier: string | number | null = '') => {
    const moduleTitle = module ? `${module}__` : '';

    return `${moduleTitle}${component}${getString(componentId, '_')}${getString(element, '-')}${getString(
      modifier,
      '--'
    )}`;
  };

Для каждого модуля создаём функцию, которая содержит имя модуля. Например, для модуля clients-search.

import { getTestId } from '@bcs/library';

export const useTestId = getTestId('clients-search');

И в самом модуле, в компонент используем useTestId() для компонентов.

import { useTestId } from '../../utils/useTestId';

export const SearchClientInput: React.FC<ISearchClientInput> = ({ name, title, error, value, handleChange }) => {
  const testId = useTestId('SearchClientInput');

  return (
    <FormControl data-test-id={testId()} error={Boolean(error[name])} key={name}>
      <InputLabel htmlFor={name}>{title}</InputLabel>
      <Input
        data-test-id={testId(name)}
        type='text'
        name={name}
        value={value}
        inputProps={{
          'data-test-id': testId(name, 'item'),
        }}
        onChange={handleChange}
      />
      <FormHelperText data-test-id={testId(name, 'error')}>{error && error[name]}</FormHelperText>
    </FormControl>
  );
};

Плюсы такой функции - утилиты:

• Минимальное количество сил для уникальных названий, не надо думать! Достаточно, чтобы в 1 компоненте префикс не повторялся testId('префикс').

• При том очень стабильное поведение. Изменяется только когда сам компонент (его название) меняет название. А это как правило в следствии меняющих требования доработок.

• Уникальность работает в рамках нашей архитектуры, где только 1 уровень вложенности. Кстати, как показывает время - очень простое и удобное решение (по сравнению с FSD xD )