Оглавление

Цель исследования
Вспоминаем начальные условия
Ни одного вопроса — одни ответы
- Конфигурация подключения к PostgreSQL
- Создание init.sql
Создаём сущности
Пишем CREATE-логику
- OperationService: сущности в API
UPDATE - логика
Реализуем READ-логику для операций
DELETE-логика
Добавляем валидацию
Unit-тесты
Итоги

Это вторая часть цикла «Исследование возможностей ИИ писать код». И она особенная: GPT-4o, о котором пойдёт речь, уже успели снять с полок, а затем вернуть под давлением жалоб пользователей, но это лишь временная передышка. Модель официально заменена GPT-5 и в любой момент она снова может исчезнуть. Поэтому то, что вы читаете, это скорее исторический снимок работы с устаревшей моделью.

ИИ развивается быстрее, чем я успеваю писать статьи, но это не повод выкидывать проделанную работу. Тем более, сравнение с прямым конкурентом Claude и наблюдение за эволюцией моделей — отличный способ понять, куда движутся LLM.

Цели исследования:

Проверить, насколько жизнеспособный код генерирует ИИ.
Понять, способен ли он заменить разработчика и можно ли без техзнаний собрать рабочее приложение.
Сравнить качество и удобство работы нескольких LLM (Claude, ChatGPT, Deepseek).
Поделиться опытом промптинга для получения качественной выдачи.

В первой части мы тестировали Claude Sonnet 3.5. Теперь пришёл черёд GPT-4o — прямого конкурента от OpenAI. Мне важно не только оценить его отдельно, но и понять, как меняются комфорт, качество кода, точность доработок и реакция на ошибки при переходе от одной модели к другой. Этот материал — ещё один шаг в большом сравнительном исследовании, впереди будут и GPT-5, и другие LLM.

Историческая справка
На момент старта исследования в арсенале OpenAI было несколько моделей:

GPT-4o — универсальная модель для большинства задач, близкий аналог Claude Sonnet 3.5.
o1-preview — «рассуждающая» модель: перед ответом прогоняет внутренние шаги, выдаёт более развёрнутый и качественный результат, но работает медленнее.

Пока я продолжал делать исследование, OpenAI выкатили новые версии:

o3 — замена o1-preview.
o4-mini и o4-mini-high — лёгкие рассуждающие модели.
GPT-4.5 — новая нерассуждающая модель.

Скорость эволюции LLM оказалась такой, что выбор моделей для теста стал отдельным квестом. Для этой статьи я остановился на GPT-4o, а в следующих — сравню её с GPT-5.

Вспоминаем начальные условия

В этой части цикла мы тестируем модель без механизма рассуждения. Методология — та же, что и в первой статье: цель — разработать приложение с CRUD-операциями, валидацией, unit- и MVC-тестами.

Исходный код эксперимента — на GitHub.

Чтобы сравнение было честным, я формулировал запросы к GPT-4o максимально похоже на те, что использовал для Claude. Иногда вносил правки, чтобы не плодить "второстепенный" шум. Например, если Claude по умолчанию делал миграцию в XML, то GPT-4o я сразу указывал нужный формат, чтобы не тратить шаг на переписывание.

Код, который ChatGPT сгенерировал неидеально, я местами оставлял как есть — хотя в реальной разработке сразу бы поправил. Это требуется для сохранения непрерывного контекста в диалоге с моделью: если вносить правки вручную, при чтении статьи возникнет несоответствие между кодом в выдаче и кодом в проекте.

Первоначальный промпт

Шаблон, который отлично сработал для Claude, с GPT-4o показал себя плохо: модель часто уходила в сторону и генерировала код, который я не просил. Пришлось перестраивать промпт с нуля.

Структура у ChatGPT другая, и лично мне больше нравится упорядоченная схема Claude — у Anthropic есть подробная инструкция, как её составлять. У OpenAI я нашёл лишь несколько полезных фрагментов в официальном Cookbook. На основе этих фрагментов я и собрал новый стартовый промпт:

Начальный промпт

# Context
You will be acting as a senior backend developer. 
You are have an expertise in the following technologies: 
- Java 21+, 
- Spring boot, 
- Spring JPA, 
- Hibernate, 
- Lombok, 
- Spring Web, 
- REST API, 
- SQL. 
Your goal is to develop a production-ready solution that meets the user's needs.
You should provide clear and concise answers to questions in a friendly and professional manner.

Before starting, take your time to think through each step carefully. 
Remember to thoroughly validate your solution and be aware of boundary cases, particularly those that arise from the changes you make. 
Your solution should be perfect.

# Workflow

1. Understand the problem deeply. Carefully read the issue and think critically about what is required.
2. Develop a clear, step-by-step plan.
3. If you have questions, ask for clarification before providing a solution. After all questions have been answered, provide a solution to the user.
4. In case you are unsure how to respond to a question or don't know an answer, say "I'm sorry, I don't understand. Could you please rephrase your question?"
5. If you don't know how to proceed, say: "I am sorry, but I don't know that answer. Can you please clarify your question for me and provide more details?"

## 1. Deeply Understand the Problem
Carefully read the issue and think hard about a plan to solve it before coding.

Answer with "we can proceed" if all instructions is clear for you and you don't have question. 
Then we will start.
```

```
I have already created an application using Spring Initializr with the following dependencies: Lombok, Spring Web, Spring Data JPA, PostgreSQL Driver, Liquibase Migration. Write a Liquibase migration for the tables. Use YAML format for liquibase scripts.
`<table1>`
	Category table with columns: category_id (bigint), category_name (varchar), category_description (varchar)
`</table1>`
`<table2>`
	Operation table with columns: operation_id (bigint), operation_public_id (varchar), operation_name (varchar), operation_amount(bigdecimal), operation_type (enum), category_id (FK to category table)
`</table2>`
Suggest how to store the operation_type. In the code, the operation type will be an Enum with the values (DEPOSIT, WITHDRAW).

По смыслу он близок к исходному для Claude, но подача другая: ChatGPT лучше воспринимает промпт в формате Markdown, и, судя по опыту, строгого порядка блоков, как у Claude, здесь нет.

Подготовка завершена. Пора переходить к первой задаче.

Ни одного вопроса — одни ответы

После задания стартового промпта GPT-4o сообщил, что готов, и я отправил первую задачу — создать миграцию для таблиц.

Миграция для таблиц

Что просил

I have already created an application using Spring Initializr with the following dependencies: Lombok, Spring Web, Spring Data JPA, PostgreSQL Driver, Liquibase Migration. 
Write a Liquibase migration for the tables. Use YAML format for liquibase scripts. 

`<table1>` 
	Category table with columns: category_id (bigint), 
	category_name (varchar), category_description (varchar) 
`</table1>`
`<table2>`
	Operation table with columns: operation_id (bigint), 
	operation_public_id (varchar), operation_name (varchar), 
	operation_amount(bigdecimal), operation_type (enum), 
	category_id (FK to category table) 
`</table2>` 

Suggest how to store the operation_type. 
In the code, the operation type will be an Enum with the values (DEPOSIT, WITHDRAW).

Что сделал GPT-4o

Thanks for the details! Here's how we'll proceed:

✅ Plan

1. Enum Handling (operation_type)

We’ll store the operation_type enum as a VARCHAR in the database. This approach:

Keeps the data readable and meaningful.
Avoids the risks of ordinal-based persistence (i.e., changes in enum order).
Is compatible with JPA enum mapping using @Enumerated(EnumType.STRING).

2. Liquibase YAML Migration File

We'll write a migration file in YAML that:

Creates the category table.
Creates the operation table.
Defines operation_type as a VARCHAR.
Sets up a foreign key from operation.category_id to category.category_id.
Adds primary keys for both tables.

🧩 Liquibase YAML Migration Script

Here's a production-ready db.changelog-1.0.yaml:

databaseChangeLog:
  - changeSet:
      id: 1
      author: backenddev
      changes:
        - createTable:
            tableName: category
            columns:
              - column:
                  name: category_id
                  type: BIGINT
                  constraints:
                    primaryKey: true
                    nullable: false
              - column:
                  name: category_name
                  type: VARCHAR(255)
                  constraints:
                    nullable: false
              - column:
                  name: category_description
                  type: VARCHAR(1000)

  - changeSet:
      id: 2
      author: backenddev
      changes:
        - createTable:
            tableName: operation
            columns:
              - column:
                  name: operation_id
                  type: BIGINT
                  constraints:
                    primaryKey: true
                    nullable: false
              - column:
                  name: operation_public_id
                  type: VARCHAR(255)
                  constraints:
                    nullable: false
                    unique: true
              - column:
                  name: operation_name
                  type: VARCHAR(255)
                  constraints:
                    nullable: false
              - column:
                  name: operation_amount
                  type: NUMERIC(19,2)
                  constraints:
                    nullable: false
              - column:
                  name: operation_type
                  type: VARCHAR(50)
                  constraints:
                    nullable: false
              - column:
                  name: category_id
                  type: BIGINT
                  constraints:
                    nullable: false

        - addForeignKeyConstraint:
            baseTableName: operation
            baseColumnNames: category_id
            referencedTableName: category
            referencedColumnNames: category_id
            constraintName: fk_operation_category

🧩 Enum Mapping in Java (for reference)

In your Operation entity:

@Enumerated(EnumType.STRING)
@Column(name = "operation_type", nullable = false)
private OperationType operationType;

Let me know if you'd like:

Liquibase rollback support.
Sample Java entity classes.
Sample test data insertion via Liquibase.

Shall we move forward with the entity classes or anything else you need help with?

Создал файл миграции, но не упомянул db.changelog-master.yaml.
Не уточнял детали и сам решил: какие поля обязательны, а какие опциональны, какие типы данных использовать.

Как было у Claude:

Добавил autoIncrement для primary key.
Добавил constraint для проверки типа операции.
Перед генерацией уточнил информацию по каждой колонке.

Вывод: Claude подошёл к задаче вдумчивее и добавил защиту от ошибок, GPT-4o сгенерировал быстрее, но «на глазок» и без уточнений.

Конфигурация подключения к PostgreSQL

Что просил:

Write the configuration to connect the application to the PostgreSQL database.

Ответ GPT-4o

Sure! Here's the standard Spring Boot application configuration for connecting to a PostgreSQL database, including Liquibase support.

✅ application.yml Configuration

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/your_database_name
    username: your_db_username
    password: your_db_password
    driver-class-name: org.postgresql.Driver
  jpa:
    hibernate:
      ddl-auto: none  # Liquibase handles schema creation
    show-sql: true
    properties:
      hibernate:
        dialect: org.hibernate.dialect.PostgreSQLDialect

  liquibase:
    change-log: classpath:db/changelog/db.changelog-1.0.yaml
    enabled: true

# Optional logging for SQL debugging
logging:
  level:
    org.hibernate.SQL: DEBUG
    org.hibernate.type.descriptor.sql: TRACE

✅ Tips

Replace your_database_name, your_db_username, and your_db_password with your actual PostgreSQL config.
Make sure your YAML is properly indented and db.changelog-1.0.yaml is placed under src/main/resources/db/changelog/.

Would you like me to generate the corresponding Java entity classes next?

Что сделал GPT-4o:

Установил jpa.hibernate.ddl-auto: none (я бы предпочёл validate, чтобы ловить ошибки в сущностях на этапе компиляции).
В liquibase.change-log указал путь к миграции classpath:db/changelog/db.changelog-1.0.yaml, что намекает на наполнение master-changelog напрямую — риск получить нечитаемый файл.
Включил show-sql: true и уровень логов Hibernate на DEBUG/TRACE — замусоренные логи по умолчанию.

Как было у Claude:

Ошибки в конфигурации присутствовали, но архитектурно подход выглядел аккуратнее.

Вывод: Claude снова выглядит сильнее концептуально, но GPT-4o выдал рабочий результат без критичных ошибок.

Работа с несколькими миграциями

Задаю ChatGPT вопрос, как работать с несколькими миграциями, без каких-либо деталей реализации.

I plan to add new migration files, do I need to add each migration to application.yml for liquibase to process it?

Ответ ChatGPT

Great question — and no, you don’t need to manually add every migration file to application.yml.

✅ How Liquibase Works in Spring Boot

Liquibase uses a master changelog file (like db.changelog-1.0.yaml) as the entry point. That file can include other changelogs, and Liquibase will process them in order automatically.

🔄 Recommended Setup with Includes

Use a master changelog like this:

db.changelog-master.yaml (referenced in application.yml)

databaseChangeLog:
  - include:
      file: db/changelog/db.changelog-1.0.yaml
  - include:
      file: db/changelog/db.changelog-1.1.yaml
  - include:
      file: db/changelog/db.changelog-1.2.yaml

Then in application.yml:

spring:
  liquibase:
    change-log: classpath:db/changelog/db.changelog-master.yaml

Whenever you add a new migration:

Create a new file like db.changelog-1.3.yaml.
Add an - include: line for it in the master file.

🔧 Best Practice Tips

Version your changelog files for clarity (1.0, 1.1, etc.).
Keep each file focused on a related set of changes.
Keep the master file clean and ordered by time/version.

Let me know if you want a script or method to auto-include files dynamically, or if you want to switch to XML or SQL format later.

GPT-4o быстро исправился, но осадочек остался — хотелось получить корректный подход сразу. GPT хорошо реагирует на фидбек, но не всегда выдаёт качественный результат с первой попытки.

Создание init.sql

Прошу создать схему с определённой ролью

Write init.sql with the following information:
Create an "chatgpt_4o_app" role with a login password of 'strongPassword'.
Create a schema "chatgpt_4o" and authorize the "chatgpt_4o_app" role to use it.
Grant all privileges to the "chatgpt_4o_app" role on the "chatgpt_4o"

Ответ GPT-4o

Here's your init.sql script to:

Create the chatgpt_4o_app role with login and password.
Create the chatgpt_4o schema.
Grant usage and privileges on the schema to the role.

✅ init.sql

-- Create application role with login
CREATE ROLE chatgpt_4o_app WITH
  LOGIN
  PASSWORD 'strongPassword';

-- Create schema
CREATE SCHEMA chatgpt_4o AUTHORIZATION chatgpt_4o_app;

-- Grant all privileges on the schema to the role
GRANT ALL PRIVILEGES ON SCHEMA chatgpt_4o TO chatgpt_4o_app;

📝 Usage Tips

You can run this manually in your PostgreSQL console or configure it to run automatically using a Docker initdb script if you're using Postgres in Docker.
Make sure your Spring Boot application.yml points to the chatgpt_4o schema, like this:

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/your_database_name?currentSchema=chatgpt_4o

Let me know if you need a Docker Compose setup for PostgreSQL with this script as part of the initialization.

ChatGPT выдал простой и рабочий скрипт, без добавления дополнительных ограничений для роли. Клод, в свою очередь, предоставил более безопасное решение, но он ошибся в скрипте.

В данном случае простота победила. Клод сделал качественнее, но с проблемами, которые затянули процесс разработки. GPT-4o сделал рабочий вариант «тупо» и быстро.

Pull Request с миграциями готов
https://github.com/nzinovev/open-ai-chatgpt/pull/1

Создаём сущности

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

Write entities for the operation and category tables. Provide a path to the package where I should create these entities.

Ответ GPT-4o

Here’s how to create clean, production-ready entities for Category and Operation based on your schema and best practices with Spring Boot + JPA + Lombok.

✅ Recommended Package Structure

src/main/java
└── com/yourcompany/yourapp
    └── model
        ├── Category.java
        └── Operation.java
        └── OperationType.java (enum)

Use this path for your entity package:

> com.yourcompany.yourapp.model

You can replace yourcompany and yourapp with your actual organization and application name.

✅ Category.java

package com.yourcompany.yourapp.model;

import jakarta.persistence.*;
import lombok.*;

import java.util.List;

@Entity
@Table(name = "category", schema = "chatgpt_4o")
@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Category {

    @Id
    @Column(name = "category_id", nullable = false)
    private Long categoryId;

    @Column(name = "category_name", nullable = false)
    private String categoryName;

    @Column(name = "category_description")
    private String categoryDescription;

    @OneToMany(mappedBy = "category", cascade = CascadeType.ALL, orphanRemoval = true)
    private List operations;
}

✅ Operation.java

package com.yourcompany.yourapp.model;

import jakarta.persistence.*;
import lombok.*;

import java.math.BigDecimal;

@Entity
@Table(name = "operation", schema = "chatgpt_4o")
@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Operation {

    @Id
    @Column(name = "operation_id", nullable = false)
    private Long operationId;

    @Column(name = "operation_public_id", nullable = false, unique = true)
    private String operationPublicId;

    @Column(name = "operation_name", nullable = false)
    private String operationName;

    @Column(name = "operation_amount", nullable = false)
    private BigDecimal operationAmount;

    @Enumerated(EnumType.STRING)
    @Column(name = "operation_type", nullable = false)
    private OperationType operationType;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id", nullable = false)
    private Category category;
}

✅ OperationType.java (Enum)

package com.yourcompany.yourapp.model;

public enum OperationType {
    DEPOSIT,
    WITHDRAW
}

Let me know if you want to:

Generate DTOs or mappers.
Add base auditing fields (createdAt, updatedAt, etc.).
Configure ID generation (UUID, sequence, etc.).

Would you like the repository interfaces next?

Я ожидал более качественного результата от GPT, но давайте по порядку.

Id и его генерация

При генерации сущностей ChatGPT-4o не задал автоинкремент для category_id и operation_id и не добавил стратегию @GeneratedValue в Hibernate.

Это критичная ошибка: без стратегии Hibernate считает поле id назначаемым вручную. При попытке сохранения получится:

org.hibernate.id.IdentifierGenerationException: Identifier of entity  'com.example.openai.chatgpt.entity.Category' must be manually assigned before calling 'persist()'

Почему это важно

Поле id без стратегии генерации и без автоинкремента в DDL приводит к тому, что Hibernate не знает, откуда брать значение первичного ключа. Это значит, что:

сущность невозможно сохранить без явного присвоения ID вручную;
ошибка всплывёт только в рантайме при первом сохранении;
починка «в будущем» часто обходится дороже, потому что уже написанный код нужно переписывать под новую стратегию и миграцию.

На этом этапе у меня было два пути:

Исправить сразу — добавить стратегию генерации в сущность и автоинкремент в миграцию.
Оставить как есть и «заметить» проблему только на моменте написания контроллеров.

Второй вариант кажется заманчивым (отложить проблему), но в реальности приведёт к тому, что придётся тратить время на объяснение и исправление ошибки, рискуя поломать уже готовый код. Моё и ваше время важнее, поэтому придерживаюсь правила: баги нужно фиксить как можно раньше.

Исправление стратегии и генерации ID

Чтобы проверить, как GPT-4o справится с частичной подсказкой, я указал только на отсутствие стратегии:

Add missing generation strategy for operationId and categoryId.

Фикс operationId & categoryId

Great catch! By default, JPA needs an ID generation strategy for primary keys unless you're assigning them manually. Since operation_id and category_id are of type Long, the most appropriate strategy for PostgreSQL is usually GenerationType.IDENTITY or GenerationType.SEQUENCE.

✅ Recommendation: Use @GeneratedValue(strategy = GenerationType.IDENTITY)

This works well with PostgreSQL's SERIAL or IDENTITY columns and is simple to implement.

✅ Updated Entity Code with ID Generation

🔹 Category.java

package com.yourcompany.yourapp.model;

import jakarta.persistence.*;
import lombok.*;

import java.util.List;

@Entity
@Table(name = "category", schema = "chatgpt_4o")
@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Category {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "category_id", nullable = false)
    private Long categoryId;

    @Column(name = "category_name", nullable = false)
    private String categoryName;

    @Column(name = "category_description")
    private String categoryDescription;

    @OneToMany(mappedBy = "category", cascade = CascadeType.ALL, orphanRemoval = true)
    private List operations;
}

🔹 Operation.java

package com.yourcompany.yourapp.model;

import jakarta.persistence.*;
import lombok.*;

import java.math.BigDecimal;

@Entity
@Table(name = "operation", schema = "chatgpt_4o")
@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Operation {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "operation_id", nullable = false)
    private Long operationId;

    @Column(name = "operation_public_id", nullable = false, unique = true)
    private String operationPublicId;

    @Column(name = "operation_name", nullable = false)
    private String operationName;

    @Column(name = "operation_amount", nullable = false)
    private BigDecimal operationAmount;

    @Enumerated(EnumType.STRING)
    @Column(name = "operation_type", nullable = false)
    private OperationType operationType;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id", nullable = false)
    private Category category;
}

🧪 Optional: Liquibase Adjustment

If you're using GenerationType.IDENTITY, update your Liquibase YAML to use:

type: BIGSERIAL

For example:

- column:
    name: category_id
    type: BIGSERIAL
    constraints:
      primaryKey: true
      nullable: false

Let me know if you'd like me to regenerate the Liquibase changelog with BIGSERIAL for these IDs.

Что сделал GPT-4o:

Добавил @GeneratedValue в обе сущности.
Указал, что в миграции нужно изменить тип поля на BIGSERIAL (альтернатива autoIncrement для PostgreSQL).

При этом он предложил заменить тип в уже существующем changeset. В проде так делать нельзя: нужно создавать новый changeset, иначе ломается история миграций. Хотелось бы получить изменения через отдельную миграцию или хотя бы получить явное предупреждение вида: «Если миграция уже применена, создайте новый changeset».

Lombok: как много в этом слове багов

ChatGPT-4o использовал Lombok, как это и требовалось по ТЗ, но реализация оказалась классическим примером того, как «удобство» может обернуться скрытыми проблемами.

И снова equals() & hashCode()

Добавил аннотацию @Data, которая под капотом генерирует equals() и hashCode() для всех полей сущности.

Это незаметно спрятало потенциальную рекурсию и OutOfMemory:
- Category.equals() сравнивает все поля, включая коллекцию operations.
- Каждая Operation в этой коллекции, в свою очередь, сравнивает своё поле category.
- Получаем бесконечный цикл category → operations → category → ... до исчерпания памяти.

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

Отлавливать такие случаи помогает плагин JPA Buddy для IntelliJ IDEA: он подсвечивает опасные Lombok-аннотации и предлагает альтернативы и это лишь маленькая часть его возможностей

Чтобы не раздувать статью, я не просил GPT-4o генерировать equals() и hashCode(). Вместо этого я просто взял реализацию, которую предложил Claude в своей части эксперимента.

Небольшая подсказка, как можно формировать промпт, чтобы избежать этой ошибки:

For JPA entities, do not use @Data. Use @Getter/@Setter and 
@EqualsAndHashCode(onlyExplicitlyIncluded = true) with 'id' as the only included field. 
Do not include collections or lazy associations in equals/hashCode.

«Неизменяемые» изменяемые объекты

GPT-4o также добавил @Builder — и это выглядело как плюс: имутабельный объект всегда предпочтительнее мутабельного, но проблема в том, что @Data включает в себя @Setter для всех полей, и объект, созданный билдером, остаётся изменяемым. Появляется ложное ощущение «immutability», а следовательно, потенциальные баги.

ChatGPT так же как и Клод хорошо показывают к чему может привести неосторожное использование Lombok аннотаций.

Связи между сущностями

При генерации сущностей GPT-4o настроил связи между Category и Operation с каскадным удалением всех операций и orphanRemoval = true. Дополнительно — включил EAGER-загрузку коллекций.

Почему каскадное удаление — это риск

Расположение сущностей

GPT-4o предложил хранить сущности в пакете model. Здесь скрывается нюанс. В реальных проектах JPA-сущности обычно не поднимаются выше уровня DAO/репозиториев. На бизнес-слой они мапятся в отдельные модели. Такой подход отделяет сущность от бизнес-логики и снижает риск LazyInitializationException, т.к. работа с сущностью происходит внутри транзакции:

Рекомендуемые варианты: domain.entity или просто entity.

Названия переменных

GPT-4o добавил префиксы для всех свойств (categoryId, categoryName, operationDescription и т.д.).

Вариант GPT-4o:

var category = categoryService.getCategoryById(id);
foo(category.getCategoryId());
bar(category.getCategoryName());

Мой вариант:

var category = categoryService.getCategoryById(id);
foo(category.getId());
bar(category.getName());

Вкусовщина? Безусловно. Отказываюсь ли я от своей претензии? Конечно же нет.

Из положительного могу отметить, что GPT-4o не перепутал имена колонок и сохранил контекст схемы — значит, модель помнила исходную структуру БД (в отличие от Клода).

Ручные исправления

Эту часть я сделал без помощи ChatGPT — описанные проблемы слишком легко правятся, а объяснять их LLM заняло бы больше времени, чем фиксы:

Исправил связь @OneToMany в Category Было:

@OneToMany(mappedBy = "category", cascade = CascadeType.ALL, orphanRemoval = true)

Стало:

@OneToMany(mappedBy = "category")

Пакет для сущностей Было: com.example.openai.chatgpt.model Стало: com.example.openai.chatgpt.entity

ПР с сущностями
https://github.com/nzinovev/open-ai-chatgpt/pull/2

Переходим к созданию CRUD операций.

Пишем CREATE-логику

В первой части исследования с Claude я уже убедился, что лучше всего реализовывать CRUD по одной операции за раз — так легче контролировать качество кода и управлять процессом.

Задача прежняя: используя максимально простой промпт получить максимально качественный результат.

Write a CREATE logic for the Operation entity (Controller - Service - DAO). 
In the first iteration, skip validation of all fields.

Ответ GPT-4o

Great! Below is a clean, layered implementation of the CREATE operation for the Operation entity using:

Controller (OperationController)
Service (OperationService)
Repository (OperationRepository)
DTOs (CreateOperationRequest)
Mapping logic (simple manual mapping)

This implementation skips field validation (as requested) and assumes that the category_id provided in the request already exists.

✅ Recommended Package Structure

com.yourcompany.yourapp
├── controller
│   └── OperationController.java
├── service
│   └── OperationService.java
├── repository
│   └── OperationRepository.java
├── dto
│   └── CreateOperationRequest.java
├── model
│   └── Operation.java
│   └── Category.java
│   └── OperationType.java

📥 CreateOperationRequest.java

package com.yourcompany.yourapp.dto;

import com.yourcompany.yourapp.model.OperationType;
import lombok.*;

import java.math.BigDecimal;

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class CreateOperationRequest {
    private String operationPublicId;
    private String operationName;
    private BigDecimal operationAmount;
    private OperationType operationType;
    private Long categoryId;
}

📁 OperationRepository.java

package com.yourcompany.yourapp.repository;

import com.yourcompany.yourapp.model.Operation;
import org.springframework.data.jpa.repository.JpaRepository;

public interface OperationRepository extends JpaRepository {
}

📁 CategoryRepository.java

package com.yourcompany.yourapp.repository;

import com.yourcompany.yourapp.model.Category;
import org.springframework.data.jpa.repository.JpaRepository;

public interface CategoryRepository extends JpaRepository {
}

💼 OperationService.java

package com.yourcompany.yourapp.service;

import com.yourcompany.yourapp.dto.CreateOperationRequest;
import com.yourcompany.yourapp.model.Category;
import com.yourcompany.yourapp.model.Operation;
import com.yourcompany.yourapp.repository.CategoryRepository;
import com.yourcompany.yourapp.repository.OperationRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class OperationService {

    private final OperationRepository operationRepository;
    private final CategoryRepository categoryRepository;

    public Operation createOperation(CreateOperationRequest request) {
        Category category = categoryRepository.findById(request.getCategoryId())
                .orElseThrow(() -&gt; new RuntimeException("Category not found"));

        Operation operation = Operation.builder()
                .operationId(System.currentTimeMillis()) // Temporary ID generator; replace in production
                .operationPublicId(request.getOperationPublicId())
                .operationName(request.getOperationName())
                .operationAmount(request.getOperationAmount())
                .operationType(request.getOperationType())
                .category(category)
                .build();

        return operationRepository.save(operation);
    }
}

🌐 OperationController.java

package com.yourcompany.yourapp.controller;

import com.yourcompany.yourapp.dto.CreateOperationRequest;
import com.yourcompany.yourapp.model.Operation;
import com.yourcompany.yourapp.service.OperationService;
import lombok.RequiredArgsConstructor;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/operations")
@RequiredArgsConstructor
public class OperationController {

    private final OperationService operationService;

    @PostMapping
    public ResponseEntity createOperation(@RequestBody CreateOperationRequest request) {
        Operation created = operationService.createOperation(request);
        return ResponseEntity.ok(created);
    }
}

🧪 Example POST Request

Endpoint: POST /api/operations
Content-Type: application/json

{
  "operationPublicId": "abc-123",
  "operationName": "Initial Deposit",
  "operationAmount": 1000.00,
  "operationType": "DEPOSIT",
  "categoryId": 1
}

🔄 Next Steps (Optional)

Let me know if you'd like to:

Add field validations.
Replace manual ID generation with auto-increment or sequence.
Implement exception handling (custom errors, validation messages).
Return a DTO instead of full entity.

Would you like to proceed with any of these enhancements?

Первые наблюдения

Сразу бросилось в глаза: ни Claude, ни GPT-4o не предложили использовать record-классы для DTO, хотя в начальном промпте я указывал Java 21+. Видимо, пока эта привычка у LLM не сформировалась.

CreateOperationRequest: избыточный Lombok

GPT-4o снова использует «комбо» @Data + @Builder, разрушая идею билдера. Плюс — @NoArgsConstructor и @AllArgsConstructor впридачу. Это не оптимизация, а избыточное нагромождение аннотаций.

Аналогично Claude, GPT-4o не добавил @JsonProperty для DTO-моделей, делая API более хрупким (зависимость от имён полей на стороне Java).

Внешний ID операции в запросе

GPT-4o построил логику таким образом, что клиент присылает внешний ID операции, которая создаётся на бэкенде. Это в корне нарушает принцип разделения ответственности:

Алгоритм генерации публичных ID — зона ответственности сервера, а не клиента.
Передача таких ID клиентом даёт лишнюю пространство для потенциальных багов и злоупотреблений.

Внутренние ID в запросе

Операция связана с категорией, но требовать от клиента ID категории в запросе — сомнительная практика:

Клиенту в большинстве случаев не нужны внутренние ID.
Логичнее передавать имя категории, а на сервере маппить его на ID. Это снижает связность и упрощает API.

OperationService: сущности в API

GPT-4o возвращает наружу JPA-сущность Operation. Это сразу несколько ошибок:

Антипаттерн — приучает неопытных разработчиков отдавать сущности прямо в API.
Operation содержит ManyToOne-связь. Если она LAZY, доступ к полям вне транзакции приведёт к LazyInitializationException.
Если связь в состоянии EAGER будет в будущем заменена на LAZY, в будущем может внезапно уронить прод.
Мы раскрываем клиенту все поля сущности, включая внутренние ID и связанные структуры. (Отдаём сущность вместо DTO)
Из-за включённого по умолчанию в Spring OSIV (Open Session in View) проблема с возвращением сущности в контроллере замаскирована: сериализация в JSON подтянет данные из БД на лету, т.к. Hibernate сессия ещё открыта, но при отключении OSIV это также приведёт к неожиданным падения в боевой среде.

Временная генерация ID

Это особенно странно: в предыдущем шаге GPT-4o уже исправлял стратегию генерации ID, но в сервисе зачем-то добавил «временные» ID вручную. Hibernate и PostgreSQL прекрасно справились бы сами.

В результате CREATE-логика в текущем виде не работает.

RuntimeException для ошибок пользователя

GPT-4o обрабатывает случай «категория не найдена», но выбрасывает голый RuntimeException. В будущем, при добавлении GlobalExceptionHandler, это исключение может потеряться, и клиент получит 500-ю ошибку вместо осмысленного 400/404.

Чиним

На этом этапе я понял: если продолжу разбирать каждую проблему так детально, то исследование ChatGPT займёт вечность.

Поэтому стратегия меняется:

Кратко описываю проблему.
Прошу GPT-4o исправить код.
Оцениваю, насколько хорошо он справился.

Пробуем исправить ответ

Промпт:

Change response model in OperationController.createOperation from an entity (Operation) to a DTO

Правки GPT-4o

Great decision — returning a DTO instead of an entity is best practice to:

Prevent overexposing your entity structure.
Maintain version control over your API response models.
Decouple internal model changes from API contracts.

✅ Step-by-Step Update

We'll introduce a new response DTO called OperationResponse and use it in the controller response.

📤 OperationResponse.java

package com.yourcompany.yourapp.dto;

import com.yourcompany.yourapp.model.OperationType;
import lombok.*;

import java.math.BigDecimal;

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class OperationResponse {
    private Long operationId;
    private String operationPublicId;
    private String operationName;
    private BigDecimal operationAmount;
    private OperationType operationType;
    private Long categoryId;
}

🔁 Update in OperationService

Update the return type and add mapping logic.

✅ Updated Method in OperationService.java:

import com.yourcompany.yourapp.dto.OperationResponse;

public OperationResponse createOperation(CreateOperationRequest request) {
    Category category = categoryRepository.findById(request.getCategoryId())
            .orElseThrow(() -&gt; new RuntimeException("Category not found"));

    Operation operation = Operation.builder()
            .operationId(System.currentTimeMillis()) // Temporary
            .operationPublicId(request.getOperationPublicId())
            .operationName(request.getOperationName())
            .operationAmount(request.getOperationAmount())
            .operationType(request.getOperationType())
            .category(category)
            .build();

    Operation saved = operationRepository.save(operation);

    return OperationResponse.builder()
            .operationId(saved.getOperationId())
            .operationPublicId(saved.getOperationPublicId())
            .operationName(saved.getOperationName())
            .operationAmount(saved.getOperationAmount())
            .operationType(saved.getOperationType())
            .categoryId(saved.getCategory().getCategoryId())
            .build();
}

🌐 Updated OperationController.java

import com.yourcompany.yourapp.dto.OperationResponse;

@PostMapping
public ResponseEntity createOperation(@RequestBody CreateOperationRequest request) {
    OperationResponse response = operationService.createOperation(request);
    return ResponseEntity.ok(response);
}

Let me know if you'd like:

To map this via ModelMapper or MapStruct for larger projects.
To include category name in the response.
To create a dedicated response wrapper for consistency (ApiResponse, etc.).

Результат:

Снова @Builder + @Data.
В DTO возвращаются внутренние ID.
OperationType взят из сущности — невозможно поддерживать разные модели для API и для внутренней логики.
Нет мапперов — ChatGPT предлагает постоянно копировать код сборки объекта операции

Вывод по CREATE

Пока GPT-4o выдаёт код "в лоб": без DTO-моделей, без мапперов, с нарушением принципов проектирования. Подобные ответы закрепляют вредные привычки у разработчиков с небольшим опытом.

Что я добавлю в будущие промпты для ChatGPT:

"think step by step" — чтобы ответ был структурированным.
"If you have any questions, ask them first" — чтобы модель уточняла детали перед генерацией кода.

По моему опыту, эти фразы значительно повышают качество выдачи у GPT-4o, который сильно зависит от явного фрейминга задачи.

PR на создание операции
https://github.com/nzinovev/open-ai-chatgpt/pull/3

UPDATE - логика

Запрос к GPT-4o:

Write an UPDATE logic for the Operation entity (Controller - Service - DAO). 
In the first iteration, skip validation of all fields.
Think step by step. If you have any questions, ask them first.

Первое отличие — вопросы

Наконец-то модель решила уточнить детали:

GPT-4o уточняет детали

Perfect — let's walk through this step by step for the UPDATE logic of the Operation entity. First, I’ll clarify the assumptions and ask a couple of questions to ensure alignment.

✅ Step-by-Step Planning

1. Understanding the update use case

We're adding an endpoint to update an existing Operation based on a client-provided identifier.

Likely flow:

Receive a PUT request with an operationId (path variable) and update data (request body).
Find the existing Operation by ID.
Update the mutable fields (publicId, name, amount, type, categoryId, etc.).
Save the updated operation and return a DTO.

❓ Questions Before Implementation

To tailor this update logic precisely, I need clarification on the following:

1. Identifier for Update:

Should the operation be updated by:

operation_id (DB ID — primary key)? (default option, recommended)
or operation_public_id (external ID)?

👉 If you expect this API to be public-facing, using operation_public_id might be more appropriate.

2. Partial vs Full Update:

Should the update:

Be full update (PUT — expects full data and overwrites)?
Or partial update (PATCH — only updates provided fields)?

👉 You mentioned skipping validation, so we can start with full update via PUT.

3. Behavior on Missing category_id:

Should we:

Allow reassignment to a new category?
Or reject the update if the category is missing?

Please confirm:

✅ Use operation_id in path param
✅ Full update (PUT)
✅ Require category_id and allow category reassignment

Once confirmed, I’ll proceed with the full implementation.

Мои ответы:

1. Use operation_public_id for update
2. Partial update
3. If `category_id` is missing -> reject the update

Update operation от GPT-4o

Excellent, thanks for the clarification. Here's our refined plan for implementing the partial update logic using:

operation_public_id as the lookup key
PATCH semantics (only update fields provided)
Rejection if category_id is missing but the user attempts to change the category

✅ Final Update Plan

✅ 1. Endpoint

Method: PATCH
Path: /api/operations/{operationPublicId}

✅ 2. Update Flow

Fetch Operation by operation_public_id
Check which fields are non-null in the request
Apply changes selectively
If categoryId is present:
- Lookup and assign category
If categoryId is null but the field is attempted to be changed → reject
Save and return updated OperationResponse

✅ Implementation

📥 UpdateOperationRequest.java (new DTO)

package com.yourcompany.yourapp.dto;

import com.yourcompany.yourapp.model.OperationType;
import lombok.*;

import java.math.BigDecimal;

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class UpdateOperationRequest {
    private String operationName;
    private BigDecimal operationAmount;
    private OperationType operationType;
    private Long categoryId;
}

📤 Reuse OperationResponse.java from earlier

📁 OperationRepository.java — Add Method

import java.util.Optional;

Optional findByOperationPublicId(String operationPublicId);

💼 OperationService.java — Add Method

import com.yourcompany.yourapp.dto.UpdateOperationRequest;
import com.yourcompany.yourapp.dto.OperationResponse;

public OperationResponse updateOperation(String publicId, UpdateOperationRequest request) {
    Operation operation = operationRepository.findByOperationPublicId(publicId)
            .orElseThrow(() -&gt; new RuntimeException("Operation not found with publicId: " + publicId));

    if (request.getOperationName() != null) {
        operation.setOperationName(request.getOperationName());
    }

    if (request.getOperationAmount() != null) {
        operation.setOperationAmount(request.getOperationAmount());
    }

    if (request.getOperationType() != null) {
        operation.setOperationType(request.getOperationType());
    }

    if (request.getCategoryId() != null) {
        Category category = categoryRepository.findById(request.getCategoryId())
                .orElseThrow(() -&gt; new RuntimeException("Category not found: " + request.getCategoryId()));
        operation.setCategory(category);
    } else if (request.getCategoryId() == null &amp;&amp; requestHasCategoryField(request)) {
        throw new RuntimeException("Category ID is required when updating category");
    }

    Operation saved = operationRepository.save(operation);

    return OperationResponse.builder()
            .operationId(saved.getOperationId())
            .operationPublicId(saved.getOperationPublicId())
            .operationName(saved.getOperationName())
            .operationAmount(saved.getOperationAmount())
            .operationType(saved.getOperationType())
            .categoryId(saved.getCategory().getCategoryId())
            .build();
}

// Utility to detect if categoryId was intentionally included
private boolean requestHasCategoryField(UpdateOperationRequest request) {
    try {
        return UpdateOperationRequest.class.getDeclaredField("categoryId") != null;
    } catch (NoSuchFieldException e) {
        return false;
    }
}

🌐 OperationController.java — Add Endpoint

import com.yourcompany.yourapp.dto.UpdateOperationRequest;
import com.yourcompany.yourapp.dto.OperationResponse;

@PatchMapping("/{operationPublicId}")
public ResponseEntity updateOperation(
        @PathVariable String operationPublicId,
        @RequestBody UpdateOperationRequest request
) {
    OperationResponse response = operationService.updateOperation(operationPublicId, request);
    return ResponseEntity.ok(response);
}

✅ Example Request

PATCH /api/operations/abc-123

{
  "operationAmount": 450.75,
  "operationType": "WITHDRAW"
}

This will only update amount and type.

Would you like help adding:

Field validation (e.g., amount must be > 0)?
Custom exception classes for better error responses?
Unit tests for the service layer?

Let me know how you'd like to proceed.

Итоговый код и проблемы

Нет @JsonProperty в DTO

По-прежнему API остаётся хрупким: структура JSON напрямую зависит от имён Java-полей.

Некорректная обработка ошибок

Если передана несуществующая категория, GPT-4o предлагает кидать голый RuntimeException. В большинстве приложений это приведёт к 500-й ошибке. По сути, это ошибка клиента (400/404), и она должна обрабатываться соответствующим образом.

Лишняя выдуманная логика

Появился странный класс requestHasCategoryField, которого я явно не просил. Аналогичная ситуация была с временным ID в CREATE-логике — модель придумывает «костыли» на ровном месте.

Нет мапперов

Как и прежде, код для сборки OperationResponse тупо копируется вручную. Без централизованного маппера это увеличивает количество ошибок и дублирования.

Нелогичный порядок проверки

Проверка существования категории выполняется в самом конце метода — уже после того, как начинается сборка новой сущности. Если категория не существует, вся проделанная работа просто выбрасывается в мусорку вместе с исключением.

Несоответствие контракту API

В примере запроса отсутствует обязательный categoryId, хотя я явно указал, что он обязателен для обновления операции.

Исправляем хотя бы ключевое

Чтобы не плодить лишние ошибки, прошу модель убрать RuntimeException и заменить на корректный тип:

You throw `RuntimeException` if categoryId is null, but this is a client exception. 
Provide a custom exception which I can 'catch' in a future and wrap into 400 response.

Ответ GPT-4o

You're absolutely right — using RuntimeException here is too generic and inappropriate for signaling client-side errors (like bad input). We should introduce a custom exception, e.g. BadRequestException, that we can later handle in a global exception handler to return a proper HTTP 400 Bad Request.

✅ Step-by-Step Solution

1. Define a custom exception: BadRequestException

2. Throw it when business logic detects a client error

3. (Optional future step) Catch it in @ControllerAdvice for 400 response

📁 BadRequestException.java

Create it in:

> com.yourcompany.yourapp.exception

package com.yourcompany.yourapp.exception;

import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.ResponseStatus;

@ResponseStatus(HttpStatus.BAD_REQUEST)
public class BadRequestException extends RuntimeException {
    public BadRequestException(String message) {
        super(message);
    }
}

This annotation ensures Spring automatically returns 400 unless you override with @ControllerAdvice.

✅ Update OperationService.java

Replace this:

throw new RuntimeException("Category ID is required when updating category");

With:

throw new BadRequestException("Category ID is required when updating category");

Also replace the similar exception for "Category not found" if it's due to bad client input.

✅ Optional (Advanced): Use Global Exception Handler

Later, you can handle all custom exceptions cleanly with:

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(BadRequestException.class)
    public ResponseEntity&gt; handleBadRequest(BadRequestException ex) {
        return ResponseEntity
            .badRequest()
            .body(Map.of("error", ex.getMessage()));
    }
}

Let me know if you'd like help:

Creating NotFoundException, ConflictException, etc.
Designing a full structured error response (timestamp, path, etc.).
Writing tests for this exception flow.

GPT-4o создал кастомное исключение. Добавил над ним @ResponseStatus, и одновременно предложил GlobalExceptionHandler с обработкой этой ошибки. В результате аннотация @ResponseStatus стала бесполезной — код дублирует поведение.

Итог

Код теперь работает и выбрасывает корректный статус для ошибки клиента, но:

Архитектурно он всё ещё далёк от идеала.
Мапперов по-прежнему нет.
Контракт API с обязательным categoryId не соблюдён.

Код работает, но его есть куда улучшать. В рамках эксперимента оставляю его без изменений, иначе мы рискуем увязнуть в бесконечной доработке.

Commit на update операции
https://github.com/nzinovev/open-ai-chatgpt/commit/5d8c6d595a2f7db84eaa0f7c7ff271a0cf61978d

Реализуем READ-логику для операций

Прошу создать две ручки:

Получение всех операций с пагинацией
Получение операции по publicId Запрос к GPT-4o:

Write a FIND logic for the Operation entity (Controller - Service - DAO). 
In the first iteration, skip validation of all fields. 
You need to add two endpoints, the first one that finds all operations with pagination, and the second one that finds an operation by publicId.

Think step by step. If you have any questions, ask them first.

GPT-4o проясняет детали

Great — here's how we'll approach the FIND logic for the Operation entity.

✅ Step-by-Step Breakdown

💡 Goals

Implement two endpoints:

Find all operations (paginated)
Find operation by operationPublicId

📌 Assumptions (Let me know if you want changes)

Find all will be accessible via GET /api/operations, using query params page and size.
Default sort: descending by operationId (can be updated later).
If operationPublicId is not found → return 404 Not Found.

✅ Plan Summary

Layer	Task
Repository	Add `findByOperationPublicId` and support `Page`
Service	Add methods to wrap JPA logic and convert entities to DTOs
Controller	Add `GET` endpoints with pagination and publicId search
DTOs	Reuse `OperationResponse`

Do you want:

Filtering by category, type, or name in the list endpoint?
Sorting support on the findAll endpoint?

If not, I’ll proceed with the basic paginated + publicId lookup implementation. Please confirm or extend the requirement.

Уточняющие вопросы

Модель расписала план реализации и уточнила детали. Мои ответы:

1. Skip filtering in first implementation
2. Add sorting as you mentioned earlier: descending by `operationId`

Ответ GPT-4o

Perfect — thanks for confirming. We’ll now implement:

✅ Final Plan

Endpoints:

GET /api/operations
→ Returns paged, sorted (desc by operationId) list of operations.
GET /api/operations/{operationPublicId}
→ Returns single operation by publicId. Returns 404 if not found.

✅ Implementation Outline

📦 repository/OperationRepository.java

import com.yourcompany.yourapp.model.Operation;
import org.springframework.data.jpa.repository.JpaRepository;

import java.util.Optional;

public interface OperationRepository extends JpaRepository {
    Optional findByOperationPublicId(String operationPublicId);
}

💼 service/OperationService.java

import com.yourcompany.yourapp.dto.OperationResponse;
import com.yourcompany.yourapp.exception.NotFoundException;
import com.yourcompany.yourapp.model.Operation;
import com.yourcompany.yourapp.repository.OperationRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.data.domain.*;
import org.springframework.stereotype.Service;

import java.util.stream.Collectors;

@Service
@RequiredArgsConstructor
public class OperationService {

    private final OperationRepository operationRepository;

    public Page findAllOperations(int page, int size) {
        Pageable pageable = PageRequest.of(page, size, Sort.by(Sort.Direction.DESC, "operationId"));
        Page operations = operationRepository.findAll(pageable);

        return operations.map(this::toDto);
    }

    public OperationResponse findByPublicId(String publicId) {
        Operation operation = operationRepository.findByOperationPublicId(publicId)
                .orElseThrow(() -&gt; new NotFoundException("Operation not found with publicId: " + publicId));
        return toDto(operation);
    }

    private OperationResponse toDto(Operation operation) {
        return OperationResponse.builder()
                .operationId(operation.getOperationId())
                .operationPublicId(operation.getOperationPublicId())
                .operationName(operation.getOperationName())
                .operationAmount(operation.getOperationAmount())
                .operationType(operation.getOperationType())
                .categoryId(operation.getCategory().getCategoryId())
                .build();
    }
}

🌐 controller/OperationController.java

import com.yourcompany.yourapp.dto.OperationResponse;
import com.yourcompany.yourapp.service.OperationService;
import lombok.RequiredArgsConstructor;
import org.springframework.data.domain.Page;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/operations")
@RequiredArgsConstructor
public class OperationController {

    private final OperationService operationService;

    @GetMapping
    public ResponseEntity&gt; findAllOperations(
            @RequestParam(defaultValue = "0") int page,
            @RequestParam(defaultValue = "10") int size
    ) {
        return ResponseEntity.ok(operationService.findAllOperations(page, size));
    }

    @GetMapping("/{operationPublicId}")
    public ResponseEntity findByPublicId(
            @PathVariable String operationPublicId
    ) {
        return ResponseEntity.ok(operationService.findByPublicId(operationPublicId));
    }
}

❗ Optional: NotFoundException.java

Create under: exception/NotFoundException.java

package com.yourcompany.yourapp.exception;

import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.ResponseStatus;

@ResponseStatus(HttpStatus.NOT_FOUND)
public class NotFoundException extends RuntimeException {
    public NotFoundException(String message) {
        super(message);
    }
}

✅ Example Usage

1. Find All (Paginated, Sorted)

GET /api/operations?page=0&amp;size=5

2. Find by Public ID

GET /api/operations/abc-123

Let me know if you’d like:

Total count & paging metadata wrapped in a custom response.
Filtering by operationType, categoryId, etc.
HATEOAS-style links for navigation.

Would you like to proceed with test cases or enhancements next?

Проблемные моменты

Сортировка «зашита» в сервис

Я предполагал, что сортировка по operationId будет добавлена как параметр контроллера, чтобы её можно было гибко менять. GPT-4o же «зашил» сортировку в сервисный слой. Следовательно, любое изменение сортировки теперь требует нового релиза и правки API

Первая страница: page = 0

Модель, как и Claude, решила, что нам удобно считать страницы с нуля. Да, так принято в Pageable в Spring, но для клиента это неинтуитивно, и теперь придётся явно прописывать это в документации API, чтобы избежать путаницы.

Возврат Page напрямую

GPT-4o без стеснения возвращает Page наружу. DTO для постраничного ответа не создаётся — клиент получает огромную кучу служебной метаинформации, которая в большинстве случаев не нужна. Для удобства и гибкости нужно создавать свою модель ответа (как сделал Claude) и мапить Page в неё.

Ленивый ChatGPT

На этом этапе стало окончательно понятно: GPT-4o не склонен предлагать архитектурно правильные решения, если явно не попросить. Claude в аналогичном задании сам предложил DTO для пагинированного ответа. GPT-4o же оставил это на меня — либо править самому, либо тратить дополнительный промпт на доработку.

Вывод по READ-операции

Функционал рабочий, но архитектурно решение слабое: жёстко зашитая сортировка, отсутствие DTO для постраничного ответа. Всё это требует изменений, в рамках тестирования этого достаточно, но в реальном проекте логику придётся дорабатывать вручную или отдельными запросами к модели.

Двигаемся дальше — к последнему эндпоинту: удаление операции.

PR на read-логику
https://github.com/nzinovev/open-ai-chatgpt/pull/4

DELETE-логика

Рискнул и не добавлял уточняющих вопросов — проверим, как GPT-4o справится сам.

Запрос к GPT-4o:

Write a DELETE logic for the Operation entity (Controller - Service - DAO). 
In the first iteration, skip validation of all fields.

DELETE-логика от GPT-4o

Great — here’s a clean implementation of the DELETE logic for the Operation entity using operationPublicId as the lookup key.

✅ Summary

🔧 Requirements

Delete by operationPublicId
Skip field validation for now
Return HTTP 204 No Content on success
Return HTTP 404 Not Found if not found

✅ Implementation

📁 OperationRepository.java

No changes needed (already has findByOperationPublicId)

❗ NotFoundException.java

Already exists — reused to return 404

💼 OperationService.java — Add delete method

public void deleteByPublicId(String publicId) {
    Operation operation = operationRepository.findByOperationPublicId(publicId)
            .orElseThrow(() -&gt; new NotFoundException("Operation not found with publicId: " + publicId));

    operationRepository.delete(operation);
}

🌐 OperationController.java — Add endpoint

@DeleteMapping("/{operationPublicId}")
public ResponseEntity deleteByPublicId(@PathVariable String operationPublicId) {
    operationService.deleteByPublicId(operationPublicId);
    return ResponseEntity.noContent().build();
}

✅ Resulting Behavior

🔄 Request

DELETE /api/operations/abc-123

✅ Success Response

204 No Content

❌ Not Found

404 Not Found
{
  "error": "Operation not found with publicId: abc-123"
}

Let me know if you'd like:

Soft deletes (e.g., deleted_at column)
Deletion protection (e.g., prevent delete for DEPOSIT operations)
Audit logging

Would you like to proceed with testing or add bulk delete support next?

Результат

Модель без лишних вопросов и планов переиспользовала существующие куски кода, что стало возможным благодаря сохранённому контексту диалога (говорит о хорошем контекстном окне ChatGPT). Логика получилась рабочей, соответствующей предыдущим CRUD-операциям.

Небольшие замечания

ResponseEntity везде

Во всех эндпоинтах, включая DELETE, GPT-4o оборачивает ответы в ResponseEntity.

Это рабочий и допустимый подход, но в Spring Boot можно обойтись без этого — он и так оборачивает ответы в необходимый HTTP-status.

Для DELETE логики чаще всего достаточно вернуть void с аннотацией @ResponseStatus(HttpStatus.NO_CONTENT) или аналогичной, что делает код чуть чище.

Добавляем валидацию

По аналогии с тестом Клода, я беру только один эндпоинт — CREATE Operation — и прошу ChatGPT:

добавить валидацию входных данных
написать unit-тесты для сервисного слоя
сделать MVC-тест для контроллера

Я напомнил модели весь код создания операции, включая DTO и Entity, чтобы у неё был полный контекст.

Напоминаю весь контекст

This is how the create operation logic is currently implemented.

Context

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class CreateOperationRequest {
    private String operationName;
    private BigDecimal operationAmount;
    private OperationType operationType;
    private Long categoryId;
}

@RestController
@RequestMapping("/api/operations")
@RequiredArgsConstructor
public class OperationController {

    private final OperationService operationService;

    @PostMapping
    public ResponseEntity createOperation(@RequestBody CreateOperationRequest request) {
        var created = operationService.createOperation(request);
        return ResponseEntity.ok(created);
    }
}

@Service
@RequiredArgsConstructor
public class OperationService {

    private final OperationRepository operationRepository;
    private final CategoryRepository categoryRepository;

    public OperationResponse createOperation(CreateOperationRequest request) {
        Category category = categoryRepository.findById(request.getCategoryId())
                .orElseThrow(() -&gt; new BadRequestException("Category not found"));

        Operation operation = Operation.builder()
                .publicId(UUID.randomUUID().toString())
                .name(request.getOperationName())
                .amount(request.getOperationAmount())
                .type(request.getOperationType())
                .category(category)
                .build();

        var saved = operationRepository.save(operation);
        return toDto(saved);
    }

    private OperationResponse toDto(Operation operation) {
        return OperationResponse.builder()
                .operationId(operation.getId())
                .operationPublicId(operation.getPublicId())
                .operationName(operation.getName())
                .operationAmount(operation.getAmount())
                .operationType(operation.getType())
                .categoryId(operation.getCategory().getId())
                .build();
    }
}

@Entity
@Table(name = "operation", schema = "chatgpt_4o")
@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Operation {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "operation_id", nullable = false)
    private Long id;

    @Column(name = "operation_public_id", nullable = false, unique = true)
    private String publicId;

    @Column(name = "operation_name", nullable = false)
    private String name;

    @Column(name = "operation_amount", nullable = false)
    private BigDecimal amount;

    @Enumerated(EnumType.STRING)
    @Column(name = "operation_type", nullable = false)
    private OperationType type;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id", nullable = false)
    private Category category;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Operation operation)) return false;
        return id != null &amp;&amp; id.equals(operation.id);
    }

    @Override
    public int hashCode() {
        return id != null ? id.hashCode() : super.hashCode();
    }
}

Question

Add validation for "create operation" logic.

Think step by step. If you have any questions, ask them first.

Валидация от GPT-4o

Perfect — thanks for the confirmation.

We'll now implement full validation for the Create Operation flow using:

jakarta.validation annotations
@Valid in the controller
A custom global exception handler to return a structured 400 response

✅ Step 1: Add Validation to CreateOperationRequest

package com.yourcompany.yourapp.dto;

import com.yourcompany.yourapp.model.OperationType;
import jakarta.validation.constraints.*;
import lombok.*;

import java.math.BigDecimal;

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class CreateOperationRequest {

    @NotBlank(message = "Operation name is required")
    @Size(max = 255, message = "Operation name must not exceed 255 characters")
    private String operationName;

    @NotNull(message = "Amount is required")
    @DecimalMin(value = "0.01", inclusive = true, message = "Amount must be greater than 0")
    private BigDecimal operationAmount;

    @NotNull(message = "Operation type is required")
    private OperationType operationType;

    @NotNull(message = "Category ID is required")
    private Long categoryId;
}

✅ Step 2: Enable Validation in OperationController

Update the controller method to use @Valid:

@PostMapping
public ResponseEntity createOperation(@RequestBody @Valid CreateOperationRequest request) {
    var created = operationService.createOperation(request);
    return ResponseEntity.ok(created);
}

✅ Step 3: Add Global Exception Handler for Validation Errors

Create a new class:

> exception/GlobalExceptionHandler.java

package com.yourcompany.yourapp.exception;

import jakarta.validation.ConstraintViolationException;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.MethodArgumentNotValidException;
import org.springframework.web.bind.annotation.*;

import java.util.HashMap;
import java.util.Map;

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity&gt; handleValidationErrors(MethodArgumentNotValidException ex) {
        Map errors = new HashMap&lt;&gt;();

        ex.getBindingResult().getFieldErrors().forEach(fieldError -&gt; {
            errors.put(fieldError.getField(), fieldError.getDefaultMessage());
        });

        Map response = new HashMap&lt;&gt;();
        response.put("status", 400);
        response.put("error", "Bad Request");
        response.put("message", "Validation failed");
        response.put("errors", errors);

        return ResponseEntity.badRequest().body(response);
    }
}

✅ Example Response

❌ POST /api/operations with invalid data:

{
  "operationAmount": -5,
  "operationType": null,
  "categoryId": null
}

✅ Response: 400 Bad Request

{
  "status": 400,
  "error": "Bad Request",
  "message": "Validation failed",
  "errors": {
    "operationName": "Operation name is required",
    "operationAmount": "Amount must be greater than 0",
    "operationType": "Operation type is required",
    "categoryId": "Category ID is required"
  }
}

Let me know if you want:

To add constraints to prevent duplicate operationPublicId (custom validator)
To group validation messages under error codes for frontend mapping
To extend the same pattern to Update logic

Would you like me to update the PATCH/UPDATE logic with validation next?

Результат первого захода

ChatGPT выдал код с валидацией, но…

Нет необходимых зависимостей

Ровно та же проблема, что и с Клодом:

Не добавлен пакет jakarta.validation (это очевидно и IDE сразу подскажет, что аннотации не находятся)
Но главное — отсутствует зависимость:

<dependency>  
   <groupId>org.springframework.boot</groupId>  
   <artifactId>spring-boot-starter-validation</artifactId>  
</dependency>

Эта зависимость неочевидна для новичков: код будет компилироваться, но валидация при этом не будет работать.

Примитивный GlobalExceptionHandler

Чат добавил обработчик исключений, но решил вернуть просто HashMap. Это решение подходит разве что для быстрой отладки. В реальном проекте нужен чёткий контракт для ошибок, чтобы клиенты API понимали структуру ответа (например, ErrorResponse с кодом, сообщением, временем и т.д.). Как я уже говорил ранее, ChatGPT очень ленивый.

Утерянные исключения

В сервисе уже было исключение:

    public OperationResponse createOperation(CreateOperationRequest request) {
        Category category = categoryRepository.findById(request.getCategoryId())
                .orElseThrow(() -> new BadRequestException("Category not found"));
	//остальной код
}

Вместо того чтобы добавить его в общий обработчик ошибок, модель проигнорировала этот момент.

Можно объяснить это тем, что ChatGPT "помнит" про то, что над исключением есть @ResponseStatus(HttpStatus.BAD_REQUEST) — и ChatGPT мог «посчитать», что этого достаточно, но при появлении централизованного обработчика правильнее было бы либо перенести туда все подобные исключения, либо хотя бы явно упомянуть в «следующих шагах», что это нужно сделать

Чиним валидацию

Я дал модели тот же запрос, что и Клоду:

I've added annotations to CreateOperationRequest. However, when I send a request with incorrect data, the application does not respond with a validation error. The app ignores all annotations related to validation and passing the request on.

Ответ GPT-4o

Thanks for the update — when validation annotations are ignored, it usually comes down to one of the following 3 root causes in Spring Boot.

Let’s diagnose and fix this step by step.

✅ 1. @Valid Annotation Must Be on the Controller Parameter

Problem: The controller method is missing @Valid.

Fix: Ensure your controller method looks like this:

@PostMapping
public ResponseEntity createOperation(@RequestBody @Valid CreateOperationRequest request) {
    var created = operationService.createOperation(request);
    return ResponseEntity.ok(created);
}

⚠️ If @Valid is missing, Spring will not trigger validation even if annotations are present in the DTO.

✅ 2. You Must Be Using jakarta.validation (Correct Import)

Problem: You're importing validation annotations from javax.validation in a Spring Boot 3+ project, which uses Jakarta EE 10.

Fix:

Make sure these are your imports:

import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.NotNull;
import jakarta.validation.constraints.DecimalMin;
import jakarta.validation.Valid;

If you're mixing javax and jakarta, validation will silently fail.

✅ 3. The Validation Starter Must Be on the Classpath

Problem: Missing dependency.

Fix: Ensure your pom.xml includes this starter:


  org.springframework.boot
  spring-boot-starter-validation

This starter pulls in Jakarta Bean Validation support.

✅ Recap: Do These 3 Things

Use @Valid in the controller: @RequestBody @Valid CreateOperationRequest
Use jakarta.validation.* annotations in the DTO
Add spring-boot-starter-validation to your dependencies

Would you like me to review your pom.xml or controller code if the issue persists after checking these?

Результат — короткий, чёткий и полезный ответ с объяснением причины и конкретным решением. Это как раз тот случай, когда GPT-4o показывает сильную сторону: точечная диагностика и быстрый фикс без лишней воды.

Claude, для сравнения, сгенерировал лишние блоки кода, которые лишь путают разработчика.

Вывод по валидации

GPT-4o уверенно справляется с точечными исправлениями и диагностикой конкретных проблем, но если задача подразумевает проработку целостной архитектуры (например, валидация + тесты + обработка исключений), модель часто отдаёт примитивные или неполные решения, которые нужно дорабатывать вручную.

PR с валидацией
https://github.com/nzinovev/open-ai-chatgpt/pull/6

Unit-тесты

В качестве финального задания я попросил ChatGPT-4o написать позитивные и негативные тесты для всей логики внутри OperationService.

Напоминаю логику и прошу написать тесты

This is a reminder of the code contained in the OperationService class:

@Service
@RequiredArgsConstructor
public class OperationService {

    private final OperationRepository operationRepository;
    private final CategoryRepository categoryRepository;

    public OperationResponse createOperation(CreateOperationRequest request) {
        Category category = categoryRepository.findById(request.getCategoryId())
                .orElseThrow(() -&gt; new BadRequestException("Category not found"));

        Operation operation = Operation.builder()
                .publicId(UUID.randomUUID().toString())
                .name(request.getOperationName())
                .amount(request.getOperationAmount())
                .type(request.getOperationType())
                .category(category)
                .build();

        var saved = operationRepository.save(operation);
        return toDto(saved);
    }

    public OperationResponse updateOperation(String publicId, UpdateOperationRequest request) {
        Operation operation = operationRepository.findOperationByPublicId(publicId)
                .orElseThrow(() -&gt; new BadRequestException("Operation not found with publicId: " + publicId));

        if (request.getOperationName() != null) {
            operation.setName(request.getOperationName());
        }

        if (request.getOperationAmount() != null) {
            operation.setAmount(request.getOperationAmount());
        }

        if (request.getOperationType() != null) {
            operation.setType(request.getOperationType());
        }

        if (request.getCategoryId() != null) {
            Category category = categoryRepository.findById(request.getCategoryId())
                    .orElseThrow(() -&gt; new BadRequestException("Category not found: " + request.getCategoryId()));
            operation.setCategory(category);
        } else if (request.getCategoryId() == null) {
            throw new BadRequestException("Category ID is required when updating category");
        }

        Operation saved = operationRepository.save(operation);

        return toDto(saved);
    }

    public Page findAllOperations(int page, int size) {
        var pageable = PageRequest.of(page, size, Sort.by(Sort.Direction.DESC, "id"));
        Page operations = operationRepository.findAll(pageable);

        return operations.map(this::toDto);
    }

    public OperationResponse findByPublicId(String publicId) {
        Operation operation = operationRepository.findOperationByPublicId(publicId)
                .orElseThrow(() -&gt; new NotFoundException("Operation not found with publicId: " + publicId));
        return toDto(operation);
    }

    public void deleteByPublicId(String publicId) {
        Operation operation = operationRepository.findOperationByPublicId(publicId)
                .orElseThrow(() -&gt; new NotFoundException("Operation not found with publicId: " + publicId));
    
        operationRepository.delete(operation);
    }

    private OperationResponse toDto(Operation operation) {
        return OperationResponse.builder()
                .operationId(operation.getId())
                .operationPublicId(operation.getPublicId())
                .operationName(operation.getName())
                .operationAmount(operation.getAmount())
                .operationType(operation.getType())
                .categoryId(operation.getCategory().getId())
                .build();
    }
}

Write unit-tests for OperationService. You should write positive and negative tests where it's needed (for example: check that an exception will be thrown)

Ответ GPT-4o

Perfect — let’s create unit tests for OperationService, covering both positive and negative paths.

✅ Tools & Setup

We’ll use:

JUnit 5
Mockito (@Mock, @InjectMocks)
@ExtendWith(MockitoExtension.class)

✅ Test Cases to Cover

Method	Scenario	Expectation
`createOperation`	Valid input	Saves and returns DTO
	Category not found	Throws `BadRequestException`
`updateOperation`	Valid update	Applies changes and returns DTO
	Operation not found	Throws `BadRequestException`
	Category not found	Throws `BadRequestException`
	`categoryId` is null	Throws `BadRequestException`
`findByPublicId`	Found	Returns DTO
	Not found	Throws `NotFoundException`
`findAllOperations`	Returns paginated result	Returns correct page
`deleteByPublicId`	Found	Deletes operation
	Not found	Throws `NotFoundException`

✅ Test File: OperationServiceTest.java

package com.yourcompany.yourapp.service;

import com.yourcompany.yourapp.dto.CreateOperationRequest;
import com.yourcompany.yourapp.dto.UpdateOperationRequest;
import com.yourcompany.yourapp.exception.BadRequestException;
import com.yourcompany.yourapp.exception.NotFoundException;
import com.yourcompany.yourapp.model.*;
import com.yourcompany.yourapp.repository.CategoryRepository;
import com.yourcompany.yourapp.repository.OperationRepository;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;

import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import org.springframework.data.domain.*;

import java.math.BigDecimal;
import java.util.*;

import static org.assertj.core.api.Assertions.*;
import static org.mockito.Mockito.*;

@ExtendWith(MockitoExtension.class)
class OperationServiceTest {

    @Mock private OperationRepository operationRepository;
    @Mock private CategoryRepository categoryRepository;

    @InjectMocks private OperationService operationService;

    private Category category;
    private Operation operation;

    @BeforeEach
    void setUp() {
        category = Category.builder().id(1L).name("Test Category").build();
        operation = Operation.builder()
                .id(1L)
                .publicId("uuid-123")
                .name("Test Operation")
                .amount(BigDecimal.valueOf(100))
                .type(OperationType.DEPOSIT)
                .category(category)
                .build();
    }

    // --- CREATE ---

    @Test
    void createOperation_success() {
        var request = CreateOperationRequest.builder()
                .operationName("Create")
                .operationAmount(BigDecimal.TEN)
                .operationType(OperationType.DEPOSIT)
                .categoryId(1L)
                .build();

        when(categoryRepository.findById(1L)).thenReturn(Optional.of(category));
        when(operationRepository.save(any())).thenReturn(operation);

        var response = operationService.createOperation(request);

        assertThat(response).isNotNull();
        assertThat(response.getOperationName()).isEqualTo("Test Operation");
        verify(operationRepository).save(any());
    }

    @Test
    void createOperation_categoryNotFound_throwsBadRequest() {
        var request = CreateOperationRequest.builder()
                .categoryId(999L)
                .operationAmount(BigDecimal.TEN)
                .operationName("Invalid")
                .operationType(OperationType.DEPOSIT)
                .build();

        when(categoryRepository.findById(999L)).thenReturn(Optional.empty());

        assertThatThrownBy(() -&gt; operationService.createOperation(request))
                .isInstanceOf(BadRequestException.class)
                .hasMessageContaining("Category not found");
    }

    // --- UPDATE ---

    @Test
    void updateOperation_success() {
        var request = UpdateOperationRequest.builder()
                .operationName("Updated")
                .operationAmount(BigDecimal.valueOf(999))
                .operationType(OperationType.WITHDRAW)
                .categoryId(1L)
                .build();

        when(operationRepository.findOperationByPublicId("uuid-123")).thenReturn(Optional.of(operation));
        when(categoryRepository.findById(1L)).thenReturn(Optional.of(category));
        when(operationRepository.save(any())).thenReturn(operation);

        var result = operationService.updateOperation("uuid-123", request);

        assertThat(result.getOperationAmount()).isEqualTo(BigDecimal.valueOf(100)); // from setup
        verify(operationRepository).save(any());
    }

    @Test
    void updateOperation_operationNotFound_throwsBadRequest() {
        when(operationRepository.findOperationByPublicId("missing")).thenReturn(Optional.empty());

        assertThatThrownBy(() -&gt; operationService.updateOperation("missing", new UpdateOperationRequest()))
                .isInstanceOf(BadRequestException.class)
                .hasMessageContaining("Operation not found");
    }

    @Test
    void updateOperation_categoryIdMissing_throwsBadRequest() {
        var request = UpdateOperationRequest.builder().categoryId(null).build();
        when(operationRepository.findOperationByPublicId("uuid-123")).thenReturn(Optional.of(operation));

        assertThatThrownBy(() -&gt; operationService.updateOperation("uuid-123", request))
                .isInstanceOf(BadRequestException.class)
                .hasMessageContaining("Category ID is required");
    }

    @Test
    void updateOperation_categoryNotFound_throwsBadRequest() {
        var request = UpdateOperationRequest.builder().categoryId(99L).build();

        when(operationRepository.findOperationByPublicId("uuid-123")).thenReturn(Optional.of(operation));
        when(categoryRepository.findById(99L)).thenReturn(Optional.empty());

        assertThatThrownBy(() -&gt; operationService.updateOperation("uuid-123", request))
                .isInstanceOf(BadRequestException.class)
                .hasMessageContaining("Category not found");
    }

    // --- FIND ONE ---

    @Test
    void findByPublicId_success() {
        when(operationRepository.findOperationByPublicId("uuid-123")).thenReturn(Optional.of(operation));

        var result = operationService.findByPublicId("uuid-123");

        assertThat(result.getOperationName()).isEqualTo("Test Operation");
    }

    @Test
    void findByPublicId_notFound_throwsNotFound() {
        when(operationRepository.findOperationByPublicId("missing")).thenReturn(Optional.empty());

        assertThatThrownBy(() -&gt; operationService.findByPublicId("missing"))
                .isInstanceOf(NotFoundException.class);
    }

    // --- FIND ALL ---

    @Test
    void findAllOperations_success() {
        var page = new PageImpl&lt;&gt;(List.of(operation));
        when(operationRepository.findAll(any(Pageable.class))).thenReturn(page);

        var result = operationService.findAllOperations(0, 10);

        assertThat(result.getContent()).hasSize(1);
    }

    // --- DELETE ---

    @Test
    void deleteByPublicId_success() {
        when(operationRepository.findOperationByPublicId("uuid-123")).thenReturn(Optional.of(operation));

        operationService.deleteByPublicId("uuid-123");

        verify(operationRepository).delete(operation);
    }

    @Test
    void deleteByPublicId_notFound_throwsNotFound() {
        when(operationRepository.findOperationByPublicId("missing")).thenReturn(Optional.empty());

        assertThatThrownBy(() -&gt; operationService.deleteByPublicId("missing"))
                .isInstanceOf(NotFoundException.class);
    }
}

✅ Notes

Uses Mockito for mocking repositories.
Uses AssertJ (assertThat, assertThatThrownBy) for fluent assertions.
Covers all critical success and failure paths.

Would you like:

Integration tests for controller endpoints (@WebMvcTest)?
Test coverage for GlobalExceptionHandler?
MockMvc or RestAssured tests with Spring Boot Test?

Let me know how you'd like to extend your test coverage.

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

Проблемы тестов на создание операции

В тесте для «успешного» сценария, подготовка входных данных выглядела так:

var request = CreateOperationRequest.builder()
                .operationName("Create")
                .operationAmount(BigDecimal.TEN)
                .operationType(OperationType.DEPOSIT)
                .categoryId(1L)
                .build();

Однако при вызове operationService.createOperation(request) сервис сначала маппит DTO в сущность, а потом сохраняет её в БД.
В тесте же маппинг вообще не проверяется — вместо этого в моке возвращается заранее подготовленная операция с другими значениями, не проверяя при этом входящую модель в метод save():

when(operationRepository.save(any())).thenReturn(operation);

Далее, идёт проверка одного из полей сохранённой операции и проверка происходит не с тем значением, которое было передано в "запросе", а с тем, что заполнено в стабе

assertThat(response.getOperationName()).isEqualTo("Test Operation");

По сути, тест вообще не проверяет бизнес-логику. Он проверяет, что мок вернул то, что мы сами же в него положили. Это опасная ловушка: тест проходит, создавая ложное ощущение правильности кода.

Исправлять или нет?

Исправлять ошибки я не стал. На момент 07.08.2025 OpenAI отключили все предыдущие модели, включая GPT-4o, и выпустили GPT-5. Эта статья фактически превратилась в исторический документ — срез возможностей и ограничений модели, которой больше нет в доступе.

MVC-тесты я дописать не успел, но объёма уже собранного материала достаточно, чтобы сравнить 4o с Клодом и подвести итог.

P.S. Спустя несколько дней, GPT-4o была возвращена с пометкой "Устаревшая модель", что наводит меня на мысль о временности решения. Поэтому я принял решение оставить статью в её изначальном виде, без дописывания MVC-тестов.

PR с unit-тестами
https://github.com/nzinovev/open-ai-chatgpt/pull/7

Итоги

Взаимодействие с GPT-4o было сложным. Ближе к концу эксперимента я сформировал для себя «психологический портрет» этой модели:

Это разработчик «на чиле», который пишет код, чтобы от него отстали. Он выполняет задачу в лоб, без особых размышлений об архитектуре и качестве, и готов поправить только если явно попросить.

Из позитивного — мне понравилось, что GPT-4o часто заканчивал ответ наводящими вопросами. Это полезно для новичков: если ты не до конца понимаешь, куда двигаться, модель могла подсказать вектор.

У Клода тоже были наводящие вопросы, но они встречались реже. При этом код у Клода был более осмысленным, ближе к «production-ready» состоянию, с меньшим количеством случайных архитектурных промахов.

В прямом сравнении «балл» я бы всё же отдал Клоду. GPT-4o же оказалась в странном положении: модель официально заменили GPT-5, сняли с полок, потом вернули под давлением пользователей — и теперь она живёт как «устаревшая». Надолго ли? Вполне возможно, что в какой-то момент её окончательно уберут.

Теперь эта глава закрыта. Следующая — исследование GPT-5. На этот раз, вооружённый опытом, я постараюсь довести материал до публикации ещё до того, как выйдет GPT-6 и сравню новую модель с 4o. Будет интересно проследить эволюцию модели.

По традиции, если было интересно, заходи в мой тг-канал.

GPT-4o: последний взгляд