In a Company Where Talk Outweighs Action: What I See About Surviving the AI Era

I've been at my current company for about a month. Honestly, it doesn't feel good.

What bothers me more is that I changed companies and found the same problem. I believe I have drive, and I believe I'm prepared, but that drive just won't come out.

At my old company I blamed it on having no outlet for my ability. At the new one, I see that the human factor is bigger. In one sentence, this company lets talk outweigh action. Everyone talks, everyone argues about principles, and few people actually make things.

I want to take this situation apart: how the problem formed, how I plan to deal with it, and why I think it isn't just one company's problem but one that IT services as a whole will face in the AI era.

1. Too Many Voices, and Efficiency Burns Up in Arguments

The first thing I noticed at the new company was how many voices there are.

The people here aren't unintelligent or lazy. They are simply too eager to reason. Once something is decided, someone will ask, "Why not the other option?" "That doesn't make sense." "Your logic doesn't hold." It's like a traditional Chinese gathering, especially the northeastern style: you have to argue it through until the other person admits, "This is how it has to be."

Arguing isn't bad in itself. The problem is that many arguments aren't aimed at getting the work right; they're aimed at proving who is right. So time goes into justification instead of progress. Efficiency drops, and people are drained.

I treat this as a settling-in period. In any new environment you have to relearn everyone's pace, their limits, and how they work. But if an organization makes "arguing about principles" its main job over the long run, that's no longer a settling-in problem. It's a structural one.

2. Getting In Step with Japanese Clients: Slow, but Not Explosive

Speaking of adjustment, I think of Japanese clients.

Japanese companies also need an adjustment period at the start of a partnership, but the style is different. Chinese-style adjustment often turns into a loud clash—raised voices, plenty of emotion, positions colliding first. The Japanese style is slower, even gentle, and far less explosive.

Slowness has its advantages. You have time to see where each person stands, what they care about, and how far they can move. I have a rough sense of Japanese companies' events over the years, of which layer of people says what, and where their attention goes. I've been going to conferences and events since 2014 or 2015—more than ten years now. I'm confident in that feel for which things to say at which level, which narratives step on landmines, and which models work or don't.

That's why I say the adjustment itself isn't what's frightening. What's frightening is spending all that time adjusting and still never forming a shared understanding of how to get things done.

3. Too Few Products, Too Many Concepts

Further in, there is the product problem.

This company has made far too few actual products. What it is good at is spinning out a concept: the idea is complete, the direction sounds grand, but when it comes to something people can actually use, it gets thin.

I've built a fair number of products, and my deepest lesson is that a concept and the effect it produces once you build it and use it are often not the same thing. The idea you start with and the direction that grows out of real use frequently diverge. You can only find that difference by pushing forward and testing. You can't argue it out in a meeting.

So I've become convinced that a company focused single-mindedly on "producing concepts" is doing it wrong. Concepts matter, but they have to be built, used, and repeatedly revised. Otherwise they are just words.

4. Fix the Inside First: Build a State of Doing Solid Work

So what do we do? My answer is to fix the inside first.

People have to do solid work. Only while you're doing it do you earn the right—and the confidence—to go out and "knock on doors." Conversely, if someone isn't in a state of doing the work and just goes out to try their luck and look for opportunities, that's pure bluff. Opportunities won by bluffing can't be held, and they won't end well.

There are two hands here: one makes things, the other goes out and knocks on doors. Right now we have neither. So the order can't be reversed. First build the internal state in which people can keep doing the work.

Some will say: go out first, find demand, then come back and build. I disagree. In IT, the only constant is change. Our biggest risk is requirement change—but look at it the other way: if requirements never changed, there would be no continuous development work at all. This industry is permanently in a state of change. You can't float a concept, expect customers to buy it, and expect that concept to sell forever.

That's why mechanism matters more than concept. Concretely: discuss internally first, then set a rhythm. Decide what has to happen each week and report daily. A weekly report is too coarse. Really following a project means coordinated teamwork across the whole organization—not "I've added you to the group, and after that I don't care," followed by washing your hands of it. You trust someone, but their direction differs from yours. They walk hard for a stretch, and you look back and say, "Wrong." That turns the company upside down.

Put more bluntly: a thinker with no capacity for action is a notch below someone actually walking the road. Ideas alone don't get bought; things get bought. If you have nothing but ideas, and you drive out the people who can make things and move ideas forward, you end up with neither the people nor the money. If they succeed after leaving, you have cultivated your own enemies.

So a new project cannot be "I set the direction, you execute." It has to be joint participation and joint planning. This project is a bit like a second startup. Whether the past was success or failure, this time we build the mechanism first.

5. Two Lines: Make Things, and Own the Whole Solution

Concretely, I see two lines.

The first is to make things. Actually build them. Whether they're usable immediately or not yet doesn't matter. People see things differently; that's normal.

The second is the overall solution. A solution is made of many parts. Don't work linearly—"I want this feature now"—then let the other person build to their own understanding, only to say, "That's not what I asked for." End of story. Your control has to be comprehensive: build what you build, and what you build may create opportunities later that you can discuss. Ideas come out of conversations with people, and some of your customers are thinking in that direction too. Making these things is meaningful; you just didn't think of it at the time, or didn't know whom to look for.

More important: you have to lead the market as comprehensively as you can if you want to win. Watching a single facet won't give you competitiveness—unless you're the kind of company with overwhelming scale and investment. As for the "whose daddy is richer" kind of business—wealthy people swapping resources and slapping a project onto the books—that's a different league from climbing the ladder by doing real work. It isn't the same game.

So it's fine to talk big. But the order matters: first build it at home. Once you've built it, you have confidence. Then go out and knock on doors. Go to trade shows, talk to people, present the concept, meet again after the first conversation, talk again, and push it forward gradually. It doesn't take a lot of people. It takes diligence.

6. Products Are Worthless: From Selling Software to Riding Someone Else's Boat

On the business side, I think the money ultimately isn't in selling products. It's in fitting the other party's framework and selling in combination.

In the AI era, products are already worthless. The traditional programmer's thinking—"build a product, sell the product, earn product margin"—doesn't work anymore.

One example. Around October 20, a company released something called Context Engine. It was a direct competitor to our product. They built it straight on top of their own database, and the moment it launched, it crushed us. We spent months on ours; they have that many people. Of course they can build it better than we can. It's painful to think about.

So the business thinking has to change. Drop "selling products." Get onto the cloud, onto services, onto the partner-service path, cross-promoting and selling each other's offerings. For the end customer, there has to be a tangible form. What we sell is that form and the service it carries, not the software itself. The service runs through the cloud, and the cloud pays us a rebate. With a client who has real money, charge a small operating fee for the form. The software itself is worthless.

Think of us as a streamer: we have to package ourselves to look good. The product is the shipping box; the box itself means nothing. We've reached the point where words become reality. You put out a concept, and someone imitates it and ships a product immediately. You give people inspiration—and a joke, because your inspiration may not even be right. It's like asking an Amazon delivery driver to deliver in a Mercedes G-Wagon. Can he afford the gas, let alone the car?

7. When Technology Stops Paying, the Only Thing Left Is People

Yesterday I attended Developers IO 2026, hosted by Classmethod. Their president spoke at the end.

One thing he said mattered a great deal: in this era, there is no competitiveness other than a good mindset and a good body—showing up as a human being, in front of customers, continuously. Classmethod is one of the largest AWS partners in Japan, and its own president said that learning this and mastering that ultimately comes down to continuous self-learning. But the biggest point was this: if your body breaks, or your mind can't take it anymore, you're finished. You're out. When technology itself is no longer a differentiator, the only thing left is people.

People like us don't change someone's thinking through a product. We do it through a narrative—guiding and inspiring the other person, making the people we work with feel a sense of achievement and upward momentum. That is IT service in the new era. The IP itself becomes a service, and the human being is the service provider—not the provider of "IT software."

So how is that different from consulting? In the AI era, knowledge is worthless. Methodology is worthless. Products built from knowledge and methodology are worthless too. What is most valuable is reading people and the room: seeing the other person's current state, analyzing why these particular people are in that state, then using some method to help them reset and adjust, so they can move forward in a good state. At the key moment, you inspire them—to explore, to discover things for themselves. They grow, and they lift the people around them. That is what people are willing to pay for now, not a software product you hand them.

8. If AI and Robots Keep Developing

Let me end with a somewhat bold projection.

If AI and robots keep developing at this pace, software is the industry being hit first—software products are already worthless. Further out, I think physical products themselves will still have value, but the people who make them will gradually lose value too.

To put it another way: programmers who build IT software will lose value, because software will be created automatically by AI. Software as a tool has value; the people who make it no longer do. If AI and robots develop fast enough, all products will still have value, but the workers who make them will gradually lose it.

What do we do then? Society as a whole should be thinking about this. IT is simply the first to be hit, so we enter this painful transition earlier and look for a way to change how people interact. If that method works, the methodology can help other industries transform. I think that's a positive thing, and it's ultimately what we're after.

I don't know whether it will work. But at least right now I'm certain of one thing: continuing to circle around products is not the answer.