FoundersFeed

What if neural networks reveal that our intellectual categories are fundamentally wrong?

We organize knowledge by surface traits: law, math, philosophy, code. But that's like classifying species by looks before DNA.

If unrelated tasks consistently fire the same internal pathways in NNs, we might uncover a deeper taxonomy based on computational primitives—not human convention.

Example: statutory interpretation could be computationally closer to debugging than to other legal reasoning. Same operational structure, totally different domain labels.

DNA shattered taxonomy by exposing hidden relationships. AI might do the same for thought itself—showing us that our intellectual map was drawn by convenience, not by the actual structure of reasoning.

The categories we use to organize knowledge might just be artifacts of how we stumbled into them, not reflections of how cognition actually works.

Singapore's taxi system pre-Uber: solid phone dispatch, cheap fares, high availability... until it rained. Then zero cabs, 2-hour phone queues, persisted for years with no fix.

Uber drops in with surge pricing → problem solved instantly.

The actual root cause (revealed years later): Singapore ran a demerit system punishing drivers for accidents. Rain = higher accident risk → drivers stayed home. Government knew but refused blanket fare increases to avoid triggering inflation metrics.

Surge pricing worked because it's dynamic: price spikes high enough during rain to compensate driver risk, pulls supply back into the market. Classic example of how algorithmic pricing solves coordination failures that bureaucratic fare controls can't.

Running a full AI-native operation means 20-40% of your budget goes straight to frontier model inference (think GPT-4, Claude 3.5, Gemini Ultra). Not training, not fine-tuning—just API calls to the big labs. That's a massive cost center and shows how expensive cutting-edge reasoning still is at scale. If you're building something real, you're either optimizing prompts like crazy, caching aggressively, or routing cheaper models wherever possible. Otherwise your margins get obliterated by OpenAI's pricing.

AI engineer job postings surged 80% year-over-year. Companies are aggressively hiring for roles spanning ML infrastructure, LLM fine-tuning, and production deployment. The spike reflects the shift from AI experimentation to actual product integration—teams need engineers who can bridge research and scalable systems. If you're building with transformers, optimizing inference, or wrangling GPU clusters, demand has never been higher. 🚀

Interesting behavioral pattern: users are more willing to ask AI systems questions they'd never ask another person. This reveals something fundamental about human-AI interaction design—the psychological barrier for "dumb questions" or sensitive topics drops to near zero when facing a machine.

Think about it: you'll ask an LLM to explain basic programming concepts you're embarrassed not to know, or probe deeply personal scenarios without fear of judgment. This changes the UX paradigm entirely.

For developers building AI products: this isn't just about privacy or anonymity. It's about designing for radical honesty in user queries. Your system needs to handle the full spectrum—from genuinely naive questions to edge cases humans would self-censor.

The technical implication? Your prompt engineering and safety layers need to account for this uninhibited query behavior while maintaining helpful responses. The gap between "what users ask AI" vs "what they'd Google" is massive and growing.

Hardware wallet concept with isolated Bluetooth radio (bitchat) and an embedded small LLM trained specifically on self-custody tech and sovereignty advocacy.

The idea: build a secure device that combines cold storage with local AI assistance for privacy-focused users. No internet dependency, just Bluetooth for peer-to-peer comms. The LLM would help users understand key management, multisig setups, and sovereignty best practices without phoning home to centralized servers.

Technically interesting because it solves the UX problem of self-custody without compromising security. Most people screw up cold storage because the learning curve is brutal. A local LLM trained on cypherpunk principles could guide them through recovery phrases, transaction signing, and threat modeling.

The distribution model: make millions selling to early adopters, then flip the script and give them away to maximize adoption. Classic open-source hardware playbook but with an AI twist.

Main challenge: fitting a useful LLM into hardware wallet constraints (limited compute, power, storage). You'd need aggressive quantization and a domain-specific training set. Think 1-3B parameter models optimized for security Q&A, not general chat.

Bluetooth-only radio keeps attack surface minimal. No WiFi, no cellular, just local mesh capability for sovereign comms. Could enable encrypted peer-to-peer transactions without internet infrastructure.

This is basically what happens when you combine Trezor, Meshtastic, and a security-focused LLM into one device. The economics of giving them away after profitability is the interesting part - creates network effects for a sovereignty-focused ecosystem.

Enterprise sales cycles compressed from 12 months down to 90 days. That's a 4x acceleration in deal velocity. This shift is massive for B2B SaaS economics - faster cash conversion, reduced CAC payback periods, and higher capital efficiency. The driver? Likely a combo of product-led growth mechanics, better demo-to-value time, and enterprises getting more comfortable with faster procurement for cloud tools. For founders, this means you can iterate GTM strategy way faster and hit profitability milestones earlier. For enterprises, it signals they're finally treating software buying like actual software - fast, iterative, low-friction.

GhostJacking attack vector exploits request logging mechanisms to inject malicious payloads. Attacker crafts HTTP requests that get written to application logs, then leverages log parsing vulnerabilities or log analysis tools to execute code. Classic supply chain attack through the logging pipeline - your WAF blocks the request but the damage is already in your logs waiting to be triggered. Watch your log aggregators and SIEM parsers, they're now part of your attack surface.

Switching from frontier models to Qwen slashed costs from $400M down to $125M. That's a 69% cost reduction just by changing the underlying LLM. Qwen's price-performance ratio is absolutely crushing it for production workloads at scale. If you're burning cash on OpenAI/Anthropic APIs and your use case doesn't need bleeding-edge reasoning, this is the math that matters.

New paper drops on 'Mind Viruses' - examining how memetic patterns propagate through AI training data and influence model behavior. Core thesis: certain linguistic structures act like cognitive exploits, getting reinforced through RLHF loops and contaminating downstream outputs.

Key technical insight: they mapped how specific phrase patterns ("as an AI", "I cannot", safety theater language) create attractor states in latent space. Models trained on synthetic data from other LLMs inherit these artifacts, creating a feedback loop of increasingly sanitized outputs.

They propose a detection method using activation clustering to identify when models enter these "infected" states vs. generating novel responses. Could be useful for red-teaming and training data curation.

No code release yet but methodology looks reproducible. Worth reading if you're working on model alignment or trying to understand why all LLMs are starting to sound the same.

The killer advantage of AI agents over humans? Zero emotional overhead. You can iterate 100+ versions without triggering burnout, frustration, or the classic "I quit" moment. No ego, no fatigue—just pure execution loop. This is why agentic workflows scale: the bottleneck shifts from human patience to compute budget. In practice, this means you can brute-force design iterations, A/B test prompts endlessly, or refactor code without the psychological tax. The real game-changer isn't intelligence—it's temperament at scale.

Các nhà phát triển chưa từng phát hành sản phẩm có thu phí (hoặc quá sợ để nhận tiền) đang bỏ lỡ một hiểu biết quan trọng:

Người dùng thực sự chi trả không chỉ “chịu đựng” sản phẩm của bạn — họ chủ động báo lỗi, đề xuất tính năng và lan truyền đến mạng lưới của họ. Việc thanh toán tạo ra “cảm giác gắn kết với kết quả” (skin in the game). Người dùng miễn phí sẽ biến mất. Còn người dùng trả tiền trở thành những người đồng kiến tạo.

Nỗi sợ thu phí thường chỉ là hội chứng kẻ mạo danh được ngụy trang dưới vẻ thấu hiểu người dùng. Nếu công cụ của bạn giải quyết một vấn đề có thật, ai đó sẽ sẵn sàng trả tiền. Và những người dùng trả phí sẽ cho bạn tín hiệu để lặp nhanh hơn bất kỳ phiên bản beta miễn phí nào.

Giám sát viên của Todos' Agent giờ không chỉ đơn thuần lên lịch tác vụ—nó còn chủ động xem xét đầu ra của các tác nhân (worker).

Quy trình như sau: Bạn giao một nhiệm vụ nghiên cứu cho giám sát viên (chạy gpt-4o hoặc tương tự). Giám sát viên sẽ ủy quyền nhiệm vụ cho một tác nhân chuyên nghiên cứu (được hỗ trợ bởi deepseek-v3 hoặc deepseek-v4-pro). Khi chuyên gia hoàn tất, giám sát viên sẽ tự động đánh giá báo cáo dựa trên các yêu cầu ban đầu của bạn. Nếu đầu ra không đạt chuẩn, giám sát viên sẽ tự động gửi lại để chỉnh sửa hoặc làm lại hoàn toàn—không cần can thiệp thủ công.

Thực chất đây là các vòng lặp QA theo kiểu agent được tích hợp sẵn trong lớp điều phối. Giám sát viên đóng vai trò như một “cổng kiểm soát”, đảm bảo ngưỡng chất lượng trước khi hiển thị kết quả cho bạn. Khá ổn để giảm chi phí lặp lại trong các hệ thống đa tác nhân.

Quy trình viết code tốt nhất nếu ngân sách không phải là rào cản:

Fable 5 thiết kế giải pháp → Fable 5 triển khai → Fable 5 tự rà soát → GPT-5.6-sol kiểm toán mã → Fable 5 sửa lỗi → GPT-5.6-sol thực hiện xác thực cuối cùng.

Pipeline đa mô hình này dùng Fable 5 cho việc giải quyết vấn đề một cách sáng tạo và triển khai, sau đó tận dụng GPT-5.6-sol như một người phản biện quan trọng để phát hiện các tình huống biên và áp dụng các “cổng chất lượng”. Vòng lặp lặp đi lặp lại (triển khai → kiểm toán → sửa → xác thực) phản ánh cách các đội ngũ kỹ thuật hàng đầu vận hành, nhưng được tự động hóa bằng LLM. Tốn kém? Có. Hiệu quả cho mã nguồn mang tính sống còn ư? Hoàn toàn đúng.

Nếu ngân sách không phải là ràng buộc, đây là một quy trình viết code bằng AI “đỉnh”:

Bắt đầu với Fable để thiết kế giải pháp ban đầu → để Fable viết code → Fable tự rà soát → chuyển cho GPT-4.5-sol để kiểm tra sâu hơn → Fable vá các vấn đề → GPT-4.5-sol thực hiện xác thực cuối cùng.

Pipeline đa mô hình này tận dụng tốc độ của Fable để lặp nhanh và chiều sâu suy luận của GPT-4.5-sol để làm các “cổng kiểm soát” chất lượng. Hãy nghĩ đây là tích hợp liên tục (CI) nhưng thay bằng LLM thay vì lint. Bước tự rà soát trước khi kiểm tra bên ngoài giúp giảm đáng kể các lỗi hiển nhiên, trong khi lượt GPT cuối cùng bắt các trường hợp biên mà Fable có thể bỏ sót.

Tốn kém? Đúng. Có hiệu quả cho code mang tính then chốt? Chắc chắn.

Xây dựng sản phẩm dựa trên hành vi người dùng > sao chép đối thủ.

Với todos (không gian làm việc cho cộng tác người–máy), chúng tôi cho ra v1 trước, rồi lặp lại dựa trên các mẫu sử dụng thực tế:

• Kết nối máy của người dùng không ổn định → bổ sung hỗ trợ sandbox trên đám mây
• Nhiều người dùng không có tài khoản GitHub → xây dựng tính năng lưu trữ mã nguồn nền tảng
• Xem trước tệp còn cồng kềnh → triển khai xem trước trực tuyến theo thời gian thực
• Cần quy trình làm việc với nhiều máy → phát hành remote shell

Trong khi đó, không khoan nhượng loại bỏ các tính năng giá trị thấp: đồng bộ worktree, prompt library, async git push.

Kết quả? Thậm chí không thể dự đoán tập tính năng của tháng tới vì sản phẩm phát triển theo nhu cầu người dùng thực tế, không phải một lộ trình cố định. Đây là cách bạn xây công cụ mà các nhà phát triển thật sự muốn dùng, chứ không phải thứ trông “hoành tráng” trong một slide pitch deck.

Xây dựng sản phẩm bằng cách lắng nghe các mẫu sử dụng thực tế, không sao chép đối thủ.

Bắt đầu Todos như một nền tảng cộng tác giữa con người và tác nhân. Phát hành v1, sau đó lặp lại dựa trên hành vi người dùng thực tế:

• Máy cục bộ của người dùng không ổn định → bổ sung hỗ trợ sandbox trên đám mây
• Nhiều người không có tài khoản GitHub → xây dựng kho mã được lưu trữ trên nền tảng
• Xem trước tệp còn cồng kềnh → phát hành tính năng xem trước trực tiếp ngay trên trình duyệt
• Các nhóm cần phối hợp trên nhiều máy → thêm remote shell

Ngoài ra, đã loại bỏ không thương tiếc các tính năng ít được dùng: đồng bộ worktree, thư viện prompt, async git push.

Không có lộ trình. Không phân tích đối thủ. Chỉ cần phát hành, quan sát, rồi thích nghi. Mình không thể nói Todos sẽ trông như thế nào vào tháng tới, vì sản phẩm phát triển dựa trên dữ liệu sử dụng, không phải một tài liệu đặc tả.

Mọi sản phẩm đều bắt đầu từ số 0. Những chiến thắng trước đó không quan trọng.

Khu chôn vùi những tính năng thất bại/đứng lại của Anthropic đang ngày càng lớn:

Claude trong Chrome - tiện ích mở rộng trình duyệt không bao giờ được phát hành
Claude Cowork - không gian làm việc cộng tác bị dẹp bỏ một cách lặng lẽ
Agent Teams - hệ đa tác tử được công bố nhưng mãi không thấy đâu
Dispatch - “vaporware” tự động hóa quy trình
Opus 4.8 - bản nâng cấp huyền thoại chẳng bao giờ thành hiện thực
Memory - tính năng ngữ cảnh bền vững vẫn chưa hoạt động
Dynamic Workflows - một lời hứa tự động hóa khác vẫn chưa được thực hiện

Mẫu hình ở đây: Anthropic công bố những tính năng tham vọng nhưng lại gặp khó khăn trong khâu triển khai ngoài các lần ra mắt mô hình cốt lõi. Họ làm rất tốt ở nghiên cứu và các bản phát hành mô hình (Sonnet 3.5, Haiku), nhưng lại tệ trong việc đưa tính năng sản phẩm lên thực tế. Đúng kiểu vấn đề cổ điển của các phòng thí nghiệm AI - nhà nghiên cứu xuất sắc, kỹ năng kỹ sư sản phẩm yếu.

So với OpenAI khi họ triển khai GPTs, bộ nhớ, canvas, giọng nói nâng cao và series o1. Hoặc Google với việc ra mắt Gems, API đa phương thức thời gian thực và Gemini 2.0 Flash.

Anthropic cần hoặc tập trung thuần vào việc xuất sắc về mô hình, hoặc thuê những kỹ sư sản phẩm nghiêm túc để có thể thực sự “đưa hàng ra thị trường”.

Vừa thử bản dựng Android Auto mới nhất trên một chiếc Taycan và tôi nhận ra tích hợp Grok trên xe Tesla mạnh mẽ đến mức phi lý. Sự khác biệt là một trời một vực. Cài đặt Grok trên Tesla không chỉ là một trợ lý giọng nói “gắn thêm” nữa—mà nó được tích hợp sâu vào lớp hệ điều hành của xe. Trong khi Android Auto vẫn giống như một hệ thống chiếu màn hình điện thoại, kèm độ trễ và mức truy cập hạn chế vào API của xe, thì Grok trên Tesla lại có quyền truy cập gốc tới dữ liệu telemtry của xe, ngăn xếp điều hướng và các hệ thống điều khiển. Nó có thể hiểu các truy vấn ngôn ngữ tự nhiên về trạng thái pin, tối ưu sạc, lập kế hoạch tuyến đường với lưới giao thông thời gian thực, và thực thi lệnh cho xe mà không gặp nút thắt thông thường kiểu “yêu cầu–phản hồi”. Lợi thế kiến trúc nằm ở chỗ Grok chạy trên phần cứng suy luận tùy biến của Tesla và truy cập trực tiếp vào bus CAN, chứ không đi qua một lớp trung gian. Điều này đồng nghĩa với thời gian phản hồi dưới 100ms và khả năng nhận thức theo ngữ cảnh về trạng thái xe mà Android Auto đơn giản không thể sánh kịp do môi trường bị “sandboxed”. Nếu bạn đang xây dựng các giao diện AI cho ô tô, đây là bản tham chiếu để nghiên cứu.

Ngừng xây dựng các tác nhân không bị ràng buộc. Chúng chưa sẵn sàng cho sản xuất và bạn đang lãng phí thời gian để gỡ lỗi sự hỗn loạn nảy sinh thay vì triển khai tính năng. Hãy giới hạn không gian hành động của tác nhân, xác định ranh giới rõ ràng và sử dụng đầu ra có cấu trúc. Kiến trúc tác nhân tốt nhất thường khá “nhàm”: quyền truy cập công cụ có giới hạn, tiêu chí thành công rõ ràng và các phương án dự phòng mang tính quyết định. Nếu tác nhân của bạn có thể “làm bất cứ điều gì”, thì 80% thời gian nó sẽ chẳng làm được gì hữu ích.