标签：#p

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion. I built Hiyoko PDF Vault — a macOS PDF tool — in Rust. Choosing the right PDF library was the first real decision. lopdf or pdfium. Here's what I found. lopdf: pure Rust, no dependencies lopdf is pure Rust. No C bindings, no system libraries, no bundling headaches. What it does well: Merge, split, rotate pages Read and write PDF structure Metadata manipulation Bates numbering Works well for structural PDF operations What it struggles with: Rendering PDFs to images (not its job) Complex font handling Malformed PDFs — lopdf is strict; real-world PDFs often aren't For a tool that manipulates PDF structure without rendering — merge, split, encrypt, add watermarks, strip metadata — lopdf is the right choice. Pure Rust means easy cross-compilation and universal binaries with no extra work. pdfium: full rendering, C dependency pdfium is Google's PDF engine (from Chromium). The pdfium-render crate wraps it for Rust. What it does well: Accurate PDF rendering to images Handles malformed PDFs that lopdf rejects Text extraction from complex layouts Full PDF spec compliance What it requires: Bundling the pdfium binary with your app (~20MB) Architecture-specific binaries (x86_64 and aarch64 for universal binary) More complex build setup For a tool that needs to display PDFs or extract text from complex documents, pdfium is the right choice. You pay for it in bundle size and build complexity. What I actually use lopdf for structural operations: merge, split, encrypt, watermark, metadata, Bates numbering. Apple Vision Framework (via Tauri shell commands) for OCR — it's already on the user's Mac and handles Japanese text better than anything I could bundle. I avoided pdfium because the bundle size increase wasn't worth it for my use case. If I needed accurate rendering, that calculation would change. The honest recommendation Start with lopdf. It covers most PD

I thought DEV Challenges were about winning. What participating in DEV Challenges taught me. A few months ago, I joined DEV. I didn't know many people. I wasn't well known. I simply wanted to become a better developer. Like many newcomers, I believed something very simple. "If I can win a challenge, maybe that means I'm becoming a real developer." So I kept participating. Sometimes I built retro games. Sometimes I experimented with AI. Sometimes I simply challenged myself to finish something before the deadline. Every challenge taught me something. Every badge made me smile. But after several months, I realized something unexpected. The biggest prize wasn't the badge. I started asking myself... What happens after the contest ends? The badge stays on my profile. The project goes to GitHub. Then... What's next? That question stayed with me for a long time. Then I realized something. I had been focusing on the contest. But the real value wasn't the contest. It was the community. Without DEV... I would never have discussed ideas with developers from around the world. I would never have received reactions from people I had admired. I would never have met developers with completely different ways of thinking. The challenge wasn't just building software. The challenge was becoming part of a community. Something I had rarely experienced before. Most communication happens inside companies. DEV felt different. It gave me a place to keep showing up. To keep learning. To keep improving. That matters more than I realized. The hardest part isn't building software. This surprised me. As I kept building apps, I realized something. Building an app is difficult. But building a place where people discover that app... is much harder. That's when I started appreciating communities like DEV even more. Someone had to build this place. Someone had to create a market where beginners and experienced developers could stand on the same stage. That's an incredible achievement. My goal changed.

Hey developers! 🚀 I wasted too much time setting up dummy backends just to test my frontend designs. So, I built Stardust API Engine — a completely free, serverless mock server. What it does: Instant live endpoints for /users and /products (Ready to fetch() ). In-built Custom JSON Data Generator to structure your own schemas. 100% serverless, zero login friction, and lightning fast. Check it out here: https://stardustofficial.github.io/stardust-api/ Feedback is highly appreciated! Built with 🌌 by Zishan.

In the world of Generative AI, there is a massive difference between asking for a "pancake recipe" and asking for "eligibility criteria for phase III immunotherapy trials." In specialized fields like healthcare, a standard vector search often fails because medical terminology is dense, specific, and unforgiving. 🏥 Today, we are building a High-Precision Medical RAG (Retrieval-Augmented Generation) engine. We will move beyond simple semantic search by implementing Hybrid Search (Dense + Sparse vectors) using the powerhouse BGE-M3 model, storing it in Qdrant , and fine-tuning the results with FlashRank . This approach ensures that technical medical terms (like EGFR L858R mutation ) aren't lost in the "vibe" of a vector space. Keywords: Hybrid Search , Medical RAG , BGE-M3 Embeddings , Qdrant Vector Database , Clinical Trial Retrieval . The Architecture: Why Hybrid Search? Traditional RAG relies on "Dense Vectors" (semantic meaning). However, in clinical trials, keywords matter. A patient searching for "Pembrolizumab" needs that exact drug, not just "something related to cancer." By using BGE-M3 , we get the best of both worlds: Dense Retrieval : Captures the context and intent. Sparse Retrieval (Lexical) : Captures specific keywords and medical codes. Reranking : Re-evaluates the top hits to ensure the most clinically relevant document is on top. graph TD A[User Query: Medical Case] --> B{BGE-M3 Encoder} B -->|Dense Vector| C[Qdrant Collection] B -->|Sparse Vector| C C --> D[Hybrid Search Results] D --> E[FlashRank Reranker] E --> F[Top K Relevant Documents] F --> G[LLM: Final Synthesis] G --> H[Actionable Clinical Insight] Prerequisites 🛠️ Before we dive in, make sure you have your environment ready: Qdrant : Our high-performance vector database. BGE-M3 : A state-of-the-art embedding model that supports dense, sparse, and multi-vector retrieval. FlashRank : An ultra-fast, lightweight reranking library. LangChain : To orchestrate our RAG pipeline. pip install qdrant-c

I’m building ScriptTap, a no-root Android automation app for user-controlled phone workflows. The app lets people create scripts with taps, swipes, routines, screen-aware checks, OCR/text detection, image/pixel checks, variables, logic, and AI-assisted script creation. The technical side is hard, but the trust side may be harder. ScriptTap needs Android Accessibility permission because user-authored input automation requires it. That is a powerful permission. I do not want to minimize it, hide it behind vague onboarding copy, or expect people to click through without understanding what they are enabling. That creates a product-design problem. If the copy is too soft, it feels dishonest. If the copy is too warning-heavy, a legitimate automation tool can feel suspicious before the user even understands what it does. The explanation I am trying to make clear is: ScriptTap is no-root. Scripts are created and controlled by the user. Screen capture is user-controlled. It does not bypass Android permissions, lock screens, app security, or consent flows. Accessibility is required for overlay/input automation, so users should understand why it is being requested. The short version I keep coming back to is: ScriptTap uses Accessibility so your scripts can interact with the screen the way you tell them to. This is a powerful permission. You should only enable it if you understand and trust what the app is doing. For developers who have built apps with sensitive permissions: How did you explain the permission without either hiding the risk or scaring users away from a legitimate feature?

A few weeks ago, I started exploring the Afriex MCP server. The setup was surprisingly straightforward. Connect your MCP client. Configure your API key. Verify the connection. Done. But then I ran into a different problem. Not a technical problem. A prompt problem. The Blank Prompt Problem Once everything was connected, I found myself staring at an empty prompt box. What should I ask? Sure, I could retrieve balances. I could create customers. I could generate virtual accounts. But what were the most useful workflows? What were the prompts that would actually help developers build real products? This isn't a problem unique to Afriex. It's becoming a common challenge across the entire MCP ecosystem. The infrastructure exists. The tools work. But many developers don't know where to start. MCP Changes How We Build Traditionally, integrating a payment API looked something like this: Read documentation Find the endpoint Write HTTP requests Parse responses Build business logic With MCP, the workflow looks very different. You can simply tell your AI assistant what you want to build. For example: Create a customer onboarding flow that: - Collects customer details - Generates a virtual account - Displays payment instructions Build it using Next.js and TypeScript. Instead of manually stitching everything together, the AI can interact with infrastructure through the MCP server. That's incredibly powerful. But only if you know what to ask. The Idea That's what led me to build the: Afriex MCP Prompt Cookbook A collection of practical, production-oriented prompts designed specifically for developers building with Afriex MCP. The goal is simple: Copy. Paste. Build. Instead of starting from scratch every time. The cookbook is open source and available on GitHub: https://github.com/SonOfUri/afriex-mcp-cookbook Feel free to explore the prompts, use them in your own projects, and contribute new recipes. What's Inside The cookbook is organized around real-world use cases. Not API endpoi

AI Agent 的记忆系统通常只解决一个问题：「记住」。gbrain 存知识图谱，Hindsight 存向量，Memory tool 存偏好。三个仓库堆满数据，但你问 Agent「我上周看的那篇关于 Agent memory 的文章说了什么？」——它答不上来。不是因为记不住，是因为它的记忆系统没有「采集」这一层。 这就是 Knowledge-and-Memory-Management（KMM）的定位：不是另一个记忆数据库，而是一个 知识采集 → 精炼 → 召回 → 同步 的全链路插件。v0.0.2 把这条链路做完了。 架构思路：把「采集」和「记忆」解耦 KMM 不做记忆存储，它只做三件事： 采集 — 从 40+ 工具把原始知识拉进来 精炼 — 把原始材料变成结构化笔记 + 知识图谱节点 同步 — 写 OneDrive，让所有设备共享同一个知识池 下方是三层采集管线示意： 层 工具数 代表工具 网页 9 Scrapling (CF 绕过)、Chrome DevTools Protocol、GStack Browser 视频 12 抖音批量转录、yt-dlp、Whisper ASR (99 语种) 文档 9 SenseNova PDF/PPT/Word 引擎、MinerU、book_cache (710+ 本) 3 层召回：不让任何一条知识掉队 搜索时先查本地 FTS5（毫秒级），没命中就走 Hindsight 向量（语义近似），再不中就落 gbrain 知识图谱（关联推理）。三层兜底，基本不存在「查不到」的情况。 代码片段：rclone 做云盘双向同步 KMM 的 CloudSyncEngine 不造轮子，直接用 rclone 做统一同步层。核心代码很直白： class CloudSyncEngine : def __init__ ( self ): self . _check_rclone () def _check_rclone ( self ): result = subprocess . run ([ " rclone " , " version " ], capture_output = True , text = True ) if result . returncode != 0 : raise RuntimeError ( " rclone not installed " ) def bidirectional_sync ( self , local_path , remote_path ): """ 双向增量同步，每 4h 自动执行 """ cmd = [ " rclone " , " bisync " , local_path , remote_path , " --resync " ] return subprocess . run ( cmd ) 这没什么黑科技，关键是架构决策：用 rclone 支持 12+ 云盘（OneDrive / 阿里云盘 / 百度云盘 / Dropbox / Mega / 天翼云等），不需要为每个云盘写专属 SDK。一份配置，双向同步，cron 每 4 小时自动执行。 一个完整的采集流 用户丢过来一个抖音视频链接 → collect_video() 自动走三条线并行： yt-dlp 下音频 → Whisper ASR 转文字 → PaddleOCR/EasyOCR 提关键帧文字 。输出汇总后 → generate_note() 写结构化笔记 → create_note() 入 gbrain 知识图谱 → sync_to_cloud() 推 OneDrive。全自动，零人工参与。 踩过的坑 不要用 Python 重写云盘同步 。KMM v0.0.1 试过直接调各云盘 REST API，token 刷新、分片上传、断点续传全要自己处理，维护成本极高。v0.0.2 切到 rclone bisync 后问题归零。 视频分析不只看语音 。抖音很多技术号用字幕 + PPT 画面讲内容，语音只占信息量的 60%。必须 OCR 做画面补充，否则丢失大量知识。 去重不做在采集层 。采集层只管拉，去重交给 gbrain 的 content_hash 和 nightly_maintenance 的 orphan compaction，职责分离更干净。 适用场景 如果你的 AI Agent 已经跑了一段时间，积累了几千条笔记 / 几百个知识图谱节点，但你还是觉得「它好像什么都不懂」——问题很可能出在知识摄入链路上。KMM 适合你已经有一套记忆系统，缺的是一个自动化的知识采集和同步层。 仓库： github.com/mage0535/Knowledge-and-Management ，MIT 协议，PR

GitHub added a tiny field to the Copilot usage metrics API this week that is going to create a lot of very confident spreadsheets. Enterprise and organization admins can now see ai_credits_used in the user-level Copilot usage reports. One field. Per user. Available for single-day and 28-day reports. It is not the invoice, and GitHub is careful to say it is a consumption signal rather than a billed total. Still, the shape is obvious. Now AI usage can sit next to adoption, activity, team, department, cost center, and whatever else the company already exports into a dashboard. That is useful. It is also exactly how a tool metric becomes a management metric. And once that happens, the question is no longer "can we measure AI usage?" The question is "what weird behavior will this metric create?" every useful metric becomes a temptation I understand why this field exists. If a company is paying for Copilot, especially with usage-based pieces attached to more expensive models and premium features, it needs some way to understand consumption. Platform teams need budget signals. Engineering leaders need adoption signals. Procurement needs something more concrete than "people seem to like it." Finance will eventually ask why one org burns through credits much faster than another. That is normal. The problem starts when a consumption signal is treated as a productivity signal. High AI credit usage might mean a developer is doing valuable work with agent mode, code review, test generation, refactoring, or research. It might also mean the developer is stuck, repeatedly asking the model to solve the wrong problem, generating code that gets deleted, or using a heavyweight model where a small one would have been fine. Low AI credit usage might mean a developer does not need much help. It might mean the work is mostly design, review, debugging, incident response, mentoring, or architecture. It might mean the codebase is small and well understood. It might mean the developer is skept

As software engineers, we often architect solutions in a virtual ideal: fast networks, elastic resources, and servers that never physically degrade. But what happens when your carefully crafted systems need to interact with the messy, unpredictable physical world? Think factory floor monitors, real estate camera networks, or remote tracking devices. Suddenly, those cloud assumptions about infinite uptime and perfect connectivity crumble. My journey, particularly architecting and maintaining a continuous 24/7 camera livestream for a real estate group over six years, has been a masterclass in this reality. It's revealed that true reliability in the physical realm demands a hybrid approach – one that intelligently merges the power of edge computing with the scalability and data insights of the cloud. This isn't just about connecting devices; it's about building resilience into the very fabric of your architecture. In this article, I'll share the battle-tested strategies and design principles that enable systems to not just survive, but thrive, despite the harsh realities of physical deployment. 1. The Core Strategy: Smart Edge, Simple Cloud One of the most common pitfalls in hybrid architecture design is treating the edge device as a mere 'dumb' terminal, solely responsible for streaming raw data to a powerful cloud backend. This approach creates a critical single point of failure: if the network drops, the entire system grinds to a halt. Instead, I advocate for a Smart Edge, Simple Cloud architecture. This principle establishes a clear division of responsibility: The Edge : This is where the magic happens locally. The edge system should be robust enough to handle local processing , data filtering , buffering , and immediate hardware control . Critically, it must be capable of operating autonomously for extended periods without an active cloud connection. Think of it as a mini data center, designed for self-sufficiency. Benefits of a Smart Edge : Reduced bandwidth cost

I've wanted easy trunk-based development for Salesforce for years. Short-lived branches, frequent merges, small pull requests, and CI fast enough that developers aren't afraid to commit. The same practices that engineering teams use everywhere else. Every time I tried to make it work, I hit the same wall: Apex tests require an org. That single dependency turns every validation run into an infrastructure problem. Before a test can execute, you need authentication, environment provisioning, metadata deployment, test execution, and cleanup. The result is feedback loops measured in minutes instead of seconds. I got tired of waiting and built Nimbus, a local Apex runtime that executes Apex tests without an org. This is what I learned while trying to make trunk-based development actually work for Salesforce. Why trunk-based development is hard in Salesforce Trunk-based development depends on fast feedback. If validation takes seconds, developers make smaller changes, merge more frequently, and keep branches short-lived. If validation takes fifteen minutes, behavior changes. Pull requests get larger, unrelated work gets batched together, and validation stops happening continuously because validation itself becomes expensive. Salesforce has always had a structural challenge here because Apex only runs inside Salesforce. A typical validation pipeline looks something like this: sf org login jwt sf org create scratch sf project deploy start sf apex run test sf org delete scratch There is nothing inherently wrong with these steps. The problem is that most of them have nothing to do with testing. They're infrastructure management. The actual validation of business logic is only one part of the process. The longer I worked with Salesforce CI, the more obvious it became that the bottleneck wasn't Apex itself. The bottleneck was everything required to create an environment where Apex could run. The solutions I tried first Before building a local runtime, I tried solving the problem

I know it sounds strange, but I am in my first year in CS Major, and I don't like posting things on social media, but I found lately that companies are more likely to hire people who are active on social media like X (Twitter). For me, I genuinely post my projects on LinkedIn, but not sharing things like today I learned something new etc... What's your opinion about that? Or How can I manage that?

A notes app that lives in your MacBook's notch. Discussion | Link

submitted by /u/fagnerbrack [link] [留言]

Every time you open a new session with an AI coding tool, it starts from zero. It does not know what you decided yesterday, what failed last week, or what comes next. You have to explain the project again. And again. EGC (Extended Global Context) fixes this. EGC is a local runtime that gives every AI coding tool you use a persistent memory. At the end of each session, the AI saves what it learned: decisions made, what failed, your preferences, what comes next. At the start of the next session, it loads that state back automatically. One install. Every tool. Every session. Website: https://fmarzochi.github.io/EGCSite What it looks like in practice You open Claude Code on a project you have not touched in two weeks. Without typing anything: State loaded from egc-memory via ~/.egc/state/Projects--MyApp.md Context and preferences acknowledged. Ready to pick up: - Test full install on a clean machine - Add GEMINI.md with session memory protocol - Publish v1.0.1 fix after clean install test passes The AI already knows what you were building, what decisions you made, what failed, and exactly where you stopped. You did not type anything. You just started working. How it works EGC ships two MCP servers that run locally during every session. egc-memory: 14 tools for persistent memory Tool What it does get_state Loads project memory at session start update_state Saves decisions, preferences, and next steps store_decision Persists a single decision to SQLite query_history Returns past decisions by timestamp search_history Full-text search with BM25 ranking working_memory_set Stores transient context with a TTL lesson_save Records cross-session knowledge with confidence decay lesson_recall Retrieves active lessons above a threshold detect_patterns Surfaces repeated commands and recurring errors compress_observations Compresses hook events to save token budget State files live at ~/.egc/state/<project-slug>.md . One file per project. Plain Markdown. Human-readable. egc-guardian:

Doing the work and being able to explain the work are two different skills. I've had the first one for 8 years. I'm building the second one now. I'm a Cloud Platform Engineer. AWS, Kubernetes, Terraform, Linux. Regulated environments, healthcare, production systems. Real experience. Almost zero public documentation of it. That's the gap I'm closing, starting from Day 1. The platform is KodeKloud. Each session gives you tasks across multiple tools. I'm posting the Linux and AWS tasks here. Here's what I built and what actually matters about each one. Task 1 (Linux): Create a User with a Non-Interactive Shell The task was to create a system user that can own processes but cannot log in interactively. This is what you do for service accounts. bash ssh user@hostname sudo su - useradd username -s /sbin/nologin cat /etc/passwd | grep username The /sbin/nologin shell is the important part. The user exists in the system, can own files and run processes, but cannot open a shell session. You verify by checking /etc/passwd because the last field in each line is the assigned shell. I've been doing this in production environments for years. I still verify every time. Not because I'm unsure. Because in a regulated environment, you don't assume, you confirm. Task 2 (AWS): Create an EC2 Key Pair via CLI aws ec2 create-key-pair \ --key-name my-key-pair \ --key-type rsa \ --key-format pem \ --query "KeyMaterial" \ --output text > my-key-pair.pem aws ec2 describe-key-pairs --key-names my-key-pair The private key is returned exactly once at creation. AWS does not store it. If you lose it, you generate a new one and replace it everywhere it was used. I've seen this cause real problems in production environments where the key wasn't backed up properly. Always run chmod 400 my-key-pair.pem after saving it. SSH will refuse to use a key file with open permissions. It won't tell you that's the reason straight away. What Day 1 Taught Me That 8 Years Didn't Nothing here was technically new to

The Quest Begins (The "Why") Honestly, I was tired of staring at charts at 2 a.m., trying to catch that perfect entry while my coffee went cold. I’d set a manual alert, jump onto the exchange, click “buy”, and then second‑guess myself as the price slipped away. It felt like I was playing a never‑ending game of Whac‑A‑Mole, and I kept losing the mole. One night, after yet another missed opportunity, I thought: What if I could offload the repetitive bits to a script? Not a fancy AI that predicts the future—just a simple bot that watches the market, checks a condition, and places an order when the condition is met. If I could automate the boring part, I could focus on strategy, learning, and maybe even get some sleep. That was the dragon I wanted to slay: the exhaustion of manual trading. The Revelation (The Insight) The big “aha!” moment came when I realized I didn’t need to build a high‑frequency trading engine from scratch. There are solid, well‑tested libraries that handle the messy bits—authentication, rate limits, WebSocket connections—so I could concentrate on the logic. Using CCXT (a unified crypto exchange library) and a touch of asyncio , I could write a bot that: Connects to an exchange (I used Binance’s testnet so I wouldn’t lose real money). Polls the ticker for a symbol at a reasonable interval. Checks a simple condition—like “price > 20 % above the 20‑period moving average”. Places a market order if the condition holds, then waits for the next cycle. It felt like Neo dodging bullets in The Matrix when the bot finally executed a trade without crashing or getting rate‑limited. The relief was genuine: I could now let the code do the watching while I worked on the next idea. Wielding the Power (Code & Examples) The Struggle – A Naïve Loop My first attempt was a blocking while True loop with time.sleep . It looked harmless, but it had two nasty traps: Trap #1 – No error handling. A network hiccup would raise an exception and kill the whole script. Trap #2 – I

There is a class of feature that used to be impossible to ship for free: anything that needed a language model. You wired up an API key, you ate the per-token bill, and every prompt your users typed went off to someone else's server. For a small public tool, that math usually killed the idea before it started. That changed. Recent versions of Chrome ship a language model, Gemini Nano, and expose it to any web page through the Prompt API . The model runs on the user's own machine. No API key. No inference bill. No data leaving the browser. We put this into a real, live tool, a free Mermaid diagram editor where you describe a diagram in plain English and the browser writes the Mermaid code for you. This post is the developer's version of that story: how the API actually works, the code that makes a small on-device model trustworthy, and an honest accounting of what you gain and what you give up. What "AI in the browser" means in 2026 The important word is built-in . This is not WebGPU plus a 4 GB model you download and run yourself. The model ships with Chrome, and you talk to it through a small standard-track JavaScript API. As of Chrome 148, the Prompt API is stable for web pages (it had been available to extensions since Chrome 138). It is the general-purpose member of a growing family of built-in APIs: Prompt API ( LanguageModel ): general natural-language prompting, now multimodal (text, plus image and audio input). Summarizer, Writer, Rewriter, Proofreader : task-specific, text-to-text. Translator and Language Detector : backed by expert models, desktop only. The Prompt API is the one you reach for when you need something the task APIs don't cover, like "turn this description into Mermaid source." So that is the one this post focuses on. The 15-line version Here is the whole happy path. Check availability, create a session, prompt it. // Feature-detect first. Old browsers won't have this at all. if ( ' LanguageModel ' in self ) { const status = await LanguageMod

Chaos engineering sounds expensive. Netflix built Chaos Monkey to randomly kill production servers. Google runs DiRT (Disaster Recovery Testing) across their entire infrastructure. Amazon does game days where they intentionally take down services. You're building a Node.js API. You don't have a platform team. You don't have a chaos infrastructure. But you still need to know: what happens when your dependencies get slow? The good news is that 80% of the value of chaos engineering comes from one question, and you can answer it locally in five minutes. The one question that matters What does my application do when a dependency responds slowly or not at all? Not "what if the server catches fire" — that's infrastructure chaos. What about application chaos: the database is slow, the payment API is timing out, Redis is having a bad day. These happen constantly in production and they're almost never tested. The failure modes look like this: Your DB gets slow under load → your API response times climb → your timeout fires → you retry → now you're sending twice the load to an already-slow DB Your Redis cache goes down → every request hits Postgres directly → Postgres gets slow → same cascade Stripe's API takes 3 seconds instead of 200ms → your checkout route times out → users get errors → you're losing revenue Every one of these is a latency failure , not a crash. The service is still up. It's just slow. And slow is the hardest failure mode to test because your local environment is fast. Why local testing misses this When you test locally, your "database" is either: A real local Postgres running on the same machine (sub-millisecond latency, not production-like) A mock that returns instantly ( jest.fn().mockResolvedValue(data) ) A fake with a flat delay ( await sleep(200) ) None of these produce realistic latency. A real production database has: Fast responses most of the time (p50 ~5ms) Occasional slowdowns (p95 ~50ms) Rare but real spikes (p99 ~200ms, p99.9 ~2000ms) The spik

For 13 years I have worked in production at a steel-tube manufacturer. Not in an office — on the floor, with the machines, the night shifts, the handovers at 6 a.m. A few years ago I started building software in my free time. Not tutorials for their own sake — tools that solve problems I actually see every day. Why a factory worker writes code In production you learn one thing fast: it does not matter what looks good on a slide. It matters what works at shift handover. That perspective turned out to be my biggest advantage as a self-taught developer — I know the problem before I write the first line. What I have built PIPEZ — a shift & part-count PWA. Offline-capable, running on Cloudflare Workers + D1, live in production to capture shift and piece-count data that used to live on paper. A tool-management app. A multi-user client-server app with optimistic concurrency and a local AI assistant, used daily in the office to manage the lifecycle of dies in tube production. DeepCode — an agentic AI coding client. Electron + React + TypeScript, with its own tool loop, a swarm mode, and CI/tests. The project I am proudest of. Plus multi-agent systems, RAG pipelines, and n8n automations that run every day. The stack Python/FastAPI, TypeScript/React, Node, Docker, PostgreSQL + pgvector, Cloudflare Workers, MCP, computer vision. Writing in public I will be writing here about the bridge I keep coming back to: real production experience plus building with AI. If you are automating something messy and real, I would love to compare notes.

Project Log #9: My AI Agent Works on My Phone. But What About Yours? Okeke Chukwudubem Okeke Chukwudubem Okeke Chukwudubem Follow Jun 20 Project Log #9: My AI Agent Works on My Phone. But What About Yours? # ai # webdev # programming # productivity 1 reaction Add Comment 3 min read