제주사는/마이너지향/입코딩전문/초보아빠/개발자겸/관리자겸/지금은백수 https://xitter.cf/t.co/sSCC2Gij8J

대한민국 성남시
Joined April 2009
이런 류의 글들을 볼때마다… 다시 확인하게 되는 사실… 그 옛날 우리가 “개발자”라고 불렀던 사람들은 사실은 다른 두 부류의 사람들이었다. “과정”이 중요한 사람과 “결과”가 중요한 사람.
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.
3
16
1
86
7,405
트윗이 흥하니까 더 적어보자. 나는 “과정”이 좋아서 이 일을 업으로 삼고 평생을 살았다. “결과”는 자연스레 따라온다고 진심으로 믿었다. 이제, 세상은 나를 방망이 깎는 노인 취급한다. 지금이라도 방망이 공장에 취직해야하나? 늘 그랬듯 우리는 답을 찾겠지만, 내가 그 우리에 속할지는 모르겠다.
14
568
좋은 결과를 얻을려면 좋은 과정이 필수적이라고 믿었기에 우리는 ”과정“에 집착했고, 엉덩이 근육, 손가락 관절, 경험에서 나오는 직관, …을 미덕으로 여겼었다. 그땐 그랬다.
1
1
9
807
REA가 그렇게 핫하다길래… 오 잘하네! 그런데 아까운 토큰으로 왜 리버스를 함? 그냥 만들면 안됨?
218
AI를 이용해서 개발했을땐 만들었다(make;create;write)대신 제작했다(produce)라는 표현을 쓰기로 했다. 오늘 애플2용 피아노 프로그램을 프로듀스했다. github.com/iolo/a2piano #장피디의제작일기
3
9
501
AI도 돈이 있어야 쓰지... 토큰이 감당 불감당이라... 로컬에서 돌릴만한 간단한 작업 돌려볼까 했더니... 시도때도없이 디스크 풀~ 맨날 풀이야 / 맨날 풀이야 / 도커와 모델로 가득찰 줄이야 / 이제 난 거지야 / 정말 거지야 ...
1
1
183
디스크 제조사 주식을 사야하나... 아... 어차피 디스크도 메모리구나... Orz 그냥 풀이나 먹고 살아야겠다.
87
AI들 너무 주절주절 말은 많은데 토큰만 빨리고 읽기도 귀찮아요! 그래요? 그럼 객관식으로 하세요! 객관식 문항은 어떻게 뽑아요? AI한테 (주관식으로) 물어보세요. (응?)
1
246
여러분~ 6502 어셈블리 배우세요~ 30분이면 뱀게임을 만들 수 있어요! iolo.kr/easy6502/ 대AI의 시대에 그런걸 왜 배우냐구요? 레고를 왜 하세요? 직소퍼즐은 왜 하세요? AXY 세개의 8비트 레지스터로 푸는 스도쿠 같은 느낌?
3
16
54
3,212
배워두시면 애플2, 패미콤(NES), 코모도어64 프로그램을 짤 수 있을지도 몰라요. 그건 왜 짜냐구요? 대AI 시대에는 이런 거라도 해야... 치매를 예방..(틀려)
1
247
Forth가 남다르시네요! 혹시 Forth에 관심있으세요? 자매품 Easy Forth도 있답니다. iolo.kr/easyforth/ 일부러 esoteric하게 만든게 아니라 실전용 언어랍니다! 대AI 시대에 이런걸 왜 배우냐구요? 이런 거라도 해야... 치매를 예방..(틀려)
3
277
jev 테스트삼아 오래만에 토큰 탕진 중. 기존의 LLM 들이 사람의 손을 대신하는 거였다면(코딩, 그림그리기, PPT만들기, 글쓰기), 이 녀석은 "회의"를 대신 하는 녀석. PRD작성(사람) -> PLAN.md(사람+LLM)->구현(LLM) 이었는데... PLAN작성을 jev+LLM으로 할수 있게 됨. 그래서 다음은 뭐냐?
3
10
986
물론 코드 안에서... 복잡하지만 근거없는 수많은 조건문(과 분기)를 jev api 호출 몇번으로 퉁칠 수 있지만(그게 jev가 원하는 거겠지만)... 그건 아직 너무 무섭... 현실적인 문제는 LLM들이 jev state와 question(!)를 잘 못 만든다는 거...
177
AI로 만든 흔한 한글 코드 변환기 but 애플2용 CALL3327 N바이트 한글 코드 지원 iolo.kr/hangul-code-converte… CLI 또는 라이브러리로도 사용할 수 있습니다. github.com/iolo/hangul-code-…
1
241
이런건 얼마든지 더 잘해도 좋은데... 굳이 6502 코딩까지 학습했을까요... 그런건 그냥 취미로 하게 냅두지...ㅠㅠ
53