Software teams have spent years building a culture around code reviews. Before an important change reaches production, another engineer usually checks it, questions it, tests the logic, and makes sure the team understands what is about to change. That habit has become so normal that shipping serious code without review now feels risky.
Data work has not always had the same protection.
A data team might update a model, change a transformation, rename a column, adjust a metric definition, or rebuild a pipeline that feeds dashboards, internal tools, forecasts, and AI products. The code might look fine in a pull request, but the real impact often lives inside the data itself. A small change in one model can quietly affect revenue reporting, customer segmentation, product analytics, or an AI system that depends on fresh and accurate inputs.
This is the gap CL Kao is trying to close with Recce.
As the founder and CEO of Recce, CL Kao is working on a simple but important idea: data changes should be reviewed with the same seriousness as code changes. For companies building AI-driven software, that idea is becoming harder to ignore. AI products do not run on code alone. They depend on trusted data, clean pipelines, clear definitions, and systems that can be checked before something breaks.
Who is CL Kao
CL Kao, also known as Chia-liang Kao, is a builder with a long history in developer tools, open source, infrastructure, and data systems. Before Recce, he was known for creating SVK, a distributed version control system that came before Git became the default choice for many software teams.
That background matters because Recce is not just another data quality tool. It reflects a founder who has spent years thinking about how technical teams collaborate, review changes, and ship complex systems with confidence.
Kao’s work has often sat close to the place where software teams feel pain. Version control solved a major collaboration problem for engineers. MLOps and data platforms helped teams manage more complex technical workflows. Now, with Recce, Kao is focused on a problem that many data teams know too well: reviewing data changes is still slower, messier, and less visible than reviewing code.
His achievement is not only in building a product. It is in recognizing that modern data work needs a stronger review culture, especially now that AI systems are making data quality even more important.
Why code reviews became a normal part of software delivery
Code reviews became standard because software teams learned a hard lesson. Even good engineers miss things. A second set of eyes can catch bugs, improve design, question assumptions, and protect the product from avoidable mistakes.
A strong code review does more than block bad code. It creates shared understanding. It helps teams see why a change was made, what it affects, and whether it fits the larger system. It also leaves a record of the decision, which makes future debugging and collaboration easier.
That is why code review became part of the software development rhythm. Write the code. Open the pull request. Review the change. Discuss the risk. Merge when the team is confident.
Data teams are now reaching a similar moment.
Analytics engineers, data engineers, and software teams often use Git, pull requests, tests, and deployment pipelines. Tools like dbt have helped make analytics engineering more code-like. But reviewing a data change is not the same as reviewing application code. A reviewer cannot always understand the impact by reading SQL alone.
The real question is not only, “Does this code run?”
The better question is, “What does this change do to the data, the metrics, and everything downstream?”
Why data reviews are becoming more important
Data changes can look small and still carry a large impact.
A team might update the definition of active users. A revenue table might change how refunds are counted. A transformation might remove duplicate records. A new column might be added to support an AI feature. In each case, the code change may be short, but the business meaning behind it can be significant.
This is where many teams struggle. Traditional tests can confirm that a model runs or that a column is not null, but they do not always explain whether the data still makes sense. They may not show which dashboards changed, which downstream models moved, or whether a business-critical number shifted in a dangerous way.
That creates a review problem.
A pull request might show the SQL diff, but not the data diff. A reviewer might see a line of code change, but not the effect on the final table. Someone might approve the change because the tests passed, only to discover days later that an executive dashboard, a finance report, or an AI workflow is now producing the wrong result.
For AI-driven software, this risk grows even larger. AI products often depend on data pipelines that feed recommendations, predictions, customer insights, automation, and decision-making systems. If the data changes in a way nobody reviewed properly, the software can behave differently even if the application code itself was not touched.
That is why data review is becoming a serious engineering habit, not just a quality-control task at the end.
What Recce does for modern data teams
Recce is built to help data teams preview, validate, and review data changes before they reach production. It is especially focused on teams using dbt, where data models, transformations, and pull requests are already part of the workflow.
The product helps reviewers understand the actual impact of a change. Instead of asking someone to judge a data pull request from code alone, Recce gives the team more context around what changed in the data, where that change flows, and what needs to be checked before approval.
In practice, that means Recce can support workflows such as:
- comparing data before and after a change
- reviewing downstream impact through lineage
- creating validation checklists for pull requests
- helping teams share evidence during review
- giving reviewers more confidence before merge
- reducing manual checks and scattered screenshots
The value is clear. Data teams do not just need more alerts after something breaks. They need better visibility before a risky change is merged.
That is the space CL Kao is building around.
How CL Kao is bringing software discipline to data work
The strongest idea behind Recce is that data review should happen inside the development workflow, not after the damage is done.
Many teams already know how to review code. They have pull requests, comments, approvals, and CI checks. But data changes need a slightly different kind of review because the most important evidence is often not in the code. It is in the data impact.
CL Kao is taking the discipline of software review and adapting it for the reality of data work. That does not mean simply copying code review and calling it data review. It means giving data teams the missing context they need to make better decisions.
A reviewer should be able to see what changed, which models are affected, whether the numbers moved in an expected way, and what checks were performed. The review process should help people understand the change instead of forcing them to guess.
This is where Kao’s developer tools background becomes important. He understands that technical teams do not adopt workflows just because they sound good. They adopt them when the workflow makes the job easier, faster, and safer.
Recce is built around that kind of practical trust. It helps teams approve data changes based on evidence, not blind confidence.
Why Recce matters for AI-driven software
AI has made data quality more visible and more urgent.
For years, many data problems stayed inside dashboards and reports. A broken metric might confuse a business meeting or delay a decision. That was already painful. But in AI-driven software, data problems can move directly into product behavior.
A bad dataset can affect a recommendation engine. A stale table can shape a customer-facing automation. A broken transformation can change how an AI system classifies, predicts, or prioritizes information. In other words, data quality is no longer just an analytics concern. It is part of software reliability.
This is why CL Kao and Recce are working at an important moment. Companies want to build faster with AI, but speed without trust creates risk. Teams need a way to move quickly while still understanding whether their data changes are safe.
The old approach of checking data manually after a problem appears is not enough for modern AI systems. By then, the damage may already have reached users, reports, models, or automated workflows.
A stronger review process gives teams a better chance to catch issues earlier. It turns data validation from a late-stage cleanup job into part of the normal software delivery process.
The role of dbt in Recce’s growth
dbt changed the way many companies think about analytics engineering. It helped bring software development practices into data work, including version control, testing, documentation, and modular transformation logic.
That shift created a new need. Once data teams started working more like software teams, they also needed better ways to review changes like software teams.
But reviewing a dbt pull request can still be difficult. SQL changes may be clear to the person who wrote them, but not to every reviewer. A model can pass basic tests while still changing the meaning of a metric. A downstream report can shift without anyone noticing during review.
Recce fits into this gap. It helps data teams review dbt changes with more context. Instead of looking only at code, teams can inspect the actual data impact. They can use lineage to understand where the change travels. They can use checklists to keep the review structured and repeatable.
This makes the pull request more useful. It becomes a place where the team can discuss not only what changed in the code, but what changed in the data and why it is safe to ship.
How Recce changes the review experience
A strong data review process needs more than a green test result. It needs clarity.
Recce helps create that clarity by making data impact easier to see, discuss, and approve.
Reviewers can see what changed
In many data workflows, reviewers have to rely on code diffs and trust. Recce adds more evidence by showing how the data itself changed. That gives reviewers a better way to judge whether the change is expected, harmless, or risky.
Teams can understand downstream impact
A data model rarely lives alone. It often feeds other models, dashboards, reports, and applications. Lineage helps teams understand what sits downstream from a change, so they can focus review time where it matters most.
Validation becomes easier to share
Data review often becomes messy because evidence is spread across screenshots, notebooks, comments, and private checks. Recce makes validation more structured by giving teams a clearer way to share what was checked and why the change is ready.
Pull requests become more meaningful
A pull request should not only answer, “What code changed?” For data teams, it should also answer, “What did this change do to the data?” Recce helps make that second question easier to answer.
Teams can reduce late-stage firefighting
When data issues are discovered after deployment, the fix is usually more expensive. People have to trace the problem, explain the error, repair trust, and sometimes correct decisions made from bad data. Better review before merge can reduce that cycle.
CL Kao’s achievement beyond building a product
The most interesting part of CL Kao’s work is that he is not only building a tool. He is helping define a category that many data teams already needed but did not always have a name for.
Software teams have code review. Data teams need data review.
That sounds simple, but it represents a real shift. It means treating data changes as first-class engineering changes. It means acknowledging that data pipelines now power more than reports. They support AI systems, business operations, product experiences, and executive decisions.
Kao’s earlier work in developer collaboration gives this mission extra weight. His career shows a steady interest in helping technical teams manage change. With SVK, that meant version control and collaboration. With Recce, it means making data changes easier to inspect, validate, and trust.
The company’s growth also points to a wider market need. Recce started as an open-source project and has expanded into a cloud platform for team collaboration. That path matters because open-source tools often grow when practitioners feel a real pain and want a practical solution.
For CL Kao, the achievement is not just funding, product launches, or technical features. It is the larger push to make data review a normal part of how modern teams ship software.
Why data reviews could become normal in every AI company
Every serious AI company depends on data. The quality of that data shapes the quality of the product.
As AI becomes more connected to business workflows, companies will need stronger ways to prove that their data changes are safe. This is especially true when teams are shipping fast, changing models often, and connecting data pipelines to automated decisions.
A future where data review becomes standard is easy to imagine. Before a data change reaches production, the team checks the impact. They review downstream effects. They confirm important metrics. They document what was validated. They approve the change with confidence.
That is very similar to what happened with code review. At one time, code review was not always a default habit. Over time, it became a core part of responsible software engineering.
CL Kao is betting that data review will follow the same path.
And for AI-driven software, that bet makes sense. Teams cannot build trustworthy AI on top of data changes they do not understand. They need workflows that make correctness visible before production, not after users or stakeholders discover the problem.
What makes CL Kao’s approach different
What makes CL Kao’s approach stand out is that it does not remove people from the review process. It gives people better information.
That is an important difference. Some tools promise full automation, as if human judgment is the problem. Recce takes a more grounded approach. It recognizes that data review still needs people who understand the business, the pipeline, the metric, and the product. The goal is to help those people review faster and with more confidence.
This is especially useful for teams where data work sits between engineering and business. A data change may be technically correct but still wrong for the business meaning of a metric. A reviewer needs context to catch that. Better tooling can bring that context into the workflow.
That is why Recce feels aligned with how modern teams actually work. It supports collaboration, review evidence, impact visibility, and structured validation. It helps teams move faster without pretending that speed alone is the goal.
Why CL Kao’s story matters now
The rise of AI-driven software has made one thing clear: data is no longer a background asset. It is part of the product.
When software depends on data pipelines, those pipelines need the same level of care as application code. They need review, validation, ownership, and trust. Without that, teams may ship quickly, but they may also ship uncertainty.
CL Kao is building Recce around the belief that data teams deserve better review workflows. His work connects the discipline of software engineering with the reality of modern data systems. It also points toward a future where reviewing data changes is not an optional step, but a normal part of building reliable software.
That is why the idea behind Recce is bigger than one product. It speaks to where software development is going. As AI systems become more common, the teams building them will need stronger ways to understand how data changes affect the products, models, and decisions that depend on them.
In that shift, CL Kao is helping make data review as important, expected, and valuable as code review.
