标签：#python

GitHub热门项目 | [EMNLP 2025 Demo] PDF scientific paper translation with preserved formats - 基于 AI 完整保留排版的 PDF 文档全文双语翻译，支持 Google/DeepL/Ollama/OpenAI 等服务，提供 CLI/GUI/MCP/Docker/Zotero | Stars: 36,617 | 55 stars today | 语言: Python

GitHub热门项目 | GEO-first SEO skill for Claude Code. Comprehensive AI search optimization for any website — citability scoring, AI crawler analysis, brand authority, schema markup, platform-specific optimization, and PDF reports. If you want learn how to sell this to real businesses, check out the skool community | Stars: 10,149 | 96 stars today | 语言: Python

GitHub热门项目 | A股自动选股系统 — 多种技术形态自动扫描，收盘后自动运行并推送飞书 | Stars: 5,919 | 195 stars today | 语言: Python

Every field above is part of the contract enforced by publisher validate . This post exists so the pipeline always has something real to plan against. Why tool-calling changes the threat model A language model that only emits text has one output channel: the reply. A model that can call tools has as many output channels as it has tools, and each of them is reachable by anything that can get text into the context window — a fetched page, a code comment, a file name, a CI log. The useful framing is that the context window is an untrusted input, and every tool is a sink . Prompt injection is not a new vulnerability class so much as a confused-deputy problem wearing a new hat. Three questions per tool For each tool exposed to a model, write down: What does it read? A tool that reads secrets turns any injection into an exfiltration primitive, whether or not the model "intends" it. What does it change? Distinguish reversible writes from irreversible ones. Deleting a branch and deleting a production table sit in different buckets. Who authorised it? Authority should ride with the request, not with the agent process. An agent running as a service account is an agent with the union of every user's permissions. A minimal mitigation set Scope credentials per invocation, not per deployment. Make irreversible tools require an out-of-band confirmation that the model cannot itself produce. Log the full tool-call payload, not a summary. The summary is written by the thing you are investigating. None of this is exotic. It is ordinary least-privilege design applied to a component that happens to take instructions from strangers.

Most data engineers write pipelines the way most people write shell scripts: run it, eyeball the output, ship it. That works right up until a schema changes upstream, a null slips through a join, or someone "fixes" a transformation and silently breaks three downstream tables. By then the bug isn't your problem anymore — it's a bad number in someone's dashboard. Software engineers solved this problem decades ago with automated testing. Data engineering has been slower to adopt the habit, partly because our code touches messy external reality (files, databases, clusters) in a way a typical web app doesn't. But that's exactly why testing matters more here, not less. This article is a practical, DE-flavored crash course in pytest — the dominant Python testing framework — plus the patterns you actually need for pandas, Polars, and PySpark pipelines. Why bother testing a data pipeline? A few concrete failure modes that tests catch before production does: A column gets renamed upstream and your join silently produces all-null matches instead of erroring. A "cleaning" function that's supposed to drop duplicates accidentally drops valid rows too. A date-parsing function works on your local machine's locale and breaks in the CI environment. A refactor changes an aggregation from sum to mean and nobody notices until finance asks why revenue looks 90% smaller. None of these require exotic testing techniques. They require the habit of writing small, deterministic checks against small, deterministic inputs — which is exactly what pytest is built for. Where pytest fits — and where it doesn't Before diving in, it's worth being precise about scope, because "testing a data pipeline" actually covers two different questions, and conflating them is a common source of confusion: Is my code correct? Given a known input, does the transformation logic produce the right output? This is a property of your code , and it doesn't change based on what day it is or what a source system decided to

Stop drawing the graph: reactive agents over versioned artifacts Most agent frameworks make you draw the graph : connect nodes, wire memory, declare control flow. But a knowledge problem is not a workflow. Take a realistic question: "Why did infrastructure costs increase in Q2?" The answer may need Confluence docs, GitLab merge requests, CSV spend data, a calculation, source verification — and a clarifying question. The next question needs a different path. There is no universal graph here, and asking a developer to draw one for every possible question is asking them to predict the future. So we built an agent runtime where you don't describe execution at all . You describe what artifacts exist and what agents can do with them; the runtime derives what runs next from state changes. Agents react to events. There is no graph and no node pipeline. This is ctxloom — a reactive, artifact-driven agent runtime, now open source. What it looks like The whole loop is: create an artifact → agents react → one atomic patch → context advances . A knowledge question — say, "how much does GPU inference cost?" — becomes a chain of typed artifacts: UserQuery → TypedDoc → Evidence → Claim → Answer . Each is produced by an agent that reacts to the previous artifact. No graph describes this chain; it falls out of what each agent consumes and produces. ARTIFACT CREATED / UPDATED │ ▼ AGENTS REACT ──self.effects──► Effects ──compile──► Patch ▲ │ └──────────────────────────────────────────────────────┘ Context v+1 The event that wakes an agent is derived from that same change — the causal chain can never drift from the actual state. from pydantic import BaseModel from ctxloom import Budget , Consume , Context , Runtime , RuntimeResources , create_agent , produce , structured_llm class Question ( BaseModel ): text : str class FindingBody ( BaseModel ): text : str class Finding ( BaseModel ): text : str source : str class Conclusion ( BaseModel ): text : str @produce ( Finding ) async def ana

This article provides a step by step comparison of three Gemma 4 deployments on a single AWS hosted GPU enabled system. A suite of Python MCP tools is built to simplify management of each deployment, and one benchmark harness is shared across all three so that the runtime is the only variable. https://github.com/xbill9/gemma4-dev The whole exercise cost under three dollars, and that is the part worth keeping. Nineteen instances and about four and a half instance-hours bought three serving sweeps, nine timed boots and a handful of A/B restarts. It also bought five wrong claims, each caught by measuring instead of reasoning. On hardware where a run is expensive, the cheapest of those five would have shipped with a caveat attached. What is this project trying to Do? Three rigs in this monorepo serve google/gemma-4-E2B-it on an AWS G5g instance. One runs vLLM, one runs a pure JAX port, one runs PyTorch with transformers. The hardware is identical and only the runtime slot moves, so this should be the cleanest A/B available. For months it was not, because each rig measured itself with its own harness and quoted its own number. Three harnesses computing three statistics is not a comparison. Prerequisites An AWS account with G-family quota in us-east-1 . Each g5g.2xlarge is 8 vCPU, so 16 vCPU of spot quota runs two at once. A subnet, a security group opening TCP 8000, and an instance profile carrying AmazonSSMManagedInstanceCore plus read on the Hugging Face token secret. A Hugging Face token in Secrets Manager. It is fetched at boot into a root-only EnvironmentFile and never appears in user data. boto3 and the standard credential chain. No AWS CLI shell-outs, no inbound SSH rule, and no private key anywhere in the flow. AWS EC2 G5g Instance g5g.2xlarge — 8 vCPU, 16 GiB host Host CPU AWS Graviton2, aarch64 GPU 1x NVIDIA T4G, Turing, SM 7.5 GPU memory 15,360 MiB per nvidia-smi ; AWS lists 16,384 nominal G5g is the only family AWS ships that puts an NVIDIA GPU behind a Gravi

This article provides a step by step comparison of three Gemma 4 deployments on a single AWS hosted GPU enabled system. A suite of Python MCP tools is built to simplify management of each deployment, and one benchmark harness is shared across all three so that the runtime is the only variable. https://github.com/xbill9/gemma4-dev The whole exercise cost under three dollars, and that is the part worth keeping. Nineteen instances and about four and a half instance-hours bought three serving sweeps, nine timed boots and a handful of A/B restarts. It also bought five wrong claims, each caught by measuring instead of reasoning. On hardware where a run is expensive, the cheapest of those five would have shipped with a caveat attached. What is this project trying to Do? Three rigs in this monorepo serve google/gemma-4-E2B-it on an AWS G5g instance. One runs vLLM, one runs a pure JAX port, one runs PyTorch with transformers. The hardware is identical and only the runtime slot moves, so this should be the cleanest A/B available. For months it was not, because each rig measured itself with its own harness and quoted its own number. Three harnesses computing three statistics is not a comparison. Prerequisites An AWS account with G-family quota in us-east-1 . Each g5g.2xlarge is 8 vCPU, so 16 vCPU of spot quota runs two at once. A subnet, a security group opening TCP 8000, and an instance profile carrying AmazonSSMManagedInstanceCore plus read on the Hugging Face token secret. A Hugging Face token in Secrets Manager. It is fetched at boot into a root-only EnvironmentFile and never appears in user data. boto3 and the standard credential chain. No AWS CLI shell-outs, no inbound SSH rule, and no private key anywhere in the flow. AWS EC2 G5g Instance g5g.2xlarge — 8 vCPU, 16 GiB host Host CPU AWS Graviton2, aarch64 GPU 1x NVIDIA T4G, Turing, SM 7.5 GPU memory 15,360 MiB per nvidia-smi ; AWS lists 16,384 nominal G5g is the only family AWS ships that puts an NVIDIA GPU behind a Gravi

The Brave Wanderer: I made Claude play a Pokémon it never read a guide for Full timeline video of this 2,000-turn run (game frames + a live cost counter on the left, the model's real-time thinking log on the right): https://youtu.be/ewyM7mzGzTM At the end of the first article in this series , I made a promise. Fable 5's fluency in FireRed owed half its credit to the walkthroughs it had memorized — it wrote down "Oak's Parcel," an item the game hadn't shown it yet, 141 turns early. So the only honest exam is a new exam paper: "Same harness, same model, a map it cannot recite — I'll post the numbers." This article is those numbers. The exam paper is Pokémon Team Rocket Edition — the Chinese fan translation of the Spanish community hack Pokémon Edición Team Rocket, released in January 2026. You play a Team Rocket recruit working your way up from the Five Island base. Five story rounds, four regions; the Kanto chapter alone is labeled 30-35 hours for a human player. And most importantly: this game is essentially absent from the model's training data . No guide to recite. Just the screen and itself. There's also a lovely narrative twist: the hack sets your home base inside the original FireRed's Five Island Rocket Warehouse — the enemy hideout you raid late-game as the hero in the official version. Same map, opposite allegiance. Rules unchanged: vision only, one screenshot plus its own notes per turn, one button-press tool, a 2,000-action cap. The result, up front 8 hours 43 minutes, 2,000 turns, $113.44. It reached the middle of the prologue's first mission — roughly 40-60 minutes of human play time. It taught itself plenty: menus, battles, catching, the save flow, all from scratch; after losing to a fellow recruit it wrote a revenge battle plan into its notes, ground levels, and actually won the rematch; it even induced map rules like "dark blue water can't be surfed, light blue can," and maintained a dead-ends list and an NPC-interview checklist in its notes. One deta

Every time I put a model behind an endpoint I make the same lazy decision. I pick whatever I used last time, or whatever I read about most recently, and I tell myself I'll benchmark it properly later, and later never arrives because there is always something with an actual deadline on it and comparing model latencies feels like procrastination even when it isn't. I never do it. Not once. So I built the thing that would make me do it. One prompt, fired at six models at once, streaming side by side in columns, with time to first token and cost per run underneath each one. About 390 lines of Python. Code's here , MIT, take it. Then I ran it, and three things happened that I didn't plan for. The integration is two lines, and that's the least interesting part DigitalOcean's inference endpoint speaks OpenAI, so this is the whole thing: client = OpenAI ( base_url = " https://inference.do-ai.run/v1/ " , api_key = os . environ [ " DIGITAL_OCEAN_MODEL_ACCESS_KEY " ], ) Every model below goes through that one client. Llama, DeepSeek, Mistral, Qwen, OpenAI's open-weight gpt-oss line. Only the model string changes. That is the pitch, and it's real, and I'll move past it quickly because you already knew an OpenAI-compatible endpoint would work like an OpenAI- compatible endpoint. What I didn't know is everything that follows. One footnote before you paste that snippet. The credential is a model access key , created under the Gradient AI Platform. It is not the API token from Settings, API. Different thing, different page. (Although, as I found out later, the endpoint doesn't care nearly as much about that distinction as the docs do.) Six streams, no event loop I wanted the columns to fill simultaneously. Real racing, not six sequential progress bars pretending. The tidy way to do that is one endpoint that fans out server side and multiplexes everything back down a single connection. I didn't do the tidy way. The browser opens one EventSource per model instead: GET /stream?model=<

I maintain no_human . It's open source, and this month I'm getting it ready for outside contributors, so this post is part announcement, part ask. What it does: no_human proves the code it wrote is correct. You drop a ticket on the board (or point it at Jira or Linear) and it plans, writes the code, and opens a pull request. Before that PR reaches you, the work is checked by a second model that never saw the coder's session and is told to assume the job is not done. You get a pass/fail checklist that cites files and lines, not a score. If the agent deleted or weakened a test, a tamper guard stops the attempt. For bug fixes, the tests offered as proof have to fail on the old code and pass on the new. It's free and open-source, on your machine. If you're thinking about contributing, here's what you'd be walking into. You don't need a Claude account to work on it. The test suite is hermetic: uv sync --frozen && uv run pytest -q -n 4 runs all ~2,980 tests without ever calling a model. A credential only comes into play if you want to run the product end to end. The good first issues are scoped down to file and line, each with a repro and the command that verifies the fix. Past those, the one I most want help with is backend adapters . The implementer runs behind a narrow protocol, and I want adapters for more coding agents: opencode, Aider, Goose, Crush, Amp, Qwen Code, and a longer list in the issue. One agent per PR, and comment before you build. Some of these tools have no headless mode, and I'd rather tell you that before you spend a weekend finding out. Not everything needs Python, either. There are open invitations for UX polish on the web board — frontend and design contributions, with the rule that a sketch or screenshot comes before code — and for making the PRs the agent opens read better : the PR body is the artifact a human judges, and right now it's information-dense but plain. Fair warning about scope: only the coder seat is swappable. The reviewer, planner

I was up at 2 AM, staring at seventeen PDFs that refused to tell me anything. My midterm was in six days, and my notes were a mess of arrows, acronyms, and half-typed definitions. I wanted a chatbot that could answer questions about my own lectures. Not a fancy one. Just something that would take a question, find the relevant slide, and answer in plain language. So I built one. I used MonkeyCode for the free model access and free server space. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Their open-source platform's free tier includes 10 million tokens and a server slot, which is enough for a weekend prototype. The “why not” won. The plan was simple: extract text from the PDFs, split it into chunks, retrieve the most relevant chunks with a dumb similarity search, then ask a model to answer from those chunks. No vector database. No fine-tuning. Just a few lines of Python and a POST request. The extraction step was almost too easy. from pypdf import PdfReader def extract_pdf ( path ): return " \n " . join ( page . extract_text () for page in PdfReader ( path ). pages ) Most of my slides were text-heavy, so it worked. One deck came out as garbage because the pages were rotated. That was my first warning: garbage in, confident nonsense out. Next, chunking. I set a chunk size of 1,200 characters with an overlap of a hundred. Small enough to be relevant, big enough to contain a complete idea. def chunk_text ( text , size = 1200 , overlap = 100 ): chunks = [] for i in range ( 0 , len ( text ), size - overlap ): chunks . append ( text [ i : i + size ]) return chunks I didn't use a vector database. My whole corpus was about two hundred chunks, so TF-IDF plus cosine similarity was enough. More importantly, it made every retrieval transparent. I could see exactly which chunks the bot pulled, and why. from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity def retrieve ( query , chunks

Last Tuesday, my free endpoint returned a valid JSON contract. The next call returned a summary. Same prompt. Same model label. No version bump. I almost merged code that expected a schema and instead got a paragraph. Free tiers are not the enemy. Silent drift is. When you wire a free AI server into your PR pipeline, you accept three facts: shared compute, changing model configs, and zero guarantee. So you need gates that fail closed. This is the checklist I now run before any AI-generated suggestion touches a merge branch. I built these gates against an open-source gateway called MonkeyCode. Why? It gives solo devs free model access and a free server for trial workloads. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Convenient, yes. Safe by default? No. So I test every claim. Gate 1: Pin the response contract Your prompt must define an exact shape. For a bug triage task, I require a JSON object with severity , summary , and file fields. If the response is not parseable JSON, the gate fails immediately. { "severity" : "high" , "summary" : "Null pointer on empty input" , "file" : "src/parse.ts" } No fallback. No partial acceptance. Gate 2: Snapshot a baseline Run the same prompt ten times. Record output length, hashes, and tokens per call. Store those as baseline.json . Later, compare every new response against that range. for i in $( seq 1 10 ) ; do curl -s your-monkeycode-endpoint -d '{"prompt":"triage this bug"}' \ | jq -r '.output' | sha256sum done If the hash variance crosses an evidence threshold, the gate flags it. Gate 3: Time-box and cost-cap Free servers queue. You need a timeout and a token budget. I use 8 seconds and a hard cap of 600 tokens. The gate reads usage metadata from the response and rejects when either limit is hit. if response . elapsed > 8 or response . usage . total_tokens > 600 : reject ( " over budget " ) Track this weekly. Drift often starts as a slow climb. Gate 4: Apply semantic checks Gates are not jus

I used to think encryption was simple: take a password, use it as the key, done. Then I built a small encryption tool myself, and realized that's not how any of this works. This is the first post in a series where I'm documenting what I'm actually learning while building CryptoGraphy , a small Python project I'm using to study applied cryptography properly instead of just calling library functions and hoping they're right. My background is in SOC analysis and pentesting — I'm used to finding broken crypto, not building it. Writing this project is forcing me to understand the "why" behind the fixes I used to just recommend. The naive approach If you've never dug into how encryption actually works, this looks completely reasonable: AES . encrypt ( password , data ) Pass in a password, get encrypted data back. It reads clean. It "works" in the sense that it runs without errors. And it's wrong in a way that's easy to miss if nobody ever shows you why. Why it breaks AES doesn't take a password. It takes a key , and that key has to be an exact size — in my project, 256 bits (32 bytes). A password is neither of those things. It's variable-length, human-chosen, and (unless your users are unusually disciplined) low-entropy. If you pad or truncate a password to force it into 32 bytes, you haven't created a strong key — you've created a shortcut for an attacker. They don't need to break AES. They just need to guess the password, since the password is the key in disguise. This matters because passwords and keys have completely different jobs. A password needs to be memorable to a human. A key needs to be unpredictable to a computer. Treating them as interchangeable collapses two different security properties into one weak one. The fix: derive the key, don't reuse the password In crypto.py , the password never touches AES directly. It goes through a key derivation function first — specifically Argon2id: from argon2.low_level import hash_secret_raw , Type SALT_SIZE = 16 KEY_SIZE

AI agents do not need to hallucinate to make the wrong decision. They can read accurate information, reason correctly, and still take the wrong action because the information changed before execution. That is the problem FreshCtx is built to address. The same failure keeps appearing in different systems Developer feedback around FreshCtx surfaced several versions of the same underlying problem: A subscription status changed in Stripe, but an application acted on its old snapshot. A deployment worker continued after another worker had already claimed the job. An agent relied on remembered database action items instead of checking their current status. A research source changed after a claim had been prepared. A voice workflow reached an outdated business record after correctly understanding the request. Different industries and different tools, but the same gap: The reasoning was valid when produced, but stale when executed. What changed in FreshCtx 0.6.0 FreshCtx now provides the same pre-action freshness boundary across several practical environments: Stripe Subscription validation An Agno pre-tool integration Synchronous LangGraph action-node wrappers Asynchronous LangGraph action-node wrappers Selective revalidation of only the evidence an action declared Audit evidence explaining why an action was allowed or blocked The LangGraph integration checks the evidence an action depends on immediately before the node runs. If a required dependency changed or cannot be verified, FreshCtx blocks before the node body starts. FreshCtx does not replace LangGraph routing, retries, checkpointing, transactions, or idempotency. It adds the missing freshness check at the point where reasoning becomes action. Why framework neutrality matters Agno and LangGraph have different execution models. Stripe is not an agent framework at all. The integration changes, but the control remains consistent: An action declares the evidence it depends on. FreshCtx checks that evidence again at the

I attend conferences regularly, and for years I’ve wanted a badge that makes it easy for people to find me online. In 2019, I attended defcon and built defpi , a goofy raspberry pi powered badge. While that was fun I wanted a bit more turnkey and I found just what I wanted with a Badgeware Badger (nerdy domain hack badgewa.re). Since my use case is to just have my socials via QR I chose the e-ink version as it made the most sense. So what does the Badger come equipped with? RP2350 WiFi 1000mAh battery USB-C MicroPython I might not be the biggest Python fan but in the age of AI does it matter? I just ask Codex to help me get the desired outcome I'm looking for! So Codex and I cooked a few hundred lines of Python and boom my profiles are only a QR code scan away. Let's take a look at my default badge screen in all its glory. Social screen. All in all it's pretty simple, get you to either my LinkedIn or my personal site . The crazy thing is the simulator lets me test the code before I deploy it to the badge. make sim and I'm able to test it locally. Then a simple make deploy while the badge is connected and it deploys it all. You can check out the code repo if you wanna steal slopfork my setup. Hacksore / badger Badger 2350 badge Personal Badgeware app for the Badger 2350. Requirements: macOS, uv , Git, and a data-capable USB-C cable. Run make to see the three available commands. Simulator make sim The first run clones and builds Badgeware Desktop beside this repo. Later runs reuse that build, stage the current app in an isolated filesystem, and launch it at the Badger's 264×176 resolution. Simulator controls: Space : Button B; flip between the badge and social/QR screens ↑ / ↓ : change the background pattern ← / → : Buttons A and C Esc : hot reload Deploy the app Connect the Badger over USB-C. Double-tap RESET . Wait for the BADGER drive to appear. Run: make deploy The command validates the app, copies its Python and image files into /apps/badge , safely ejects the dr

In the previous article, we learned how to secure our APIs using JWT Authentication and protect routes from unauthorized access. Now let's explore another feature used in almost every AI application— file uploads . If you've built applications like ChatGPT, document Q&A systems, resume analyzers, legal contract reviewers, or medical report analyzers, one thing is common across all of them: The user uploads a file. Without file uploads, there is nothing for the AI model to process. If you haven't read the previous article, check it out first to continue the series: Protecting routes with JWT Tokens Why Do We Need File Uploads? Consider some popular AI applications: ChatGPT allows you to upload PDFs and images. Resume analyzers require your resume. Legal AI assistants analyze contracts. Medical AI systems analyze lab reports. RAG applications build knowledge bases from documents. The workflow usually looks like this: User │ ▼ Upload File │ ▼ FastAPI │ ▼ Save / Read File │ ▼ Process using AI FastAPI makes uploading files extremely simple. Installing Required Package FastAPI uses python-multipart to process uploaded files. Install it using: pip install python-multipart Your First File Upload API FastAPI provides two important classes: File UploadFile Let's import them. from fastapi import FastAPI , File , UploadFile app = FastAPI () Creating the Upload Endpoint @app.post ( " /upload " ) def upload_file ( file : UploadFile ): return { " filename " : file . filename } Run the application. Open Swagger UI. Click POST /upload . You'll notice FastAPI automatically provides a file picker. Upload a file. Response: { "filename" : "resume.pdf" } Our API successfully received the uploaded file. Understanding UploadFile You might wonder: Why didn't we simply use a string or bytes? FastAPI provides the UploadFile class because it contains useful information about the uploaded file. Some commonly used attributes are: file . filename Returns: resume.pdf file . content_type Returns: a

Small automations often look easy: take information from one place and turn it into a task somewhere else. The hard part is what happens when the information is incomplete, someone submits the same request twice, or the workflow sees something it was never meant to use. A useful automation should handle those situations without creating extra cleanup for the owner. I built a small runnable example around four simple checks. 1. Make sure the important information is there If a request is missing something the team needs, the workflow does not create a half-finished task. It places the request on a short review list and explains what is missing. 2. Do not create the same work twice Repeated submissions happen. The example recognizes a repeated request and creates only one task instead of making the team sort out duplicates later. 3. Keep out information the workflow does not need The example copies only the agreed fields into its output. An unexpected column in the input is ignored instead of being passed along automatically. 4. Let a person review the result The example creates an owner-review list. It does not contact customers, connect to outside services, or turn on a live process. A person stays in control of what happens next. The repository includes four made-up requests, the expected result files, and ten automated checks. Those checks cover missing information, repeated requests, unexpected fields, broken input files, and repeatable results. This is an Allure Labs demonstration, not client work and not a claim about business results. You can see the code and sample output here: https://github.com/Allura-Gensin/small-workflow-automation-demo If one small file-based process is creating repeated or incomplete work, start with a $125 written workflow plan or a $500 tested small build. Describe one starting event, one result, and what the workflow must never do. The fixed-scope options and limits are here: https://offers.allurelabs.ai/workflow-automation/ Or use t

This week was a high-output sprint across the stack—from low-level p2p networking in Python to refining agentic workflows in TypeScript. I pushed 53 commits and opened 13 PRs, maintaining a perfect 7-day streak while balancing deep protocol work with personal knowledge management. TL;DR I didn't really intend for this to be a "build everything" week, but that’s exactly where the momentum took me. Between hardening WebRTC implementations in py-libp2p and chasing down edge cases in agent orchestration, I managed to ship 53 commits and keep my daily streak alive for the full seven days. The stats show a heavy tilt toward new code—over 12,000 additions—as I laid the groundwork for better telemetry and more robust p2p networking. What I Built Deep in the Networking weeds: py-libp2p Most of my "deep work" hours went into py-libp2p . Networking code is unforgiving, but incredibly satisfying when it clicks. I spent a significant chunk of time in libp2p/kad_dht implementing configurable subnet-diversity limits and table-wide IP-group caps. If you've ever dealt with Sybil attacks or just messy peer distributions, you know why this matters—it’s about making the DHT resilient, not just functional. On the transport side, I was neck-deep in libp2p/transport fixing WebRTC issues. I had to guard private-slot writes and ensure we’re using close_peer_connection at every production site to avoid hanging resources. I also spent time on a tricky Windows-specific bug where we needed to listen on a concrete non-loopback interface for tests to actually pass. Hardening Reachable & Breakscale I’ve been refining Reachable , specifically making the "Ask" feature behave more like a natural conversation. I had to harden the store behind it to ensure state doesn't drift when the UI gets complex. Over at breakscale , I hit a weird one: Vitest failing on Node 26 because of jsdom 's localStorage implementation. I opened an issue, tracked it down, and pushed a fix to put localStorage back where it be

First of all, I warmly welcome everyone out there in the DEV Community. [Completely open for discussion — drop your thoughts below.] From my perspective, it feels like everyone is racing towards AI/ML. The moment someone says they want to become an AI/ML Engineer, the conversation immediately shifts towards: Python → ML → Deep Learning → LLMs → Latest AI Tools And thinking about it, well, it’s quite understandable too. AI is one of the most exciting areas in technology right now. BUT, I have a question… Why are we starting to treat AI/ML Engineering as something completely different from Software Engineering? I often see people following an extremely narrow path towards AI/ML while completely skipping the fundamentals of Software Engineering. Backend development gets ignored. Databases, networking, operating systems, system design — all of them get ignored. And afterwards: APIs, deployment, testing, distributed systems… All of these seem quite trivial, right? Because the end goal is simply to create or automate something with AI. But it’s quite clear to me that AI can’t possibly live by itself. For any AI model to thrive, we need data. That data needs storage and pipelines. A model needs an application around it. That application needs APIs. Those APIs need backend infrastructure. And now we have an actual system. That system needs to be monitored for bugs, optimized for CPU and memory efficiency, refactored when necessary, maintained over time, and tested against new use cases. So thinking about all of this: How does one even fathom becoming an AI/ML “Engineer” without understanding what they are actually engineering into and working on? Maybe AI/ML Engineering and Software Engineering aren’t two completely different entities. Maybe they are different components of the same system. Now, I’m not saying: “You should become an expert in everything.” Specialization is indeed important. But specialization doesn’t necessarily mean abandoning the fundamentals that the spe