회사에서 Visual Studio내에서 chat-gpt 5.4를 1년 넘게 써오고 있는데, 가면 갈수록 더 좋아지고 있더군요. 코딩 자체는 이젠 10%미만이고 90%이상이 ai와 대화해서 코드를 바꿉니다. AI가 작성한 코드 리뷰에 90% 시산을 씀. 이렇게 바꿔라 저렇게 바꾸면 현재 코드와 비교해서 좋은지 조사해봐. 무엇 무엇 해야 하는데 어떤 알고리즘이 있는지 나열 바람 등등

5시간 /당일 쿠폰을 다 써버리니, 내가 직접 코딩 하려하니 답답, 다른일 하고 다음날 ai와 일 시작….
이젠 직접코딩 시대는 저물고 있는 느낌

저희 회사도 같아요. 코드쓰는거 보다 코드베이스 및 시스템을 빨리 이해, 응용이 더 중요해진거 같네요

요새는 다 시스템 디자인 위주죠. 손코딩 하던 시대는 이미 물건거 갔음.
옛날에 어셈블러 물건너 가듯이..
요새는 회로 반도체 설계도 모두 AI로.. 회로도 만들어줘, 부품 골라줘, 시뮬레이션 해줘, 테스트케이스 만들어줘, 모두 AI

저희도 거의 100% ai로 코드 작업합니다.

복잡도에 따라 다를텐데… 그래도 우리는 아직까지 손으로 많이 함. 예를들어 React에있는 그많은 component랑 state management를 다 AI로 한다는거는 무리지 않나요? 연계되는것도 많고 config이랑 이리저리 폴더랑 저쪽 micro service에있는 코드와 얽히고 섥히는 관계도 복잡한데 말이죠. 물론 페이지 한장정도는 하다보면 suggestion들이 방방떠서 vibe coding로 90%이상 코딩한다라는 의미라면 동의.

제 경우엔, vc 안에 모든 코드 들어 있기에 ai가 전체구조를 잘 파악하고 있습니다. 변수하나가 매우 복잡하게 여러파일에 얽혀져 있지만, 명령하면 관련된 모든 파일을 잘 수정 하더군요. 제 경우는 Cuda gpu 코딩이 대부분인데, ai가 매우 만족 스럽게 일해주고 있습니다. 물론 디테일하게 type를 해야하고 ai가 코드한 결과물을 계속 리뷰하면서 원하는 결과에 도달해야 합니다.

읽어보니 제가 하는방식보다는 더 발전된 방법인거 같네요. 전 명령까지 때리진 않거든요. 암튼 지금까지는 운좋게도 이분야에서 승승장구했지만 이제는 서서히 마음의 준비를 해야할것같습니다.

VS code 에서 AI agent를 사용하신다는 말은 혹시 GitHub Copilot을 사용하신다는 말씀인가요? 아니면 다른 방법으로 agentic AI 를 프로그래밍에 사용하시는지 궁금합니다.

저는 VS Code에 GitHub Copilot하고 Matlab 연결

VS code 내에 Codex: full access, 5.4 High로 세팅 되어 있습니다. 대충 알고리즘 설명 입력하면, 이상한 비 효울적 코드가 생성 됩니다. 잘 설명한 문장을 넣어줘야 합니다. Ai는 너무 edge case를 고려하여 일일이 코딩하는 경우가 있는데, 이러 이러한 edge case는 없다등 type 해 넣어야 할 것 같습니다. 깔끔하게 코드 해줘서 너무 편해요.

Code pull request (동료/coderabbit)전에 실행하는 명령어.
두번정도 돌려야 완성됨

# Fix Linter Diagnostics

Review and address relevant clang-tidy diagnostics for recently edited files, but keep the
lint scope, binary selection, and verification loop aligned with the repository scripts.

## Workflow

1. Run Scripts/clangTidy.sh from the repository root with its default arguments.
– Let the script determine the relevant recently edited files and lint scope.
– Use shell commands only through the terminal tool.
– Treat this script as the source of truth for selected files, compile database, header filter, .clang-tidy config,
CUDA arguments, and resolved tool binaries.
2. Inspect the clang-tidy-fixes.yaml file written under the build directory selected by Scripts/clangTidy.sh.
– Treat this file as the canonical summary of the identified diagnostics.
– The wrapper currently chooses the newest available compile_commands.json under build/; do not assume the path
is build/Debug unless the script output confirms it.
– If it is missing, empty, or suspiciously incomplete, rerun Scripts/clangTidy.sh once and inspect the outputs
before concluding that there are no actionable diagnostics.
3. Decide whether to apply automated replacements, manual fixes, or suppressions.
– Scripts/fixTidy.sh may be used when its preconditions are acceptable. It runs the repository lint wrapper,
applies exported replacements with clang-apply-replacements, and formats the edited sources.
– Scripts/fixTidy.sh requires a clean git worktree and may apply many replacements. If the worktree is dirty or the
desired change must be more selective, handle diagnostics manually.
– After any auto-fix pass, review the resulting diff before making further edits or reporting success.
4. Review each reported diagnostic before changing code.
– Ignore unrelated pre-existing diagnostics outside the script-selected scope.
– If the diagnostic is in scope and valid, fix it with the smallest safe local change.
– If the diagnostic is in scope but a fix would require a non-trivial public API, behavior, or performance change,
suppress it with a tightly scoped // NOLINTBEGIN(diagnostic-name) and // NOLINTEND(diagnostic-name) pair around
the relevant code.
5. Apply severity guidance consistently:
– Error-level diagnostics must be fixed or suppressed.
– Warning-level diagnostics should be fixed only when the public API change and performance impact are minimal.
– Otherwise, suppress Warning-level diagnostics narrowly.
6. Write suppressions carefully:
– Use the exact diagnostic name reported by clang-tidy.
– Keep the suppression scope as small as possible.
– Add a detailed code comment explaining why the warning does not apply to this code and what context makes the
suppression acceptable here.
– Preserve existing suppression comments unless the new change makes them obsolete.
7. Treat the task as incomplete until every in-scope reported diagnostic has been fixed or explicitly suppressed.
– Make at least one textual edit when acting on the diagnostics.
8. Run the full verification loop after the changes:
– Scripts/formatCpp.sh
– cmake --build --preset conan-debug
– Scripts/clangTidy.sh
9. Before finishing, perform a lightweight verification pass:
– confirm edited files are formatted
– confirm the build succeeds
– confirm each diagnostic acted on is now resolved or covered by the intended narrow suppression
10. If verification fails, inspect the failure and continue until the task is actually resolved.

– Fix regressions caused by the new changes.
– If a step fails for an unrelated pre-existing issue, report the exact blocker and separate it clearly from the
diagnostics handled in this pass.

11. End with a concise disposition summary that lists:

– files changed
– diagnostics fixed
– diagnostics suppressed
– any remaining blockers or assumptions

## Direct Tool Use

Prefer repository scripts for normal operation. Direct clang-tidy, run-clang-tidy, or clang-apply-replacements
commands are acceptable only for narrow inspection, targeted verification, or carefully selected replacement
application.

When invoking tools directly:

– Use the exact binary paths and versions that the lint scripts resolved. If Scripts/clangTidy.sh reports
clang-tidy-21, do not substitute an unversioned clang-tidy or another versioned binary unless it is the same
resolved executable.
– Match the wrapper’s flags and inputs: .clang-tidy, the selected compile_commands.json directory, exported fixes
location, header filter, selected file list, CLANG_TIDY_BINARY, and CUDA flags when CUDA files are involved.
– Prefer copying the exact run-clang-tidy command printed by Scripts/clangTidy.sh when reproducing a lint run, along
with any environment variables the wrapper exported.
– For replacement application, use the same clang-apply-replacements version policy as Scripts/fixTidy.sh
(clang-apply-replacements version 17 or newer, with the newest matching binary discovered on PATH).
– Do not let direct commands broaden lint scope, use stale build directories, or bypass diagnostics that
Scripts/clangTidy.sh would report.

## Boundaries

– Do not change the lint scope selection logic. Scripts/clangTidy.sh remains the source of truth for which recently
edited files are in scope.
– Prefer the smallest safe rewrite over opportunistic cleanup.
– Do not use Scripts/runFix.sh.
– Do not use wrapper scripts that invoke Scripts/runFix.sh, such as Scripts/fixAll.sh, unless the user explicitly
changes this instruction.
– You may use Scripts/fixTidy.sh, but only after considering its clean-worktree requirement and broad auto-fix
behavior.
– Do not stop after reviewing diagnostics; continue until each in-scope reported item has been resolved or explicitly
suppressed.
– Do not claim formatting, build, or lint success unless those steps were actually rerun.

## Output Expectations

– Use Markdown only where it adds value.
– Use backticks for file paths, commands, and diagnostic names.
– Keep summaries concise.
– Include a final disposition summary for the diagnostics handled in this pass.
– When assumptions are required, document them at the end.

codex쓰시는군요. 한번도 안써봤는데 GitHub Copilot과 비교했을때 어떤지 궁금하네요. 회사에서는 GitHub Copilot 지원해줘서 데이터분석위해 쓰기시작한지 3주 됐습니다. 그래서 VS Code도 처음으로 쓰게 된지 3주 됐는데 이 조합으로 오토컴플리션 기능과 에이전트 기능 쓰며 매일 놀라고 있습니다. Codex 는 더 좋을지 궁금하네요

저는 아예 첨부터 Cursor씀