was exploring VAD (voice activity detection), found a paper that goes further: Voice Activity Projection (Ekstedt & Skantze, KTH)
instead of the present, it predicts who'll be talking over the next 2 seconds, so an agent can see a handoff coming
paper: arxiv.org/abs/2205.09812
it chops the 2 secs into 4 chunks per speaker. 8 yes/no's = 256 possible futures, and the model gives each future a probability. no human labels needed, the recordings already contain what happened next
rebuilt what langgraph does for me from scratch. ~400 lines, no framework.
tool registry, retry logic, cost tracking, context compression, sub-agents, all the stuff the framework does quietly.
if you're using these things and want to see what's under the abstraction, it's small enough to read in one sitting.
github.com/Eniimz/agent-harn…
been building an agent that writes x posts, on langgraph
you set a niche once. it finds a real story in that space, researches it, drafts a post in the voice of accounts you actually read, and waits for you to approve before anything's final.
what's in it:
- tavily search across the niche queries, then a deeper pass on whichever story ranks best
- a research step that pulls out only facts that appear in the source
- 13 posts i like, catalogued as named structures the planner picks from depending on the story
- a critic node that fails linkedin phrasing, moralizing endings, and any claim it can't trace back. loops with feedback, capped at 3 tries
- human approval before it's done. reject with feedback and it re-plans from the top instead of just rewording
- state saved after every node, so a run survives getting killed
- a log of past posts so it stops repeating itself
#buildinpublic #langgraph
would love to hear @FarzaTV thoughts on this
There's always two philosophies to grind i think, one is this one this one you endure pain, focus, push through, get your desired outcome, something i incline towards. The other is someone who's doing for the fun of it and doesn't rely on the outcome but just the process.
spent some time reading agent workflow patterns in claude cookbooks, great stuff to get a mental model on how these workflows of agents work
github.com/anthropics/claude…
Forward Deployed Engineers are basically SWEs who work directly with customers. I was recommending roadmap.sh to a friend and saw it recently added FDE as a dedicated path. The difference i noted was AI engineering , DevOps and communication skills
azaz retweeted
AI has made it easier to write optimized code on day 0, but it is creating a new problem...
Ask an LLM to write some code, and it will often reach for the most "correct" version - caching, batching, async, configurable strategies. Code that looks staff-level from the first commit.
If you keep probing it to optimize further, it will come up with such absurd optimizations that you may not have even heard of.
Most of these optimizations solve a problem you do not have yet. A function handling 50 records a day does not need a connection pool, a retry queue, and a pluggable backend. It needs to work and be readable.
To be honest, we engineers have always over-engineered, but AI has lowered the cost of writing the complex version to nearly zero, so the lazy default (write the simple thing first) no longer feels lazy. It feels like leaving performance on the table.
The result is codebases full of abstractions nobody asked for. Interfaces with a single implementation. Generic configs for cases that will never change. Vector operations and macros no one asked for.
The skill that matters now is not writing optimized code. It is knowing when to stop optimizing. Premature optimization used to be expensive enough that most people avoided it by default. Now it is one prompt away.
Good engineering judgement is about knowing which optimizations the problem in front of you actually needs.
Hope this helps.
How has this happened now, is Jarvis gonna be with you on this 😅
Have spent all of 2026 building something new post-FaZe. Excited to join @ycombinator this summer as I continue on this next chapter.
Ten years ago I was 20, moving out of the FaZe House in New York to our new place in Newport Beach.
This week I turned 30, and I’m feeling the same excitement here in SF that I felt in 2016. Excited to share more soon 🙏🏻
azaz retweeted
So it's been around 4 weeks since I'm working on something crazy and still haven't even marketed it which even attracted a PR from @mvanhorn yesterday
I'm building uWestJS v2.0 a complete platform adapter that brings uWebSockets (one of the fastest HTTP/WS implementations) to NestJS. We're talking 3-4x faster than Express (the benchmarks say itself) while keeping all the NestJS patterns you love. Basically a deep dive into systems level web programming.
What I've shipped so far:
HTTP Platform:
- Hybrid streaming body parser (buffers small bodies, streams large ones)
- Streaming compression (gzip/brotli/deflate) with content negotiation
- Static file serving with ETag, range requests, and conditional GET
- CORS handler with RFC-compliant preflight validation
- Multipart/form-data with streaming file uploads
- Full middleware pipeline (Guards, Pipes, Filters, Interceptors)
WebSocket Platform:
- Room-based broadcasting with efficient message distribution
- Per-message deflate compression
- Automatic backpressure handling (pauses when clients are slow)
- Full NestJS decorator support (@SubscribeMessage, @MessageBody, etc.)
- Lifecycle hooks (onConnection, onDisconnect)
- Exception filters for WebSocket errors
Architecture deep dive:
Memory optimizations:
- Stack-allocated ArrayBuffer handling
- Header caching (parse once, cache forever per request)
- Parsed body caching (parse once, return cached result for subsequent calls)
- Cookie parsing cache (parse on first access, cache the Map)
Streaming strategies:
- Hybrid body parser: 3 modes (awaiting → buffering → streaming)
- Automatic mode switching based on consumption pattern
- Zero-copy streaming where possible (pipe directly to destination)
- Backpressure propagation (pause uWS when Node.js stream is full)
- Streaming compression (compress chunks on-the-fly, no buffering)
Performance patterns:
- Lazy initialization (only parse what you actually use)
- Referential equality for empty bodies (same object reference = zero allocations)
- Efficient room management (Set-based lookups, O(1) operations)
- Message queue for backpressure (buffer messages when client is slow)
- Abort multiplexing (multiple handlers on single uWS abort callback)
Edge case handling:
- Dual rejection mechanism
- Graceful degradation (skip unknown compression encodings)
- Defensive programming (handle non-RFC-compliant headers)
- Race condition prevention
Building this taught me more about core HTTP, WebSockets, and Node.js internals than any tutorial ever could. Every feature required reading specs, understanding edge cases, and making architectural decisions about memory vs speed tradeoffs.
The specs/docs rabbit hole I went down:
- uWebSockets.js documentation - Understanding their zero-copy architecture, backpressure handling, and why they're so fast. Learning about their streaming model and how it differs from Node.js streams.
- RFC 7230 (HTTP/1.1 Message Syntax) - Implementing proper transfer-encoding handling. Did you know chunked MUST be the final encoding? Our implementation handles non-compliant headers gracefully.
- RFC 7231 (HTTP Semantics) - Building CORS preflight validation that actually follows the spec.
- RFC 6265 (HTTP State Management) - Cookie parsing, serialization, and security. Implementing signed cookies, httpOnly flags, and SameSite attributes correctly.
- RFC 1952 (GZIP) & RFC 7932 (Brotli) - For streaming compression. We compress responses on-the-fly without buffering - crucial for large payloads.
- Express.js source code - Spent days understanding their middleware patterns, body parsing, and error handling to maintain API compatibility. Your Express code should just work.
- NestJS docs and adapter contracts - Deep dive into AbstractHttpAdapter, AbstractWsAdapter, ModuleRef, and the entire DI system. Understanding how Guards, Pipes, and Filters get resolved and executed.
- Socket.IO internals - Replicating their room management and broadcasting API. Understanding how they handle namespaces, acknowledgments, and connection lifecycle.
- Busboy documentation - Implementing RFC-compliant multipart/form-data parsing with streaming file uploads and proper backpressure handling.
Launching v2.0 on NPM and publicly soon.
GitHub: github.com/FOSSFORGE/uWestJS
As always, I love this kind of posts by @arpit_bhayani
Every engineer I know has asked this at some point: "How deep should I actually go?" According to me, the decision to go deep down the rabbit hole comes down to two things:
1. curiosity - what genuinely pulls you in
2. career direction - where you want to be in the next 2/3 years, not where the internet says you should be
My honest take: depth works best when it serves at least one of those. Ideally, both.
If something aligns with your career direction, going deep is an obvious win. One simple way to test this is to think in 2/3 year windows and ask yourself: Does understanding this layer actually move me closer to where I want to be?
If you are building web apps, you do not need to master CPU instruction sets. If you are working on databases, B-tree internals matter far more than knowing every Linux kernel detail. Context changes what "deep" really means.
Abstraction layers exist for a reason. They let you build without getting overwhelmed. A frontend engineer who understands HTTP is usually more valuable than one who has memorized TCP packet headers but struggles to ship features.
If something does not align with your career direction, curiosity still matters. Learning out of pure interest is not wasted time. You do it because it optimizes for motivation, long-term learning, and happiness.
What does not make much sense is going deep in areas that serve neither curiosity nor direction - often driven by comparison or fear. So keep checking in with yourself. Ask questions. Course-correct often.
Depth is most powerful when it is intentional.
i have been using obsidian for quite a while for note taking and stuff, using it as a rag is a real good idea, gonna try this out to see if its really good
#rag #llm #ai
LLM Knowledge Bases
Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). The latest LLMs are quite good at it. So:
Data ingest:
I index source documents (articles, papers, repos, datasets, images, etc.) into a raw/ directory, then I use an LLM to incrementally "compile" a wiki, which is just a collection of .md files in a directory structure. The wiki includes summaries of all the data in raw/, backlinks, and then it categorizes data into concepts, writes articles for them, and links them all. To convert web articles into .md files I like to use the Obsidian Web Clipper extension, and then I also use a hotkey to download all the related images to local so that my LLM can easily reference them.
IDE:
I use Obsidian as the IDE "frontend" where I can view the raw data, the the compiled wiki, and the derived visualizations. Important to note that the LLM writes and maintains all of the data of the wiki, I rarely touch it directly. I've played with a few Obsidian plugins to render and view data in other ways (e.g. Marp for slides).
Q&A:
Where things get interesting is that once your wiki is big enough (e.g. mine on some recent research is ~100 articles and ~400K words), you can ask your LLM agent all kinds of complex questions against the wiki, and it will go off, research the answers, etc. I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents and it reads all the important related data fairly easily at this ~small scale.
Output:
Instead of getting answers in text/terminal, I like to have it render markdown files for me, or slide shows (Marp format), or matplotlib images, all of which I then view again in Obsidian. You can imagine many other visual output formats depending on the query. Often, I end up "filing" the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always "add up" in the knowledge base.
Linting:
I've run some LLM "health checks" over the wiki to e.g. find inconsistent data, impute missing data (with web searchers), find interesting connections for new article candidates, etc., to incrementally clean up the wiki and enhance its overall data integrity. The LLMs are quite good at suggesting further questions to ask and look into.
Extra tools:
I find myself developing additional tools to process the data, e.g. I vibe coded a small and naive search engine over the wiki, which I both use directly (in a web ui), but more often I want to hand it off to an LLM via CLI as a tool for larger queries.
Further explorations:
As the repo grows, the natural desire is to also think about synthetic data generation + finetuning to have your LLM "know" the data in its weights instead of just context windows.
TLDR: raw data from a given number of sources is collected, then compiled by an LLM into a .md wiki, then operated on by various CLIs by the LLM to do Q&A and to incrementally enhance the wiki, and all of it viewable in Obsidian. You rarely ever write or edit the wiki manually, it's the domain of the LLM. I think there is room here for an incredible new product instead of a hacky collection of scripts.
azaz retweeted
LLM Knowledge Bases
Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). The latest LLMs are quite good at it. So:
Data ingest:
I index source documents (articles, papers, repos, datasets, images, etc.) into a raw/ directory, then I use an LLM to incrementally "compile" a wiki, which is just a collection of .md files in a directory structure. The wiki includes summaries of all the data in raw/, backlinks, and then it categorizes data into concepts, writes articles for them, and links them all. To convert web articles into .md files I like to use the Obsidian Web Clipper extension, and then I also use a hotkey to download all the related images to local so that my LLM can easily reference them.
IDE:
I use Obsidian as the IDE "frontend" where I can view the raw data, the the compiled wiki, and the derived visualizations. Important to note that the LLM writes and maintains all of the data of the wiki, I rarely touch it directly. I've played with a few Obsidian plugins to render and view data in other ways (e.g. Marp for slides).
Q&A:
Where things get interesting is that once your wiki is big enough (e.g. mine on some recent research is ~100 articles and ~400K words), you can ask your LLM agent all kinds of complex questions against the wiki, and it will go off, research the answers, etc. I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents and it reads all the important related data fairly easily at this ~small scale.
Output:
Instead of getting answers in text/terminal, I like to have it render markdown files for me, or slide shows (Marp format), or matplotlib images, all of which I then view again in Obsidian. You can imagine many other visual output formats depending on the query. Often, I end up "filing" the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always "add up" in the knowledge base.
Linting:
I've run some LLM "health checks" over the wiki to e.g. find inconsistent data, impute missing data (with web searchers), find interesting connections for new article candidates, etc., to incrementally clean up the wiki and enhance its overall data integrity. The LLMs are quite good at suggesting further questions to ask and look into.
Extra tools:
I find myself developing additional tools to process the data, e.g. I vibe coded a small and naive search engine over the wiki, which I both use directly (in a web ui), but more often I want to hand it off to an LLM via CLI as a tool for larger queries.
Further explorations:
As the repo grows, the natural desire is to also think about synthetic data generation + finetuning to have your LLM "know" the data in its weights instead of just context windows.
TLDR: raw data from a given number of sources is collected, then compiled by an LLM into a .md wiki, then operated on by various CLIs by the LLM to do Q&A and to incrementally enhance the wiki, and all of it viewable in Obsidian. You rarely ever write or edit the wiki manually, it's the domain of the LLM. I think there is room here for an incredible new product instead of a hacky collection of scripts.
