Dev Log 2: 800+ commits just to fix one problem?

Around March this year, Claude released Cowork, a multi-agent platform tailored for non-coding scenarios. I used it to maintain my X (formerly Twitter) for a few days, and gained more followers than I had in years. But because Claude Cowork is blocked in mainland China, and given its high monthly subscription cost, any developer who took that into account would naturally get the idea of building a replacement product.

Naturally, I am no exception.

As of now, "adam-agent-server" has iterated to v1.19.1 on the npmjs platform. Three months, 874 commits, more than 260,000 lines of code, 300+ planning documents, 289 open issues — not counting the branches that failed local validation and were not merged. Yet, from the project's inception to now, it has neither become a replacement, nor is it cheaper than subscribing to Claude directly. Perhaps the only tangible result, generated outside the platform, is a working automated podcast production pipeline. It is as if I were building a large-scale farm, only to end up with the conclusion: the custom water-supply-and-drainage system designed for the farm is viable.

I don't understand code. This is not a professional's false modesty — quite the opposite, it is the conclusion I finally reached after more than 800 commits on this project, finding it still riddled with holes, and deciding to stop and reflect deeply.

Writing code in the past was like constructing a tall building. Each department had clearly defined responsibilities. Designers were in charge of the blueprint, bricklayers were in charge of the pouring — and even within every roughly-divided stage, there were multi-layered, vertical and horizontal divisions of labor. Born into this age of high industrialization, we are no strangers to this assembly-line work. Otherwise, how could there be so many people endlessly complaining and refusing to be a repetitive, mechanical cog?

This is like software development before AI, and I suspect many would agree with me on this point. When it comes to construction, it just feels familiar—most people have not actually participated in it. But for software development, for you who were drawn in by the title, including me as I type these words, if I were to assert: "the 'developer' or 'developer' does not refer to everyone involved in a software project, but specifically to that small group of people who turn the 'project manager's' ideas into code." Could we exchange a look and tacitly treat each other as "one of us"?

So for us humans of the pre-AI era, faced with a tool that can sweep up the work of multiple departments and wrap up each step beautifully, the astonishment is understandable. This is also part of the reason why the more you depend on AI tools, the more you feel their awesome power. But this is just a side note, not the main topic. What I really want to say is that software engineering is not like building Lego, where you can just snap various blocks together—it is a complex system requiring the integration of multiple modules. Anyone from the pre-AI era of programming, no matter which part of software engineering they were in, cannot really be called someone who "knows code." Of course, the diversity of the human race allows for the occasional genius who stands far above the rest. I won't comment on that; I only discuss the general case.

For people like us who have only ever seen the "trees" and never truly seen the "forest," the deepest and most natural feeling about AI programming is probably: "As long as you have an idea, AI will turn it into a product," or going a bit deeper: "As long as you have a 'verifiable' idea, AI will turn it into a product and verify it."

I used to firmly believe in this "iron law" myself, and joked with friends time and again, "we just lack a good idea." But do we really just lack a "good idea"?

Yes, and no.

I say "yes" because a good idea is not the kind of "idea" we usually pass around in conversation. Not a "bright idea" that pops into our head in a flash of inspiration; not an "aha moment" about something you suddenly understand in the shower; not the kind of "brainwave" of wanting to develop an app that auto-reads WeChat messages and does voice broadcasts after scrolling through them daily. None of these are it. But what is a truly "good idea"? It's not that I'm being vague — I only have a thin, blurry understanding myself, and can only do my best to explain, more for the purpose of offering a line of thought.

A good idea is a "result" built on solid research and grounded in a real application scenario. Treat the market as soil; the "good idea" is like a seed — a starting point that is foreseeable, can grow, condensed from the previous "life cycle", carrying the genetic information of the previous generation, and also able to be influenced by its surroundings to bring forth new "life". This is probably the inspiration The Imagination of Marketing gave me: it blasted a crack in the fortress I had built for myself. Although I could clearly see light streaming through, I could never see the full picture. Generalities like these have already drained the understanding I had.

So when I say: "Yes. We are indeed missing a good idea." — the "good idea" I want to express is precisely the concept I've been trying hard to explain clearly. But I also said "not," and what that means is: "We are not only missing a good idea. Because even if we had a 'true' 'good idea,' that doesn't mean it would turn into a product as we expect, let alone a successful one."

At this point, another pair of concepts was introduced: "product" and "successful product". This reminds me of a common misconception about using AI. When AI reduces the marginal cost of implementing an unrelated feature to nearly zero, we are more likely to "casually" fix a trivial issue, more likely to "casually" add a feature that looks like a "nice extra" but is actually "gilding the lily". And when these seemingly inconsequential "casual" choices accumulate, we have already turned a snake into a "Demi-Gods and Semi-Devils" (天龙八部). Of course, like "marketing", I don't have enough understanding to further elaborate on what a "successful product" is. It was just a passing thought at the time, leaving a little "I was here" footnote.

Then why do I think having a good idea alone isn't enough? For three reasons.

1. Lack of Appreciation for Good Products

Whenever AI is discussed, there's an inevitable question: when AI takes over every aspect of our lives, what will be left for us humans? I once cleverly said: "What's left is history"—but that was just being evasive. We can reason from two extremes. If AI takes over everything, and humans are indeed left with only "history," then the question is moot, because it's unnecessary. If AI doesn't take over anything, and becomes, like the steam locomotive, the chip, and many other general-purpose technologies that caused historical turning points, just another driving force for an industrial (or industry) revolution, then according to the cyclical evolution of history itself, it will mostly only result in the reorganization of classes and the rise and fall of dynasties. For the individual, this change is slow and lasting in time, gradual and gentle. We just need to go with the flow; there's nothing else to do, and nothing we can do.

But the fear is that AI will only take over part of human activity. It neither renders humanity completely meaningless (of course, we may not have meaning without AI either—dev logs don't do philosophy), nor does it bring about change as gently as spring rain, only on a very long timescale. To use an imperfect analogy, take a house: if an earthquake is small enough, it may not even shake, and the people inside naturally feel nothing; if it's large enough to be utterly devastating, reducing the building to rubble, everyone perishes together, and no further analysis is needed. But if the earthquake is neither large enough to completely collapse the building nor small enough to be barely felt, we can split into two hypotheses at this point: does it stop after one shake, or does it last for a long time? The former is simpler—just the aftermath of one more sudden natural disaster. But for the latter, if the magnitude is uncertain and continues, the first thing it breeds is "panic"—and on top of that, each floor feels the shaking differently… my imagination can carry the scenario no further, but I'm suddenly reminded of two films, Snowpiercer and The Hunger Games.

But let's leave it at that. This analysis was only meant to argue another unrelated idea, and to lay a little groundwork for "in case my analysis is off, I have a fallback". What I really want to say is: "Discussions about AI are endless at every stage". I will only take a small slice of that — the "theory of AI taste" — to forcibly pull this back into the "development log" discussion.

The so-called taste, in its literal sense, is your ability to appreciate the dishes at a restaurant. Someone might ask: "I go to eat for fullness and value — what does that have to do with appreciation?" Indeed, you've touched on one of the most influential aspects of AI on our lives — not that AI can be eaten as a meal, but as usual I can use cooking as an analogy. If one day someone invented a cooking machine that, no matter what cuisine and no matter which country's, could deliver it to you with guaranteed quality as long as you ask — at that point, in terms of food alone, what factors would distinguish one person from another?

Right — it's taste. If the cost of production is negligible, the only factor that determines quality is the discriminating eye of the one making the demand — that is, "taste."

But the cooking metaphor is actually simple. For software engineering, from project initiation to determining direction, from planning to implementation, from MVP to integration testing, the taste required does not all concentrate on "one" traditional role. The taste of project initiation comes from the product manager, the taste of code implementation comes from the developer, and the taste of integration testing comes from the CI engineer. And this is just a model derived from a very simplified abstraction of the entire development system; in practice, the capability required to grasp the whole process is only higher, not lower.

In other words, in the past I was only responsible for laying bricks; all I needed was a sense of "straight and true." Now that I manage the entire project, I need to have an "eye" sufficient (not even excellent) for the whole process from infrastructure to fit-out. And it's not enough for a single-trade craftsman to have only an "eye" — one has to elevate it to the level of "aesthetic sense" to produce results that exceed the average.

So, whether the "one-man-army" is enough to fight depends on whether you have a "taste" broad enough to cover a field, or even cross multiple fields.

II. Lack of a Stop-Loss Point

"Give me more time, and I can definitely do better!" But for us humans, the most scarce thing is "time"—and only "time". Of course, this is just a general-scale conclusion suited only to philosophical inquiry. What I really want to say is that any project is a section truncated by the continuous transformation between "cost" and "benefit".

I'm not saying that once returns fall to a certain level, a project becomes not worth doing or unaffordable—rather, when its "marginal cost" and "marginal return" reach a certain ratio, it will be replaced by other, more "efficient" projects that emerge in the market.

When you build a product but pay no attention to the market's reaction, treating it like a pet that you simply "devote" to, you transform from a "producer" into a "consumer". You no longer have the right to empower it; on the contrary, it actively shows a "needs gap", causing you to dissipate your time, energy, and money — and more — spontaneously and without restraint. Yet you wallow in self-satisfaction amid the busyness, turning a blind eye to the occasional flashes of abnormality, until at last you grow blind again, driven by time, and become a mechanical puppet.

Of course, I don't have any profound "project" or "market" theories; my tone may lean toward "preaching," but these are all heartfelt experiences that arise naturally when I do a clean retrospective of my own failed product development.

Not many wounds, but each one runs deep.

III. Lack of Imagination

I have mentioned the book "The Imagination of Marketing" multiple times recently. You could also say: as someone who wants to master the use of AI as a novel productivity tool — or after you use it to build an excellent product and complete the most important step, monetization — marketing ability is essential.

But what I want to talk about is imagination for the product. If you never dreamed of going somewhere, how would you know you achieved your dream? How would you know where to go? Let alone how to get there. If you can't imagine something at all, even if "Aladdin" placed it in front of you, how would you know it is what you want? And how would you describe to the "genie of the lamp" what you want?

Yes, the analogy works.

For example, I want an apple—of course, the statement should actually be: "I want something like an apple." But it has already subtly shifted the concept, because as stated earlier, we shouldn't have the concept of "apple".

Why don't we take a God's-eye view of the whole process? Xiao Wang wants something, and only we bystanders know that what he wants is an "apple." He himself has only a vague notion — not the complete image of an "apple," and he doesn't have the concept of "apple." How would he describe it?

It could be: "I want a fruit about the size of an orange, with a thin, smooth skin, with a pear-like texture when eaten but with less juice." It could also be: "Give me a fruit with smooth skin, fist-sized, less juicy, sweet to eat, no need to peel, just wash and eat." But no matter which version, we need to layer our own imagined attributes on top of existing things. Because for an ordinary person like me, imagination is like stacking a tall tower—it can only be built on already existing images. Only a few rare geniuses are capable of building castles in the air in completely unknown territory.

These are imaginations of the result: I want something, with certain characteristics. But when you draw a line between the current state and the result, we have thousands and thousands of paths to the destination. So, knowing the start and the end, how to get there becomes the question.

Let's use a bridge as an analogy. It's clear: to go from this shore to the opposite one, you need "a" bridge (swimming, flying, etc. are not considered). But suppose you have no notion of what a bridge looks like; suppose you are the first person who wants to build a "bridge" (before the bridge was ever named). Unless you already have in your mind a framework of a plank laid flat across two supports, and from that imagine the embryo of a "bridge," and then starting from the supports imagine "bridge piers," and so on — unless at every step you need to stack upon the known something you consider unknown, the known can never spontaneously become something else (of course, there are things in the world that transform spontaneously, like a seed becoming a sapling, but in that case, what does it have to do with you?).

So, if I say: "Imagine what you want, and you have a destination. Imagine how to get to that place, and you have a means of transportation. Whether you imagine an endpoint or sketch the line connecting the start to the end, we are, given known conditions and under the seasoning of our own taste, creating something (or some thing) that doesn't yet exist. But if someone has already arrived at the place you want to go before you, don't pretend that you didn't want to go there. The wiser move is to take their endpoint as your starting point, take their taste as the keynote, and start imagining your next adventure right away"—are you, like me, once again full of expectations for the unknown?

In the end, true blindness is not about being unable to see clearly, but about pretending not to see.