2026-07-15 05:48:03
2026 IBM Report Enterprise in 2030 highlights AI is changing what companies do and how they do it. 79% of executives say AI will significantly contribute to their revenue by 2030, but only 24% can clearly see where that revenue will come from. That gap between expectations and outcomes presents the leadership challenge of this decade. CIOs and boards must now answer questions that existing governance frameworks were not designed to address: which generative AI systems are deployed, where data resides and how sensitive it is, who owns the risk, how failures are detected, and how the organization can prove controls are working.
AI-first organizations will need more than principles-based AI governance. They will need clear operating controls, decision rights, monitoring routines, and auditable evidence that executives, regulators, customers, and employees can trust. For example, IBM’s 2025 report found that 20% of organizations that experienced a breach attributed it to unauthorized AI tools, adding an average cost premium of $670,000.
This article introduces a practical Generative AI Trust Control Framework for CIOs, CTOs, CISOs, chief risk officers, general counsel, and board directors. The framework helps leaders move from policy statements to control evidence by organizing governance around eight control domains: inventory, risk classification, data boundaries, vendor assurance, human oversight, monitoring, incident response, and board reporting.
For CIOs and boards, the central issue is how organizations can govern the speed, scale, and autonomy of AI adoption without losing control of data, accountability, compliance, and customer trust. Typical technology governance assumes that systems are known, approved, and relatively stable; generative AI challenges this assumption. Employees often use non-approved AI tools. AI can also be adopted through vendors in an existing system. There are three risks that can add to the problem:
• Models can produce plausible but incorrect answers
• Retrieval systems may reveal sensitive data
• Agents can perform workflows faster than existing approval processes.
Resulting in exposure to a company across data privacy, bias, IP, cybersecurity, third-party dependence, and public trust, this creates an exposure portfolio. Risk mitigation does not need to be a one-off approach for each risk but should instead be undertaken through a shared control approach.
The principles of fairness, transparency, accountability, privacy, security, and human oversight are already being implemented by many organizations as part of AI governance. These principles should be followed, but they do not indicate whether a business unit should be permitted to add private client data to a generative AI system. They do not explain what organizations hope to obtain from an AI vendor. They do not notify the customer operations leader when human review is required. They do not report to the board the number of high-risk use cases in production or whether controls are working. There were 362 AI-related incidents reported in the Stanford 2026 AI Index in 2025, a 55% increase from the previous year.
CIOs need evidence; they cannot manage generative AI through one-time approvals. They need a repeatable operating model that makes AI use visible, classifies risk before deployment, assigns accountable owners, defines minimum controls, monitors performance, and escalates exceptions.
Widely recognized frameworks provide important foundations. The NIST AI Risk Management Framework and its Generative AI Profile emphasize governance, mapping, measurement, and risk management. ISO/IEC 42001 provides requirements for establishing and continually improving an AI management system. The EU AI Act reinforces the importance of risk classification, transparency, documentation, and oversight.
The Generative AI Trust Control Framework is designed to turn AI governance into an evidence-driven system. The framework has eight control domains. Its purpose is to connect each domain through a common workflow so that every material AI use case can be identified, evaluated, controlled, monitored, and reported in a repeatable, consistent way.
Each domain answers a specific executive question and produces evidence that can be reviewed by management, internal audit, regulators, customers or the board.
|
Control Domain |
Executive Question |
Example Control |
Evidence Produced |
|---|---|---|---|
|
1. AI Usage |
Where is AI being used? |
Maintain a centralized landscape of AI systems, AI pilots and projects, embedded vendor features, and employee-facing tools. |
Approved use-case record with owner, purpose, users, data sources, and status. |
|
2. Risk classification |
How risky is the use case? |
Tier each use case by data sensitivity, business impact, regulatory exposure, autonomy, and reversibility of harm. |
Risk rating and required control baseline. |
|
3. Data sovereignty and control |
What data may the system access, and where does it reside?What jurisdictional, sovereignty, and regulatory requirements apply? |
Define permitted and prohibited data classes, retention rules, sovereignty constraints, and model-training restrictions. |
Data-use approval and privacy/security review record. |
|
4. Model and platform control |
What models and platforms are in use? |
Assess vendors, model documentation, audit rights, indemnities, security posture, and change-notification terms. |
Vendor risk file and approved model record. |
|
5. Human oversight |
Where must humans intervene? |
Define decision rights, review thresholds, escalation paths, and prohibited autonomous actions. |
Human review logs and exception records. |
|
6. Continuous monitoring |
Is the system behaving as expected? |
Monitor for hallucination, bias, drift, data leakage, prompt injection, misuse, and performance degradation. |
Control dashboard and test results. |
|
7. AI incident response |
What happens when AI fails? |
Create playbooks for harmful outputs, data exposure, model abuse, regulatory complaints, and operational disruption. |
Incident record, root-cause analysis, remediation plan, and lessons learned. |
|
8. Board reporting |
Can leadership trust the AI portfolio? |
Report adoption, risk posture, incidents, control gaps, exceptions, and residual risk on a regular cadence. |
Quarterly AI trust dashboard and board decision log. |
Generative AI ethics and their application are typically referred to as ethical responsibilities, but in the business context, they are business imperatives. Organizations that fail to consider ethical issues may lose the trust of their customers, employees, and governments. Public trust in AI remains fragile.
It is important to define transparency to ensure AI outputs can be explained and traced. Accountability ensures that responsibility for AI-driven decisions does not pass through the system unchecked. Human oversight is necessary, especially in high-impact situations where judgment and context are important. Consent and disclosure are critical elements, as people are increasingly eager to know when they are communicating with AI. When ethical behavior becomes an integral part of everyday business, it can become a source of sustainable innovation.
Trust should be measured, not presumed. A board cannot govern generative AI by asking whether management feels comfortable with deployment. It needs evidence that the AI portfolio is visible, risk-tiered, controlled, monitored, and aligned with the organization’s risk appetite. The board does not need to review every model. It does need to know whether management has a reliable system for identifying material AI risk and escalating risks based on defined risk ratings.
This diagram shows how organizations move from identifying AI risks to implementing ethics, governance, and controls in order to ultimately build trust.
Values are significant, yet insufficient in themselves. Companies will need to have working controls in place that embed governance as an integral part of their regular business practices. The control lifecycle—Discover, Classify, Assess, Control, Monitor, and Evidence—can be applied repeatedly to the way AI systems are used within the enterprise:
Discover: Keep an up-to-date inventory of all AI systems and agents, including their capabilities, data lineage, shadow AI systems identified through network monitoring and procurement audits, ownership, risk ratings, and business purposes.
Classify: Apply a three-modal approach to governance, recognizing that predictive ML, generative AI, and agentic AI have different risk profiles and therefore should be managed differently.
Assess: Conduct adversarial robustness testing before deployment, including prompt injection, jailbreak, and data poisoning testing, as well as bias evaluation and IP exposure analysis, not just functional testing.
Control: Implement runtime policy controls, including human-in-the-loop policies for high-risk decisions, agentic kill switches, and least-privilege access scoping for all AI-to-system integrations.
Monitor: Deploy continuous observability, including monitoring for bias drift, performance degradation, data exposure, and agent action logs, along with automated alert thresholds based on defined KRIs.
Evidence: Create auditable artifacts such as red-team evidence packs, agent decision logs, AI-SBOMs (Software Bills of Materials for model provenance), and KRI dashboards for board reporting and regulatory compliance.
Trust should be a core competency for CIOs and boards. This means moving from principles to controls, controls to evidence, and evidence to continuous assurance. Firms that can demonstrate how they use AI, segregate risks, protect data, maintain human accountability, detect and address failures, and monitor residual risks at the board level will be more likely to earn the trust of customers, regulators, employees, and investors.
This new world will be built on trust, not just for security purposes, but as a differentiator that may determine an organization’s success or failure.
1. https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/enterprise-2030/
2. https://kpmg.com/us/en/media/news/trust-in-ai-2025.html
2026-07-15 05:46:57
Tel Aviv, Israel, July 14th, 2026/CyberNewswire/--
Researchers observed Claude Tag responding to messages containing the literal text “@Claude” without requiring a genuine structural Slack mention. As a result, content delivered through bots, webhooks, automated feeds, or other external sources could potentially be interpreted as instructions.
The research demonstrated the potential impact through a connected internal organizational resource. Bot-generated messages instructed Claude Tag to retrieve internal information, publish it into Slack, and subsequently delete the original resource using the organization’s configured connection.
The video below demonstrates the observed behavior and its potential impact on connected organizational systems.
“Our research raises a fundamental question for every organization deploying enterprise AI agents: who is actually authorized to instruct the agent?” said Tal Melamed, CTO and Co-Founder of Tego AI. “Organizations need controls that validate the origin and purpose of sensitive actions before an agent is allowed to execute them.”
The research also identified broader concerns involving untrusted automated content becoming an indirect instruction channel, connected applications and MCP servers expanding the potential impact, administrative access to stored channel information outside Slack’s native membership model, and limited visibility through existing history, compliance, and audit interfaces.
“A safety classifier can be an important defense, but it should not be the final authorization boundary for enterprise actions,” Melamed added. “Sensitive operations require deterministic controls that remain effective even when the model misunderstands a request, trusts the wrong identity, or makes an incorrect decision.”
Tego AI recommends applying least-privilege permissions to Claude Tag connections, preferring read-only access, avoiding channels that ingest untrusted external content, restricting administrative access, retaining relevant Slack logs, and introducing independent runtime authorization for sensitive actions.
Tego AI responsibly disclosed the findings to Anthropic. Anthropic classified the submission as informative and disputed that literal “@Claude” text or bot-generated messages initiate Claude Tag sessions under the product’s default configuration. Tego AI’s full report documents the observed behavior, supporting evidence, security implications, and disclosure timeline.
Read the full technical report, including supporting evidence and the disclosure timeline:
Tego AI currently operates in stealth. This is the company's second public security disclosure. According to Tego AI, it has identified additional security issues across other major AI agent platforms, with further disclosures planned.
CTO
Tal Melamed
Tego AI
This story was published as a press release by Cybernewswire under HackerNoon’s Business Blogging
Disclaimer:
This article is for informational purposes only and does not constitute investment advice. Cryptocurrencies are speculative, complex, and involve high risks. This can mean high prices volatility and potential loss of your initial investment. You should consider your financial situation, investment purposes, and consult with a financial advisor before making any investment decisions. The HackerNoon editorial team has only verified the story for grammatical accuracy and does not endorse or guarantee the accuracy, reliability, or completeness of the information stated in this article. #DYOR
2026-07-15 05:43:18
In the strategic decision making process, business intelligence (BI) has become vital to an organization's process. Whether businesses are looking to gauge how their business is performing or to uncover new business opportunities, BI can prove to be of immense benefit. However, many still use legacy BI systems that were built at a time when business needs, volumes of data and technologies were vastly different.
They are critical for businesses to operate, but can be difficult to keep up with the requirements of real-time analytics, cloud applications, and AI-driven insights. However, replacing the entire BI infrastructure can be costly, time consuming and disruptive. For this reason, many organisations are opting for a hybrid model which combines cloud-based systems with legacy systems. Reliability of the proven infrastructure and flexibility with the cloud means businesses can future-proof their BI environment while not sacrificing the value of existing infrastructure investments.
Today, there is a sea of data coming from a wide variety of sources like enterprise apps, customer interactions, connected devices and digital platforms. In such a competitive world, this information needs to be readily available for prompt decision making by businessmen.
Traditional BI systems were primarily used to create historical reports and get ahead of the scheduled dashboards. All these abilities are useful, but today's businesses need a lot more. They need interactive dashboards, predictive analytics, self-service reporting and data analysis on huge volumes of data in real time.
Organizations can fulfill these changing expectations by modernizing BI. It enhances operational efficiency, decision making and helps businesses to adapt to market fluctuations without compromising on the systems that are still critical to their business operations.
Legacy systems are complicated, and carry several years of business data and are frequently employed for mission critical applications. It is not possible to replace these completely in most cases, particularly in the case of large organizations with complex IT infrastructure.
Rather, organizations are taking a hybrid approach to BI, integrating on-premises and cloud-based analytics solutions. This enables businesses to leverage the many capabilities of the cloud, such as elasticity, advanced analytics, and low maintenance, without having to invest in new equipment.
A number of firms are beginning to realize that legacy and cloud platforms can complement each other and not collide. Legacy systems and cloud systems are still used to manage operational workloads, and the cloud systems provide better reporting, analytics and collaboration.
The first step in any successful modernization process is to grasp the existing B-I picture. They should review how their current systems are being utilized and identify the performance issues, with a view to finding the right applications to integrate with the cloud.
This assessment also includes an examination of data sources, data reporting mechanisms, end-user needs and security protocols. Familiarizing oneself with these factors enables businesses to make decisions on modernizing for business value instead of just for the sake of it. With a solid assessment plan, there are fewer risks in implementing assessments and a clear direction for successfully integrating legacy and cloud assessments.
Gradual implementation is one of the best strategies that can be employed to modernize BI. Moving all applications, reports and databases at once can create a complicated and impactful migration process that can cause disruption to business operations.
Phased approach enables organizations to step up modernization gradually. The initial step in a cloud ERP solution is typically starting with cloud reporting and dashboards on top of on-premises transactional systems. Once the teams are more familiar with the new environment, more analytics workloads can be moved based on operational requirements.
This step-by-step approach helps to reduce risk, ease user adoption and give organizations the opportunity to further tailor their modernization path as they go.
Information from various systems, such as enterprise resource planning (ERP), customer relationship management (CRM), financial applications and operational databases, are used by modern businesses. If not integrated, these systems are isolated and form data silos, which hinder visibility and make business intelligence less effective.
The emphasis of a modern BI strategy is on building a data ecosystem that is connected and links data from both the legacy and cloud environments. With the use of API, cloud connectors, and advanced data integration solutions, it is feasible to get data from various sources and ensure consistency and accuracy. These systems are then linked together to present a single source of truth to decision makers which can be accessed from anywhere and from all points of data.
With many platforms becoming integrated within the same organization, having quality data is becoming more and more significant. Poor governance, lack of clarity around definitions, multiple data records and security concerns can diminish trust in business intelligence.
With good data governance, data can be trusted and protected both on premise and in the cloud. Clearly defines the business data's owners, sets common standards and facilitates conforming to industry regulations.
Effective governance also enhances collaboration within the organisation, as everyone has access to the same trusted information. This uniformity helps in making more informed decisions and prevents any miscommunication or confusion between the reports.
When data is to be transferred from one environment to another security is always a big concern. As organisations embark on the modernization journey, they need to make sure that sensitive information is kept safe all along the way.
Current cloud providers feature sophisticated security features, such as encryption, identity and access management, constant checking and conformance certifications. These capabilities, combined with robust internal security policies, provide a secure hybrid IT environment that helps safeguard critical business data.
Organizations can adopt cloud innovation and still have confidence in the security of their data and its confidentiality, integrity and availability with a well-designed security strategy.
The adoption of hybrid business intelligence has been gaining momentum in the wake of digital transformation's rapid pace, as companies look to balance flexibility and adaptability with sustainable growth. The future of AI, automation and real-time analytics will continue to transform the way businesses gather, analyse and utilise information.
Companies that invest in building their hybrid BI foundation now will be able to embrace innovations in the future without having to re-engineer their technology foundation. Therefore, adopting the integration of legacy systems with cloud platforms enables businesses to stay agile without jeopardizing the investments that have been instrumental for them over the years.
Business intelligence is no longer just a technology initiative, it's a business decision. Businesses can leverage better scalability, analytics and data governance capabilities, better decision making and without impacting on critical business operations by integrating legacy systems with cloud platforms.
By carefully combining both, companies are able to keep the advantages of their existing BI investments and enjoy the advantages of the innovations and flexibility of the cloud today. The need for speed, smarter and data-driven decisions is accelerating and will continue to grow – and those organisations that can make it work with modernisation of their BI world will be more competitive and successful in the future of a more digital world.
2026-07-15 05:24:03
When a Google engineer released the
But wait, why a CLI tool, and not an MCP server? MCP is all the rage nowadays — seems like everyone and their dog is shipping MCP servers.
MCP is pretty great. It enables AI agents to surface all kinds of relevant context and take meaningful actions to accomplish your goals.
But the MCP paradigm has real issues. The internet is replete with this refrain in the security department:
But beyond security, MCP has some real fundamental limitations as a paradigm in how it fits into the agentic workflow.
To understand the limitations of MCP as a paradigm for the agent, we have to understand where it fits in within the agent loop.
When a model's CoT decides it wants to make a tool call (including MCP tools), it emits tokens indicating the tool name and the arguments it cooked up for it, e.g., Bash(rm -rf /) or mcp__atlassian__getJiraIssue(…). Permission system notwithstanding, the harness then executes that tool call.
Although these both execute as tool calls, Bash script behavior is runtime-mediated, while MCP call behavior is ultimately model-mediated.
There are two fundamental differences between these two styles of tool calls, you might say at the control plane layer, and then at the data plane layer.
Fundamentally, the intent to make the tool call updateConfluencePage(…) with its specific args is determined entirely by the reasoning step, and fixed on inference return. So one turn / one inference = one tool call.
With a shell available, if the agent needs to call an API a thousand times (e.g., run 1K trials of something with some delay between each), the model can do that easily; it just emits a Bash tool request for:
for i in {0..999}; do
…
done
And if it wants # of iterations determined dynamically by the outcome of some other command, and to manipulate each sub-step's outputs (e.g, parse with jq) and conditional logic, no prob — it's got a Turing-complete runtime environment right within that single tool call.
AI models are really good at this: they frequently emit ad-hoc, multi-line scripts to execute complicated workflows efficiently right within a single turn.
AI agents can't interact with MCP in the same way.
An agent using MCP must execute 1K separate inference turns for the same result, each turn having to stay on track and duplicate input + reasoning + output tokens — bloating latency, context window, and cost by 1K× 💳
While the control plane dictates the intent to take an action (and it being limited to one per turn of inference), the data plane dictates action content, inputs + output.
Let's say you want to tail some logs, search for a term, or read a doc.
head, tail, grep to manipulate the actual output before it lands in their context.
Likewise, on the producer side, let's say you have this workflow:
You're working on a design doc with an agent.
You have it do its work and write it up locally as a .md file for you to review, and for it to make targeted edits with sed or other tools based on feedback.
So every time it wants to edit a section of the doc (e.g., "Fix that typo"), the model doesn't need to re-inference the whole 6KiB doc — very slow, very expensive to essentially tell a model, "Attend to that huge doc in the previous turn, and make this tiny edit" over and over.
The agent pushes it to Confluence/Google Docs.
Others review it and give feedback.
You instruct the agent to make edits and amend it → go to step (2).
With MCP, each time you push (step 3), the agent must:
putDoc MCP toolBut with a CLI, the agent can easily construct commands to refer to file paths on disk if the CLI supports it, or if not, craft it with variable/command substitution:
gws docs documents batchUpdate \
--documentId="…" \
--requests="[
{
…
\"body\": {
\"content\": \"$(cat mylocaldoc.md)\"
}
}
]"
It never has to first pull the contents into the main conversation context and send that to the model just to have it infer a JSON copy of it for the MCP request. Zero tokens are spent on reading the file and inferencing up a JSON MCP request.
It's extremely efficient to iterate quickly while making small, targeted edits and uploading frequently.
The Google Workspace CLI gws is a model example of a CLI that plays well with agents:
gws reflects it instantly.MCP has several advantages over plain CLI tools.
One is the MCP automatically surfaces context upfront to the model about the available tools it ships, and when and how to use them.
which commands to see if a CLI exists, and then --help commands to figure out how to use it, or to search the web for documentation.Much of the discoverability gap of CLI tools can be remediated with the right skills, which instruct the agent when to use them, and only if the model determines they're needed is the whole skill doc pulled into context, where it can teach the model how to use the CLI.
Besides discoverability and instruction, the MCP paradigm has a number of other advantages.
For example, despite MCP's reputation for wildly inconsistent and sometimes insecurely implemented authn/authz paradigms across implementations, it does offer the ability to centralize control over what external systems agents can interact with and what they can do in them.
The
MCP remains extremely beneficial, with a lot of active development going on, and as ecosystems standardize around it, AI agents will get more and more capable.
But it's not the right paradigm for every task. For many workflows, the humble CLI is underrated and much better suited.
When using MCP, every tool call is an inference boundary. If the agent needs to look at N files, filter out certain lines, and update a DB, it must loop N individual turns of text generation. This introduces significant latency, token costs, and a N× chances for hallucination mid-loop.
With a script, the agent acts like an engineer: it writes a Bash/Python script that handles the workflow and data manipulation and curates the model-facing output, and the model doesn’t have to "think" about the raw data mid-loop.
That's why when I need to develop a new connector for my agents to interact with, I often reach for developing a CLI first over an MCP server.
2026-07-15 04:55:35
Eleven pull requests shipped to our main branch last month after being reviewed by an agent. That sounds riskier than it is, and the agentic part isn’t even what I find interesting about it.
The thing I keep coming back to is this. Everyone is wiring AI into code review right now, and they’re all doing it with the same handful of models. Those models are turning into a commodity. They get cheaper and better every few months, and the distance between the best one and the next one down keeps shrinking. If we’re all using more or less the same engine, the engine can’t be what sets any of us apart. What sets you apart is what you feed it: the context, the why behind a change. That part is yours, and it’s the part hardly anyone is bothering to build.
Most AI review reads the diff and stops. A diff can tell you what changed. It can’t tell you why it changed, or what it was meant to do, or whether the clean, passing, well-written code in front of you is even the right code to be writing. We don’t just want to build the thing right, we want to build the right thing. I built the reviewer around that gap rather than around the model, and I think that’s the decision that matters.
The reviewer reads the ticket
Before I get to the reviewer, though, there’s a simpler and slightly embarrassing problem worth naming.
Code review on most teams is two-tier; we just don’t say it out loud.
There’s the pull request someone actually reads. They pull it down, sit with it, and leave real comments. Then there’s the other kind, the “LGTM” nine seconds after it lands, because it’s a version bump or a config tweak and everyone knows it’s fine. That second kind is the majority, and it isn’t really a review. It’s a person spending real, expensive minutes to produce a rubber stamp, over and over, all day, on changes they were never going to block.
We do a lot of that and pretend it counts. It leaves a green checkmark, so it looks like a review happened, but nobody actually looked. And it isn’t free, because it quietly eats the attention the hard reviews need. The engineer who approved fifteen trivial PRs before lunch is the same one who then has to think clearly about the migration that could take production down, and by the time that one lands, a good chunk of the clear thinking is already gone.
So I stopped treating the two as the same thing and split them.
The classifier does one job. It works out how much a change could hurt you, and routes it accordingly.
I built two lanes, not three. There’s no “medium risk” tier, on purpose, because medium risk is where accountability quietly disappears. Everyone assumes someone else has the middle, so nobody does. A change is either safe enough to go on its own or it isn’t, and when I can’t say for sure, it isn’t.
Safe is opt-in rather than assumed. A PR only reaches the automatic lane if every file it touches is on a list I’ve explicitly marked as low blast radius, and the default for anything not on that list is human required. On top of that, there are a few hard gates. Nothing touching auth, billing, or migrations goes through automatically. The diff has to be under a size limit, since a small wrong change is a quick revert, while a large one can eat your afternoon. Every check has to be green. And we lean on feature flags.
That last part matters more than it sounds, because it splits merging and releasing into two separate decisions. The code can land on main by itself while the call to actually turn it on for customers stays with a person, which is where I want it.
The whole thing is deliberately boring. The classifier can only take a human off a change when it can strongly justify doing so, and it never adds risk of its own. The most it can do is decline to spend attention on something that never needed it. The upshot is that nobody starts their morning nodding at a change they barely read. That was the point.
You can’t read intent off a diff.
This is where the bet actually lives.
Put a better model under the reviewer, and it gets a bit sharper at spotting bugs in the lines that changed. That’s genuinely useful, but it’s also the easy part, the part every tool already does, because it’s what the model gives you for nothing. What no model can do on its own is tell you whether the code does the right thing, because the right thing isn’t in the diff. It’s in the ticket someone wrote, the epic it hangs off, the scoping call made three weeks ago about what the feature is even for. None of those ships is in the box. You have to go and get it and wire it in.
So that’s what ours does. Before it reads a single line of code, it pulls the Jira ticket off the branch, the parent epic, the product and technical scoping attached to them, the repo’s own conventions, and whatever comments are already on the PR. Then it reads the diff with all of that in hand.
What I want it to catch is the thing a diff reader structurally can’t: code that works perfectly and solves the wrong problem. The kind that passes every test, gets approved, and turns into a rewrite two weeks later when someone notices it built something the ticket never asked for. No linter finds that, because there’s nothing wrong with the code. The wrongness is in the intent behind it, and you can’t read intent off a diff.
There’s a second thing the context buys that I didn’t expect. Because the reviewer already has all that background, it also knows what not to say. That context is for the reviewer’s benefit, not the author’s, since the author already knows the project. The reviews that actually land are the ones that read everything and then say only the two or three things that matter, and it’s the context that lets them be that short.
I’d rather tell you what the eleven PRs actually did than what I was hoping they’d do.
On correctness, it’s been good. It caught real bugs across those eleven, the kind that slip past CI and a tired skim and come back three weeks later as an incident, and it caught all of them before the code merged. One was on a change to a tool that is itself meant to catch dangerous edits, where it found two holes that would have let bad changes through. That more or less paid for the whole thing on its own.
It also plays well with the other bots, which I didn’t expect to care about as much as I do. We run a couple of other review agents, and on one PR, they’d already flagged the same issue. Rather than pile on and repeat it, ours linked to their threads and went looking for what they’d missed. It read the room. That’s a small thing, but it’s roughly the difference between a reviewer people listen to and one they mute.
And then the part I have to be straight about. The catch I actually built it for, the clean code that quietly does the wrong thing, hasn’t really shown up yet. Eleven PRs and no clear intent mismatch. I’m oddly fine with that, because the likeliest explanation is that people aren’t shipping code that misses the point, which is the outcome I wanted anyway. The day it does catch one is the day the context earns its keep rather than the model. Until then, we keep feeding our corrections back into it, so it gets a little better on the reviews it has already done.
It’s noisy sometimes, too. A couple of junk comments a run, opinions I overrule, nits nobody needed. I don’t mind. A reviewer that never annoys anyone isn’t looking hard enough, and one that’s too loud is a much easier thing to tune down than a quiet one is to wake up. We’re still tuning it, and we will be for a while. That’s the job.
Auto-merge is live for the low-risk lane. The risky work still goes through a person, and it will for a while yet.
The reason I spent the time on this comes down to one belief. The models will keep getting better, and every team gets that upgrade for free, on the same day, from the same vendors. So the model won’t be what separates the teams that pull ahead. What separates them is the slow, unglamorous work of feeding the machine enough to understand not just the code but the reason the code exists. That’s the part almost nobody is doing, and it’s the part I’m betting on.
2026-07-15 04:36:34
In 2021, I graduated with my Master’s degree in Industrial Engineering in Germany and decided to move back to China. During the final year of my degree, I taught myself Python and SQL on DataCamp. I used those skills to pass a data case study and landed my first job at a small SaaS startup in Shanghai. A year later, I moved to an American company, RRD, also in Shanghai.
I worked there from 2022 to 2024. During those two years, I noticed a few undeniable trends in the data and tech industry. Eventually, these trends made me realize I needed to leave. Here is why.
At my job, I used Microsoft Teams and Power BI. However, many of my friends in domestic companies used local Chinese office suites and BI tools.
China has built its own independent software ecosystem. It works perfectly fine for those used to it, but it is completely separate from the global market. Because my skills and habits were rooted in global tools like Power BI, my employment options in China were almost entirely limited to foreign companies. That instantly shrank my job market.
Between 2022 and 2024, the decoupling of global and domestic tech became obvious. Salesforce shut down its direct China operations, and Tableau made similar moves. Many companies were forced to adopt domestic ERP software.
For a Data Analyst, the ERP system is your foundation. Domestic ERPs and SAP run on completely different logics. The same divide is happening with cloud infrastructure—global players like AWS, Azure, and GCP versus domestic Chinese clouds.
I realized I was standing at a crossroads. I had to choose a path: adapt entirely to the Chinese software ecosystem, or stick with the international one. Trying to jump back and forth between the two just means a massive loss of time and high learning costs.
Profit margins for many companies in China are tight. Even in multinational companies, the high-profit departments usually stay abroad, leaving the Chinese branches with strict cost constraints.
For example, we did not have the budget to give everyone a Power BI Pro license. Because of this, a significant part of my job turned into finding cheap workarounds. I had to figure out how to set up local servers for Power BI or build wrappers for Tableau just to save money. Instead of spending my time analyzing data and creating real business value, I was wasting energy trying to bypass budget rules using cheap alternatives.
When the AI boom started, the tools were immediately inaccessible in China. Using them requires extra effort: setting up VPNs, buying virtual foreign phone numbers, and navigating blocks.
On top of that, a $20 monthly subscription for AI tools is expensive relative to local salaries. AI is developing at lightning speed. I didn't want my first step with every new technology to be researching how to secretly bypass regulations just to use it.
Ultimately, I decided to leave China. The choice was half for my career and half for my family.
Today, I am back in Germany, working as a Data Analyst. Looking back, I am happy with my decision. I can focus my time on creating real value, and most importantly, I am staying seamlessly connected to the global tech frontier.
