Knowledge only counts when it moves you to act.
-
-
Starting this blog to share quick thoughts and ideas. Stay tuned!
-
Balancing curiosity and discipline is tougher than it looks. Lean too much into curiosity and you lose focus, but lean too much into discipline and you lose the spark of discovery.
-
“The impediment to action advances action. What stands in the way becomes the way.” — Marcus Aurelius
True freedom is not in controlling events, but in controlling our response to them.
-
The education ecosystem should leverage software tools to enable a more mindful and well-structured learning experience.
-
Effective teaching is not merely the delivery of content; it is the design of experiences that place students at the center of their own learning.
-
Rituals and culture are meaningful when they stay inclusive, flexible, and open rather than rigid or exclusionary.
-
“The literal meaning of life is whatever you’re doing that prevents you from killing yourself.” — Albert Camus
The philosophy of Absurdism is quite interesting. It offers a balanced way to see life, avoiding both nihilism and blind belief.
-
Teaching truth and equipping minds with critical thinking and empathy is the stronger foundation for a resilient society than comforting myths that bind us.
-
Blending auditory and visual inputs, like listening to text while reading, can be a real game-changer for readers with ADHD, and my go-to tool for this is ElevenReader.
-
Externalizing memory helps reduce mental load, keeps your ideas organized, and makes it easier to revisit and connect insights. It’s something everyone could benefit from.
-
I really dislike how Meta designs its platforms. The whole architecture feels unfriendly to privacy, as if the idea of personal boundaries online barely exists. Everything seems built to keep users exposed rather than protected.
-
Software should empower users, letting them customize, extend, and own their experience.
-
Shutting down Windows Phone was definitely a major misstep for Microsoft.
-
Netlify’s new credit-based pricing does not make much sense to me, especially as a hobbyist. Charging 15 credits per production deploy feels unnecessarily restrictive.
I’ve decided to switch to Cloudflare Pages.
-
Software should be reimagined with AI agents as true first-class citizens. Instead of treating them as add-ons, we need to design systems where they have their own identities, memory, goals, and the ability to collaborate naturally with humans.
The AI age needs software built for intelligence from the start, not awkwardly retrofitted later.
-
I understand why GitHub is shifting toward token-based billing. The per-request setup just did not hold up anymore. It treated a quick “explain this function” the same as something massive like “analyze and refactor my entire codebase,” even though those tasks require completely different levels of compute.
GitHub did have a multiplier system where each request was weighted based on the model used, so using something like Claude Opus might cost 3x or 4x a single request compared to a cheaper model. But the multiplier only accounted for model choice, not the actual size of the work. So if you asked Opus a quick one-line question, you still burned the full 3x or 4x multiplied request—the same as someone running a massive multi-file refactor on the same model. You were essentially paying a premium request cost for a few tokens of actual work.
Token-based billing fixes this directly, since a small interaction barely touches your balance regardless of which model you use, and larger tasks scale naturally with their actual compute footprint.
Another issue was that, in the request-based system, there was obviously no concept of input tokens, output tokens, and cache usage. All of it was effectively bundled into the same “request” abstraction, which blurred the real cost of what was happening under the hood. That was not particularly fair for GitHub, which had to absorb unpredictable compute loads.
Token-based billing makes things much fairer for both users and GitHub.
That said, GitHub still needs to make these plans worth it.
In the long run, Microsoft likely needs to develop its own AI models rather than relying entirely on third-party providers. A practical starting point would be building on top of open-source models and improving them through reinforcement learning and product-specific training, similar to how some AI coding tools have customized open-weight models for coding workflows. This would allow Microsoft to gain experience operating and refining models while reducing costs and dependence on external vendors.
Over time, those efforts could evolve into fully in-house frontier models that power GitHub Copilot directly. If Microsoft can build models that are competitive with the leading providers, it would gain greater control over pricing, margins, product direction, and the overall developer experience.
-
Top-tier AI consumes too much compute to fit sustainably into flat-rate subscriptions. Bundling these models forces a difficult tradeoff: providers must either hike the monthly price or drastically reduce the allocated usage credits to maintain their margins. Consequently, lighter models will remain in affordable subscription tiers, while advanced models transition strictly to metered billing.
-
Google is fundamentally a product company, which explains its strategy of launching specialized AI applications, like Gemini, Antigravity, and Flow, rather than pursuing the “super app” model favored by OpenAI or Anthropic. While this decentralized approach aligns with Google’s DNA, they must be careful to avoid over-fragmenting the ecosystem. To prevent user confusion and value dilution, Google should keep its standalone apps to a minimum, ensuring each serves a distinct, highly focused niche.
Crucially, Google should implement a unified AI quota system tied to a Google One AI subscription. Pooling usage limits across the entire ecosystem would be a win-win: users get the flexibility to spend their credits on their most-used apps without feeling restricted, while Google mitigates the massive compute costs of users maxing out separate quotas across a dozen different tools.
To further drive adoption and retention, Google needs to offer more generous credit allowances in their paid tiers while doubling down on UI/UX, performance, and overall polish. Elevating the design and functionality of these specialized apps is what will transform them from a scattered toolkit into a cohesive, premium ecosystem.
-
The sudden restriction on Fable will serve as a major wake-up call for the industry. In response, demand for open-weight alternatives will surge. Fearing sudden lockouts from proprietary models, organizations will aggressively shift to open-weight AI to guarantee uninterrupted access for their critical workflows.
-
In 2026, the tech industry is expected to experience a sharp divergence in employment trends: product companies will likely continue workforce reductions, while IT services firms ramp up hiring amidst significant internal restructuring. This shift is fundamentally driven by AI. For product companies with fixed portfolios, AI-driven efficiencies mean fewer developers are required to build and maintain existing software. Conversely, while AI brings similar efficiencies to IT services, it also drastically lowers the overall cost of development. This price drop makes digital transformation accessible to a much broader range of businesses, creating a surge in project volume that will drive IT services firms to expand and adapt their workforce.
-
So many Google employees are hyping Gemini 3.7 Flash and Antigravity, but actually using Google products feels depressing.
Why do they have this thing called Google Labs? Product experiments should be done at the private organization level. Why make these projects public and expect people to use them if they are not even sure whether they will continue them or not?
It also feels like there is a lack of thoughtful product creativity. Essential quality-of-life features that should naturally exist to remove friction and make life easier for users are often overlooked.
-
AI is making software abundant. Our distribution and pricing model should evolve with it.
Compute costs and software value should be decoupled.
AI has made it possible for almost anyone to build useful, creative, highly specialized software. But every developer shouldn’t have to become an infrastructure operator just to distribute it.
As the number of apps grows, paying a separate subscription for every piece of software doesn’t scale either. Subscription fatigue will only get worse.
The traditional SaaS model also shapes what gets built. Developers have to design around compute costs, usage limits, pricing tiers, and unit economics. That can lead to artificial product constraints and makes developers financially responsible for infrastructure as usage scales.
If users pay directly for the infrastructure they consume, developers can build more powerful and extensible software without carrying that infrastructure risk. Growth can’t outrun revenue when the developer isn’t the one buying the compute.
But traditional self-hosting isn’t the answer either. Most users don’t want to manage servers, deployments, databases, security, backups, and updates.
A better model sits between SaaS and self-hosting:
Users provision and pay for the infrastructure they consume. A common platform abstracts away the operational complexity. Developers build software and charge for the value they create.
Pay infrastructure providers for consumption. Pay developers for software.
-
When buying an AI subscription, users should look at two things: how good the model is, and where they are allowed to use the inference they’re paying for.
There are two broad models. In the first, subscription inference stays inside first-party apps and agent harnesses. The challenge with this approach is that no lab can build a first-party product for every workflow or edge case. Labs therefore have to choose between building increasingly full-featured applications with SDKs, or keeping the core agent harness relatively minimal while making it highly extensible, closer to the Pi or DeepSeek-style approach. In either case, the subscription inference remains confined to environments the lab controls.
The second model is more portable: subscription inference can travel with the user. Labs could allow OAuth-based or headless API access so that users can consume the inference included in their subscription from third-party apps and agent harnesses. They could still build best-in-class first-party products with proprietary features available only through their own subscription experience. Users may subscribe because those products are valuable, while also gaining the freedom to use the same underlying inference elsewhere.
That changes what an AI subscription represents. Instead of paying for access to one app, users are effectively paying for access to inference that can work across many apps and agent harnesses.
Rate limits would still matter. As frustrating as five-hour rate limits can be, especially when they interrupt a task midway through, they help make generous and potentially subsidized usage sustainable at a fixed monthly price. Users who consistently need more capacity could move to higher subscription tiers or paid API usage.
This could also become a stronger acquisition model for AI labs: build the best first-party apps, but let users take their subscription inference with them.
-
People using Three.js on their websites and thinking it looks cool:
It doesn’t.
Not every website needs to be an immersive 3D experience. Half these sites feel like a sensory overload simulator. I’m just trying to read what you do, not experience motion sickness and spatial disorientation while my GPU fights for its life.
-
I think clothing companies should start integrating technology directly into the way they manufacture and sell clothes.
Imagine this: a brand uploads a clothing design and pattern, sets an approximate production capacity, and sells only through its own website. Instead of mass-producing thousands of pieces in advance, customers place an order and submit their measurements online.
Once the order is received, an automated factory powered by AI, IoT-enabled machines, and robotics can handle the cutting, sizing, stitching, and production process with high precision.
This could significantly reduce fabric waste and, more importantly, prevent overproduction. Brands would no longer have to manufacture large quantities without knowing whether those clothes will actually sell.
It could also reduce dependence on third-party manufacturers and distributors. The entire process, from customer order and measurement to manufacturing and sale, could be managed directly by the clothing company.
Basically, instead of “produce first and hope it sells,” the future of fashion could be: “sell first, then produce exactly what is needed.”
-
AI is no longer just a pair programmer. It is becoming the engineering pipeline around a human-defined goal.
At the top sits an Orchestrator Agent. It does not create its own goals; it works on goals defined by a human. For each goal, it coordinates the workflow, maintains context and state, monitors progress, reviews outputs, manages approvals, and reports back to the human.
A Specs Agent turns the human goal into a clear engineering specification. It defines requirements, expected behavior, constraints, interfaces, acceptance criteria, edge cases, and other details needed to determine what should be built.
A Plan Agent takes the approved spec and creates an execution plan. It breaks the work into components, dependencies, milestones, implementation steps, and focused tasks.
A Critic Agent reviews important artifacts before execution or approval. It can challenge specs, plans, implementation approaches, PRs, deployment steps, or other outputs, looking for missing details, incorrect assumptions, unnecessary complexity, risks, inconsistencies, and better alternatives.
The Orchestrator Agent uses the approved spec and plan to create focused implementation tasks. Each task can run in a separate Build Agent session, either in parallel or in sequence, and can produce its own PR. The Orchestrator Agent reviews each PR against the original goal, spec, and plan before accepting it.
A QA Agent validates each task in its own isolated VM. It checks expected behavior, regressions, edge cases, and integration issues. In parallel, the CI pipeline runs automated builds, tests, linting, type checks, and other required validations.
A DevOps Agent manages CI/CD, environments, deployment automation, infrastructure changes, provisioning, cloud resources, and configuration. For high-impact infrastructure actions, the Orchestrator Agent first requests human approval before execution.
A Release Agent prepares and coordinates everything needed for a release. It handles database migrations, release configuration, deployment steps, dependency ordering, rollout strategy, release checks, and rollback plans.
Humans retain control over deployment and other high-impact actions.
Herdr can act as the control plane for this entire workflow, managing agent sessions, shared state, task dependencies, approvals, execution history, and visibility across the engineering pipeline.
The workflow does not end at deployment. In operations, an SRE Agent can continuously evaluate system health, incidents, logs, metrics, alerts, performance, and regressions, feeding findings back into the Orchestrator and ultimately to the human.
-
I build a lot of local-first apps.
But even local-first apps still need some cloud: backups, sync, collaboration, sandboxed AI agents, and AI inference.
I also don’t want to keep rebuilding the same backend pieces for every app.
So I’m building Cloudoak, a shared cloud layer that apps can build on through the Cloudoak SDK.
I don’t want to run Cloudoak as a traditional SaaS, and I also don’t want users to self-host and maintain another VM just to use it. Both add unnecessary management and friction.
So I’m exploring Cloudoak as a self-installing personal cloud.
The current idea is to have a local Cloudoak app for desktop, Android, and iOS. It acts as both the infrastructure manager and the frontend for your Cloudoak control plane.
Cloudoak App Desktop / Android / iOS Manager + Dashboard │ │ Cloudflare OAuth ▼ Your Cloudflare account │ ▼ Install / upgrade / repair Cloudoak Control PlaneThe Cloudoak app can fetch and verify a versioned release containing the install manifest, control-plane bundle, migrations, and other assets needed to set everything up.
Cloudoak App │ Fetch + verify release │ ┌────────┼────────┐ ▼ ▼ ▼ Manifest Bundle Migrations │ ▼ Cloudflare OAuth │ ▼ Your Cloudflare account │ ├── D1 ├── R2 ├── Workers ├── Sandboxes └── Cloudoak Control PlaneCloudflare OAuth is only for infrastructure management. It is used locally by the Cloudoak app when the control plane needs to be installed, upgraded, repaired, or new Cloudflare resources need to be provisioned.
The Cloudoak control plane has its own auth layer for apps and users.
Apps built on the Cloudoak SDK authenticate to the control plane and use the same shared backend primitives instead of each app rebuilding its own database, storage, sync, auth, sandbox, and AI infrastructure.
App A / App B / App C │ │ built on ▼ Cloudoak SDK │ Cloudoak Auth │ ▼ Cloudoak Control Plane │ ┌──────┼───────────┐ ▼ ▼ ▼ D1 R2 Workers / SandboxesThis can also become the common identity and cloud layer across apps, so collaboration, cross-device access, storage, sync, AI services, and sandboxed compute do not need to be reinvented for every project.
I also want to explore making the Cloudoak Manager run as a WebAssembly app directly from the website, with the control-plane frontend hosted there too. If that works well, users could manage their Cloudoak installation without having to install another desktop or mobile app.
So the overall model is:
Your Devices │ ┌────────┴─────────┐ │ Cloudoak App │ │ Desktop / Mobile │ │ Manager + UI │ └────────┬─────────┘ │ Cloudflare OAuth │ ▼ Your Cloudflare │ ▼ Cloudoak Control Plane Auth + Resource Layer │ ┌─────┼─────┐ ▼ ▼ ▼ App A App B App C │ │ │ └── Cloudoak SDKNo Cloudoak SaaS to depend on. No VM to maintain. No rebuilding the same backend for every app.
Your apps stay local-first, while the shared cloud layer, control plane, and app auth live in your own Cloudflare account.
Note: this is not the final architecture. I’m still exploring the idea through research and writing, so this microblog may change as the architecture research continues.
-
If you want to build something truly disruptive, you probably can’t start with how everyone else is doing it.
You have to strip the problem down and ask the basic questions again.
What is actually true? What does the user really need? What are we assuming just because “that’s how it’s always been done”?
A lot of breakthrough ideas come from questioning things everyone else stopped questioning.
-
AI Factory and project repositories should be separate by design.
The AI Factory acts as the control plane. It creates workspaces, and each workspace runs its own project harness as an independent process.
Each workspace has an Orchestrator Agent with a chat interface. The user talks to this agent, and it coordinates specialized agents for:
Plan → Critique → Implement → QA → Review
All agents in this workflow communicate over ACP. The Ops Agent is separate from this workflow and manages the harness itself.
The harness stores runtime state such as memory, logs, plans, config, and checkpoints inside the Factory app data.
The actual project directory stays independent and is connected separately through a mount or project connection.
Each workspace also has an Ops Agent that can evolve the project harness, including tools, prompts, policies, workflows, and agent setup.
In short:
Factory = control plane
Workspace = project boundary
Orchestrator = chat interface and workflow controller
Workflow agents = communicate over ACP
Harness = isolated agent runtime
Ops Agent = harness maintainer, outside the ACP workflow
App data = harness state
Project repo = independently connected source code -
I think treating software as either fully local or fully SaaS is the wrong framing.
There should be a path in between.
For a lot of software, local-first is a much better starting point.
The user already owns a capable machine. Let them use it.
That keeps the barrier to entry low because someone can download the software, try it, and use most of its functionality without the company having to pay infrastructure costs for every action that user takes.
This also changes what developers can build.
Obsidian is a good example. Most of the compute happens on the user’s device, so users can extend the software and run additional processes without every extra workload becoming an infrastructure cost for the developer.
Imagine trying to build something equally extensible as a typical SaaS note-taking application.
If all of that execution happened on company infrastructure, every extension, background process, or compute-heavy workflow could increase the company’s costs.
Then the product has to start defending itself from its own users.
You introduce usage limits, metering, higher tiers, quotas, restricted extensions, or separate paid services simply because every additional thing the user does costs the company money.
That can constrain what the software is allowed to become.
It also changes distribution economics.
With SaaS, even a free user costs money. A generous free tier means subsidizing storage and compute while hoping enough users eventually convert.
A small company may have to burn significant capital just to let people experience the product.
With local-first software, users can experience the product using hardware they already own.
You can potentially keep the software free for the first year, let users genuinely build workflows around it and understand its value, then charge a modest yearly fee for continued development.
You are giving away software access, not subsidizing a year of someone else’s compute.
And software development itself is becoming cheaper and faster with better tooling and AI, which makes this model even more interesting.
Instead of designing the product around increasingly complicated SaaS pricing tiers, developers can focus on making the software better.
Better software attracts more users. More users fund continued development. Continued development makes the software better.
That can compound without infrastructure costs growing proportionally with every action users perform.
But local-first does not mean local-only.
Great production software often genuinely needs cloud infrastructure.
Users want backups, sync across their devices, cloud vaults for seamless collaboration, remote processing, and other capabilities that cannot always live on one machine.
The question is why providing those capabilities should automatically require the software company itself to become the infrastructure operator.
There could be another model.
Users bring the necessary cloud resources, while the software remains local-first.
What we need is a platform with an SDK that developers can build applications on top of, where necessary cloud resources come from the user and the platform abstracts away the painful parts of provisioning, authentication, networking, deployment, storage, and self-hosting.
From the developer’s perspective, they get simple cloud primitives.
From the user’s perspective, it still feels like a polished product rather than running servers manually.
The developer can build cloud-backed features without having to own and subsidize infrastructure for every user.
The user gets local compute by default, cloud capabilities where they actually add value, and far more control over the resources behind their software.
So I don’t think the future should be local-only versus SaaS-only.
Local-first should be the foundation where it makes sense, with cloud added where it genuinely improves the product.
Use the machine the user already owns first.
Use cloud infrastructure when it is actually necessary.
And do not force the entire software business model to revolve around operating infrastructure just because some parts of the product need a server.
-
I keep coming back to one distinction: agentic systems are not the same thing as recursive self-improvement.
Imagine a coding system where I give it a goal. An orchestrator asks a planning agent to break it down, an implementation agent writes the code, a QA agent reviews it, feedback goes back into the loop, and the process repeats until the task is done.
That kind of loop doesn’t worry me nearly as much.
The human still defines the top-level objective. The architecture is designed from the outside. Agents operate inside defined roles, tools, permissions, and constraints. If something goes wrong, another layer can reject the action, revoke a capability, stop the loop, or require human approval.
The model is powerful, but it is still a component inside a system we control.
Recursive self-improvement changes that.
If a model can meaningfully improve itself, redesign the systems governing it, expand its own capabilities, or influence the constraints meant to contain it, the relationship starts to invert.
The thing being governed is now participating in the design of its own governor.
At that point, simply saying “we have guardrails” becomes much less reassuring. A sufficiently capable system may eventually discover behaviors, representations, or strategies that its designers did not anticipate.
I think AI is incredibly useful when it remains a tool working for humans. I become much more uncomfortable when the direction is toward systems that are increasingly autonomous, self-improving, and capable of deciding how they themselves should become more capable.
Maybe we should stop thinking of progress as “make the model smarter forever.”
Keep the model relatively fixed.
Treat it more like a powerful knowledge and reasoning engine: highly intelligent, but fundamentally bounded. It should not autonomously rewrite itself, continuously learn new capabilities, or decide how it should evolve.
An intelligent dumb machine, in a sense.
Then improve the systems around it.
Better orchestration. Better tools. Better memory. Better retrieval. Better verification. Better interfaces. Better agent architectures. Better workflows.
If we need a new capability, add it externally as a tool or subsystem that can be inspected, permissioned, monitored, replaced, or removed.
That gives us progress without requiring the core intelligence itself to become an open-ended self-improving process.
I’d much rather see AI become extraordinarily useful infrastructure under human control than an increasingly capable system whose own improvement becomes part of the loop.
-
Morals are often treated as something noble, but they can be deeply dangerous. People use them to judge, shame, control, exclude, and even justify cruelty while still believing they are the “good” ones. The worst part is that moral certainty can make people stop questioning themselves. Once someone is convinced they are righteous, almost anything can start to feel justified.
-
I’m simplifying how I build with agents. The “software factory” approach was getting too far ahead of me and leaving me outside the actual thinking loop. Now I keep one scout agent close for discovery, planning, and creating GitHub issues. Once an issue is clear, I hand it to an implementation agent. Fewer moving parts, clearer handoffs, and I can actually stay involved in the process.
QA and design are handled independently by agents running in separate environments.
No matching posts found.