Skip to content
View 1kalin's full-sized avatar
🎯
Focusing
🎯
Focusing

Block or report 1kalin

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Content in all repositories owned by your account will be closed.
Maximum 250 characters. Please don’t include any personal information such as legal names or email addresses. Markdown is supported. This note will only be visible to you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
1kalin/README.md

Kalin Smolichki

I build agent systems that check their own work, and I ship the evidence with them.

Most AI demos prove a system succeeds on a case it was built for. That is the easy half. The half that decides whether you can leave something running is what happens when it is wrong.


What I do

Evaluation harnesses, not demos. Every system I deliver ships with a way to measure whether it actually works, on a held-out set, with the number visible. When someone later changes a chunk size or swaps a model, you find out whether it got better instead of guessing.

Validation loops that bounce. Agents propose, a separate checker runs the code rather than reading the claim about it, and work goes back until it converges. A loop that never bounces has not been shown to work. It has only been shown to run.

Production data integration. Eight years of it. Connectors for SAP ODP, Salesforce, Salesforce Marketing Cloud, ServiceNow, Workday, NetSuite, OData and the Google stack, landing into Snowflake, Databricks, Redshift, BigQuery and Synapse. If your data lives somewhere awkward, I have probably already moved it.


The record

Pull requests merged 329
Pull requests reviewed 439, for ~44 engineers across 19 repositories
Tickets delivered 569, ~97% closed
Production incidents resolved 107, none left open, 34 at critical severity
Contributions in the last year 1,072

Open work

agent-eval-demos — three small demos on verifiable evaluation. Each runs from a clean checkout with no API key, no GPU and no network, and each ships the number it claims alongside the command that produces it.

  • rag-evaluation-demo — retrieval with the harness attached, not bolted on. 6/6 held-out, 7 tests.
  • validation-loop-demo — rejects a plausible-but-wrong first attempt, accepts the corrected second.
  • brief-to-report-demo — structured input to a reviewable artefact, end to end.

Measurement work in the open: I read PrimeIntellect-ai/community-environments end to end and found that CHANGED_ENVS=none collapses their pytest parametrisation to an empty set, so a run reports 6 skipped, exits 0, and the badge goes green. Their pytest major-version upgrade was validated by a run that executed none of their tests. Every claim in that issue ships with the command that produced it, so any of it can be re-derived or thrown out.


How I work

I state the number and its caveat. A 6/6 on a six-item fixture is a demo, not a benchmark, and I say so in the README rather than letting it be quoted as one.

I answer no where the answer is no. Unverified is a professional answer; a confident guess is not.

I would rather tell you the build is the wrong build before taking money for it.

Java · Python · TypeScript · React Manchester, UK

@1kalin's activity is private