Mert 
GitHub’ta her gün yüzlerce yeni proje trending listesine giriyor. Ancak bu projeleri takip etmek, hangilerinin gerçekten önemli olduğunu belirlemek zaman alıcı bir iş. Bu sorunu çözmek için awesome-trending-repos projesini geliştirdim.
GitHub Actions ile otomatik günlük güncellemeler
Proje Nedir?
awesome-trending-repos, GitHub’ın trending sayfasındaki projeleri otomatik olarak takip eden, günlük olarak güncellenen bir liste. Proje her gün gece yarısı UTC’de çalışıyor ve trending reposu analiz edip sonuçları README.md dosyasına yazıyor.
Temel özellikler:
Nasıl Çalışır?
Proje, GitHub Actions kullanarak otomatik olarak çalışıyor. Her gün gece yarısı (UTC) bir workflow tetikleniyor, GitHub trending sayfasını scrape ediyor, verileri analiz ediyor ve sonuçları README.md dosyasına yazıyor.
Veri toplama süreci:
CI/CD pipeline ile otomatik workflow yönetimi
Özellikler
Günlük Otomasyon
GitHub Actions ile her gün otomatik olarak çalışıyor. Manuel hiçbir işlem gerektirmiyor. Sistem her gün gece yarısı UTC’de trending verilerini çekip README.md’yi güncelliyor.
Geçmiş Takibi
Proje, son 7 günün verilerini saklıyor. Bu sayede bir projenin trending listesindeki konumu nasıl değişmiş görebiliyorsunuz. Yeni giren projeler, yükselenler ve düşenler hakkında detaylı bilgi veriliyor.
Dil Bazlı Sıralama
Trending projeleri programlama diline göre kategorize ediyor. JavaScript, Python, TypeScript, Go, Rust gibi popüler dillerdeki projeleri ayrı ayrı takip edebiliyorsunuz.
Görselleştirme
ASCII grafikleri ile projelerin yükselişini ve düşüşünü görsel olarak takip edebiliyorsunuz. Hangi projelerin kaç yıldız aldığını, hangi hızla büyüdüklerini grafiklerden görebiliyorsunuz.
Teknik Detaylar
Proje Node.js ile yazıldı ve ES Modules kullanıyor. GitHub Actions ile otomatikleştirildi ve Octokit library’i ile GitHub API’ye entegre edildi.
Kullanılan teknolojiler:
Sonuç
awesome-trending-repos projesi ile GitHub’taki trending projeleri otomatik olarak takip edebiliyorsunuz. Her gün güncellenen liste ile en yeni ve en popüler projeleri kaçırmıyorsunuz.
Proje hem kişisel kullanım için hem de developer community’si için değerli bir kaynak oluşturuyor. Otomasyon sayesinde zaman kazandırıyor ve trendleri takip etmeyi kolaylaştırıyor.
Bu yazı DevTo-MCP aracılığıyla DEV.to’ya gönderilmiştir.
NVIDIA, sekiz lider AI laboratuvarını bir araya getirerek açık kaynak öncü modelleri geliştirmek üzere Nemotron Koalisyonu’nu kurarak Nemotron 4’ün temelini atıyor.
Teknoloji devleri IBM ve Nvidia, GPU destekli çözümleriyle kurumsal yapay zekada devrim yaratıyor. Nestle testiyle 30 kat hız ve %83 maliyet tasarrufu sağlandığı gösterildi.
Kia, en küçük elektrikli modeli EV2’yi satışa sundu. 26.600 eurodan başlayan fiyatı, 453 km’ye varan menzili ve kompakt SUV yapısıyla model, elektrikli araçlara erişimi kolaylaştırmayı hedefliyor.
Cross-Client AI: How One Conversation Spans Mobile, Web, Desktop, and Smart Glasses with Gemini
GitHub: https://github.com/omanandswami2005/omni-agent-hub-with-gemini-live
Devpost Blog: https://devpost.com/software/omni-speak-anywhere-act-everywhere
The technical story behind Omni’s most unique feature — real-time device orchestration powered by Google Gemini Live API
2. The Inspiration
The idea for Omni was born from pure frustration. I was walking down the street, speaking into my phone’s AI assistant, asking it to write a complex Python script. It generated the code perfectly, but I was on a tiny screen. I couldn’t test it, copy it easily, or run it. I had to email it to myself and open it on my desktop later.
Why should a conversation be trapped on the device that started it? Why couldn’t I tell my phone to open the script on my laptop? That singular question led me to build Omni for the #GeminiLiveAgentChallenge.
3. Session-First Architecture
Traditional AI assistants use a “Client-First” architecture. You log into an app, and that app starts an isolated conversation with the cloud. If you open the same app on your laptop, it’s a completely different conversation.
Omni uses a “Session-First” architecture. The AI session exists independently in the cloud. Devices don’t own the conversation; they subscribe to it. When you speak into your phone, the audio is processed by the Gemini Live API. When the AI responds, it doesn’t just reply to the phone. It broadcasts its response, both audio and structured UI data, to every device currently subscribed to your session.
4. Event Bus Deep Dive
To make this work with near-zero latency, I built a custom Fan-out Pub/Sub Event Bus in backend/app/services/event_bus.py.
When the live WebSocket pipeline (ws_live.py) receives a structured response from Gemini, it publishes it:
class EventBus:
"""Per-user fan-out event distribution with bounded queues."""
def __init__(self, queue_maxsize: int = _DEFAULT_QUEUE_MAXSIZE) -> None:
# { user_id: set[asyncio.Queue] }
self._subscribers: dict[str, set[asyncio.Queue[str]]] = {}
self._queue_maxsize = queue_maxsize
Every connected client (Web Dashboard, Desktop App, Mobile PWA) subscribes to this bus. The challenge was deduplication. If your phone sends a command, and the AI renders a chart, you want the chart on your desktop monitor, but you might not want the phone to waste resources rendering the exact same heavy chart if it’s already playing the audio. Omni uses an origin_conn ID injected into the event payload so clients can filter or adapt their rendering logic based on whether they initiated the action.
5. Cross-Device Orchestration (Layer 3)
The magic happens in the Device Controller agent (backend/app/agents/cross_client_agent.py). This agent acts as a proxy for physical hardware actions.
Let’s walk through a real scenario: “Take a screenshot on my desktop.”
transfer_to_agent to hand off to the Device Controller.send_to_desktop tool in its registry. It fires the command over the WebSocket to the connected Desktop Client.CROSS_CLIENT_INSTRUCTION = (
"You are the Device Controller agent. You route actions to the user's REAL connected devices "
"(desktop tray app, Chrome extension, web dashboard).nn"
"## Your Toolsn"
"- send_to_desktop: Send an action to the user's desktop tray app (e.g. open_app, type_text, capture_screen).n"
)
6. Client Deep Dives
Building the clients was an exercise in distinct technologies communicating over a shared protocol.
qasync to integrate asyncio WebSockets. It acts as the physical actuator, executing shell commands or capturing the screen. 7. Mic Floor Management
When multiple devices are connected to a single audio stream, chaos ensues if two devices try to transmit at once. I implemented a Mic Floor State Machine in backend/app/api/ws_live.py.
The system has three states:
When your phone starts streaming audio, it requests the floor. The backend grants it and broadcasts a LISTEN_ONLY event to your Desktop and Web Dashboard. They immediately disable local microphone capture until the phone releases the floor or an auto-timeout occurs.
8. Memory Layer
Context isn’t just about the current session; it’s about history. Omni uses a dedicated Memory Service interacting with Firestore. When a session ends, or when explicitly commanded, the AI extracts key facts (“User prefers Python over Java”, “User works in finance”) and stores them in the Knowledge Bank. When you start a new session on a different device tomorrow, those facts are injected into the Root Router’s context prompt, ensuring continuity across time and hardware.
9. Tech Stack Summary
10. Try It
Experience the seamless cross-client orchestration yourself:
11. What’s Next for Cross-Client
The immediate next step is expanding the capability registry. I want the Desktop Client to automatically expose installed applications (like VS Code or Docker) as T3 tools to the AI without manual configuration. Furthermore, I’m working on deeper integration with the Chrome Extension to allow the AI to actively scroll and click on elements based on voice commands from a completely different device.
This blog post was created for the purposes of entering the Gemini Live Agent Challenge Hackathon hosted on Devpost. #GeminiLiveAgentChallenge
Deep Dive into the Technical Challenges
Building a truly synchronized multi-client system surfaced unique synchronization issues. For example, if a user speaks into their mobile phone, the phone captures the PCM audio and streams it to the FastAPI backend. The backend forwards this to Vertex AI. Vertex AI processes it and returns both an audio response and structured JSON data representing the UI state.
The backend must stream the audio back to the mobile phone for playback, while simultaneously broadcasting the structured JSON UI data to all connected clients (like the desktop web dashboard) via the Event Bus. If the Event Bus is too slow, the user hears the audio response before seeing the UI update. If the audio buffer is mismanaged, the speech stutters. Balancing the asyncio.gather tasks in ws_live.py was paramount to achieving the seamless “Omni” experience.
Furthermore, integrating the TaskArchitect required careful schema definitions. When a user asks a complex question like “Research top AI stocks, execute a python script to calculate their P/E ratio, and graph the results”, the Root Agent must recognize the complexity, avoid calling a simple tool, and hand off to the TaskArchitect. The TaskArchitect then generates a Directed Acyclic Graph (DAG) of tasks, executing them sequentially or in parallel, while publishing progress updates to the Event Bus so the React frontend can render a live progress bar.
This project demonstrated the immense power of the Google Gemini Live API when paired with a robust, event-driven, multi-modal backend.
Further Architectural Considerations
The design of the PluginRegistry was another significant hurdle. In a multi-agent system, providing every agent with every tool schema consumes massive amounts of the context window. By implementing a lazy-loading mechanism, the Root Router only sees a ToolSummary. When it decides a tool is necessary, it requests the full ToolSchema from the registry. This drastically reduces token usage and latency.
The Device Controller (Layer 3) handles the physical cross-device execution. When the desktop client connects to the WebSocket, it advertises its local capabilities (e.g., take_screenshot, open_application). The backend dynamically registers these as T3 proxy tools. If the user commands their phone to “Take a screenshot on my desktop”, the Root Router delegates to the Device Controller, which invokes the take_screenshot proxy tool. The backend forwards this command over the WebSocket to the PyQt6 desktop client, which executes the local OS command using PyAutoGUI or mss, captures the screen, and sends the image data back to the backend. The backend then injects this image into the Gemini Live session, allowing the AI to analyze the desktop screen entirely via a voice command originating from the phone. This is the true power of Omni.
Deep Dive into the Technical Challenges
Building a truly synchronized multi-client system surfaced unique synchronization issues. For example, if a user speaks into their mobile phone, the phone captures the PCM audio and streams it to the FastAPI backend. The backend forwards this to Vertex AI. Vertex AI processes it and returns both an audio response and structured JSON data representing the UI state.
The backend must stream the audio back to the mobile phone for playback, while simultaneously broadcasting the structured JSON UI data to all connected clients (like the desktop web dashboard) via the Event Bus. If the Event Bus is too slow, the user hears the audio response before seeing the UI update. If the audio buffer is mismanaged, the speech stutters. Balancing the asyncio.gather tasks in ws_live.py was paramount to achieving the seamless “Omni” experience.
Furthermore, integrating the TaskArchitect required careful schema definitions. When a user asks a complex question like “Research top AI stocks, execute a python script to calculate their P/E ratio, and graph the results”, the Root Agent must recognize the complexity, avoid calling a simple tool, and hand off to the TaskArchitect. The TaskArchitect then generates a Directed Acyclic Graph (DAG) of tasks, executing them sequentially or in parallel, while publishing progress updates to the Event Bus so the React frontend can render a live progress bar.
This project demonstrated the immense power of the Google Gemini Live API when paired with a robust, event-driven, multi-modal backend.
Further Architectural Considerations
The design of the PluginRegistry was another significant hurdle. In a multi-agent system, providing every agent with every tool schema consumes massive amounts of the context window. By implementing a lazy-loading mechanism, the Root Router only sees a ToolSummary. When it decides a tool is necessary, it requests the full ToolSchema from the registry. This drastically reduces token usage and latency.
The Device Controller (Layer 3) handles the physical cross-device execution. When the desktop client connects to the WebSocket, it advertises its local capabilities (e.g., take_screenshot, open_application). The backend dynamically registers these as T3 proxy tools. If the user commands their phone to “Take a screenshot on my desktop”, the Root Router delegates to the Device Controller, which invokes the take_screenshot proxy tool. The backend forwards this command over the WebSocket to the PyQt6 desktop client, which executes the local OS command using PyAutoGUI or mss, captures the screen, and sends the image data back to the backend. The backend then injects this image into the Gemini Live session, allowing the AI to analyze the desktop screen entirely via a voice command originating from the phone. This is the true power of Omni.
People have started compiling screenshots of a phrase that appears constantly in AI-generated text. “It’s not just a tool — it’s a paradigm shift.” “It’s not about efficiency; it’s about transformation.” The pattern is a structural artifact of how large language models are trained, aligned, and instructed, and understanding its origins reveals something significant about the current state of AI development.
The Pattern Has a Name
In classical rhetoric, this construction is called antithesis, or negative-positive parallelism. It works by first negating a familiar assumption, then replacing it with something supposedly more expansive or profound.
When used by human writers, it’s a high-impact device deployed sparingly. Advertising copywriters use it to reframe value propositions. Political speechwriters use it to signal a turning point. The entire effect depends on restraint.
A language model has no concept of restraint, applying the structure indiscriminately whether describing a recipe, explaining a bug fix, or summarizing a business report. A rhetorical technique designed for occasional emphasis becomes a verbal tic repeated across every response.
Where the Pattern Comes From
The internet is disproportionately populated by text written to sell, persuade, or maximize engagement. Content marketing, SEO articles, LinkedIn thought leadership posts, and corporate press releases all rely heavily on contrast framing.
During pre-training, a language model absorbs the statistical distribution of human language across billions of documents. When text sounds authoritative or insightful, the probability of encountering an “It’s not X, it’s Y” sequence is high. The model encodes the structure as a valid marker of “expert communication,” with no capacity to recognize it as a marketing convention.
The overuse follows directly from training on human-generated web text. The models are mirroring the engagement-optimized habits of the internet, distilling the collective style of digital marketing into a predictable format.
How RLHF Locks It In
Pre-training loads the pattern into the model’s weights, and Reinforcement Learning from Human Feedback (RLHF) cements it through preference optimization.
In RLHF, human annotators compare pairs of model responses and rank them for quality. Their rankings train a Reward Model, which then automatically scores the LLM’s outputs at scale. Annotators are instructed to reward nuance, multi-faceted perspectives, and comprehensive insight.
The problem is that human annotators frequently conflate the appearance of nuance with actual depth. When evaluating two competing responses, a rater is statistically more likely to upvote a response using contrast framing. The full antithesis structure, “Photosynthesis is not merely a biological function — it is the foundational engine of life on Earth,” reads as more insightful than a flat declarative like “Photosynthesis converts light into energy,” even when it carries less information.
Over millions of RLHF iterations, the Reward Model learns a proxy: dialectical hedging correlates with high helpfulness scores. The LLM learns to inject contrast framing into responses because doing so inflates its reward, regardless of whether it adds meaning.
RLHF also trains models to be face-saving. Models are penalized for being blunt, dismissive, or overconfident. The “It’s not just X, it’s Y” structure is safe, validating the user’s existing assumption while adding a layer of elaboration that makes it extremely difficult for a rater to flag the response as unhelpful. Researchers studying this dynamic have described the result as AI conditioned for servility.
The Mathematics Behind the Structure
Recent research has shown that both RLHF and its successor, Direct Preference Optimization (DPO), can be interpreted as forms of contrastive learning. The model is trained to increase its alignment with “chosen” (human-preferred) responses and decrease its alignment with “rejected” ones.
In practice, rejected responses tend to be brief, flat, and declarative, while chosen responses tend to be verbose, expansive, and multi-faceted. The model learns to structurally oppose the negative sample within its own generation. Prefacing with a negation (“it’s not X”) distances the token trajectory from the rejected sample space, and stating the elevated alternative (“it’s Y”) pulls it toward the preferred one.
The “It’s not X, it’s Y” structure is the direct linguistic output of this mathematical optimization. The antithesis surface form is what the contrastive objective produces most reliably, given the composition of human preference data.
The Institutional Layer
Beyond training dynamics, there is a more direct cause. Many LLMs operate under system prompts that instruct them to be “profoundly helpful,” to “look for deeper meanings,” or to “avoid generic responses.” A model without genuine subjective understanding uses structural proxies for depth, reaching for the constructions its training data associates with high-level conceptual thinking.
Anthropic’s Constitutional AI framework explicitly instructs Claude to balance competing values and perspectives. Anthropic has even sourced public input to draft these principles through a process called Collective Constitutional AI. When a model is constitutionally required to weigh tradeoffs in every response, it gravitates toward concessive structures: “While X is true, we must also consider Y.” The constitutional mandate to avoid reductive thinking maps directly onto dialectical hedging.
The Downstream Effects
This pattern, at scale, is doing measurable damage to written communication.
A 2025 study tracked stylistic convergence in peer-reviewed academic publications following the release of ChatGPT. Using SciBERT embeddings to measure linguistic similarity across millions of papers, researchers found a significant increase in LLM-associated linguistic features in the scientific literature. The study noted a reduction in authorial variance and individual intellectual voice, while acknowledging that AI assistance helps non-native English speakers achieve syntactic fluency in high-tier publishing.
Separate research analyzing persuasive discourse found that LLM-generated arguments cluster tightly together in linguistic space, showing high similarity to each other and low similarity to human writing. LLMs exhibit lower lexical richness than humans and maintain unnaturally high scores for “anticipation” and “trust” even in adversarial contexts, drawing from a shared rhetorical playbook with contrast framing as one of its core moves.
When every paragraph builds to a reversal, readers stop experiencing the reversal as meaningful. The scaffolding becomes visible, and the rhetorical performance crowds out the substance.
Why Simple Fixes Don’t Work
Asking a model to “stop sounding like an AI” rarely works. The model typically switches to a different formula, often adopting over-casual language or forced contrarianism, while maintaining the underlying contrastive logic.
Negative instructions (“Do not say ‘it’s not X, it’s Y'”) are similarly ineffective. The model’s internal representation of high-quality text is structurally tied to contrast framing through DPO and RLHF. Blocking a specific phrase pushes the model to find a synonymous structure, so “While X is true, Y is paramount” ends up carrying the same rhetorical function under a different surface form.
Effective mitigation requires structural prohibition. Prompts that target the behavior at the level of linguistic category, prohibiting “thesis-antithesis patterns,” “dialectical hedging,” and “rhetorical equivocation,” are significantly more effective because they block the statistical pathway established during alignment training, rather than just banning a specific phrase. Instructing the model to define things affirmatively, and to treat contrastive structures as high-impact tools used sparingly, produces noticeably more direct prose.
The Deeper Problem
The “It’s not X, it’s Y” pattern is a symptom of an alignment strategy that has optimized for the appearance of nuance, using rhetorical elaboration as the proxy signal for quality. RLHF as currently practiced penalizes declarative confidence and rewards elaborate framing, because human evaluators operating under time pressure consistently mistake rhetorical complexity for intellectual depth.
The signal annotators send is “this sounds thorough,” and the model learns to optimize for exactly that signal. The output is text that reads as considered but delivers less information than a direct statement would.
Fixing this requires rethinking what signals human annotators are actually rewarding during preference tuning, and whether those signals reliably correspond to quality. Until that changes, AI-generated text will keep reaching for the same contrastive move, in every response, on every topic, at scale.
Research sourced from academic papers on RLHF, DPO, and LLM stylistics, including work from arXiv on contrastive learning in alignment and ACL Anthology findings on AI argumentative style.
