DEV Community: Yongsik Yun

Four Multipliers for Using AI Well: My Working Model

Yongsik Yun — Sat, 30 Aug 2025 14:01:01 +0000

Summary

I don’t think “good prompts” are enough. In my experience, outcomes improve when I understand what my keywords actually mean and can roughly predict what the model will return.

This post shares my current model in a report style, but the views are personal and context-dependent.

Why this matters (my take)

I keep returning to four areas that change results the most:

Tool Understanding
Knowing model limits, context management, and I/O formats reduces avoidable iteration.
Requirements Understanding
Clear problem statements, success criteria, and non-functional needs (security, performance, operations) keep direction stable.
Design & Architecture Understanding
Boundary setting, dependency control, and explaining trade-offs lower change cost.
Organization & Process Understanding
Roles, collaboration flow, deployment and operations realities increase execution efficiency.

The 4× model

I think results behave like a product of four “pillars”:

Outcome ≈
(Depth of prior learning)
× (Understanding of the problem context)
× (Design & architecture skill)
× (Environment awareness: org, infra, process)

If any one term is near zero, the whole outcome drops sharply. That’s what I’ve observed, not a universal law.

Human ↔ AI split (what I’m experimenting with)

I’m actively designing how to split work between AI agents and myself across the four pillars. It’s a work in progress.

Pillar	What it means	Delegate to AI agents	Keep human-led (for now)
Tool	Prompt scaffolds, format transforms, test data generation	Patterned refactors, doc drafting, spec-to-code skeletons	Choosing models, context strategy, safety/limits
Requirements	Clarify terms, map examples, validate acceptance criteria	Requirement clustering, duplicate detection, glossary drafts	Final problem framing, success metrics, risk acceptance
Design & Arch	Option listing, RFC skeletons, sequence/state diagrams	Alternative enumeration, boilerplate architectures	Final boundary decisions, trade-off ownership
Org & Process	Checklists, runbooks, review templates	Routine updates, status summaries, meeting minutes	Incentives, role design, escalation paths

Practical checklist

Do I know the model’s constraints and how I’ll manage context?
Are success criteria and non-functionals explicit?
Can I explain my trade-offs like I would in a design review?
Does the plan reflect team roles and deployment reality?
For each pillar, what is agent-do vs human-decide?

Closing

This is the frame I’m using right now:
Prior learning × Context understanding × Design skill × Environment awareness.
I expect efficiency to drop when any one term weakens. My current focus is to make the agent/human split explicit in each pillar.

If you use a different split or model, I’d like to learn from it.

Guide to Adding Comments to Tables and Columns When Automatically Generating Entities Using ORM in…

Yongsik Yun — Sun, 18 Feb 2024 17:21:21 +0000

Overview

This document provides a guide on how to add comments to tables and columns when automatically generating entities using ORM in Java backend development.

Problem

While developers can understand the meaning of columns through annotations, data engineers must manually check the source code or ask the developer, which can be inconvenient.
When using annotations and column comments together, there can be issues with framework dependency, decreased efficiency, and human error.

Solution

Use the comment attribute introduced in JPA 3.2 to add comments to tables and columns.
Utilize both Hibernate’s @Comment annotation and JPA 3.2's comment attribute to enable automatic refactoring for future version upgrades.

Key Points

JPA 3.2’s comment attribute
- The comment attribute was added to table and column annotations starting from JPA 3.2.
- This attribute allows you to directly specify descriptions for tables and columns.
Hibernate @Comment annotation
- The @Comment annotation provided by Hibernate can be used to add descriptions to columns.
- This is useful in environments that do not support JPA 3.2.
Automatic refactoring for future version upgrades
- Tools like OpenRewrite can be used to automatically convert Hibernate @Comment annotations to JPA 3.2's comment attribute.
- This allows for easy code upgrades when Spring Data JPA and Hibernate’s JPA 3.2 versions are supported in the future.

Code Examples

JPA 3.1 + Hibernate

@Column  
@Comment(value = "Is locked")a  
private boolean accountNonLocked = true;

JPA 3.2

@Column(comment = "Is locked")  
private boolean accountNonLocked = true;

References

How to automatically reload spring boot in vscode

Yongsik Yun — Wed, 24 Jan 2024 10:29:25 +0000

When developing a Java project in VSCode, it can be quite inconvenient when Spring reload does not occur after an automatic build. To address this issue, Gradle continuous is commonly used.

Terminal 1

gradle build -t

Terminal 2

gradle bootRun

While Terminal 1 only needs to be started once, doing it every time is inconvenient. One solution to this problem is to use the compounds feature in VSCode's launch. compounds allow multiple launch configurations to be executed as a single unit.

Solution

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Spring Boot-BaseApplication",
      "type": "java",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "mainClass": "kr.co.findthebest.Application",
      "projectName": "workspace",
      "args": "",
      "envFile": "${workspaceFolder}/.env",
      "encoding": "UTF-8"
    },
    {
      "name": "Run gradle continuous",
      "type": "node-terminal",
      "command": "gradle build --warning-mode=all -t --parallel --build-cache --configuration-cache",
      "request": "launch",
      "cwd": "${workspaceFolder}"
    }
  ],
  "compounds": [
    {
      "name": "Auto build",
      "configurations": [
        "Run gradle start",
        "Spring Boot-BaseApplication"
      ],
      "stopAll": true
    }
  ]
}

By modifying the launch.json as above, you can create a compounds named "Auto build."

Running this compounds will execute "Run gradle continuous" and "Spring Boot-BaseApplication" sequentially.

This approach eliminates the need to start each terminal individually, streamlining the process.

Another method involves adding a task to use the preLaunchTask feature in launch. However, due to less smooth background pattern matching, this method may reduce the risk of failure in certain situations.

Conclusion

When developing a Java project in VSCode and aiming for automatic build and Spring reload, using compounds is an effective solution.

By adopting this method, you can simplify the workflow, reducing cumbersome tasks.

DEV Community: Yongsik Yun

Four Multipliers for Using AI Well: My Working Model

Summary

Why this matters (my take)

The 4× model

Human ↔ AI split (what I’m experimenting with)

Practical checklist

Closing

Guide to Adding Comments to Tables and Columns When Automatically Generating Entities Using ORM in…

Overview

Problem

Solution

Key Points

Code Examples

JPA 3.1 + Hibernate

JPA 3.2

References

How to automatically reload spring boot in vscode

Solution

Conclusion

Related links