@xiaogaifun: A Major Pitfall Our Team Encountered with Codex. I want to sincerely share a topic we discussed in our weekly meeting. This might be a common pitfall for many people using agent products like Codex. In short, if we just keep issuing commands and accepting suggestions from Codex without understanding or judgment, then these...

X AI KOLs Timeline News

Summary

The team shares the problem of over-reliance on AI leading to a lack of deep understanding among members when using Codex. It emphasizes that humans should act as leaders of AI, not mere messengers, and need to understand the principles and logic, turning AI output into their own experience.

A Major Pitfall Our Team Encountered with Codex. I want to sincerely share a topic we discussed in our weekly meeting. This might be a common pitfall for many people using agent products like Codex. In short, if we just keep issuing commands and accepting suggestions from Codex without understanding or judgment, these outputs don't truly become our own capabilities. Because if someone else clicks, the result would be pretty much the same. As AI agents become more capable, we don't have to handle every detail ourselves, but we still need to know why something is done this way and roughly how it was solved. If you don't know at first, that's fine. After AI finishes, we should go back and ask it, and then form our own experience and understanding. Why this long reflection? It started half a year ago. After the Spring Festival this year, my small team all got equipped with Codex. In our internal collaboration, a common phrase we used was: let AI do it first. To be honest, this workflow sounds simple, but actually doing it well is quite hard. After all, people have habitual thinking. The good news is that after months of deliberate practice, everyone has developed the habit of letting AI go first. But then, I noticed a new problem. Some colleagues started to lack curiosity. If Codex said it works, they accepted it; if Codex said it doesn't work, they accepted that too. They didn't study the underlying principles or logic. Let me give a real example. Earlier, I wrote a tutorial on how to integrate DeepSeek V4 with Codex. At that time, Codex didn't support third-party models, so we needed a bridging tool like CC Switch. Later, Codex announced support for third-party models. I thought, this should be simpler now. So I asked a colleague to research how to quickly integrate DeepSeek V4. He promptly took a screenshot, told Codex the requirement, and after analysis, Codex said it still couldn't be done because of protocol incompatibility. He sent me the screenshot and stopped there. I thought he couldn't figure it out, so I took over and continued researching. Later, I confirmed that Codex's newly opened third-party models require compatibility with OpenAI's Responses API. DeepSeek V4 doesn't support this protocol yet. So even though Codex opened up third-party models, DeepSeek still couldn't be directly integrated. That was the end of it. This Monday, a friend of mine who runs a traditional business told me that Codex would report an error whenever he sent an image. I asked and found out he had followed my earlier tutorial and connected to DeepSeek V4, which itself doesn't support multimodality. So I wanted to try integrating Kimi's new model into Codex. After all, I've been using Kimi's new model to make PPTs and analyze data recently, and the results are excellent. This model is natively multimodal. I expected it to be much faster this time, since we had already been through the first pitfall. As long as we first check whether Kimi supports the Responses API, the rest of the approach would be clear. The colleague took on the new task and started working. Same method as before: he continued to feed the documentation and requirements to Codex, letting Codex handle it. After analysis, Codex determined that Kimi's model couldn't be directly integrated due to protocol incompatibility. At this point, clever Codex gave him a suggestion: how about I write a bridging software? That should work. He said yes. So Codex solved it this way. Then he happily came to me and said the task was done. Hahaha. When I asked, I found out he had no clue about the logic or principle behind it. I said, if the protocol is incompatible, couldn't we just use software like CC Switch directly, instead of building our own? He knew nothing about all this. I felt something was wrong with this approach — he had outsourced all thinking and understanding to Codex. And that's why we had our exchange in today's weekly meeting. My experience is that we should be the leader of AI, not a messenger. A leader doesn't have to do the work personally, but must know why it's done that way. AI can be responsible for execution; humans should be responsible for understanding, judgment, and decision-making. This reminds me of a phrase from "Left Ear Mouse" (left ear listener): to be a leader that people are willing to follow. 1. Help people solve problems. When most people in the team or around you ask "How do we solve this problem?", you can always step up and tell them what to do. 2. Be relied upon. When most people in the team or around you make critical decisions, they come to you for advice and ideas. Perhaps when collaborating with AI, we should still work towards this direction. If we only make requests and act as a mouthpiece, we have no confidence inside. Wu Jun once told a story. In 1503, Columbus's fleet arrived in Jamaica. The local natives initially welcomed them warmly, but later, after some crew members stole from the locals, the natives refused to provide food. Columbus faced a food shortage. Columbus had some knowledge of astronomy and carried an astronomical almanac. He flipped through it and found that a total lunar eclipse would occur on the night of February 29, 1504. Three days before the eclipse, Columbus met with the local tribal chief. He told the chief that his god was angry because the locals had stopped providing food, and as punishment, the moon would angrily turn red and disappear from the sky in three days. On the night of the eclipse, it happened exactly as he said. The moon gradually turned red and then vanished into darkness. The natives were terrified and begged Columbus for mercy. Columbus performed a ritual and said that if they continued to provide ample food, the god would forgive them. The locals were thus controlled. What is the essence of this story? Columbus and the natives saw the same moon and the same eclipse. But Columbus understood the astronomical principles behind the eclipse, so he could use this phenomenon. The natives didn't understand, so they were dominated by it. The same applies to today's AI era. AI tools are available to everyone; everyone can use them. But if we just stay at the level where AI tells us the answer and we accept it, AI gives a plan and we execute it, AI says it can't be done and we default to not doing it, then we are no different from the natives watching the eclipse. I increasingly feel that AI can be our executor, but not our cognition. The real work that belongs to humans is to continuously transform AI's output into our own understanding.
Original Article
View Cached Full Text

Cached at: 07/03/26, 04:40 PM

A Major Pitfall Our Team Encountered with Codex

I want to share candidly about a topic that came up in our team’s weekly meeting today. This is something many people might run into when using agent products like Codex.

In short, if all we do with Codex is keep giving instructions and accepting suggestions, without understanding or judgment, then those outputs don’t really become our own capability. Because if someone else pressed the same buttons, the result would be pretty much the same.

As agents become more and more capable, we don’t have to handle every detail ourselves, but we still need to know why something is done a certain way and roughly how it was solved.

If we don’t know at first, that’s okay. After the AI is done, we should go back and ask it questions, then form our own experience and understanding.

Why such a long reflection? It all started about half a year ago.

After the Chinese New Year this year, my small team was fully equipped with Codex. A piece of jargon we often used in internal collaboration was: “let the AI do it first.”

To be honest, this workflow sounds simple, but actually making it happen is quite hard. After all, people have mental inertia.

The good news is, after months of deliberate practice, everyone has developed the habit of letting the AI go first.

But then, I noticed a new problem. Some colleagues started to take things at face value. If Codex said something worked, they believed it. If Codex said something didn’t work, they accepted it. They didn’t dig into the underlying principles and logic.

Let me give you a real example.

I had previously written a tutorial on how to integrate DeepSeek V4 with Codex.

At that time, Codex didn’t support third-party models, so you needed a bridging tool like CC Switch.

Later, Codex announced support for third-party model integration. I thought, “Great, this should be simpler now.”

So I assigned a colleague to look into how to quickly integrate DeepSeek V4.

He promptly took a screenshot, told Codex what he needed, and Codex analyzed it and replied that it still couldn’t be done because the protocols were incompatible.

He sent me the screenshot and stopped there.

I thought at the time he couldn’t figure it out, so I took over and continued investigating. I confirmed that the newly opened third-party model support in Codex required compatibility with OpenAI’s Responses API.

DeepSeek V4 didn’t support that protocol. So even though Codex had opened up to third-party models, DeepSeek still couldn’t be directly integrated.

That was the end of it.

This Monday, a good friend who runs a traditional business told me that whenever he sends an image to Codex, it throws an error.

After asking, I found out he had integrated DeepSeek V4 following my tutorial, and V4 itself doesn’t support multimodality.

So I started thinking about integrating Kimi’s new model into Codex. After all, I’ve been using Kimi’s new model recently to make PPTs and analyze data, and the results have been excellent. That model is natively multimodal.

I expected this to go much faster, because we had already gone through the first pitfall. As long as we first checked whether Kimi supported the Responses API, the rest of the approach would be clear.

My colleague took on the new task and started. He used the exact same method as before: he fed the documentation and requirements to Codex and let Codex do the work.

After analysis, Codex concluded that Kimi’s model couldn’t be directly integrated due to protocol incompatibility.

At this point, smart Codex gave him a suggestion: “How about I write a bridging software? That would work.”

He said okay. So Codex went ahead and did it.

Then he came to me excitedly and said the task was done. Hahaha. When I asked him about it, I realized he had no idea about the logic or principles behind it.

I said, “If the protocols are incompatible, couldn’t we just use something like CC Switch instead of building our own?”

He knew nothing about any of that. I felt this method was problematic — it was like he had outsourced all his thinking and understanding to Codex.

So that’s what led to our discussion in today’s weekly meeting.

My takeaway is this: we should become the leader of AI, not just a mouthpiece.

A leader doesn’t necessarily have to do the work themselves, but they must know why it’s being done that way. AI can handle execution; humans need to handle understanding, judgment, and decision-making.

This reminds me of the mantra from “Left Ear Mouse” (a well-known Chinese tech blogger): be a leader people want to follow.

  1. Solve people’s problems. When most people on your team or around you keep asking, “What do we do about this problem?” you can step up and tell them what to do.
  2. Be relied upon. When most people around you are making critical decisions, they come to you for advice and opinions.

Maybe even when collaborating with AI, we should still strive in that direction. If we just make requests and act as a mouthpiece, we have no real confidence.

Wu Jun once told a story.

In 1503, Columbus’s fleet arrived in Jamaica. The local natives initially welcomed them warmly, but later, after some crew members stole items from the locals, the natives refused to provide food. Columbus and his men faced a starvation crisis.

Columbus had some basic astronomical knowledge and carried an astronomical almanac with him. He flipped through it and found that on the night of February 29, 1504, there would be a total lunar eclipse.

Three days before the eclipse, Columbus met with the local tribal chief. He told the chief that his god was angry because the locals had stopped providing food. As punishment, in three days, the moon would turn red with anger and then disappear from the sky.

On that night, the lunar eclipse really happened. The moon gradually turned red and then faded into darkness. The natives were terrified and pleaded with Columbus for mercy.

Columbus performed some kind of ritual and said that as long as they continued to provide ample food, the god would forgive them. That’s how he got the locals under control.

What’s the essence of this story? Columbus and the natives saw the same moon and the same eclipse.

But Columbus understood the astronomical principles behind the eclipse, so he could leverage it. The natives didn’t understand, so they were controlled by it.

The same thing applies to today’s AI era. AI tools are available to everyone. Everyone can use them.

But if we only stay at the level where AI tells us the answer and we accept it, AI gives us a plan and we execute it,

AI says something can’t be done and we accept it as fact, then we’re no different from the natives watching the eclipse.

I increasingly feel that AI can be our executor, but it cannot become our cognition.

What truly belongs to humans is the continuous effort to take what AI produces and turn it back into our own understanding.

Similar Articles

@blueskylh1: The most painful thing about solo product development or leading an AI team is being a "mindless messenger" between different chat windows. After the PM writes the requirements, I have to copy and paste them into the developer's chat. After seeing the sharing from Jason @jxnlco, a developer experience engineer on the OpenAI Codex team, I set up a workflow without...

X AI KOLs Timeline

Introduces a multi-AI agent collaborative workflow based on local plain text files and OpenAI Codex, allowing PM, backend, frontend, and QA to efficiently develop via file relay without copy-pasting.

@dotey: https://x.com/dotey/status/2057250417638035555

X AI KOLs Timeline

This article shares usage tips from the Codex official team, including persistent conversation flow, voice input, task intervention and queuing, tool integration, automation, and goal setting, to help users get the most out of Codex, an AI coding agent.

@Luckyjudy666: 8 Tips to Make Codex Your Personal Assistant 1. Build a Shared Memory for Codex Core rules go in Agents.md, project background in Obsidian, repeated processes as skills, personal preferences and common questions in Memories. Otherwise, Codex is like a new colleague every time, having to explain everything from scratch...

X AI KOLs Timeline

This article shares 8 tips for using the Codex AI assistant effectively, including building shared memory, remote task execution, scheduled automation, file organization, and teaching new software operations, all aimed at improving work efficiency.

@Pluvio9yte: OpenAI released an internal PDF about how their own engineers use Codex. Their security, infra, frontend, and API teams use it daily: • Quickly understand completely unfamiliar codebases • Refactor across dozens of files • Generate edge case tests that devs easily miss …

X AI KOLs Timeline

OpenAI published a guide detailing how their internal engineering teams use Codex for code understanding, refactoring, performance optimization, and more, highlighting practical use cases and best practices.

@Xudong07452910: This paper is a must-read for heavy users of Claude Code, Codex, or other AI Agents. It doesn't study how Agents fail on benchmarks, but a more real problem: In real development, what exactly are AI coding agents doing...

X AI KOLs Timeline

This paper analyzes 20,574 real-world coding-agent sessions to identify how AI agents misalign with developer intent, finding that constraint violations and inaccurate self-reporting are the most common failure modes, imposing trust and effort costs rather than irreversible damage.