-
1. Ask questions, understand, and design
When starting something with AI, we tend to just throw it a task and say, roughly, build this for me~ Once you have prototyped it that way, confirmed that it works, and decided to build it that way, I think it is very helpful to dig into how the actual implementation works at least once. As you keep asking questions, you start thinking, huh? Maybe this should not be done this way, or would this other approach not be better? That leads you to think of a better design.
Asking about tradeoffs is also very useful, but AI does not readily tell you about the downsides. If you ask about problems that could arise from an implementation and the tradeoffs against other alternatives, I think you can choose a better design among them.
In the end, I think the codebase itself is the strongest harness. That is why we need to design and implement things well from the beginning and continually question and explore the actual design and implementation methods.
-
2. Make good use of lint
These days, one of the things I hear most often is to use lint, and lint really is the best. If a certain rule is not being followed well, adding a custom lint rule that checks it deterministically works well. Of course, custom lint is like a test, so if it becomes too implementation-specific, there is a risk that it will become outdated. This also needs to be designed and reviewed carefully, but custom lint seems to be the cheapest and most effective way to increase the probability.
And with custom lint, instead of merely saying that something is wrong, you can write how to fix it in the message. Or you can record lint usage, see which lint rules are repeatedly violated, and use that information in reverse to strengthen the prompt for those areas.
- A self-improvement loop using lint
- The Tailwind style lint released by shadcn
- Developers in the AI era design verification
- FSD also seems to be one way to keep code well maintained. It is not simply that adopting FSD is good; by enforcing the direction of dependencies (custom lint can come in here too), modules can be managed independently to create code with high cohesion and low coupling. It does not necessarily have to be FSD, but I think it is one good approach. (Reviving a broken FSD architecture with AI)
-
In the end, LLMs are a probability game.
And in order to raise that probability (to bring it close to 100%, that is, to make it more deterministic), developers' work is to introduce various engineering methods and design verification.
- Design carefully from the start by understanding and asking questions
- Gradually supplement what is lacking through a deterministic verification loop (lint being the simplest yet most effective example)
I wonder if this could create a slightly better loop.
- This is a little off-topic, but BAML, which began as a language wrapping LLMs to produce structured output, and jev, an LLM that produces structured output, can both be seen as developers' attempts to bring AI into the realm of deterministic engineering. That is interesting as well.
- How the Next.js team closed 1,500 issues
- They reviewed the reasons to close an issue and the reasons not to close it in isolation, closed it only when both probabilities exceeded 80%, and returned the result as structured data.
- Notion's ratcheting system
- This article is about a tool released by the Notion team called eslint-seatbelt. They could not immediately treat lint violations as errors, but leaving them as warnings provided no enforcement, so the system records the current number of lint errors per file and prevents that number from increasing, reducing it gradually.
- Lint has a feature called suppressions, but because it has no enforcement on its own and requires a separate hook or CI configuration, I just use eslint-seatbelt.
Learnings
토스 기술 블로그, 토스 테크AI가 팀 규칙을 지키도록 하는 방법Coding Agent를 위한 StylepackX (formerly Twitter)shadcn (@shadcn) on Xhttps://x.com/shadcn/status/2099534231114314145?s=46linkedin.comAI 시대의 개발자는 검증을 설계한다 (2) 구조를 검증하는 Lint'아 저 컴포넌트에다 저런 조회 로직 추가하면 안되는데..REDBEANAI와 함께하는 무너진 FSD 살리기 (ESLint, skills, agents, hooks, CI , 자동화, claude code)안녕하세요, 프론트엔드 엔지니어 이홍빈입니다.이번 글에서는 AI를 활용하여 무너진 FSD 구조를 살린 경험에 대해 공유하려고 합니다.결론 요약AI harnessing + Guardrail 조합으로 핵심 도메인의 FSD 의존성 위반 -91%, 순환 참조 -90%를 달성했습니다.CI 자동화로 가드레일을 구성하여 지속 가능한 시스템을 구축했습니다.팀원과 함께 문제의식을 갖고, 시각화하고 공동 작업할 수 있는 기반을 마련하였습니다.지표시작 (Apr)결과 (May)감소율총 린트 에러20113-93.5%Boundary 위반14913-91.3%순환 참조313-90.3% [HTML 리포트를 활용한 과정 시각화]배경최근 프론트엔드에서 모듈을 도메인을 기반으로 설계하고, 의존성에 따라 계층화하는 FSD(Feature-sl..GeekNewsJev - 문장 대신 판단과 확률을 반환하는 AI 모델 | GeekNewsTypeSafe AI가 분류, 라우팅, 점수화와 조건 분기처럼 소프트웨어 안에서 반복되는 판단을 자동화하는 모델 Jev를 얼리 액세스로 공개함 문장을 자유롭게 생성하는 대신 미리 정한 형식의 값과 확률을 반환하며, 여러 판단 결과를 한 번의 요청에서 병렬로 출력함 각 답에 신뢰도와 불…YouTube[한영자막] 슬롭에는 슬롭으로 맞섭니다 — Vaibhav Gupta, BoundaryTech BridgeBoundaryBAMLThe programming language for agents.typesafe.aiIntroducing System One Models & Jev - TypeSafe AI BlogTypeSafe AI is an AI lab building machine-native intelligence infrastructure for automation, designed to make decisions within software. Try our first System One Model, Jev, in early access.nextjs.orgHow we closed 1,500 GitHub issues in one monthHow the Next.js team used an agent to research old reports and work through the issue backlog.NotionCustom ESLint ratcheting: how Notion modernizes code without slowing down developmentDiscover how Notion's innovative ratcheting system with custom ESLint rules gradually modernizes code, eliminates technical debt, and maintains high quality standards without sacrificing development speed or overwhelming engineersGitHubGitHub - justjake/eslint-seatbelt: Gradually tighten ESLint rules in your codebaseGradually tighten ESLint rules in your codebase. Contribute to justjake/eslint-seatbelt development by creating an account on GitHub.eslint.orgBulk Suppressions - ESLint - Pluggable JavaScript Linterhttps://eslint.org/docs/latest/use/suppressions
