Imagine people like Sam Altman having access to frontier models without any restrictions that allows them plot strategies to reach their goal in a long term timespan that you don't even realize when it even began.
That's scary. They could fight for censored model for the mass, not for them.
I have better a idea, since everybody need an engineer to build the damn thing, how about we teach non engineer people to talk to engineer people. Why is it always our burden to learn and improve. UX problem, blame the engineer. Comunication problem, blame the engineer. Documentation problem, blame the engineer.
I'm so sick of it. Comunication is a tango. If you - who need the product and are ready to pay for it - don't take your damn time to effectively articulate what are your needs then you should go to school again and learn it.
By the way, since you all non-engineer people are so good at communicating, why are you not communicating effectively your needs?
> If you - who need the product and are ready to pay for it - don't take your damn time to effectively articulate what are your needs then you should go to school again and learn it.
Instead they will go and buy a product that was made by engineers who asked them "what they actually need" and "how can we make it easier for you".
It's not about "why should I always care, I have enough". It's about "who will make better product and earn more money".
> By the way, since you all non-engineer people are so good at communicating, why are you not communicating effectively your needs?
They are good at socialising, blurting out words at each other and they think it's good communicating (it's emotional reassurance of eachother, not a technical facts exchange, but it's still their valid need), but when you say that to them, they are upset and don't want to buy a product from you. Don't tell that to their faces. Of course, if you want to do something and don't want people to buy it, do follow on what you wrote.
> Instead they will go and buy a product that was made by engineers who asked them "what they actually need" and "how can we make it easier for you".
That sort of decision making is not done by engineers. You are blaming engineers about product decisions made by management, product management, UIX design, analysts ...
Well, you are right. I conflated "engineers" with "experts". UX people, product management, analysts should improve their communication skills. Engineers (like me) too.
Engineers should have better communication skills, but if the whole weight of communication is put on engineers instead of people hired to actually be responsible for this, engineers will be burned out.
> That sort of decision making is not done by engineers. You are blaming engineers about product decisions made by management, product management, UIX design, analysts ...
Thank fucking god someone who understand it. Sometime I feel an alien listening people bitch about engineers. A product is not just the result of engineers.
The thing is, neither the software engineers nor the users know wtf should be done completely. Communication across domains is hard.
Let's try a physical items example: have you ever ordered a piece of furniture or other home improvement thing, got exactly what you asked for, professionally done... and then later found out there were better ways to do it (at similar cost) that you hadn't even imagined?
Was it because you didn't know what to ask for? Was it because the experts in home improvement didn't volunteer that there are other options? Was it because they sell one thing and didn't even know there are other options? Did you even ask what options you have or did you just order the thing?
Yes, but it is necessary to achieve better results.
> Was it because you didn't know what to ask for? Was it because the experts in home improvement didn't volunteer that there are other options?
That's bad communication from both sides. Having good information on each of the sides leads to better communication. Client with better communication will have better results for himself. Seller having better communication will give better results to his clients. Worse than his average to clients with bad communication, better than his average to clients with better communication. But his average will be higher than average of seller with bad communication.
Sellers with better communication will provide better service and will attract customers. Sad corollary: he will also attract a lot of customers with bad communication.
> Was it because you didn't know what to ask for?
Yeah, when I don't know what to ask for, I search for expert who will know what I should ask and will help me with expanding my knowledge of the options.
> Let's try a physical items example: have you ever ordered a piece of furniture or other home improvement thing, got exactly what you asked for, professionally done... and then later found out there were better ways to do it (at similar cost) that you hadn't even imagined?
Yes, I speak from experience of such moments.
> The thing is, neither the software engineers nor the users know wtf should be done completely.
It's easier and more effective to educate a small group of software engineers than a lot of users, that's why engineers SHOULD try to communicate better.
> Communication across domains is hard.
It is. But the expert has typically to communicate across one domain, his own against "no_domain". User would have to learn to communicate better or become domain expert in a lot of different domains.
> Yeah, when I don't know what to ask for, I search for expert who will know what I should ask and will help me with expanding my knowledge of the options.
> Yes, I speak from experience of such moments.
And did you actually look for an expert or did you just get something from Ikea? Do you even know how to identify an expert furniture designer?
One of my points is we think we're damn unique but we aren't. And my example has us as customers.
Real world example: I was in $RANDOM_HOTEL last month. Now I want to redo the attachment system for all my curtains in the house because theirs was smarter than what I knew to ask for.
> And did you actually look for an expert or did you just get something from Ikea?
Sorry, but I don't see the point of your comment.
I looked for an expert who helped me with expanding my options. Expert != "will sell his exact product he is trying to sell in the place he is working at". Sometimes as an expert you even have to advise a client against your product, because he will try to use something not designed for him.
> I was in $RANDOM_HOTEL last month. Now I want to redo the attachment system for all my curtains in the house because theirs was smarter than what I knew to ask for.
But did you look for an expert? Expert might suggest a better alternative than you currently have, but you gained information yourself by accident. If not for that happy accident and you being observant, you wouldn't know.
Yes to everything you said and also to what i said :) You just took it personally.
The whole idea is I'm trying to place the "expert" software engineers in a position where they're not the experts to make them understand their clients better.
> and you being observant
OT: How many other great home improvement ideas have i missed because i wasn't observant enough?
Edit: or is it really off topic? Will the customer of the software engineer research, say, all possible database solutions or, even assuming great communication with the engineers, just pick a good enough one from their combined knowledge?
> UX problem, blame the engineer. [...] Documentation problem, blame the engineer.
I see UX and usable documentation as among my responsibilities as a developer. It's not that I "blame" myself if the documentation is confusing for a user, it's that I say "oh, that's a documentation bug". And it's my job to fix bugs.
That's what I started doing in my company, encouraging the use of AI to polish prototypes and communication before handing it to the tech team smooths out alot of issues while exloring the solution space.
What if I told you there’s this thing in 2026 called an LLM that can translate between any two languages with high fidelity for free, and you just clicked a single button in your browser to use it
If you need external input to improve yourself then I'm wondering if you are ready to be a father. I might sound rude, but it is not my intention. I don't know how else to put it. It is still better than people who never learn this either way.
When we only have ourselves to care about, I think it is easier to be irresponsible about our health. It is only ourselves who suffer the consequences. That kind of "solitary-ism" or ego can swing either way: you care so much for yourself that you focus on your health, or instead focus on enjoying those things life has to offer like food and wine (often at the expense of health).
Unlike my and many other's parents, I waited until I was older, more mature and planned beginning a family. Nonetheless, I suspect none of us were truly prepared for what that would mean—especially in the life-changing ways it manifest in.
So if some of us were not focused on our own health before going into fatherhood, I am not surprised. No doubt there are others that had checked off that box but started a family with much slimmer finances than I thought necessary to begin fatherhood.
In the end I suspect it is easy to Monday-morning quarterback my introduction to fatherhood and determine where I could have done better. At the same time, and I am considering my own upbringing, I could have done much, much worse. And yet most of us make it to adulthood with more or less healthy minds and bodies.
What this person could've take away here was that:
- Contrary to what the article states, parenthood in males can sometimes even boost testosterone through external factors.
- Or that resitance training and diet is a great way to deal with daily stress.
What instead they took away was that improving oneself for family somehow makes you unfit to be a parent.
A rather dark interpretation. Sincerely hope they are OK and well.
JSON Schema is already the schema format inside OpenAPI, AsyncAPI, and MCP. Using it means OBI can reference those specs directly without translation. Any other choice would have made interop harder, not easier.
The programming language analogy is about structural compatibility between contracts, not about the wire format the contract is written in.
Well he didn't choose JSON, he chose JSON Schema and since the documentation is trying to hide the existence of JSON Schema and the potential limitations of it when used in combination with e.g. gRPC, when the schema is 99% of the project it's hard to trust the project.
That said, if it feels buried, I'll look at surfacing it more clearly.
You're right about the gRPC fidelity issues though. int64 precision, oneof vs oneOf semantics, enum value mapping, and well-known types all need careful handling when binding to Proto. The tradeoff is that JSON Schema is already the schema format inside OpenAPI, AsyncAPI, and MCP, so OBI can reference their schemas directly without translation. Proto would have given better fidelity for gRPC but required schema translation for every other binding. Picking JSON Schema prioritizes cross-binding reach over depth in any one protocol.
The fidelity limitations deserve clearer documentation. Adding that to the list. Thanks for pushing on this.
OBI needs its schema format to be universally parseable, deterministic to compare, and rich enough to describe the portable subset of any binding format's type system. JSON Schema meets those requirements without tying the spec to any one ecosystem. Proto-level fidelity would center gRPC. A custom IDL would fragment tooling. JSON Schema is the neutral ground.
The limitations are real, especially with proto. For example, our own proto interface creator implementation maps 32-bit integers to JSON Schema `integer` and 64-bit integers to `string` to avoid JSON precision loss beyond 2^53, following Proto3's canonical JSON mapping. Proto enums are int-valued with names; JSON Schema enums are typically strings. Proto's oneof differs semantically from JSON Schema's oneOf. Maps with non-string keys can't be expressed directly.
These affect cross-service structural comparison, not execution. Executors handle source types natively on the wire, so int64 stays int64 when you actually make a call. Transforms bridge shape differences between operation schemas and binding sources at runtime. The comparison layer works at a coarser grain in v0.1 because that's what makes it deterministic and universally implementable. Future profile versions can tighten comparison precision as the ecosystem converges on the tradeoffs worth making.
reply