Это вторая часть цикла «Исследование возможностей ИИ писать код». И она особенная: 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).
Thanks for the details! Here's how we'll proceed:
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)
.
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.
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
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 сгенерировал быстрее, но «на глазок» и без уточнений.
Что просил:
Ответ GPT-4oWrite the configuration to connect the application to the PostgreSQL database.
Sure! Here's the standard Spring Boot application configuration for connecting to a PostgreSQL database, including Liquibase support.
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
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 вопрос, как работать с несколькими миграциями, без каких-либо деталей реализации.
Ответ ChatGPTI plan to add new migration files, do I need to add each migration to application.yml for liquibase to process it?
Great question — and no, you don’t need to manually add every migration file to application.yml
.
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.
Use a master changelog like this:
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.
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 хорошо реагирует на фидбек, но не всегда выдаёт качественный результат с первой попытки.
Прошу создать схему с определённой ролью
Ответ GPT-4oWrite 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"
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.
-- 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;
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 с миграциями готов
Повторяем те же действия, что просили у Клода. Попросил добавить сущности, а также указывать структуру пакетов, где хранить код.
Ответ GPT-4oWrite entities for the operation and category tables. Provide a path to the package where I should create these entities.
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.
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.
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;
}
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;
}
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, но давайте по порядку.
При генерации сущностей 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 & categoryIdGreat 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
.
This works well with PostgreSQL's SERIAL
or IDENTITY
columns and is simple to implement.
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;
}
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;
}
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».
ChatGPT-4o использовал Lombok, как это и требовалось по ТЗ, но реализация оказалась классическим примером того, как «удобство» может обернуться скрытыми проблемами.
Добавил аннотацию @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-загрузку коллекций.
Почему каскадное удаление — это риск
Скрытая логика удаления
Одно удаление родительской сущности может повлечь за собой удаление множества связанных объектов, и это будет происходить «молча».
Риск потери данных
Ошибка в логике работы с сущностью может привести к необратимому удалению информации, которую удалять не планировалось.
Проблемы с производительностью
Каскадное удаление может сгенерировать десятки или сотни SQL-запросов, легко привести к N+1 или загрузке большого объёма данных в память.
Orphan removal
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 операций.
В первой части исследования с Claude я уже убедился, что лучше всего реализовывать CRUD по одной операции за раз — так легче контролировать качество кода и управлять процессом.
Задача прежняя: используя максимально простой промпт получить максимально качественный результат.
Write a CREATE logic for the Operation entity (Controller - Service - DAO).
In the first iteration, skip validation of all fields.
Ответ GPT-4oGreat! 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.
com.yourcompany.yourapp
├── controller
│ └── OperationController.java
├── service
│ └── OperationService.java
├── repository
│ └── OperationRepository.java
├── dto
│ └── CreateOperationRequest.java
├── model
│ └── Operation.java
│ └── Category.java
│ └── OperationType.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;
}
package com.yourcompany.yourapp.repository;
import com.yourcompany.yourapp.model.Operation;
import org.springframework.data.jpa.repository.JpaRepository;
public interface OperationRepository extends JpaRepository {
}
package com.yourcompany.yourapp.repository;
import com.yourcompany.yourapp.model.Category;
import org.springframework.data.jpa.repository.JpaRepository;
public interface CategoryRepository extends JpaRepository {
}
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(() -> 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);
}
}
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);
}
}
Endpoint: POST /api/operations
Content-Type: application/json
{
"operationPublicId": "abc-123",
"operationName": "Initial Deposit",
"operationAmount": 1000.00,
"operationType": "DEPOSIT",
"categoryId": 1
}
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 не сформировалась.
GPT-4o снова использует «комбо» @Data + @Builder
, разрушая идею билдера. Плюс — @NoArgsConstructor
и @AllArgsConstructor
впридачу. Это не оптимизация, а избыточное нагромождение аннотаций.
Аналогично Claude, GPT-4o не добавил @JsonProperty
для DTO-моделей, делая API более хрупким (зависимость от имён полей на стороне Java).
GPT-4o построил логику таким образом, что клиент присылает внешний ID операции, которая создаётся на бэкенде. Это в корне нарушает принцип разделения ответственности:
Алгоритм генерации публичных ID — зона ответственности сервера, а не клиента.
Передача таких ID клиентом даёт лишнюю пространство для потенциальных багов и злоупотреблений.
Операция связана с категорией, но требовать от клиента ID категории в запросе — сомнительная практика:
Клиенту в большинстве случаев не нужны внутренние ID.
Логичнее передавать имя категории, а на сервере маппить его на ID. Это снижает связность и упрощает API.
GPT-4o возвращает наружу JPA-сущность Operation
. Это сразу несколько ошибок:
Антипаттерн — приучает неопытных разработчиков отдавать сущности прямо в API.
Operation
содержит ManyToOne
-связь. Если она LAZY, доступ к полям вне транзакции приведёт к LazyInitializationException
.
Если связь в состоянии EAGER будет в будущем заменена на LAZY, в будущем может внезапно уронить прод.
Мы раскрываем клиенту все поля сущности, включая внутренние ID и связанные структуры. (Отдаём сущность вместо DTO)
Из-за включённого по умолчанию в Spring OSIV (Open Session in View) проблема с возвращением сущности в контроллере замаскирована: сериализация в JSON подтянет данные из БД на лету, т.к. Hibernate сессия ещё открыта, но при отключении OSIV это также приведёт к неожиданным падения в боевой среде.
Это особенно странно: в предыдущем шаге GPT-4o уже исправлял стратегию генерации ID, но в сервисе зачем-то добавил «временные» ID вручную. Hibernate и PostgreSQL прекрасно справились бы сами.
В результате CREATE-логика в текущем виде не работает.
GPT-4o обрабатывает случай «категория не найдена», но выбрасывает голый RuntimeException
. В будущем, при добавлении GlobalExceptionHandler
, это исключение может потеряться, и клиент получит 500-ю ошибку вместо осмысленного 400/404.
На этом этапе я понял: если продолжу разбирать каждую проблему так детально, то исследование ChatGPT займёт вечность.
Поэтому стратегия меняется:
Кратко описываю проблему.
Прошу GPT-4o исправить код.
Оцениваю, насколько хорошо он справился.
Промпт:
Change response model in OperationController.createOperation from an entity (Operation) to a DTO
Правки GPT-4oGreat 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.
We'll introduce a new response DTO called OperationResponse
and use it in the controller response.
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 the return type and add mapping logic.
import com.yourcompany.yourapp.dto.OperationResponse;
public OperationResponse createOperation(CreateOperationRequest request) {
Category category = categoryRepository.findById(request.getCategoryId())
.orElseThrow(() -> 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();
}
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 предлагает постоянно копировать код сборки объекта операции
Пока 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
Запрос к 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.
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.
To tailor this update logic precisely, I need clarification on the following:
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.
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
.
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-4oExcellent, 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
Method: PATCH
Path: /api/operations/{operationPublicId}
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
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;
}
import java.util.Optional;
Optional findByOperationPublicId(String operationPublicId);
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(() -> 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(() -> new RuntimeException("Category not found: " + request.getCategoryId()));
operation.setCategory(category);
} else if (request.getCategoryId() == null && 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;
}
}
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);
}
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-4oYou'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.
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
.
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.
Later, you can handle all custom exceptions cleanly with:
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(BadRequestException.class)
public ResponseEntity> 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
Прошу создать две ручки:
Получение всех операций с пагинацией
Получение операции по 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.
Implement two endpoints:
Find all operations (paginated)
Find operation by operationPublicId
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
.
Layer | Task |
---|---|
Repository | Add |
Service | Add methods to wrap JPA logic and convert entities to DTOs |
Controller | Add |
DTOs | Reuse |
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-4oPerfect — thanks for confirming. We’ll now implement:
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.
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);
}
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(() -> 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();
}
}
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> 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));
}
}
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);
}
}
GET /api/operations?page=0&size=5
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
в неё.
На этом этапе стало окончательно понятно: GPT-4o не склонен предлагать архитектурно правильные решения, если явно не попросить. Claude в аналогичном задании сам предложил DTO для пагинированного ответа. GPT-4o же оставил это на меня — либо править самому, либо тратить дополнительный промпт на доработку.
Функционал рабочий, но архитектурно решение слабое: жёстко зашитая сортировка, отсутствие DTO для постраничного ответа. Всё это требует изменений, в рамках тестирования этого достаточно, но в реальном проекте логику придётся дорабатывать вручную или отдельными запросами к модели.
Двигаемся дальше — к последнему эндпоинту: удаление операции.
PR на read-логику
https://github.com/nzinovev/open-ai-chatgpt/pull/4
Рискнул и не добавлял уточняющих вопросов — проверим, как 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-4oGreat — here’s a clean implementation of the DELETE logic for the Operation
entity using operationPublicId
as the lookup key.
Delete by operationPublicId
Skip field validation for now
Return HTTP 204 No Content
on success
Return HTTP 404 Not Found
if not found
No changes needed (already has findByOperationPublicId
)
Already exists — reused to return 404
public void deleteByPublicId(String publicId) {
Operation operation = operationRepository.findByOperationPublicId(publicId)
.orElseThrow(() -> new NotFoundException("Operation not found with publicId: " + publicId));
operationRepository.delete(operation);
}
@DeleteMapping("/{operationPublicId}")
public ResponseEntity deleteByPublicId(@PathVariable String operationPublicId) {
operationService.deleteByPublicId(operationPublicId);
return ResponseEntity.noContent().build();
}
DELETE /api/operations/abc-123
204 No Content
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.
@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(() -> 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 && id.equals(operation.id);
}
@Override
public int hashCode() {
return id != null ? id.hashCode() : super.hashCode();
}
}
Add validation for "create operation" logic.
Think step by step. If you have any questions, ask them first.
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
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;
}
Update the controller method to use @Valid
:
@PostMapping
public ResponseEntity createOperation(@RequestBody @Valid CreateOperationRequest request) {
var created = operationService.createOperation(request);
return ResponseEntity.ok(created);
}
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> handleValidationErrors(MethodArgumentNotValidException ex) {
Map errors = new HashMap<>();
ex.getBindingResult().getFieldErrors().forEach(fieldError -> {
errors.put(fieldError.getField(), fieldError.getDefaultMessage());
});
Map response = new HashMap<>();
response.put("status", 400);
response.put("error", "Bad Request");
response.put("message", "Validation failed");
response.put("errors", errors);
return ResponseEntity.badRequest().body(response);
}
}
{
"operationAmount": -5,
"operationType": null,
"categoryId": null
}
{
"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-4oThanks 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.
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.
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.
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.
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
В качестве финального задания я попросил 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(() -> 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(() -> 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(() -> 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(() -> new NotFoundException("Operation not found with publicId: " + publicId));
return toDto(operation);
}
public void deleteByPublicId(String publicId) {
Operation operation = operationRepository.findOperationByPublicId(publicId)
.orElseThrow(() -> 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)
Perfect — let’s create unit tests for OperationService
, covering both positive and negative paths.
We’ll use:
JUnit 5
Mockito (@Mock
, @InjectMocks
)
@ExtendWith(MockitoExtension.class)
Method | Scenario | Expectation |
---|---|---|
| Valid input | Saves and returns DTO |
Category not found | Throws | |
| Valid update | Applies changes and returns DTO |
Operation not found | Throws | |
Category not found | Throws | |
| Throws | |
| Found | Returns DTO |
Not found | Throws | |
| Returns paginated result | Returns correct page |
| Found | Deletes operation |
Not found | Throws |
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(() -> 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(() -> 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(() -> 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(() -> 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(() -> operationService.findByPublicId("missing"))
.isInstanceOf(NotFoundException.class);
}
// --- FIND ALL ---
@Test
void findAllOperations_success() {
var page = new PageImpl<>(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(() -> operationService.deleteByPublicId("missing"))
.isInstanceOf(NotFoundException.class);
}
}
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. Будет интересно проследить эволюцию модели.
По традиции, если было интересно, заходи в мой тг-канал.