A narrow experiment inside a larger ambition
Pino SI is Kooya’s project, and this is our public research note rather than an independent endorsement. SI expresses a superintelligence ambition; it is not a claim that this capability has been achieved. The public research snapshot identifies coding as the first planned pilot and evaluation as planned.[1]
A useful early question can be much smaller than the long-term ambition. When a person describes a programming task in everyday mixed-language phrasing, can additional language adaptation improve the resulting code? A controlled comparison can investigate that question without pretending to settle every aspect of Philippine-language intelligence.
What the published comparison commits to
The public design starts two paths from the same open model. Path A receives coding training. Path B receives Philippine-language training before coding training. Both face the same coding problems and tests. The site also describes native-speaker-written Taglish questions and checking whether English remains strong. It does not publish a complete experimental protocol.[1]
The considerations below explain how to interpret such a design. They should not be read as announcements that particular settings, sample counts or acceptance thresholds have already been selected. Separating a public plan from unresolved methodological choices keeps a later report honest about what was actually tested.
The extra training stage is also a confound
If Path B performs better, the first defensible finding would concern the two tested training paths. It would not automatically establish that Philippine-language content alone caused the improvement. Path B has an additional stage, which may change total training exposure, computation and the sequence of learning.
A stronger investigation could consider an additional comparison with matched training effort, or a series of smaller comparisons that vary one factor at a time. Whether that is feasible is a research decision, not a commitment in the public snapshot. Any report should state which variables were matched and which differed, including downstream coding training and the inference conditions used for evaluation.
Running code creates evidence with boundaries
Chen and colleagues’ original code-model paper introduced HumanEval to assess functional correctness through programming tasks and execution. It also demonstrated that the number of sampled attempts can materially affect reported success. This is methodological context, not a statement that Pino SI uses HumanEval or the model described in that paper.[2]
For the planned comparison, an interpretable report would distinguish a single attempt from success after repeated attempts or repair. It would explain whether either version received feedback from tests. Equal questions are only part of fairness: the same execution conditions, available tools and attempt budget matter when attributing a difference to the model versions.
A passing test is only as informative as the test
The EvalPlus research showed that expanding test coverage can uncover incorrect generated programs missed by narrower tests and can change model rankings. Its lesson here is about measurement quality. It supplies no evidence about Pino SI’s capabilities or its choice of evaluation material.[3]
An illustrative coding task might request a function that totals values while handling an empty input. A few ordinary examples may miss an error on the boundary case. Reviewers should ask whether the test expresses the full task and whether a failure is caused by code, ambiguous wording or the evaluation environment. Counting those failure types separately makes the result more actionable.
Language comparison needs human judgment as well
Equivalent English and Taglish prompts should preserve the same requirements, constraints and edge cases. A literal translation can introduce hints or ambiguity, making the language comparison partly a comparison of task difficulty. Native-speaker review can examine whether a question sounds natural while retaining its intended technical meaning.
This note proposes reporting functional correctness separately from clarity and language appropriateness. Fluent explanations do not establish working code, while working code alone does not establish that a model communicates well with the intended user. English retention also deserves its own results rather than disappearing into an average that combines languages.
The Taglish research note examines why preserving a speaker’s constraint needs its own review alongside working code.
What an informative first report would say
A useful report would identify the comparison performed, evaluation scope, attempt rules and uncertainty around the observed differences. It would include unsuccessful cases and describe any changes made after inspecting results. Material used to improve a system should be distinguished from material reserved to assess the resulting version.
The outcome could support another experiment, expose a tradeoff or fail to show a reliable improvement. Each is informative if the conditions are clear. No private training-source identities or guessed base-model details are needed to explain that logic. The first public evidence should support the narrow claim tested, with broader capability claims left for broader evidence.