Computer

In the last few months, while writing code using tools like Claude or Codex, my most striking realization wasn’t that “programmers are obsolete,” but rather that many tasks that used to be given to newcomers for practice can now generate a basic first draft themselves. Whether it’s creating a scaffold, adding several tests, or making small modifications on the fly—after running through these operations, the speed is genuinely fast, so fast it feels almost bittersweet.

For someone like me, who graduated ten years ago, frankly, this is more about increasing efficiency. Because I generally know where it’s reliable and where it isn’t; where something looks functional but actually has pitfalls hidden further down the line. But for fresh graduates, this topic isn’t so straightforward. AI isn’t just here to take over a few hours of manual labor; it feels more like it is compressing the traditional path of how a newcomer goes from zero knowledge to proficiency. This is also why I wanted to write about it separately.

Stunned. / Dumbfounded.

The official ChatGPT side doesn’t make it easy to track tokens and costs directly, so I found a third-party platform and ran a round of similar tasks using GPT-5.4 and GPT-5.5 in Codex, setting the thinking mode to high. The result was very straightforward: simple questions were relatively mild (in terms of cost), with GPT-5.5 being about 30% more expensive than GPT-5.4; however, once complex tasks were involved, the costs shot up to 2.6 times, and both the request count and token consumption increased simultaneously.

My current assessment is very straightforward: this isn’t something that can be decided just because of the statement “5.5 has a higher unit price.” In simple tasks, the cost mainly comes from the unit price; but in complex tasks, what is actually expensive is the entire calling chain (or execution flow). However, looking at it another way, 5.5 does genuinely feel like it’s absorbing your rework costs for you. The model is more willing to think through multiple steps, perform more actions, and check things more thoroughly. Ultimately, the billing isn’t based on a single answer; it’s based on the complete set of actions, which also minimizes the number of back-and-forth cycles required from the human user.

Initially, I didn’t actually plan on testing it. When I came across the news that OpenAI was releasing ChatGPT Images 2.0 on April 21, 2026, my first reaction was just “another image version update.” However, when I checked the Artificial Analysis leaderboard and saw that GPT Image 2 (high) ranked first for text-to-image generation with an Elo of 1332, I felt a bit compelled to test it anyway.

The results are quite impressive; the Chinese output is excellent, it can handle comics, and character/narrative consistency across multiple continuous images has also improved. However, as I tested it further, I felt that what is truly worth discussing this time isn’t “it draws better,” but rather “it starts making things that were previously taken as default truths seem unreliable.” This subject matter is more complicated than a simple leaderboard ranking.

Scrolling through the model updates tonight was genuinely mind-boggling.

My current judgment is straightforward: this round is no longer merely a wave of model releases. It involves three fronts working simultaneously—model capabilities, API pricing, and chip stack ownership. Anyone who focuses on only one of these aspects will likely have a biased view. And it is precisely because these three dimensions are intertwining that the large model sector appears so intensely competitive.

These past couple of days, I came across Anthropic’s Project Glasswing, which is scheduled for release on April 7, 2026. My first reaction was a bit stunned. It wasn’t because another model scored higher, but because it locked the top-tier capabilities into a small circle, initially reserved for defensive players like AWS, Apple, Google, Microsoft, and Linux Foundation.

My own judgment is very direct: This matter is more important than another benchmark record. What frontier AI companies are selling now is no longer just the model itself, but an entire set of access controls—“who gets the capability first, how much capability they get, and what kind of auditing and constraints they have to endure after receiving it.” Models are becoming increasingly like dangerous tools, and the release rhythm is becoming more like issuing licenses.

Previously, when I debugged C++ in VS Code, the configuration basically stopped at launch.json, maybe with an extra line for GDB. Fill in the program, fill in the gdb, set the breakpoints. And then what? Then every time before debugging, I had to manually run cmake --build in the terminal. What was even more annoying was that after setting breakpoints on custom prices, contracts, or order types, the VS Code debug window often only showed a bunch of internal fields. The data was correct, but it wasn’t human-readable. The ridiculous part is that some tutorials I saw before stopped around launch.json. It wasn’t until recently, when I had an AI set up a new project for me, that it conveniently added preLaunchTask and gdb_printers.py, that I realized: debugging C++ in VS Code isn’t just about starting GDB. You can automatically trigger CMake compilation before debugging, and after hitting a breakpoint, you can even let GDB load a Python script to format business types into something readable for us. Honestly, this isn’t some black magic. But it perfectly filled two annoying gaps in daily C++ debugging: pre-launch build and variable display after a breakpoint.

When I recently wrote the algorithm service, as soon as I implemented modules like twap and vwap, this old problem popped up again.

If we rely on class names to enforce semantics in C++, the naming convention quickly becomes out of control. Things like TwapOrderManager, VwapOrderManager, and AlgoOrderManager sound like, “I know my structure isn’t contained, but I’ll at least add a prefix.” Frankly speaking, organizing by folders and then adding a layer of namespace isn’t about code snobbery; it’s filling the gap that C++ has because it lacks Java’s native package system.

While browsing the forum this time, what struck me most wasn’t which company released another leaderboard, but a very basic statement: “Not enough VRAM; no matter how large the parameters are, it’s useless.”

Previously, I always understood “slow model” as a computational power issue. However, the more I read, the clearer it became that often, the problem isn’t that the GPU can’t compute it, but rather that the data cannot reside in the right place. Just by changing the memory path, the token speed doesn’t just slow down; it drops drastically.