이런 류의 글들을 볼때마다… 다시 확인하게 되는 사실…
그 옛날 우리가 “개발자”라고 불렀던 사람들은 사실은 다른 두 부류의 사람들이었다. “과정”이 중요한 사람과 “결과”가 중요한 사람.
When I was writing Unreal Engine 1, my time was divided as follows:
- Around 30% went to seriously deep coding on hard problems: assembly language texture mappers, C++ BSP trees, data persistence, object oriented systems design, and networking.
- Around 70% was just typing and refactoring large bodies of code needed for a complete engine feature set. This was not hard, and while I was doing it my mind was mostly on the deeper coding topics, thinking and planning for what's next. It didn't feel much different from vibe coding today, except that it was just me typing code on an IBM Model M keyboard rather than prompting it and reviewing the results.
So, it has always seemed perfectly logical that we would rely on AI for that 70%, once the AI could do it with a similar quality standard as we could, which has never been perfection. It came as no surprise that, after a few years of AI model evolution, it was able to take the reigns on that 70% and free up programmers' time for more valuable tasks.
What's more of a surprise is the emergence of AI as a sort of insta-Carmack able to solve hard technical problems quite cleverly and often cleanly, and that it's able to reason about and work in complex 3D scenes both by operating the tools and by directly understanding the raw data files.
I abandoned assembly language in 1998 when out-of-order CPUs made much simpler C/C++ code faster, and never I missed it. If prompting through architectural documents, concept art, and design plans can transcend typing code and tweaking vertices, that will enable developers to spend their time on higher-level, higher value technical and creative tasks.
What matters is the end product, whether it's a game or an engine. Anything developers can do to try out more ideas and make better software and games faster is a win for everyone.
토큰을 부어서 취약점을 찾아내고… 토큰을 부어서 취약점을 제거하고… 토큰을 부어서 취약점을 만들고… 토큰을 부어서 토큰을 먹는 하마를 만들고… 대환장파티는 아직 시작도 안했…
news.hada.io/topic?id=35568
AI를 이용해서 개발했을땐 만들었다(make;create;write)대신 제작했다(produce)라는 표현을 쓰기로 했다.
오늘 애플2용 피아노 프로그램을 프로듀스했다. github.com/iolo/a2piano
#장피디의제작일기
오랜만에 블로그를 써 보았다.
“애플2 피아노와 낭만에 대하여...”
iolo.kr/posts/2026-10-03-a2p…
AI도 돈이 있어야 쓰지... 토큰이 감당 불감당이라... 로컬에서 돌릴만한 간단한 작업 돌려볼까 했더니... 시도때도없이 디스크 풀~
맨날 풀이야 / 맨날 풀이야 / 도커와 모델로 가득찰 줄이야 / 이제 난 거지야 / 정말 거지야 ...
여러분~ 6502 어셈블리 배우세요~ 30분이면 뱀게임을 만들 수 있어요! iolo.kr/easy6502/ 대AI의 시대에 그런걸 왜 배우냐구요? 레고를 왜 하세요? 직소퍼즐은 왜 하세요? AXY 세개의 8비트 레지스터로 푸는 스도쿠 같은 느낌?
Forth가 남다르시네요! 혹시 Forth에 관심있으세요? 자매품 Easy Forth도 있답니다. iolo.kr/easyforth/ 일부러 esoteric하게 만든게 아니라 실전용 언어랍니다! 대AI 시대에 이런걸 왜 배우냐구요? 이런 거라도 해야... 치매를 예방..(틀려)
jev 테스트삼아 오래만에 토큰 탕진 중. 기존의 LLM 들이 사람의 손을 대신하는 거였다면(코딩, 그림그리기, PPT만들기, 글쓰기), 이 녀석은 "회의"를 대신 하는 녀석. PRD작성(사람) -> PLAN.md(사람+LLM)->구현(LLM) 이었는데... PLAN작성을 jev+LLM으로 할수 있게 됨. 그래서 다음은 뭐냐?
소스는 github.com/onionmixer/sdl2qu…
이거 하자고 sdl 포팅하고, 매트록스 그래픽 드라이버 포팅하고… ㄷ ㄷ ㄷ
AI로 만든 흔한 한글 코드 변환기 but 애플2용 CALL3327 N바이트 한글 코드 지원
iolo.kr/hangul-code-converte…
CLI 또는 라이브러리로도 사용할 수 있습니다.
github.com/iolo/hangul-code-…
이번에 다시 해보니...
이햐... 잘 하네요.
뭔가 제대로 이해하고 있는거 같아서... 어설픈 영어로 작성한 문서를 윤문시켰는데... 이햐... 잘하네요.
github.com/iolo/hangul-code-…


