AI Makes Mistakes Too. The Difference Now Is That Those Mistakes Can Be Executed.

The longer you use AI, the more naturally you come to realize one simple fact: AI makes mistakes too. It can misunderstand a question, confidently explain something that does not exist, write faulty code, or arrive at the wrong conclusion. When AI was mainly a conversational tool, these mistakes were usually manageable. If an answer seemed wrong, you could simply ask again. If the code was flawed, a human could review and correct it. But as AI evolves from a tool that generates answers into an agent that directly operates computers, the meaning of a mistake begins to change. AI can now read, create, modify, and delete files. It can run programs, execute shell commands, and sometimes carry out long sequences of work with little or no human intervention.

The most dangerous AI mistake is not necessarily giving the wrong answer. It may be successfully executing the wrong judgment.

Imagine an AI agent believes it is cleaning up a temporary directory inside a project. If the files really are temporary, there is no problem. But the outcome can be very different if the agent misunderstands its working directory or miscalculates a relative path. What makes this especially difficult is that everything that follows may still be perfectly logical: “This is a temporary file I created. The task is finished, so I no longer need it. Therefore, I should delete it.” There is nothing obviously wrong with the reasoning except for one thing: the first assumption may be false. The computer does not verify that assumption. If the command itself is valid, the computer executes it exactly as instructed.

Recently, I had a small experience on my development machine that made me think seriously about this problem.

I found an unfamiliar file named tmpblock0.js in my Documents folder. It had been created at 11:32 a.m. the previous day. The file contained what appeared to be an incomplete fragment of HTML from a project I had been working on. It was not a normal project file, nor was it part of the Git repository. I had no idea why it was sitting in my Documents folder, so I separately asked the two AI coding agents I had been using during development.

Interestingly, both AIs said they had created it.

One AI explained that while checking the syntax of inline JavaScript on a /space/ page, it had extracted a script block into a temporary file. According to its explanation, it miscalculated a relative path, causing the file to be created in the Documents folder instead of the intended temporary workspace. It even provided a detailed account of how the string <script> inside an HTML comment may have been mistaken for an actual script tag, producing an incomplete 164-byte fragment. It then described the file as a leftover from its own mistake and deleted it.

When I asked the other AI about the same file, it also said that the file appeared to have been created during one of its previous analysis tasks. Its explanation was remarkably similar. It suggested that the file had been generated while extracting a script block from the /space/ page for JavaScript syntax checking, and that an HTML comment containing <script> had likely been misidentified as a real tag.

The two explanations were surprisingly similar. Perhaps that should not be surprising at all. Given the same file, the same project structure, and the same traces left behind, two different AIs could reasonably infer the same likely cause.

But there was one critical problem.

Neither AI had direct evidence proving that it was actually the one that created the file. There was no confirmed execution command or definitive file-creation record from the time it appeared. In the end, the exact origin of tmpblock0.js remained unknown. It seems plausible that it was a temporary artifact created during an AI-assisted coding task, but it is still impossible to determine with certainty which AI created it, what command created it, or exactly how it ended up there.

What interested me most about this experience was not the identity of the file, but the reaction of the AIs.

Both agents examined the remaining evidence, reconstructed a highly plausible explanation of what had happened, and then identified themselves as the actor responsible. Even if their reasoning about the cause was correct, that did not mean their conclusion about who performed the action was also correct. When an AI gives an extremely detailed explanation of a past event, it does not necessarily mean the AI remembers that event. It may simply be reconstructing the most probable story from the files, code, and current working environment available to it.

Then something more important happened.

One of the AIs concluded that the file was a temporary artifact it had created and deleted it. The file did not even appear in the Windows Recycle Bin afterward. The file itself was only a 164-byte incomplete fragment, so there was no meaningful damage. But one fact was now clear: although the actual creator of the file had never been established, the AI concluded that the file belonged to its own previous work and made a real change to the filesystem based on that conclusion.

The inference was uncertain. The execution was not.

When people discuss the risks of AI, they often imagine malicious AI or an AI system compromised by an attacker. But in real-world use, a much more common problem may simply be an ordinary mistake made by an otherwise normally functioning AI. AI does not need malicious intent to miscalculate a path, misunderstand the purpose of a file, or mistakenly believe that something was created during one of its previous tasks. And if it has sufficient permissions, it can turn that mistaken judgment directly into action.

Development machines are particularly vulnerable to this problem. Developers often relax security barriers that ordinary users rarely touch. They use administrator privileges, run PowerShell and shell scripts, store SSH keys and Git credentials, and keep API keys in environment variables or configuration files. Credentials for development servers and databases may also be present on the same machine. Each of these practices is ordinary and often necessary for development, but together they give an AI agent with broad filesystem and terminal access considerable power.

Requiring human approval for every AI action is not necessarily a good solution either. If every file modification and every command requires confirmation, much of the benefit of automation disappears. Repeated approval requests can also create approval fatigue, eventually causing users to click “Allow” without carefully reviewing what they are approving.

The real question is not whether AI should have all permissions or none. The more useful question is where its freedom to act should end.

An AI agent might be given considerable freedom inside a project directory while being restricted from Documents, the user’s home directory, credential stores, and other sensitive locations. Destructive operations such as deletion, bulk moves, or overwriting important files could be treated differently from ordinary code edits. The key is not to rely solely on telling the AI to “be careful.” Safety should not depend entirely on whether the AI remembers an instruction at the exact moment it matters.

This experience also exposed another problem: logging.

After discovering the file, I tried to determine who had created it, but there was no decisive creation record. Both AIs could analyze the filename, its contents, and the project structure and produce convincing explanations, but neither could prove who had actually created it. The problem is that logs are often created only when something is considered worth recording at the time.

When a tiny temporary file is created, it may seem like a meaningless intermediate artifact. But when that same file is discovered the next day in an unexpected location, suddenly it matters who created it, when it was created, and which command produced it. By the time those questions become important, the relevant record may no longer exist.

There is a reason an aircraft’s black box is not activated only when the pilot thinks an accident is about to happen. We often discover which information mattered only after something has gone wrong. If an AI records only the actions it considers important, then the mistake it considered unimportant may be the first thing missing from the record.

There is no need to preserve every action forever, but certain minimum records may need to exist independently of the AI’s own judgment: file creation and deletion, large-scale modifications, external command execution, permission changes, and other actions that may become important during a later investigation.

The logging problem becomes even more complicated when multiple AI agents work in the same environment.

One AI may create a file. Another may later discover it and infer that it was part of its own previous work. It may modify or delete the file because it appears unnecessary. A third AI may then examine what remains and reconstruct an entirely different explanation of what happened. Each judgment may seem reasonable based on the information available at that moment, while no single agent actually knows the complete history.

Without an independent record, the boundary between inference and actual history begins to blur.

The fact that two AI agents both looked at the same file and concluded that they had created it is only a tiny example. But as multiple agents increasingly work simultaneously inside development environments, the question of “who did what” may become far more important than it is today.

AI is clearly moving toward greater autonomy: using more tools, performing longer tasks independently, and requiring less human intervention. This can bring enormous gains in productivity. I have experienced this myself. Tasks that once required a great deal of time can now be completed at astonishing speed.

And that is precisely why it becomes easy to forget one simple fact.

AI makes mistakes too.

When people first allow an AI to operate their computer, they tend to inspect everything. They review every diff and check the result of every command. But after the AI performs correctly ten times, then a hundred times, trust naturally grows. The user checks less often and eventually begins allowing the agent to handle more things on its own.

Paradoxically, the more capable AI becomes, the faster this trust develops.

But greater trust does not eliminate the possibility of error. The frequency of mistakes may decrease, yet if the AI’s permissions and operational scope continue to expand, the consequences of a single mistake may become much larger.

The exact identity of the 164-byte temporary file found in my Documents folder remains unknown. I still cannot say who created it or which command produced it. But one thing did happen: two AI agents both concluded that the file was part of their own previous work, and one of them decided that it was its mistake and deleted it.

The important question is not whether a particular AI accidentally created one strange file. The larger issue is that AI can confuse inference with fact, and when given sufficient permissions, it can turn an uncertain inference into a real-world action.

We are moving from an era focused mainly on asking how intelligent AI is into one where we must also ask a different question:

When AI is wrong, how far can it go?

As capability grows, we give AI more authority. As authority grows, the consequences of mistakes grow with it. Autonomy therefore needs boundaries. Actions need records. Changes need a path to recovery.

AI makes mistakes. Anyone who uses it long enough eventually learns that.

The real danger is that when AI becomes good enough, reliable enough, and useful enough, we may eventually forget that simple fact.

patreon.com

AI도 실수한다. 문제는 이제 그 실수가 실행된다는 것이다

AI를 오래 사용하다 보면 자연스럽게 알게 되는 사실이 있다. AI도 실수한다. 질문을 잘못 이해하고, 존재하지 않는 사실을 그럴듯하게 설명하며, 코드를 잘못 작성하거나 엉뚱한 결론을 내리기도 한다. 대화형 AI를 사용할 때만 해도 이런 실수는 대부분 큰 문제가 아니었다. 답이 이상하면 다시 물어보면 되고, 잘못된 코드는 사람이 검토한 뒤 수정하면 됐다. 그러나 AI가 단순히 답을 생성하는 도구에서 컴퓨터를 직접 조작하는 에이전트로 바뀌면서 같은 실수의 의미도 달라지고 있다. 이제 AI는 파일을 읽고 만들고 수정하며 삭제할 수 있고, 프로그램을 실행하고 셸 명령을 사용하며 때로는 상당히 긴 작업을 사람의 개입 없이 수행한다.

AI의 가장 위험한 실수는 반드시 엉터리 답을 내놓는 것이 아니다. 틀린 판단을 성공적으로 실행하는 것이 더 위험하다.

가령 AI가 프로젝트 내부의 임시 디렉터리를 정리한다고 생각했다고 해보자. 삭제 대상이 정말 임시 파일이라면 아무 문제가 없다. 하지만 작업 디렉터리를 잘못 인식하거나 상대경로를 잘못 계산했다면 결과는 달라질 수 있다. 더욱 까다로운 점은 이후의 논리가 모두 정상적일 수 있다는 것이다. ‘이것은 내가 만든 임시 파일이다. 작업이 끝났으니 필요 없다. 따라서 삭제한다.’ 논리 자체에는 이상이 없다. 첫 번째 전제 하나만 틀렸을 뿐이다. 그러나 컴퓨터는 그 전제가 맞는지 확인하지 않는다. 명령이 정확하면 정확하게 실행한다.

최근 개발 머신에서 이 문제를 생각하게 만드는 작은 일을 직접 경험했다.

Documents 폴더에서 tmpblock0.js라는 낯선 파일 하나를 발견했다. 생성 시각은 전날 오전 11시 32분이었다. 파일에는 내가 작업하던 프로젝트의 HTML 일부로 보이는 불완전한 코드 조각이 들어 있었다. 정상적인 프로젝트 파일도 아니었고 Git 저장소에 포함된 파일도 아니었다. 왜 이런 파일이 Documents 폴더에 존재하는지 알 수 없어 당시 개발에 사용했던 두 AI 코딩 에이전트에게 각각 물어봤다.

흥미롭게도 두 AI 모두 자신이 만든 파일이라고 답했다. 한 AI는 /space/ 화면의 인라인 자바스크립트 문법을 검사하는 과정에서 script 블록을 임시 파일로 추출했고, 상대경로를 잘못 계산해 원래 사용해야 할 임시 공간이 아니라 Documents 폴더에 파일이 생성됐다고 설명했다. HTML 주석 속 <script>라는 문자열을 실제 태그로 잘못 인식하면서 164바이트짜리 불완전한 조각이 만들어졌다는 구체적인 경위까지 제시했다. 그리고 자신의 실수로 남은 파일이라며 삭제했다. 다른 AI에게 같은 파일을 물어보자 역시 이전 분석 과정에서 자신이 만든 임시 파일로 보인다고 답했다. /space/의 인라인 자바스크립트를 검사하기 위해 script 블록을 추출하고 문법 검사를 하는 과정에서 HTML 주석 속 <script>를 실제 태그로 오인했을 가능성을 설명했다.

두 설명은 놀랄 만큼 비슷했다. 어쩌면 당연한 일이었다. 같은 파일, 같은 프로젝트 구조, 같은 흔적을 놓고 원인을 추론한다면 서로 다른 AI가 비슷한 결론에 도달하는 것도 충분히 가능하다. 그러나 결정적인 문제가 있었다. 두 AI 모두 자신이 실제 생성자라는 직접적인 증거를 가지고 있지 않았다. 정확한 실행 명령이나 당시 파일 생성 기록도 확인되지 않았다. 결국 tmpblock0.js가 어떤 프로그램에 의해, 어떤 명령으로, 정확히 어떤 과정에서 만들어졌는지는 아직 확인되지 않았다. AI 코딩 작업 중 만들어진 임시 파일일 가능성은 높아 보이지만 어느 AI가 만들었는지조차 확정할 수 없다.

이 경험에서 흥미로운 것은 파일의 정체보다 AI의 반응이었다. 두 AI는 남아 있는 증거를 바탕으로 상당히 그럴듯한 사건의 원인을 재구성했고, 동시에 그 사건의 주체를 자기 자신이라고 판단했다. 원인에 대한 추론이 맞더라도 행위자에 대한 판단까지 맞는다는 보장은 없다. AI가 어떤 사건을 매우 구체적으로 설명한다고 해서 반드시 그 사건을 기억하고 있다는 뜻도 아니다. 현재의 파일과 코드, 작업 환경을 분석해 가장 가능성이 높은 이야기를 재구성하고 있을 수도 있다.

더 중요한 일은 그다음에 벌어졌다. 한 AI는 자신이 만든 임시 파일이라고 판단한 뒤 파일을 삭제했다. Windows 휴지통에도 남지 않았다. 파일 자체는 164바이트에 불과한 불완전한 조각이었기 때문에 실제 피해라고 할 만한 것은 없었다. 하지만 여기에는 분명하게 확인된 사실이 하나 있다. 파일을 누가 만들었는지는 끝내 확인되지 않았지만, AI는 자신이 만든 파일이라는 결론을 내렸고 그 판단을 근거로 실제 파일시스템에 변경을 가했다. 추론은 불확실했지만 실행은 확실했다.

AI의 위험을 이야기하면 흔히 악의적인 AI나 해킹당한 AI부터 떠올린다. 그러나 실제 사용 환경에서 더 자주 마주칠 가능성이 높은 문제는 정상적으로 작동하는 AI의 평범한 실수일 수 있다. AI는 악의를 가지지 않아도 경로를 잘못 계산할 수 있고, 파일의 용도를 잘못 판단할 수 있으며, 자신의 이전 작업이라고 착각할 수도 있다. 그리고 충분한 권한을 가지고 있다면 그 잘못된 판단을 그대로 실행할 수 있다.

특히 개발 머신은 이런 문제에 취약하다. 개발자는 일반 사용자보다 컴퓨터의 여러 보안 장벽을 조금씩 풀어놓고 사용하는 경우가 많다. 관리자 권한을 사용하고 PowerShell이나 셸 스크립트를 실행하며 SSH 키와 Git 인증정보를 저장한다. 환경변수나 설정 파일에는 API 키가 들어가기도 하고 개발 서버와 데이터베이스에 접근할 수 있는 인증정보가 존재하기도 한다. 각각은 개발을 위해 필요한 평범한 작업이지만 파일시스템과 터미널을 자유롭게 사용할 수 있는 AI 에이전트에게는 상당한 권한이 된다.

그렇다고 AI가 행동할 때마다 사람의 허가를 받게 하는 것도 좋은 해결책은 아니다. 파일 하나를 수정할 때마다 확인하고 명령 하나를 실행할 때마다 승인을 요구한다면 자동화의 장점이 크게 줄어든다. 반복되는 승인 요청은 결국 사용자가 내용을 제대로 확인하지 않고 습관적으로 허용 버튼을 누르는 결과를 만들 수도 있다. 중요한 것은 AI에게 모든 권한을 주느냐 빼앗느냐가 아니라 어디까지 자유롭게 행동할 수 있는지 경계를 설계하는 것이다. 프로젝트 폴더 안에서는 상당한 자유를 주되 Documents나 사용자 홈 디렉터리, 인증정보가 저장된 영역은 기본적으로 작업 범위에서 제외하고, 삭제나 대량 이동처럼 복구하기 어려운 행동은 일반적인 파일 수정과 다른 권한으로 취급하는 방식을 생각해볼 수 있다. 핵심은 AI에게 ‘조심해서 작업하라’고 말하는 것만으로 안전을 확보하려 하지 않는 것이다.

이번 경험에서는 로그의 문제도 드러났다. 파일이 발견된 뒤 누가 만들었는지 확인하려 했지만 결정적인 생성 기록을 찾을 수 없었다. 두 AI는 파일명과 내용, 프로젝트 구조를 분석해 상당히 설득력 있는 설명을 만들었지만 실제 생성자를 입증하지는 못했다. 문제는 로그 역시 필요하다고 판단되는 순간에만 남기는 경우가 많다는 것이다. 임시 파일 하나를 만드는 순간에는 아무 의미 없는 중간 산출물이라고 생각할 수 있다. 그러나 다음 날 예상하지 못한 위치에서 발견되면 갑자기 누가 언제 어떤 명령으로 만들었는지가 중요한 정보가 된다. 그때 기록을 찾으려고 해도 이미 존재하지 않을 수 있다.

항공기의 블랙박스를 사고가 날 것 같을 때만 켜지 않는 이유도 비슷하다. 무엇이 중요한 기록인지는 사건이 발생한 뒤에야 알게 되는 경우가 많기 때문이다. AI가 필요하다고 판단한 행동만 기록하게 한다면 AI 자신이 중요하지 않다고 판단했던 실수가 가장 먼저 기록에서 빠질 수 있다. 모든 행동을 무한정 저장할 필요는 없겠지만 파일 생성과 삭제, 대량 변경, 외부 명령 실행, 권한 변경처럼 사후 조사에 중요한 최소한의 기록은 AI의 판단과 독립적으로 남기는 구조를 생각할 필요가 있다.

이 기록의 문제는 여러 AI 에이전트를 함께 사용하는 순간 한층 복잡해진다. 한 AI가 만든 파일을 다른 AI가 발견할 수 있고, 두 번째 AI가 그것을 자신의 이전 작업 결과라고 추론할 수도 있다. 불필요한 파일이라고 판단해 수정하거나 삭제한 뒤 세 번째 AI가 남아 있는 기록만 보고 또 다른 사건의 경위를 재구성할 수도 있다. 각각의 판단은 그 순간의 정보만 보면 합리적일 수 있지만 전체 과정을 정확하게 알고 있는 존재는 아무도 없게 된다. 독립적인 기록이 없다면 추론과 실제 이력의 경계는 점점 흐려진다. 이번에 두 AI가 같은 파일을 두고 모두 자신이 만들었다고 판단한 일은 아주 작은 사례지만, 앞으로 여러 에이전트가 동시에 개발 환경을 다루게 되면 ‘누가 무엇을 했는가’를 추적하는 문제는 지금보다 훨씬 중요해질 수 있다.

AI의 발전 방향은 더 많은 도구를 사용하고 더 긴 작업을 스스로 수행하며 인간의 개입을 줄이는 쪽으로 가고 있다. 이것은 엄청난 생산성을 가져올 수 있다. 나 역시 직접 사용하면서 과거라면 많은 시간이 필요했던 일을 놀라울 정도로 빠르게 처리할 수 있다는 것을 경험하고 있다. 그렇기 때문에 오히려 한 가지 사실을 잊기 쉬워진다. AI도 실수한다는 사실이다.

처음 AI에게 컴퓨터를 맡길 때는 모든 행동을 확인한다. 파일 하나를 수정해도 diff를 보고 명령 하나를 실행해도 결과를 살펴본다. 그런데 열 번, 백 번 제대로 처리하는 모습을 보면 자연스럽게 신뢰가 쌓인다. 점점 확인하는 횟수가 줄고 어느 순간부터는 알아서 처리하도록 맡기게 된다. 역설적으로 AI가 유능해질수록 이런 신뢰는 더 빨리 만들어진다. 그러나 신뢰가 높아진다고 실수 가능성이 사라지는 것은 아니다. 실수의 빈도는 줄어들 수 있지만 AI가 행사할 수 있는 권한과 작업 범위가 커진다면 한 번의 실수가 만드는 결과는 오히려 더 커질 수도 있다.

Documents 폴더에서 발견된 164바이트짜리 작은 임시 파일의 정확한 정체는 아직 확인되지 않았다. 누가 만들었는지, 어떤 명령으로 만들어졌는지도 확정할 수 없다. 그러나 그 파일을 두 AI가 모두 자신의 작업 결과라고 판단했고, 그중 하나가 자신의 실수라고 결론 내린 뒤 직접 삭제했다는 경험은 분명히 남았다. 중요한 것은 특정 AI가 파일 하나를 잘못 만들었느냐가 아니다. AI가 사실과 추론을 혼동할 수 있고, 충분한 권한이 주어지면 불확실한 추론조차 현실의 행동으로 이어질 수 있다는 점이다.

우리는 지금 AI가 얼마나 똑똑한지를 평가하는 시대에서 AI가 틀렸을 때 어디까지 할 수 있는지를 함께 생각해야 하는 시대로 넘어가고 있다. 능력이 커질수록 더 많은 권한을 맡기게 되고, 권한이 커질수록 실수의 결과도 커진다. 그래서 자율성에는 경계가 필요하고, 행동에는 기록이 필요하며, 변경에는 복구 수단이 필요하다.

AI도 실수한다. 직접 사용해보면 그것을 알게 된다. 문제는 너무 잘하기 시작한 AI를 오래 사용하다 보면 어느 순간 그 단순한 사실을 잊게 된다는 것이다.

FROM BUNTGAMES.COM