jdw64
What I mean by an emerging industry is one that requires little capital and has few entrenched players—in the end, an industry where new entrants can compete with small initial capital. That's how I'd redefine it.
Because in the IT boom era, there were many technological opportunities. The boss who hired me was one example. But in the case of industrial robot manufacturing, the existing hardware supply chain is, by and large, the one investing.
In the end, what I want to say comes down to this: there are fewer industries open to new entrants.
Because in the IT boom and the construction boom, there were markets that needed less capital than you'd think in the early days. In subcontracting, for instance, you could enter with relatively little capital. But in today's technologically advanced industries, initial capital requirements are far higher. So in the past, even within the same category of industry, there clearly existed sub-markets you could participate in with comparatively little initial capital.
For example, in the old IT industry, my seniors 20 years ago said it took surprisingly little capital. But today's market isn't like that. I think this is a problem that arises as industries become more advanced.
There's a paper I read some time ago arguing that as an industry becomes more advanced, the knowledge and resources required to make a product increase.[1] [1]https://www.nber.org/papers/w27787
But this site looks like GPT made it, doesn't it? I can see GPT's characteristic green button UI and beige color scheme. GPT 6.1 tends to use a green-toned UI.
Since I’m a freelance programmer, my workflow is far removed from other people’s (there’s no review, and I mostly deliver programs based on whether they run), and I had no place to hear advice from seniors. But rramadass always helps me. Thanks to the advice you gave me, I was able to study formal verification and also study ADTs, and explore a broader world.
Some local regressions still exist, but the big looping around has decreased compared to before. It still seems long-running agents can’t fully replace humans yet. I’m always grateful, and thank you for not getting annoyed and for giving me advice even though I’m always lacking. Have a good day. Thank you so much.
May I save your comment and write it on my homepage later? Your advice seems like it will be a big help. Since I’m mostly doing things by reading manuals and books and running into problems myself, certain problems get solved quickly, but there are sections where I get stuck like this, and I always get a lot of help from you. Thank you always.
Other people say that when they do AI coding, they finish quickly, but for me it’s painful because I keep having to verify it myself.
Then it should implement the whole UML skeleton, right? But it goes like this: halfway through, at some point, it says, “This algorithm is too slow? Hmm... I need to make it faster,” and tries local optimization, so sometimes I don’t get the result I want—that is, an MVP that at least runs.
I know the overall goal clearly, but there’s a problem where it gets obsessed with a specific subgoal or keeps expanding that subgoal.
The main point is not that everything is solved if you specify all the conjunction conditions and prove that those conjunction conditions are correct. Rather, the key point is that in that process, the agent keeps expanding subgoals.
For example, two proofs, P1 and P2, are carried out, but they proceed in a way that diverges from the actual progress of the work. That is, you can prove things like "P1: the chicken is safe" and "P2: the origin of this sauce is trustworthy," but combining these does not make a chicken dish.
In other words, the proof logic holds, but my actual task doesn't get solved. I'm questioning how to solve this problem. It's frustrating that I'm not a native English speaker at times like this. I'm sorry for causing a misunderstanding.
For example, it goes like this.
I proved P1 and P2. But then it creates P1.1. It goes and finds information from an agency certifying that this chicken is safe, and puts that in. Then it starts creating P2.1 as well. The origin of this sauce is trustworthy, but maybe there’s a better one somewhere?
It goes on like that.
For example, I want to eat chicken, so I try formally verifying "chicken dish," and every time GPT or Claude starts digging into the origin of the sauce in the chicken dish or the breed of the chicken. Then the chicken dish never gets finished and never makes it to dinner, and instead I gain deep knowledge about the origin of chickens.
Of course, I know that formal verification has liveness — meaning that there must be progress in the work is also part of formal verification — but the AI judges that learning the origin of the chicken counts as progress too. Yet it ends up doing work that it actually shouldn't be doing.
Personally, while organizing these AI anti-patterns, I feel that when you formally verify one condition, verification of another condition gets weakened, and within that phenomenon I sense the AI spinning in circles again. In the end, I end up going through the process of reading and merging everything one by one myself, and I want to know whether this is something only I experience.
Product engineers, on the other hand, are actually quite ambiguous to evaluate. Many methodologies have been introduced, starting from Barry Boehm, but over time they gradually stop fitting, and there are many points that are hard to assess. It's essentially a matter of organizational management theory. The ideal of organizational management theory is that diversity comes together to create synergy, but conversely, such diversity means that decision-making within the organization slows down.
Technologists, by contrast, are very easy to observe in terms of speed or code quality. In fact, most people choose a career of learning technology and making money rather than founding a startup, and from that perspective, since "career" tends to be emphasized as an employee's career rather than a founder's career, isn't that why technologists are emphasized?
What companies value as a capability is ultimately an evaluation that can be measured. And product engineering, when you think about it, presupposes discussions with decision makers.
'Is it necessary to implement this feature?'
'Do customers actually need this feature?'
'Isn't the business model wrong?'
Most decision makers are people high up in the hierarchy, and friction with them is unavoidable. In other words, it crosses existing role boundaries, which means more frequent conflicts in organizational dynamics.
Whether that is ultimately a gain or a loss for the organization is something nobody can konw
Rather, I tend to feel that sensation even more now, while LLMs are still in their early stages.
But ultimately, for reviewers, what matters is that they “make a living through reviews,” so they have to say things that fit the fanboy tier they’re targeting.
The problem is that fanboys are generally people who buy more devices to begin with, so they also judge reliability based on the existing product lineup, and reviewers are largely the same. As a result, they can’t help but judge mainly by new features.
To be precise, “reliability” requires predicting the future, and that’s not easy. How would you know if your computer might break tomorrow? There are serious hinge issues with the iPhone Duo right now—how would people buying it have predicted that?
Prediction is basically break-even even when you’re right, and easy to criticize when you’re wrong, so it’s a hard attribute for reviewers to review.