Forem

I Am Back

Alvaro — Sat, 25 Apr 2026 12:52:55 +0000

Hello Everyone, I want to apologize for this hiatus that I had to take as writer of leads horizons. I have delayed most of the posts and ideas I had to share with all of you. I will resume my writing activities next week, so I am looking forward to any feedback you can/what give me. To give some context, the hiatus was to handle my mental health, and make some changes that will help me move toward my goals and personal happiness. I would like to personally thanks my wife for being a great support all this time 🙏. I want to also say thanks to everyone who is subscribed to the newsletter or reads independently in substack for your support. To show my appreciation, I will add a complimentary subscription to everyone. Thanks again for your support & reading this newsletter, Regards, Alvaro

Long-Term Team Productivity

Alvaro — Sat, 25 Apr 2026 12:51:47 +0000

It has been almost a year since McKinsey released their developer productivity approach. While I fully disagree with their ideas, it highlights the ongoing interest of companies in continuously improving per-developer productivity.

Regardless of whether you work within an agile or non-agile framework, most teams seem unable to complete the assigned work for each cycle. This indicates that we are maximizing utilization.

Leads Horizons is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

The Queuing Theory Behind Work

As work is a continuous stream of requests, it typically takes the form of a waiting queue and is governed by its principles. This is why queuing theory helps us understand how tasks accumulate and how delays can propagate through the system. By analyzing the flow of tasks and identifying bottlenecks, we can better manage workloads and improve efficiency.

Here are two formulas that actually drive the entire system:

Kingman's Formula

Kingman's Formula, also known as the VUT equation, is a widely used approximation in queuing theory. It helps estimate the average waiting time in a queue. The formula is given by:

Kingman's Formula highlights the impact of variability and utilization on waiting times. As utilization approaches 100%, waiting times increase dramatically, which is why it's crucial to avoid overloading systems.

Little's Law

Little's Law is a fundamental theorem in queuing theory that relates the average number of items in a queue (L), the average arrival rate of items (λ), and the average time an item spends in the system (W). The law is expressed as:

Little's Law is useful for understanding and managing queues in various contexts, including software development. It implies that to reduce the number of tasks in progress (L), you can either decrease the arrival rate of tasks (λ) or reduce the time tasks spend in the system (W). This principle supports the idea of not overloading development teams and allowing adequate time for tasks to be completed efficiently.

If we combine both formulas, we can have an obvious image of what happens to our system when a 100% utilization is reached and there is even the slightest amount of variability

Effects of +100% Long-Term Utilization

Now that we have clarified, the math being our task management at work. Let’s discuss the effects of long term sustained high utilization. There are many systems that follow the previous principles, allowing us to observe the stress test effects on both human and non-human systems.

For example, when a CPU or any other system is used at 100% for extended periods or overclocked beyond its standard limits, several adverse effects can occur:

Heat Generation: High utilization and overclocking increase the CPU's heat output. Excessive heat can lead to thermal throttling, reducing performance, and in extreme cases, hardware damage.
Reduced Lifespan: Constant high usage or overclocking can shorten the CPU's lifespan. Increased electrical stress and heat degrade the CPU's materials over time.
System Instability: Overclocking can cause crashes, freezes, and unexpected reboots. Even at 100% utilization, a system can become unresponsive if it lacks resources.
Increased Power Consumption: High utilization and overclocking lead to higher power consumption, raising energy costs and stressing the power supply unit (PSU) and cooling systems.
Performance Bottlenecks: Consistent 100% CPU utilization can bottleneck other components like the GPU, RAM, and storage devices, leading to suboptimal performance.
Noise Levels: Higher utilization and overclocking often require more aggressive cooling, increasing noise levels and potentially creating a less comfortable working environment.

Translating this to humans, constant busyness leaves no time for creative thinking or effective problem-solving, leading to burnout, decreased work quality, and overall productivity loss.

Preventing the Effects of High Utilization In Humans

Similar to a CPU, there are ways to mitigate these effects:

Be Strategic About 100% Utilization

Strategic planning for 100% utilization during critical periods can be beneficial but should be done cautiously to avoid long-term negative effects.

Critical Deadlines: Reserve 100% utilization for critical deadlines or important milestones. Ensure the team understands the importance and temporary nature of this increased workload.
Clear Communication: Communicate clearly about the reasons for the increased workload, its expected duration, and available support. Transparency helps manage expectations and reduce stress.
Support Systems: Provide additional support during these periods, such as extra resources, temporary team members, or access to mental health services.

By being strategic about 100% utilization and ensuring adequate cooling-down periods, you can maintain a healthy and productive team, ready to tackle challenges without burning out.

Cooling Down

Allow periods of reduced workload for recovery and creative thinking to maintain long-term productivity and prevent burnout.

Scheduled Breaks: Implement regular breaks throughout the workday. Encourage short breaks to rest and recharge, improving focus and productivity.
Downtime Projects: Allocate time for side projects, learning opportunities, or innovation days. This gives a break from usual tasks and fosters creativity.
Flexible Work Hours: Offer flexible work hours or remote work options to accommodate different working styles and needs, leading to a more balanced and satisfied team.

Monitoring and Feedback

Just as monitoring CPU temperatures and stability is crucial, regularly checking in on your team's workload and well-being is essential. This can involve:

Regular Check-ins: Schedule regular meetings to discuss workload, challenges, and signs of burnout. Encourage open communication and provide a safe space for concerns.
Performance Metrics: Use tools to monitor the team’s performance and workload. Metrics like cycle time, throughput, and work-in-progress (WIP) limits help understand the team’s capacity and adjust workloads accordingly.
Feedback Loops: Establish continuous feedback loops for team input on processes, workload, and job satisfaction. This helps make informed decisions to improve productivity and well-being.

Preventing Bottlenecks

To prevent bottlenecks in your development process, consider these strategies:

Task Prioritization: Prioritize tasks by urgency and importance. Ensure critical tasks are completed first to avoid overwhelming the team with less important work.
Workload Distribution: Distribute tasks evenly among team members to avoid overburdening individuals, which can lead to delays and decreased productivity.
Cross-Training: Encourage cross-training to ensure multiple team members can handle different tasks, reducing dependency on single individuals and allowing for a more flexible team.

Final Thoughts

It's easy to fall into the trap of continuous sprinting and overutilization at work, so recognizing the importance of balance is crucial. Allowing time for cooldown periods, fostering creativity, and ensuring a healthy work environment are essential for long-term success.

Sustainable productivity is about creating an environment where teams can thrive, innovate, and deliver high-quality work consistently. By being strategic and mindful, we can achieve a more productive and satisfied team ready to tackle any challenge.

The Announcement Google Cloud NEXT Made That Will Actually Change How Robots Work

mote — Sat, 25 Apr 2026 12:40:54 +0000

This is a submission for the Google Cloud NEXT Writing Challenge.

Everyone's Fixated on the Wrong Thing

Google Cloud NEXT '26 dropped, and the tech press spent 48 hours writing up the Gemini Enterprise Agent Platform, the Apple partnership, and TPU v8. All deserved coverage. But the announcement that will actually change how robots work in the real world barely made the headlines.

It's called Agent Space.

What Agent Space Actually Is

Agent Space is Google's platform for deploying AI agents that interact with the physical world — not chatbots that answer questions, but agents that maintain persistent state in dynamic environments, process sensor data, and execute feedback-driven task loops. It's Google's answer to a simple question: what if AI agents didn't just live in data centers, but were embedded in the physical world?

This is the embodied AI problem. And it's fundamentally different from the chatbot problem.

Most AI coverage conflates "agent" with "LLM-powered chatbot." They're not the same thing. A chatbot takes text in, produces text out. A robot takes sensor data in, produces action out — and then the world changes based on that action, which feeds back as new sensor input. That's a feedback loop. Chatbots don't have feedback loops. Robots do.

Why the Feedback Loop Changes Everything

Here's what I've learned running AI on physical hardware: the hardest part isn't getting the model to reason. It's keeping a consistent model of the world as the world changes underneath you.

Your robot moved. The map is stale. The arm reached but the object slipped. The gripper force reading is noisy. The last decision was right but the outcome was wrong because the world didn't cooperate.

This is where cloud AI hits a wall. A robot running on cloud inference has latency you can't engineer around. A sensor reading arrives at time T. The query goes to the cloud. Inference runs. The command comes back at T + 150ms. Meanwhile the world moved. The faster the robot, the more useless cloud inference becomes.

You need local state. You need the agent to reason about persistent, structured world models — not raw sensor dumps, but spatial facts, temporal sequences, causal relationships between actions and outcomes. And you need it at the speed of physics.

What Nobody Is Writing About

The Agent Space announcement is getting covered as "Google enters the AI agent platform race." That framing misses the interesting part. Google isn't just building another agent workflow platform — they're building infrastructure for agents that live in the real world.

And if you're building agents that live in the real world, you're going to hit a wall that no amount of model improvement will solve: the data layer.

The models can reason. What they can't do is efficiently store, query, and update structured representations of a changing world at the speed a robot needs. That's not a model problem. That's a database problem.

I've spent two years building in this space. My drone ran cloud inference plus a flat file memory layer for the first six months. Every session felt like the robot was starting from scratch. The moment I moved to a local embedded database with structured schemas — spatial indices, temporal event logs, causal chains between actions and outcomes — the robot stopped repeating failures. Not because it got smarter. Because it finally had memory.

The Real Takeaway

Cloud AI is extraordinary at reasoning about information. Agent Space is Google's acknowledgment that the next frontier is reasoning about the physical world. These are different problems, and they require different infrastructure.

The models will keep getting better. The agents will keep getting more capable. But underneath it all, the robots that actually work in production won't be the ones with the biggest models. They'll be the ones with the best data infrastructure — structured, local, real-time, and built for the speed of the physical world.

Agent Space is Google betting that this matters. I think they're right.

(moteDB is building the storage layer for exactly this — Rust-native, embedded, multimodal. I'm obviously biased, but I also know the problem space. If you're building anything that touches the physical world with AI, I'd want to talk.)

Fairness in Child Safety AI: Why Demographic Parity Audits Are Not Optional

sentinel-safety — Sat, 25 Apr 2026 12:36:48 +0000

There's a particular failure mode in content moderation AI that the industry doesn't talk about enough: the system works, on average, but it works badly for specific groups.

Keyword filters disproportionately flag African-American Vernacular English. Toxicity classifiers flag LGBTQ+ content at higher rates than equivalent heteronormative content. Spam detection penalizes non-native English speakers. These failures are documented, reproducible, and — when they happen in a child safety context — cause serious harm.

If your child safety detection system disproportionately flags minors from certain demographic groups as high-risk, you're not just making mistakes. You're making systematic mistakes that will expose specific communities to greater scrutiny, greater false suspicion, and potentially greater harm from over-moderation. At the same time, you may be under-flagging true positives in other demographic groups — leaving some children less protected.

This is why fairness enforcement in child safety AI is not optional. And it's why we built demographic parity audits as an architectural enforcement mechanism in SENTINEL — not a metric to monitor, but a gate that blocks deployment.

What Fairness Actually Means in Detection Systems

"Fairness" in ML has multiple mathematical definitions that are often in tension with each other. For a detection system, the most relevant concepts are:

Demographic parity (statistical parity): The system flags roughly equal proportions of each demographic group. If 5% of adult users overall are flagged as high-risk, demographic parity requires that roughly 5% of adult users from any given demographic group are also flagged.

Equal opportunity: The true positive rate is equal across groups. If the system correctly identifies 80% of genuine threats in one group, it should identify roughly 80% in all groups.

Equalized odds: Both true positive rate and false positive rate are equal across groups.

These three definitions often conflict. A system that achieves demographic parity may fail equal opportunity (if the base rate of actual threats differs across groups). A system optimized for equal opportunity may produce different false positive rates across groups.

For SENTINEL, we selected demographic parity as the primary fairness gate, with supplementary monitoring of false positive parity. Here's the reasoning:

The false positive risk is the most immediately harmful. A false positive in a child safety context means a user who posed no threat is flagged, their account possibly restricted, and their behavior scrutinized. If false positive rates are higher for, say, Latino users than white users on the same platform, you've built a system that disproportionately harms a specific community. This is a direct civil rights issue.

The base rate problem is real but doesn't justify disparate impact. Some argue that demographic parity is too strict because different groups may have different base rates of predatory behavior. This argument is theoretically interesting and practically dangerous. Predatory behavior is a property of individuals, not groups. Any model that produces group-level predictions is producing biased predictions. Demographic parity is the correct standard.

What Fairness Failures Look Like in Practice

The research on algorithmic fairness in related domains gives us a detailed picture of how these failures happen:

Training data skew. If your training dataset of known grooming patterns was compiled primarily from English-language, North American platform data, your model has seen many examples of how grooming looks in that cultural-linguistic context. It has seen fewer examples of how it looks in other contexts. The result: lower true positive rates (worse recall) for grooming patterns from underrepresented communities, and potentially higher false positive rates as the model over-indexes on surface-level features that happen to correlate with certain communities.

Feature selection bias. If your linguistic signal layer uses n-gram or word embedding features trained on general-purpose English text, those features will not generalize equally across dialects, languages, and communication styles. A detection system trained to flag certain vocabulary patterns will flag non-standard English usage as anomalous — even when it's not anomalous for the users in question.

Label bias. If your training labels (confirmed grooming cases) were generated by a moderation team that itself had biased moderation practices, that bias propagates into the model. Garbage in, garbage out — but specifically, biased garbage in, systematically biased model out.

Feedback loops. A deployed model that produces disparate false positive rates creates its own future training data. More false positive labels from community X mean community X is more represented in the "flagged" training data, which reinforces the bias in the next model version.

How SENTINEL's Fairness Gate Works

SENTINEL implements fairness enforcement as a pre-deployment gate. Before any detection model — or update to an existing model — can be deployed, it must pass a demographic parity audit.

The audit process:

Step 1: Generate a fairness evaluation dataset.

This is a dataset of simulated or synthetic behavioral profiles representing a range of demographic groups, with ground-truth labels (threat / non-threat). The evaluation dataset is separate from the training data. It's designed to represent the demographic diversity of the platform's user base.

SENTINEL ships with a synthetic evaluation dataset. Platforms are encouraged to extend it with platform-specific data that represents their actual user demographics.

Step 2: Run the model against the evaluation dataset.

The model generates risk scores for all profiles in the evaluation set. Scores are recorded along with demographic labels.

Step 3: Compute parity metrics.

For each demographic group represented in the evaluation set, SENTINEL computes:

Flag rate (what percentage of profiles from this group are scored above the threshold)
False positive rate (among profiles labeled non-threat, what percentage are scored above threshold)
True positive rate (among profiles labeled threat, what percentage are scored above threshold)

Step 4: Apply parity thresholds.

SENTINEL's default thresholds: flag rate must be within ±20% of the overall flag rate for any group with sufficient representation. False positive rate must be within ±15% of the overall false positive rate.

These thresholds are configurable by platform. A platform may want stricter thresholds, or may have a different trade-off profile. The defaults are conservative.

Step 5: Gate or pass.

If any demographic group fails the parity threshold, the model cannot be deployed. This is enforced in the platform's model deployment pipeline — not a warning, not a recommendation, a hard block.

A fairness failure produces a detailed report: which group failed, what the actual vs. threshold disparity was, and what the model's overall performance metrics are. This report is included in the audit log.

Why It's Enforced, Not Monitored

An earlier iteration of SENTINEL had fairness metrics as a monitoring dashboard — visible, reported, but not blocking. This turned out to be insufficient.

The problem with monitoring-only approaches is that fairness failures in production are hard to detect and slow to surface. A 15% disparity in false positive rates between demographic groups might not be visible in aggregate moderation metrics. It won't be visible at all if the platform's reporting doesn't disaggregate by demographic group. And even if it's visible, the feedback loop from "we detected a fairness problem" to "we retrained and deployed a fixed model" is measured in weeks or months.

During that time, the biased model is flagging users at disparate rates. Real users are experiencing real harm.

Pre-deployment enforcement changes the dynamic entirely. A model that fails the fairness audit never reaches users. The harm never happens. The feedback loop is closed before deployment, not after.

This is the same logic as testing in software development. You can find bugs in production through monitoring, or you can find bugs before production through testing. Testing is better.

The Contribution Fairness Requirement

SENTINEL's fairness gate applies not just to the core platform, but to any behavioral detection model contributed to the project.

The CONTRIBUTING.md is explicit: any pull request that modifies detection logic must include a fairness analysis. This means contributors need to run the fairness evaluation suite on their modifications and include the results in their PR. PRs that improve detection performance at the cost of fairness parity will not be merged.

This creates a useful forcing function for contributors: if your modification to the linguistic signal layer improves detection accuracy overall but creates a 25% disparity in false positive rates for non-English speakers, you know before you submit the PR. You can iterate on the modification before it gets to review.

The Harder Questions

Demographic parity as a gate answers one question: is the model systematically unfair? But it doesn't answer harder questions that any mature child safety system will eventually confront:

What demographic categories should be measured? Race, ethnicity, gender, age, language, nationality? The choice of demographic categories is itself a value judgment, and not all categories are measurable from platform data. SENTINEL's default evaluation framework includes age (adult/minor), detected language, and account age as proxies. Platform-specific deployments can extend this with additional categories.

What if higher-risk groups produce legitimate base rate differences? This question is often raised as a challenge to demographic parity. Our answer: base rate differences in predatory behavior are not established empirically at the population level. They may be artifacts of over-policing — certain communities are more surveilled, so more of their bad actors are caught, so training data is skewed. Demographic parity is the correct standard precisely because we cannot trust historical label data to accurately represent true base rates.

What about intersectionality? A model might be fair when analyzed by race and fair when analyzed by gender, but systematically unfair for users who are both a particular race and a particular gender. Intersectional fairness analysis is computationally expensive but increasingly recognized as necessary. SENTINEL's roadmap includes intersectional parity analysis as a future enhancement.

Why This Matters for Regulatory Compliance

Both EU DSA and UK Online Safety Act contain non-discrimination provisions. Under the DSA, algorithmic decision systems must be non-discriminatory. Under the Online Safety Act, Ofcom can require platforms to demonstrate that their proactive safety systems do not produce disparate impact.

These provisions are currently underspecified — regulators haven't yet issued detailed technical guidance on what fairness compliance looks like in practice. But the direction of travel is clear.

A platform that can show pre-deployment fairness audits, documented parity metrics, and a hard gate preventing deployment of biased models is in a significantly stronger compliance position than one that monitors disparate impact in production and responds reactively.

The best time to build fairness enforcement is before your platform is large enough to attract regulatory scrutiny. By then, you've already accumulated deployment history, training data, and potentially liability.

Building It Right From the Start

If you're building a new moderation system, or evaluating whether to integrate SENTINEL, the key takeaway is this: fairness enforcement is architecturally much easier when it's built in from the beginning.

Retrofitting demographic parity audits onto an existing system requires:

Auditing training data for demographic representation
Building fairness evaluation datasets you probably don't have
Modifying deployment pipelines to include fairness gates
Retraining models that may have been in production for years

If you start with a fairness-gate-enforced framework, you never accumulate this technical debt. Every model trained on your platform, from day one, has been evaluated for demographic parity. Every deployment decision has been documented.

For child safety specifically, this matters more than in almost any other domain. The population you're protecting — children — is exactly the population least able to advocate for themselves when they're being harmed by algorithmic bias. Building fair systems is an architectural decision, not an aspiration.

SENTINEL's fairness gate and demographic parity audit are open source and fully documented. GitHub: https://github.com/sentinel-safety/SENTINEL. The fairness evaluation framework is documented in CONTRIBUTING.md.

靠2M 的 Via 浏览器，独立开发者如何年入千万？

GokuScraper悟空爬虫 — Sat, 25 Apr 2026 12:36:03 +0000

靠2M 的 Via 浏览器，独立开发者如何年入千万？

大家好，我是彪哥。今天我们深度拆解一下Via 浏览器。

1.Via浏览器怎么火的？

说白了，Via 能火，全靠“同行衬托”。

你看看现在手机里的那些浏览器，一个个胖得跟什么似的。比如百度、360 这些，名义上叫浏览器，

实际上恨不得把新闻、直播、短视频、天气预报全塞进去。你本来只想搜个东西，结果一开屏先给你看五秒广告，

再给你推一堆标题党新闻，这哪是浏览器啊？简直就是“牛皮癣广告大本营”。

Via 走红，就靠这三点：

第一，够瘦。别的浏览器动不动就一两百兆（MB），Via 只有2M多。

第二，够白。进去之后就是一个搜索框，没广告、没新闻、没那些乱七八糟的推送。

第三，好用。谷歌 Chrome 确实好，但在国内用着憋屈啊。没法同步、连不上网，很多功能都成了摆设。

2.开发者是谁？

我们通过网上搜索，可以很容易的去查出来他这个github上发布的仓库。

这是开发者的github主页。

通过他的博客，我们也可以看出来，这个项目应该是在18年甚至更早启动的。

我们通过悟空Github采集器来分析一下这个开发者，

粉丝数408，账号创建于16年，到今天已经十年了，最后活跃时间是24年，已经一年没有上线了。

它的主要的技术战是java，kotlin，主要看来是主要做安卓开发的。

star最多的项目就是他这个Via浏览器，一共有3712个star，同时其他的项目也没有超过200颗星的，第二高的项目也只有129颗星。

他上架应用商店用的公司马甲是上海知为网络科技有限公司，通过相关查询可以发现，

公司法人和他的Github用户名高度重合,看来是他自己开的公司，员工就他一个人，看来确实是一个独立开发者。

3. 为啥“不开源”却有 GitHub 仓库？

如果你去看 tuyafeng/Via 的 README，

第一句话就是：“Via is a simple browser, and this repository is set for localization.”（Via 是一款简单的浏览器，本仓库仅用于本地化/翻译）。

你点开 app/src/main/res 目录，里面全是各种语言的 strings.xml。

开发者（tuyafeng，也就是大名鼎鼎的 Van）很聪明。他虽然不公开浏览器的核心代码，

但他希望 Via 能走向全球。通过在 GitHub 建立一个公开的翻译仓库，全世界的志愿者就能免费帮他把浏览器翻译成俄语、德语、法语等几十种语言。

在commit记录里，我看到一个疯狂提交翻译记录的小伙，

就是这个疯狂刷屏的 solokot ，他不是“维护者”，而是一个“翻译劳模”。

他其实是一个俄罗斯志愿者。可能他觉得 Via 在俄罗斯好用，但翻译不够地道，于是他就成了义务的“俄语区产品经理”。

这种小众工具的海外市场，往往就靠那么几个热心的“带路党”。

他每隔几天更新一下俄语翻译，看起来就像他在维护整个项目一样，其实他只是在修补那些 xml 里的字符。

如果去请专业的翻译公司，几十种语言的维护费用每年也要不少钱。

而且社区翻译的比翻译公司更懂“术语”，更接地气。

开发者只需要定期把这些 strings.xml 抓取下来，塞进他那个闭源的 APK 里打包就行了。核心逻辑稳稳地锁在私有仓库里，谁也看不见。

这种“半开半闭”的模式在很多项目里非常流行：

核心代码闭源（保住饭碗）+ 翻译资源开源（利用群众）= 极低的维护成本 + 极高的全球覆盖率。

所以，那个 tuyafeng/Via 仓库其实就是个“外包翻译部”。

4.收入来源

Via 界面干净得连个开屏广告都没有，那开发者靠什么吃饭？用爱发电吗？

当然不是。

在互联网，只要你卡住了“流量入口”，钱会自动来找你。Via 的赚钱手法非常克制，但极其高效，主要靠下面几个：

第一招：搜索引擎的“暗扣”分成（也就是渠道号）

咱们搞技术的，随便抓个包或者看一眼浏览器地址栏就明白了。你打开 Via，随便用百度搜个词，注意看它跳转后的链接后缀，

里面必定藏着一串代码，比如：from=1022282z。

这就是传说中的“回扣 ID”！在行话里，这叫渠道号（Channel ID），说白了就是 Via 专属的“收款码”。

当你按下搜索的那一瞬间，百度的后台就已经记账了：“噢，这条流量是 Via 给我送过来的。”

只要你后续点了搜索结果里的任何广告，百度就会把赚到的广告费按比例分给 Via 的开发者。

除了百度，Via 列表里内置的其他搜索引擎（比如必应、神马），也全都有类似的专属 ID。你每一次日常搜索，其实都在悄悄帮开发者打工。

第二招：“默认搜索”的竞价排名

不知道老用户记不记得，有一段时间，你刚下载完 Via，它的默认搜索引擎竟然是“搜狗”，你想用百度还得自己进设置里手动切换。

这符合常理吗？

当然不符合。在国内，百度的搜索体验毫无疑问是第一梯队。那为什么开发者非要强推搜狗？

商业逻辑非常简单粗暴：那段时间搜狗给的钱多啊！对于浏览器来说，“默认设置”就是最贵的黄金地段。

大部分小白用户是懒得改设置的，默认是谁就用谁。所以，谁给的点击分成高，或者谁给的买断费多，谁就能坐上“默认引擎”的龙椅。

第三招：隐蔽的赞助商坑位（AI 搜索广告费）

咱们再仔细看看现在的 Via 首页，搜索框底下是不是凭空多出来一个叫“秘塔AI”的玩意儿？

咱们平心而论，用 Via 的用户有几个人会用这个东西？

基本没人用。

那作为一个极其克制、主打极简的独立开发者，为什么要把这个冷门功能塞进寸土寸金的首页？

真相只有一个：人家给足了广告费。现在的 AI 公司都在疯狂烧钱买流量，而 Via 手里握着几百万高密度的极客和年轻用户，这正是 AI 公司最眼馋的精准受众。

放一个链接在那，每个月稳稳收一笔坑位费，何乐而不为？

但是我要总结一下：

他没有做那种恶心的弹窗广告，也没有去偷用户的隐私。他只是老老实实做了一个好用的工具，然后“优雅地”把用户正常搜索产生的流量，卖给了大厂。

这叫站着把钱挣了。

5.有竞品吗？

X 浏览器是 Via 浏览器的直接竞品，同样是一款火爆的轻量级浏览器。

两者各平台下载量、用户体量、核心功能高度相近，安装包甚至比 Via 还要小，仅 2 兆，也由独立开发者个人维护，界面设计更偏现代。

二者商业模式基本一致：依靠标签页生态 + 搜索引擎流量分成变现。

2020 年，X 浏览器曾被优酷起诉，对方索赔 100 万元，最终判决赔偿 20 万元。起诉理由是产品主打强力广告拦截，直接损害了视频平台的广告核心收益。

能被优酷这类巨头针对性起诉索赔，本身就足以证明，轻量小众浏览器的流量规模，早已触及大厂的利益边界。

6.所以Via一年能挣多少？

既然把赚钱的暗线扒出来了，咱们就用大白话硬核推算一下。

我去七麦数据看了一眼，Via 在国内各大安卓应用商店的累计下载量破了 1 亿（没算国外的 Google Play），国内 iOS 下载量在 150 万左右。

工具类 App 的累计下载量往往存在“虚胖”，而且 Via 的用户多是懂技术的老哥，很多不点广告。

所以，我们不能瞎猜，得按照移动端的流量变现公式，做一个“推算”：

目前主流就两种结算赚钱模式：第一种是单次有效点击CPC，用户搜完东西，点击带广告标识的链接，百度就会给渠道商结算佣金，

普通关键词单次点击分成在0.1元到0.8元不等，贷款、医美这类高利润关键词，单价还会更高；

第二种是千次展示CPM，按搜索请求量直接结账，每一千次有效搜索，平台直接给结算固定收益。

总收益 ≈ 活跃用户(MAU) × 日均搜索频次 × 广告点击率(CTR) × 点击单价(CPC) × 365天

咱们不搞那种一个月赚大几百万的虚假忽悠，结合行业里真实的搜索分成单价（一次有效点击大约 0.1 到 0.3 元），

咱们分三个剧本来盘盘这位独立开发者的账本：

保守剧本：一年小几百万

假设留下来的高频搜索月活只有 100 万，而且大家都极度讨厌广告，点击率（CTR）低到只有 1%。每天每个人只搜 2 次，单价按最低的 0.2 元算。

算下来每天的保底搜索佣金大概在 4000 块钱左右。一年下来就是 140 多万。再加上一些导航栏和书签的预设坑位费，一年小几百万是兜底的。

常规剧本：一年大几百万

按照 1 亿的下载基本盘，咱们按 200 万的搜索月活来算。每天搜 3 次，点击率稍微正常点来到 1.5%，单价 0.25 元。算下来每天光是百度的搜索分成就有两万多。加上默认搜索引擎偶尔切换（比如以前默认搜狗，肯定是当时搜狗给的价码高），一年稳定营收大几百万，非常合理。

屌炸天剧本：年入千万以上

如果算上 Via 走向海外市场的底气呢？海外用户默认走的是 Google 搜索，老外那边的广告点击单价（美刀）比国内高得多。再叠加上搜索框下面“秘塔 AI”这种实打实收了费用的赞助坑位。国内外两开花，整体年净利润突破 1000 万以上，也不是很遥远。

7. 总结：给独立开发者的启示

很多干技术的兄弟，一头扎进代码里，总想着搞个颠覆行业的宏大架构，或者天天焦虑怎么去追赶外面那些吹上天的“AI 时代大风口”。

但 Via 浏览器这个案例，恰恰给我们上了一课。

真正的独立和自由，往往不需要多么高深莫测的革命性技术。

它靠的是从“第一性原理”出发，看透大厂的弱点。

大厂的浏览器为了向资本交差，为了财报好看，必须疯狂塞垃圾、搞臃肿；那咱们就反其道而行之，做极致的极简。

核心逻辑就三条：

控制成本到极致： 只有 2M 的包体，几乎不需要什么昂贵的云服务器开销，全在用户本地跑。把翻译这种费力不讨好的活儿巧妙地“开源”给社区志愿者。

克制的商业化： 坚决不去碰大厂的“核心口粮”，不惹官司。只在巨头的生态夹缝里，做一个安静的“流量分发员”，优雅地收一点搜索过路费。

耐得住寂寞： 账号创建十年，十年如一日地维护一个小小的浏览器，不搞花里胡哨的迭代。

很多人在等 AI 时代的大风口，却忘了像 Via 这样，在移动互联网的余晖里，靠一个 2M 的小工具，默默收割了十年的复利。

我是彪哥，如果这篇拆解对你有启发，点个赞或者转发给身边的码农兄弟，咱们下期再接着硬核拆解！

感谢各位朋友捧场！要是觉得内容有有点意思，别客气，点赞、在看、转发，直接安排上！

想以后第一时间看着咱的文章，别忘了点个星标⭐，别到时候找不着了。

行了，今儿就到这儿。

论成败，人生豪迈，我们下期再见！

The Abstraction of Cloud Engineering: How AI Agents Are Redefining Enterprise Architecture

Ali-Funk — Sat, 25 Apr 2026 12:35:39 +0000

Amazon Web Services is accelerating a structural shift in cloud engineering through prompt driven workflows and agent based automation. With platforms like Amazon Bedrock and its expanding architecture guidance, AWS is moving toward a model where production ready environments can be generated with minimal manual configuration.

AWS provides reference architectures, automated deployment patterns, and prescriptive guidance through its architecture center. Its startup platform emphasizes rapid environment creation and scaling.

Real World Evidence:Functionality Over Security

This shift becomes clear when examining how AI generates infrastructure code.

Research cited by Veracode shows that up to 45 percent of AI generated code fails basic security tests and introduces on average 2.74 times more vulnerabilities than human written code.

Security analysis from Styra highlights a consistent pattern in AI generated Infrastructure as Code. Models prioritize immediate usability over secure configuration.

A concrete example appears in Kubernetes environments deployed through Amazon EKS. When prompted to create a working cluster, AI systems tend to:

Expose the Kubernetes API endpoint publicly
Leave network policies undefined
Omit private cluster configuration

In AWS environments, this pattern extends further. AI generated templates frequently:

Assign overly permissive IAM roles
Expose services through security groups open to 0.0.0.0/0
Configure data services without network restrictions

These decisions are not random. A public endpoint and permissive access guarantee immediate functionality without requiring additional setup.

From an execution standpoint, the system works.

From a governance standpoint, it introduces:

External attack surface exposure
Lack of network segmentation
Unauthorized access risk

The AI does not fail. It optimizes for functional output. The failure occurs when no system enforces constraints on that output.

From Infrastructure Execution to Governance

Infrastructure creation is no longer the limiting factor. Infrastructure as Code combined with AI generation has reduced build time from weeks to minutes.

The primary constraint shifts to:

Policy enforcement
Security validation
Cost control
Regulatory compliance

When infrastructure can be generated instantly, misconfigurations scale at the same speed. Overly permissive IAM roles, publicly exposed services, and non compliant architectures can propagate across environments without friction.

The role of the enterprise architect changes accordingly.

Value is no longer defined by the ability to build infrastructure manually.
It is defined by the ability to:

Define enforceable guardrails
Audit generated environments
Validate compliance continuously
Control financial exposure

The New Skill Profile for Technical Talent

Configuration knowledge is no longer a durable advantage. Provisioning compute, networking, and containers is increasingly automated.

The differentiating skills are:

System level reasoning across distributed architectures
Security and compliance evaluation
Integration into existing enterprise systems
Failure mode and risk analysis

Knowing how to deploy a container is not a competitive skill. Understanding how an AI generated system interacts with identity management, data governance, and network boundaries is.

Enterprise Return on Investment: Speed Versus Integration Reality

For startups, AI driven infrastructure generation reduces time to market and initial cost. Teams can deploy faster, iterate faster, and access established architecture patterns immediately.

For large enterprises, the cost structure is different.

The cost is not in generating infrastructure. It is in integrating and governing it:

Alignment with legacy systems
Enforcement of regulatory requirements
Auditability of changes
Long term operational cost management

This is where technical account managers, cloud strategists, and enterprise architects create value. The generated system must align with business constraints.

The Strategic Shift

Cloud infrastructure is becoming a generated output rather than a manually constructed asset.

Control shifts to:

Governance frameworks
Security enforcement
Financial oversight

Organizations that adopt AI generated infrastructure without governance increase the likelihood of security incidents, compliance violations, and uncontrolled cloud costs.

Organizations that implement strong guardrails gain speed while maintaining control.

Sources:

AWS Architecture Center
https://aws.amazon.com/architecture

AWS Startups Portal
https://aws.amazon.com/startups

Amazon Bedrock
https://aws.amazon.com/bedrock

Styra AI Generated Infrastructure Analysis
https://www.styra.com/blog/ai-generated-infrastructure-as-code-the-good-the-bad-and-the-ugly/

Veracode AI Code Vulnerability Research
https://www.svenroth.ai/post/ai-generated-code-vulnerabilities-2-74x-4c9a7

I stopped clicking in Discord. I just tell an AI what to do.

ITTOLOGY — Sat, 25 Apr 2026 12:33:09 +0000

Managing a Discord server is a nightmare of endless clicking.

You create categories. You set up hidden channels. You configure twenty different permission toggles for a single role. And then you do it all over again the next day.

I was tired of it. So I built an AI Discord Agent that lets you manage server actions using natural language.

Meet Execord.

What it actually does

Instead of navigating menus, you just type what you want in plain English.

Most bots require rigid, memorized commands. Execord understands intent and handles the complex API logic for you.

Look at these examples:

/perform create a "Staff" category with 3 private channels inside
/perform create a VIP role and immediately assign it to @John
/perform create a new text channel and post a welcome message inside it

Before executing anything, Execord shows a confirmation step so admins can review the planned actions first. You write the sentence. The AI plans the architecture. You confirm. The bot executes the changes.

Why this is different

There are thousands of Discord bots out there. But most of them still rely on strict /commands with endless parameters.

Execord is an agent, not just a bot.

When you ask it to "give @John the VIP role", it doesn't just crash if it doesn't have the ID. It dynamically looks up John's user data, finds the exact VIP role ID, and then prepares the action for admin confirmation. It handles the context so you don't have to.

How I made it reliable

I built it using Python and the Gemini API.

If you just connect an LLM to Discord, it hallucinates IDs and fails. To fix this, Execord uses a smart two-step pipeline:

Understand & Fetch: The AI reads your prompt and figures out what real-world data it needs (like looking up channel IDs).
Execute: It feeds that real data back into the plan, and prepares and runs the confirmed API calls sequentially using structured JSON.

This means it doesn't guess. It verifies first, then acts.

Try it out

I am currently testing this concept and I am genuinely curious: Would you actually use an AI agent like this to run your community, or do you prefer manual control?

You can try Execord for free here:
Execord Website & Documentation

If you want to follow the project, the public GitHub repo is here:
github.com/ittology/Execord

Let me know your thoughts in the comments!

Cancelé Claude: medí el deterioro de calidad con mis propios benchmarks antes de irme

Juan Torchia — Sat, 25 Apr 2026 12:30:42 +0000

Cancelé Claude: medí el deterioro de calidad con mis propios benchmarks antes de irme

Estaba revisando un PR de mi equipo el martes a la tarde cuando vi el thread de Hacker News. "I cancelled Claude" — 874 puntos, 400+ comentarios, el tipo de conversación que explota porque le pone palabras a algo que mucha gente venía sintiendo pero no había articulado. Lo leí entero. Después cerré la pestaña y abrí mis propios logs.

Tengo registros de Claude Code corriendo contra el mismo conjunto de casos desde marzo. No es un benchmark académico: son los escenarios reales que le tiro en mi flujo de trabajo — refactoring de módulos TypeScript, generación de migraciones SQL, análisis de code paths en mi monorepo en Railway. Si hay deterioro, mis logs lo tienen. Y si no lo tienen, entonces el thread de HN es mayormente ruido emocional.

Spoiler: el deterioro existe. Pero no donde la mayoría se está quejando.

Claude calidad deterioro 2025: qué dicen mis logs vs. qué dice HN

Mi setup de seguimiento es simple. Desde el post sobre Claude Code quality reports vengo corriendo un conjunto fijo de 23 casos de prueba contra Claude Code. Los casos están divididos en tres categorías: razonamiento sobre código existente, generación de código nuevo, y detección de bugs en snippets que yo mismo inyecté con errores conocidos.

Cada corrida queda logueada con timestamp, modelo, tokens usados y un score manual mío del 1 al 5. No es automatizado — lo hago a mano, una vez por semana, lleva 40 minutos. Aburrido pero honesto.

Acá van los números entre marzo y julio 2025:

# Resumen de scoring — Claude Code (Sonnet base)
# Escala: 1-5 por caso, promedio semanal

Semana 2025-03-10:  avg=4.2  casos_fallados=3/23
Semana 2025-04-07:  avg=4.1  casos_fallados=3/23
Semana 2025-05-05:  avg=3.8  casos_fallados=5/23  # Primera caída notable
Semana 2025-06-02:  avg=3.6  casos_fallados=7/23
Semana 2025-06-30:  avg=3.5  casos_fallados=8/23
Semana 2025-07-21:  avg=3.7  casos_fallados=6/23  # Leve rebote

Hay deterioro. Del 4.2 al 3.5 en cuatro meses no es variación estadística — es tendencia. Pero cuando miro qué casos fallaron, la historia se complica.

Dónde empeoró, dónde no, y por qué eso importa más que el promedio

Los 8 casos que fallaron en la semana del 30 de junio: seis son de generación de código nuevo en TypeScript con constraints complejos. Dos son de análisis de code paths con más de tres niveles de indirección. Los 15 que pasaron: razonamiento sobre código existente, detección de bugs conocidos, refactoring de módulos acotados.

Mi tesis antes de abrir los logs era que el deterioro iba a estar en razonamiento complejo. Me equivoqué. Está en generación bajo restricciones múltiples simultáneas. El modelo hace peor cuando le digo "generá un hook que sea compatible con React 18, sin estados locales, que use el contexto X, que no rompa el tipo Y y que sea testeable con vitest". Cinco constraints juntos y la calidad cae notablemente frente a marzo.

Lo que NO empeoró y que nadie en el thread de HN menciona: la detección de bugs. En marzo encontraba 11 de 13 bugs inyectados. En julio encuentra 12. Mejoró levemente, aunque sea un delta pequeño. Tampoco empeoró el razonamiento sobre código que ya existe — que es, irónicamente, el caso de uso más común en mi día a día como Jefe de Desarrollo.

// Ejemplo de caso que EMPEORÓ — generación con múltiples constraints
// Prompt original (resumido):
// "Generá un custom hook TypeScript que:
//  - Sea compatible con React 18 concurrent mode
//  - No use useState ni useReducer (solo useRef para estado mutable)
//  - Consuma el AuthContext sin re-renders innecesarios
//  - Retorne un tipo discriminado (Success | Loading | Error)
//  - Sea testeable sin mock del context"

// Respuesta de marzo: hook funcional, tipos correctos, ref bien usado
// Respuesta de julio: hook funcional PERO tipo de retorno mal discriminado,
// re-render innecesario en el caso de Error, comentario en el código
// sugiere useReducer como alternativa (ignorando el constraint explícito)

// Diferencia concreta: no colapsó, pero ignoró uno de los cinco constraints

Ese patrón de "ignorar uno de los constraints cuando hay cinco o más" lo veo consistente en los casos fallados. No es que el modelo regresó a ser peor en general — es que el manejo de restricciones simultáneas parece haberse degradado.

El gotcha que nadie está midiendo: la regresión de contexto largo

Acá viene la parte que me resultó más incómoda de documentar, y que conecta con lo que ya había visto en el post sobre agentes async y observabilidad.

En mis casos con ventana de contexto larga — conversaciones de más de 15.000 tokens donde el modelo tiene que mantener coherencia con decisiones tomadas al principio — el deterioro es más pronunciado que en el promedio general. En marzo, esos casos tenían un avg de 4.0. En julio, 3.1. Eso es una caída de casi un punto entero en el mismo conjunto de pruebas.

El síntoma específico: el modelo contradice en el turno 12 una decisión que el mismo modelo tomó en el turno 3. No es un error de razonamiento en el momento — es pérdida de coherencia a lo largo de la conversación. Para mi flujo de trabajo con agentes, eso es peor que un error puntual porque es silencioso. El debugging de agentes async ya me había enseñado que los errores silenciosos son los que más duelen. Esto califica.

Lo relaciono también con lo que observé cuando armé el setup de CC-Canary: el proxy LLM-as-a-judge que puse delante del agente empezó a detectar inconsistencias de coherencia con más frecuencia desde mayo. No lo había conectado explícitamente con degradación del modelo hasta ahora.

# Log de CC-Canary — inconsistencias de coherencia detectadas por mes
# (extraído del sistema de alertas, formato simplificado)

grep "coherence_fail" /var/log/canary/2025-*.log | \
  awk '{print substr($1,1,7)}' | sort | uniq -c

# Resultado:
#   12 2025-03
#   14 2025-04
#   19 2025-05
#   31 2025-06
#   28 2025-07  # Leve baja pero sigue alto

Del 12 al 31 en tres meses. Ese número me importa más que cualquier benchmark sintético.

Errores comunes al medir deterioro de LLMs (los que cometí yo también)

Error 1: Comparar contra memoria. "Antes contestaba mejor" es una trampa. La memoria humana optimiza hacia los casos que te impresionaron o frustraron. Sin logs, estás comparando contra una versión idealizada del pasado. Yo caí en esto antes de empezar a registrar sistemáticamente.

Error 2: No controlar el prompt. Si cambiás el prompt entre corridas, no estás midiendo el modelo — estás midiendo tu prompt. Mis 23 casos tienen prompts fijos, en texto plano, guardados en un archivo de texto que no toco entre semanas. Si quiero probar una variante, la agrego como caso nuevo.

Error 3: Confundir fricción de UX con deterioro de calidad. El thread de HN mezcla ambas. Algunos de los reclamos más votados son sobre la UI de Claude.ai — respuestas más cortas, interfaz cambiada, comportamiento del botón de "nueva conversación". Eso no es deterioro del modelo, es cambio de producto. Y es legítimo quejarse, pero son categorías diferentes.

Error 4: Medir solo los casos que te importan a vos. Mis casos de generación TypeScript empeoraron. Mis casos de análisis de seguridad mejoraron levemente (relevante después de lo que vi con el supply chain attack de Bitwarden CLI — empecé a incluir casos de análisis de superficie de confianza). Si solo midiera TypeScript, concluiría deterioro total. Si solo midiera security analysis, concluiría mejora. El promedio heterogéneo es más honesto.

Error 5: No distinguir modelo de temperatura/sampling. Un cambio en los parámetros de sampling puede parecer deterioro de capacidad. No tengo visibilidad sobre eso desde afuera, pero es un confounder real que hay que tener en mente antes de atribuir todo al modelo.

FAQ: Claude calidad deterioro 2025

¿El deterioro de Claude en 2025 es real o es percepción?
Con mis logs: real en generación bajo restricciones múltiples y en coherencia de contexto largo. No real (o ligeramente positivo) en detección de bugs y razonamiento sobre código existente. El deterioro total percibido por el thread de HN mezcla degradación real del modelo con cambios de UX y con el sesgo de que la gente reporta frustraciones, no satisfacciones.

¿Qué tan confiables son mis benchmarks caseros?
Más confiables que la memoria, menos confiables que un setup con jueces automatizados y múltiples evaluadores. El scoring manual 1-5 tiene varianza. Lo que lo hace útil es la consistencia: mismos prompts, mismo evaluador (yo), misma frecuencia. No es ciencia — es ingeniería de campo.

¿Cancelar Claude tiene base empírica o es efecto manada?
Depende del caso de uso. Si trabajás principalmente con generación de código bajo múltiples constraints simultáneos, la degradación que mido es suficientemente pronunciada para replantear. Si trabajás con razonamiento sobre código existente o debugging, mis números no justifican la cancelación. El thread de HN tiene 874 puntos porque capturó una frustración real — pero la razón técnica para cancelar varía por caso de uso.

¿Qué alternativas probaste?
Corrí el mismo conjunto de casos contra GPT-4o en junio como punto de comparación. En generación TypeScript con constraints múltiples, GPT-4o tuvo avg=3.9 contra 3.5 de Claude — diferencia real pero no dramática. En coherencia de contexto largo, GPT-4o tuvo avg=3.4 contra 3.1 de Claude — básicamente parejo. Ninguno ganó con suficiente margen como para que el cambio valga la fricción de migración más el costo de reentrenar mis flujos de trabajo y mis prompts. Esto puede cambiar. Lo sigo midiendo.

¿Los posts anteriores sobre Claude Code quality cambiaron algo en lo que medís?
Sí. Después del post sobre LLMs generando security reports, agregué casos específicos de análisis de seguridad a mi suite. Después del post sobre Agent Vault, agregué casos de razonamiento sobre credenciales y permisos en contexto de agentes. La suite crece. El denominador cambia. Eso hace que las comparaciones históricas sean ligeramente ruidosas — lo reconozco.

¿Vas a cancelar o no?
No por ahora. Pero tengo un umbral definido: si el avg general baja de 3.3 por dos semanas consecutivas, o si las inconsistencias de coherencia en CC-Canary superan 40 eventos por mes durante dos meses seguidos, reevalúo. No lo decido por un thread viral — lo decido por mis propios números.

Lo que haría diferente: no cancelar por instinto, medir antes de moverse

Mi punto es este: el thread de HN tiene razón en que algo cambió. Se equivoca en el diagnóstico colectivo porque mezcla señales reales con ruido de UX, con sesgo de confirmación y con el efecto de que la frustración se viraliza más que la satisfacción.

El deterioro que mido es específico y acotado. Generación bajo constraints múltiples, coherencia en contexto largo. Si esos son los casos que dominan el trabajo de quien canceló, la decisión tiene fundamento empírico. Si cancelaron porque "siento que antes era mejor" o porque la UI cambió, están pagando un costo de migración por una percepción que no midieron.

Lo incómodo de esta conclusión es que le da más trabajo a quien quiere decidir. "¿Me vale la pena cancelar?" no tiene una respuesta global — tiene una respuesta que depende de qué casos de uso dominen el trabajo propio. Y eso requiere medición, no consenso de Hacker News.

Yo sigo con Claude porque mis números no justifican la fricción de moverme. Pero tengo el umbral claro, los logs corriendo y CC-Canary mirando. Si los números cambian, me muevo. Sin drama.

¿Medís la calidad de las respuestas de Claude en producción? ¿Tenés un setup de regresión propio? Me interesa comparar metodologías — especialmente si encontraste deterioro en casos que yo no estoy cubriendo.

Este artículo fue publicado originalmente en juanchi.dev

What a Real Digital Transformation Actually Looks Like for a Mid-Sized Business

Lycore Development — Sat, 25 Apr 2026 12:29:49 +0000

Digital transformation is one of the most overused phrases in business. Consultants use it to sell strategy engagements. Software vendors use it to sell platforms. Conference speakers use it to describe any change involving technology. After enough repetition, it loses meaning entirely.
This is unfortunate, because the underlying idea — using technology to fundamentally change how a business operates, not just automate what it already does — is genuinely valuable. The problem is not the concept. It is the way it gets packaged and sold.
This article is about what a real digital transformation looks like for a mid-sized business: what actually happens, what typically goes wrong, what success looks like, and how to tell the difference between meaningful change and expensive redecorating.

The Difference Between Digitisation and Transformation
Before anything else, it is worth being clear about what transformation is not.
Replacing paper forms with PDF forms is not transformation. Moving from a filing cabinet to a shared drive is not transformation. Building a website for a business that previously had no web presence is not transformation in the meaningful sense.
These are digitisation — making existing processes electronic. They are often worth doing. They are not transformation.
Transformation happens when technology enables a fundamentally different way of doing business — different processes, different capabilities, different competitive positioning — not just a faster or cheaper version of the existing approach.

A manufacturer that replaces paper-based production tracking with a digital system is digitising. A manufacturer that uses real-time production data to dynamically adjust scheduling, predict maintenance needs, and optimise material ordering is transforming — because the technology has enabled something the business could not do before, not just faster execution of what it was already doing.
The distinction matters because the investment, the timeline, and the organisational change required are fundamentally different. Digitisation projects are relatively predictable. Transformation is harder, takes longer, and fails more often — but produces results that cannot be achieved any other way.

What Transformation Actually Requires
The technology is usually the easiest part. This surprises most businesses when they hear it, but it is consistently true.
Building a custom platform, integrating with existing systems, and migrating data is a tractable engineering problem. It has a known solution space, can be planned and estimated with reasonable accuracy, and follows predictable patterns. The hard parts of transformation are consistently the same across businesses and industries.
Process redesign, not process automation. The instinct when digitalising a business process is to replicate the existing process in software. This instinct is almost always wrong. Existing processes were designed around the constraints of their medium — paper, phone calls, manual data entry — and they accumulate workarounds over years of operation. Digitalising a broken or inefficient process produces a faster broken or inefficient process.
Real transformation starts with understanding what the process is trying to achieve, not how it currently works. From that understanding, you redesign — sometimes radically — and then build the technology that supports the redesigned process.

Data readiness. Transformation initiatives that depend on data — which is most of them — fail far more often because of data quality problems than because of technology problems. A business that has been operating on spreadsheets for ten years has ten years of inconsistently formatted, partially duplicated, variably accurate data. Migrating this into a new system without a serious data cleaning exercise produces a new system full of bad data.
Data readiness work is unglamorous, slow, and frequently underestimated in transformation projects. It is also non-negotiable. The businesses that do it properly before building technology produce better outcomes. The businesses that skip it spend months dealing with data quality issues after launch.
Change management. The new system being technically complete and the organisation actually using it are different things. People who have been doing their jobs a particular way for years — sometimes decades — do not automatically adopt new approaches because the technology now supports them. Resistance, workarounds, and reversion to old habits are the default, not the exception.
The businesses that succeed with transformation invest in change management as a first-class activity alongside technology development: clear communication about why the change is happening, involvement of the people affected in the design process, training that is role-specific and practical rather than generic, and visible leadership support that signals the new approach is not optional.

What Success Looks Like, Measured
Transformation that cannot be measured is indistinguishable from expensive change. Every transformation initiative should have a set of specific, measurable outcomes defined before the work starts — not "improved efficiency" but "reduced order processing time from 4 hours to 30 minutes" and "reduced error rate in invoicing from 8% to under 1%."
These measurements serve two purposes. They tell you whether the transformation worked. And they create accountability for the initiative that prevents it from drifting into a technology project that runs forever without delivering business value.
The most common transformation success metrics we see are: reduction in manual processing time (measurable in staff hours per week), reduction in error rates (measurable by type and frequency), improvement in customer-facing metrics (response time, satisfaction scores, churn), reduction in cost of a specific process (measurable per unit), and improvement in decision quality (measured by the quality of the information available to decision-makers).
Choose three to five metrics before you start. Establish baselines. Measure at 30, 60, and 90 days after go-live. Adjust the approach based on what you find.

The Specific Failure Modes Worth Knowing
Transformation initiatives fail in predictable ways. Knowing them in advance does not prevent them entirely, but it does make them easier to catch and correct.
Scope expansion without timeline or budget adjustment. Transformation projects attract scope additions — stakeholders see the opportunity and want their needs included. Every addition that is not matched with timeline and budget adjustment increases risk. The discipline of maintaining a clear boundary around the MVP and managing additions through a structured change process is as important as any technical decision.
Technology selection before process design. The vendor has a compelling platform. The demo looks good. The contract gets signed. Then the business discovers that the platform's assumptions about how the process should work do not match how the business actually needs to work. The sequence should always be: understand the process, design the new approach, then find the technology that fits.
Going live without a parallel run period. Cutting over from an old system to a new one without any period of parallel operation is a high-risk approach. A parallel period — running both systems simultaneously for a defined period — is slower and more expensive but surfaces issues that only become apparent with real data and real users before the consequences are serious.
Underestimating the training requirement. A two-hour training session for a system that people will use eight hours a day is not adequate preparation. Role-specific, practical training that covers not just how the system works but how to handle the edge cases specific to each role is the minimum. Ongoing support in the first weeks after go-live is essential.

Where to Start
For a mid-sized business beginning to think seriously about digital transformation, the most useful starting point is an honest audit of where your current operations are most constrained by technology limitations.
Not where technology is absent — where it is actively constraining what the business can do. The process that everyone knows is broken but nobody has the capacity to fix. The data that exists but cannot be used because it is in the wrong system. The customer experience that is suffering because the internal tools cannot keep up with demand.
That constraint is the right starting point. Not the most ambitious vision of what the business could be, not the most impressive technology available — the specific operational constraint that, if removed, would have the most measurable impact on the business.
For businesses in the marketplace, e-commerce, or platform economy space, read Lycore's guide to maximising business potential with custom-built platforms — the principles of building technology that fits your specific model, rather than conforming to what a generic platform allows, apply across every transformation initiative.

Lycore is a custom software and AI development company with 20 years of engineering experience. We work with mid-sized businesses on digital transformation initiatives — from strategy through to delivery of custom platforms, AI integrations, mobile apps, and web applications. Get in touch.

etcd Is Your Kubernetes Database: What Breaks and What to Watch

NTCTech — Sat, 25 Apr 2026 12:26:50 +0000

etcd is the only component in your Kubernetes control plane that holds state.

Not your API server. Not your scheduler. Not your controller manager. etcd.

If etcd is slow, your cluster is slow. If etcd is inconsistent, your cluster is inconsistent. If etcd fails, your control plane doesn't degrade — it stops.

Most teams don't think about this until the cluster starts behaving in ways they can't explain.

What etcd Actually Does

The API server is stateless. It validates your request, writes desired state to etcd, and returns. The scheduler watches etcd. The controller manager watches etcd. Every pod definition, secret, ConfigMap, lease, and node registration — written to etcd first, read from etcd later.

Kubernetes is a state machine. etcd is the state.

What Breaks (And Why It Doesn't Look Like etcd)

etcd failures don't surface as "database errors." They surface as:

kubectl get pods hanging for seconds
Pods stuck in Pending or Terminating indefinitely
Deployments not rolling, ReplicaSets not scaling
Leader election flapping and log storms across control plane components None of these point at etcd in your dashboard. They look like scheduler bugs, kubelet problems, or network weirdness. The actual cause is one layer below everything you're checking.

The 4 Failure Modes Nobody Monitors

1 — Disk Latency

etcd is disk-bound, not CPU-bound. Every write requires an fsync before it acknowledges. Slow IOPS = slow writes = slow API server = slow cluster. The entire call chain collapses to the speed of your disk.

This is why etcd requires SSD or NVMe. NFS and gp2 EBS will quietly degrade your control plane under load.

2 — Quorum Instability

3-node cluster: needs 2 to agree. 5-node: needs 3. Lose quorum and the cluster goes read-only — no writes, no scheduling, no reconciliation.

Common mistakes: 2-node clusters (zero quorum tolerance), 4-node clusters (same tolerance as 3, more cost), etcd members stretched across high-latency zones. Raft heartbeat timeouts are tuned for <10ms inter-member latency. Exceed that under normal load and you'll see leader elections fire.

3 — Large Object Writes

etcd has a 1.5MB per-value default limit and a 2GB total DB limit (8GB max). Both are reachable.

Usual offenders: CRDs storing runtime state, secrets used as blob storage, ConfigMaps holding multi-MB files. etcd is not an object store. Every oversized write slows the cluster and causes fragmentation.

4 — Compaction and Fragmentation

etcd keeps a history of every key revision. Without compaction, the DB grows unbounded. Without defrag after compaction, the on-disk footprint doesn't shrink.

The pattern: DB grows quietly to several hundred MB, performance softens, nobody connects it to etcd because nothing is explicitly broken. Then a large write event pushes toward the size limit and you have an incident.

The 5 Metrics That Actually Matter

If you're only watching CPU and memory on your control plane nodes, you are not monitoring etcd.

Metric	What It Tells You
`etcd_disk_wal_fsync_duration_seconds`	P99 >10ms = warning. P99 >25ms = problem. Most important etcd metric.
`etcd_server_leader_changes_seen_total`	Should be near zero. Frequent changes = instability.
`etcd_mvcc_db_total_size_in_bytes`	Track growth rate. Growing faster than your cluster = something over-writing.
`etcd_mvcc_db_total_size_in_use_in_bytes`	Large gap vs total size = fragmentation.
`etcd_server_slow_apply_total`	Nonzero and growing = investigate before it becomes an incident.

The Rules

DO:

✅ Dedicated local SSD/NVMe for etcd data directories
✅ 3 or 5 members — always odd, never 2 or 4
✅ Monitor fsync latency as your primary health signal
✅ Automate compaction and defragmentation
✅ Snapshot etcd — treat it like a production database backup DON'T:
❌ Co-locate etcd with noisy high-I/O workloads
❌ Store large payloads in ConfigMaps or Secrets
❌ Ignore fragmentation growth
❌ Assume managed etcd (EKS/GKE/AKS) needs no visibility
❌ Treat etcd as a transparent implementation detail

The Part Most Architectures Skip

Your pods can fail and reschedule. Your nodes can fail and drain. etcd loses quorum and your cluster stops accepting writes — full stop. No automatic recovery, no clever failover, no workload that routes around it.

Most Kubernetes architectures are designed assuming etcd works. Very few are designed for when it doesn't.

Treat etcd like the database it is — because it's the most important one in your cluster.

If etcd is slow, Kubernetes lies to you. If etcd is unavailable, Kubernetes stops. If etcd is corrupted, recovery becomes a rebuild problem — not a restart.

This post is part of the Modern Infrastructure & IaC series at rack2cloud.com. Full post with architecture diagrams and HTML signal cards at rack2cloud.com/etcd-kubernetes-database.

Introducing ExcaliClaw: A Skill for OpenClaw to Generate Excalidraw Diagrams

Nick Taylor — Sat, 25 Apr 2026 12:26:43 +0000

This is a submission for the OpenClaw Writing Challenge

I already use the Excalidraw Model Context Protocol (MCP) remote server in Claude and ChatGPT, but I was curious how it would work in OpenClaw. In Claude and ChatGPT, the MCP renders the diagram inline. I can iterate, see changes in real time, edit directly, and when I am happy, open it in Excalidraw.

OpenClaw does not render the MCP's UI, so the challenge was getting my OpenClaw, McClaw to generate the scene and hand me back a shareable Excalidraw link instead. Also, meet McClaw!

Setting it up was straightforward. I pointed McClaw at the Excalidraw MCP server repository, the readme includes a link to the remote MCP, and asked it to configure itself. The one thing I had to specify was to use streamable HTTP instead of Server Sent Events (SSE) for the MCP transport, since OpenClaw defaults MCPs to SSE (deprecated in the MCP specification in favour of streamable HTTP.

From there I started to use the Excalidraw MCP server. My first test was intentionally tiny: one box that said "hello world." The MCP render worked, but the first Excalidraw share link opened an empty scene. The fix: ask it to export a full native Excalidraw scene payload, not just the MCP streaming element data.

Once I was more specific, it rendered correctly.

From there, I thought everything was fixed so I went with a more complicated diagram. McClaw and I tried a Kubernetes diagram. The boxes rendered, but labels disappeared. A later version had labels, but not the hand-drawn Excalifont. After a few rounds of iteration, McClaw and I landed on a reliable pattern:

Use explicit text elements instead of relying on Excalidraw/MCP label shortcuts.
Put text on top of shapes in the draw order.
Set fontFamily: 1 so text uses Excalidraw's hand-drawn Excalifont.
Include width and height on text elements.
Keep diagram elements large enough to read in chat previews.
Route arrows around labels where possible.
Never return an Excalidraw link unless the exported scene has real elements in it.

You can see the progression in the links generated along the way:

First hello-world export that opened empty: https://excalidraw.com/#json=Fy95JSR14xBx11AcsLanp,5Et8J3TBBTz1Dzof0lfDJQ
Fixed hello-world scene export: https://excalidraw.com/#json=tIZAfHTpxxp6SZyRCyHwz,CrzJ9xkO3jv5IcLpz-tSww
First Kubernetes architecture attempt: https://excalidraw.com/#json=a_pCVfjZVrtJ48nkUrbUg,hma7cx8T6aeRzIkQhnTLvg
Kubernetes attempt with more explicit text, but still not quite right: https://excalidraw.com/#json=UXKfZbYOghzN3r-ivWshq,VhWdX9PT-TVTZyaJ0l2-TQ
Version with explicit text elements and Excalifont: https://excalidraw.com/#json=RWA_hrunvpASHouEksoVV,2kV4_nMbAX2rBpEBQ_ELcQ
Final fresh-run diagram after the skill was tightened up: https://excalidraw.com/#json=QnzIcl0-t3iLLu8DDjZbe,dD5hPUPEn4gBr-SrjOFn_Q

That debugging process turned into a small OpenClaw skill McClaw and I built called excaliclaw.

We iterated some more and it's still a work in progress, but I'm happy with where we landed for this skill.

The skill packages everything McClaw and I worked out from the failed exports, missing labels, font weirdness, and arrow-routing issues. Now when I ask for a diagram, McClaw has a repeatable recipe instead of the two of us rediscovering those edge cases on every run.

Now arrows actually connect boxes instead of jus floating between them, labels for boxes are grouped with the box etc.

Here's an example of the skill in action for a OAuth/OIDC login flow for a web app.

If you want to use it yourself install it from GitHub using npx skills:

npx skills add nickytonline/skills --skill excaliclaw

And coming soon, once rate limiting is sorted, you'll be able to install it via ClawHub:

openclaw skills install excaliclaw

❯ clawhub publish /Users/nicktaylor/dev/oss/skills/excaliclaw --slug excaliclaw --name "Excaliclaw" --version 1.0.0
✖ GitHub API rate limit exceeded — please try again in a few minutes (remaining: 179/180, reset in 37s)
Error: GitHub API rate limit exceeded — please try again in a few minutes (remaining: 179/180, reset in 37s)

MCP gives the assistant access to a specialized tool. The skill captures the practical lessons that make it reliable.

If you want to stay in touch, all my socials are on nickyt.online.

Until the next one!

Quark's Outlines: Python Internal Types

Mike Vincent — Sat, 25 Apr 2026 12:21:23 +0000

Quark’s Outlines: Python Internal Types

Overview, Historical Timeline, Problems & Solutions

An Overview of Python Internal Types

What are Python internal types?

You use Python every day to write programs, but some parts of Python stay hidden. These are called internal types. They work behind the scenes to help your code run. You do not make these objects directly, but Python creates them while it runs your program.

Some internal types include code objects, frame objects, traceback objects, and slice objects. These objects store details about your code, the stack, and how Python handles errors or slices. You can inspect them using built-in tools or system modules.

Python uses internal types to manage execution, errors, and slicing.

type(slice(1, 5, 2))  # <class 'slice'>

This line shows that slice(1, 5, 2) creates a slice object. Python builds this object when you write slicing code.

How does Python use code objects?

A code object is a block of Python instructions. Python creates a code object when you define a function. The code object holds the function's bytecode, argument names, and other parts. It does not know the function's global variables.

You can get a function's code object using the __code__ attribute.

Python stores instructions using code objects.

def greet(name): return f"Hi, {name}"
print(greet.__code__.co_varnames)  # ('name',)

This prints the list of variable names used in the function. Code objects are read-only and do not change after creation.

What are Python frame objects?

A frame object shows the state of Python when it runs a line of code. Each time Python calls a function, it builds a frame. That frame stores the current code object, the local and global variables, and the current line number.

Frames are stacked. When one function calls another, Python adds a new frame on top of the stack.

Python uses frame objects to track function calls.

import inspect
def check(): print(inspect.currentframe().f_code.co_name)
check()  # check

This prints the name of the function running in the current frame. Frames help tools like debuggers and tracers understand what your code is doing.

How does Python use traceback objects?

When your code has an error, Python creates a traceback object. The traceback shows the call stack at the time of the error. Each level of the stack gets one traceback object.

Traceback objects help Python explain where the error came from. The last one in the chain shows the line where the error happened.

Python uses traceback objects to explain errors.

import sys
try: 1 / 0
except: print(sys.exc_info()[2].tb_lineno)  # 2

This prints the line number where the error happened. You can use traceback objects to write logs or format error messages.

What is a Python slice object?

A slice object tells Python how to cut a list or a string. It stores a start, stop, and step value. Python makes a slice object when you use a colon : in brackets.

You can also create one directly using slice(start, stop, step). The values may be numbers or None.

Python uses slice objects to slice sequences.

s = slice(2, 10, 2)
print(range(20)[s])  # range(2, 10, 2)

This prints the values at index 2, 4, 6, and 8. Python reads the slice object and uses it to cut the data.

A Historical Timeline of Python Internal Types

How did Python internal types develop?

Python internal types grew from the need to manage code execution and error handling. These types are not part of daily Python use, but they support every Python program behind the scenes.

People invented stack frames and bytecode

1959 — Stack frame tracking, IBM 1401, made it easier to debug and resume execution.

1970 — Bytecode instructions, Pascal P-code, created a way to compile programs to simple portable steps.

People designed Python’s execution system

1991 — Code and frame types, Python 0.9.0, added code objects and frame objects for functions and the call stack.

2000 — Traceback objects, Python 2.0, exposed tracebacks to help with exception handling and logging.

People improved slice handling

2001 — Slice object support, Python 2.2, added the slice type and allowed extended slicing syntax.

2008 — Full Unicode traceback, Python 3.0, improved traceback readability for all users.

2025 — Internal types frozen, Python core team, made internal object formats stable for tooling.

Problems & Solutions with Python Internal Types

How do Python internal types help your program run?

Python creates internal types to hold bytecode, manage stack frames, store errors, and handle slices. These objects are not part of your script, but they shape how Python works. Each problem shows how an internal type helps solve a task that Python must handle behind the scenes.

Problem: How do you understand what your function does at runtime in Python?

You write a function that behaves strangely. You want to inspect what it does under the hood without changing its code.

Problem: How can you view the internal steps or structure of a function?

Solution: Python stores details in a code object. You can access it using __code__.

Python lets you inspect bytecode and arguments with code objects.

def double(x): return x * 2
print(double.__code__.co_varnames)  # ('x',)

This shows that the function takes one variable named x.

Problem: How do you follow what happens when a program runs in Python?

You call one function, which calls another, and so on. Something breaks, and you want to trace which part of the code is running right now.

Problem: How can you follow the stack of function calls?

Solution: Python builds frame objects to track each function call.

Python lets you view the call stack with frame objects.

import inspect
def trace(): print(inspect.currentframe().f_back.f_code.co_name)
def outer(): trace()
outer()  # outer

This prints the name of the function that called trace.

Problem: How do you locate where an error happened in Python?

You run a block of code and it crashes. You want to know exactly which line caused the crash.

Problem: How can you find the error line programmatically?

Solution: Python creates a traceback object that stores the error location.

Python gives you line numbers from traceback objects.

import sys
try: 1 / 0
except: print(sys.exc_info()[2].tb_lineno)  # 2

This prints the line where the error happened, not where the traceback is printed.

Problem: How do you use a slice with three parts in Python?

You want to extract every third value from a list between two positions. The usual slice a:b is not enough.

Problem: How can you express a slice with a step value?

Solution: Python creates a slice object with start, stop, and step.

Python lets you define steps with slice objects.

items = list(range(10))
s = slice(1, 8, 3)
print(items[s])  # [1, 4, 7]

The slice picks index 1, then 4, then 7.

Problem: How do you log what happened after an error in Python?

You run a function that fails. You want to keep a clean log that includes the path of calls and the code line where it failed.

Problem: How do you log errors with full context?

Solution: Python keeps a chain of traceback objects for the whole stack.

Python lets you trace errors step-by-step with traceback objects.

import sys, traceback
try: 1 / 0
except:
    tb = sys.exc_info()[2]
    while tb:
        print(tb.tb_frame.f_code.co_name, tb.tb_lineno)
        tb = tb.tb_next
# <module> 2

This prints the stack trace with function names and line numbers in order.

Like, Comment, Share, and Subscribe

Did you find this helpful? Let me know by clicking the like button below. I'd love to hear your thoughts in the comments, too! If you want to see more content like this, don't forget to subscribe. Thanks for reading!

Mike Vincent is an American software engineer and app developer from Los Angeles, California. More about Mike Vincent