@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...
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.
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.
- 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.
- 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...
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
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...
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 …
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...
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.