📝 Originally published in Japanese on Zenn. This is the English version. Canonical: https://zenn.dev/uya0526_design/articles/satellite4_ai-collaboration 📚 This is satellite article #4 (the finale) in my "Read-Aloud Speed Meter dev log" series. For the whole picture, see the main article . Where This Sits The read-aloud speed meter was the first project where I adopted "AI-collaborative development" as an explicit mode. Until then, my learning style was "I write all the code myself; AI is a reviewer." With a contest deadline looming, I stepped one notch further. This article isn't a technical deep dive — it's a reflection on the development style itself. Three things: The reframe from "did you use AI" to "are you the one driving" The stumbles I actually hit in AI collaboration, and the patterns I pulled out of them Why rejecting an AI suggestion was the single most important thing 💡 This is a record of an ex-Java SE engineer learning TypeScript and Python in public. It's less a technical article and more a reflective, prose-y piece on the development process. I Switched Styles My learning articles have always run on a rule: I write the code myself; I use AI for hints, spec clarification, and bug spotting. Typing every word myself had learning value. This time there was a contest deadline, and a huge amount to cover. So I switched into a collaborative mode: AI demonstrates boilerplate (recording, fetch, API Route skeletons), and I handle the conceptual core and the design decisions. The awkward part was how to disclose that in the article. I'd publicly stated my AI use for code before, but this time I collaborated with AI on the article's outline, structure, draft prose, and even translation. In a contest with money (a prize) on the line, blurring that didn't feel honest. At first I framed it as "using AI is no different from accepting an IDE's autocomplete." But that was inaccurate. Autocomplete ≈ word/line-level completion This time ≈ delegating outline, structure,

📝 Originally published in Japanese on Zenn. This is the English version. Canonical: https://zenn.dev/uya0526_design/articles/satellite3_metrics-rationale 📚 This is satellite article #3 in my "Read-Aloud Speed Meter dev log" series. For the whole picture, see the main article . Where This Sits The read-aloud speed meter converts speaking speed into an evaluation label like "slightly fast," and stagnation rate into one like "few." Those labels ultimately become the foundation for Claude Haiku's feedback. So — on what basis did I draw the thresholds (the dividing lines)? This article digs into that "basis." The short answer from my research: I couldn't find a paper that defines an academic threshold for "N characters/min = fast/slow." This is a record of how I drew the lines honestly once I'd learned there was no firm basis. More than the metric numbers themselves, I believe being transparent about why I chose those numbers is what makes an evaluation app trustworthy. 💡 I'm an ex-Java engineer learning TypeScript in public. This one is mostly about design decisions. Why Obsess Over the "Basis"? An evaluation app passes judgment on the user: "your reading is slightly fast." Once you're passing judgment, if you can't explain "why we can say that," it's just guesswork. This app in particular passes the labels straight to Claude Haiku to generate coaching. If the foundational label has an unclear basis, the feedback built on top of it is a castle on sand. So I decided to nail down the basis for the thresholds first. Two things to research: The judgment basis for speaking speed (characters/min) The judgment basis for stagnation rate (the proportion of silence) As it turned out, these two had completely different kinds of basis. Speed Thresholds: No Academic Threshold → Draw From General Rules of Thumb What I found For speaking speed, I first looked for academic backing. Here's what I found: Speaking speed has traditionally been measured against mora count, but prior researc

📝 Originally published in Japanese on Zenn. This is the English version. Canonical: https://zenn.dev/uya0526_design/articles/satellite2_haiku-coaching 📚 This is satellite article #2 in my "Read-Aloud Speed Meter dev log" series. For the whole picture, see the main article ; for the AmiVoice integration, see satellite #1 . Where This Sits This article covers the part of the read-aloud speed meter that hands the measured numbers to Claude Haiku to generate coaching as "one compliment + one improvement." Many articles that use generative AI just dump it on the model: "here's the recognized text, evaluate it nicely." This article is the opposite. Don't let the LLM do the math. All computation and rule-based decisions are settled in code, and Haiku only does the wording. I'll go through how I designed this "two-stage" split, and which swamps I sank into during implementation. Four things: Why "code does the math, Haiku only does the wording" (the role-split design) The finalized prompt, and the messages / system / cache_control implementation First-hand findings: the prompt cache that didn't work The moment real data slapped me with "written in the prompt ≠ obeyed" 💡 I'm an ex-Java engineer learning TypeScript in public, so I drop in Java comparisons. Why Not Let Haiku Do the "Math"? Up front: Haiku is more than enough for feedback generation — in fact, you can shape the task into something Haiku is good at. The key is the role split. I settle all the metric computation (speaking speed, stagnation rate, threshold decisions) entirely in code. So by the time it reaches Haiku, it's already settled facts like this (below is from running labelMetrics on a real measurement — reading the Heike sample during development; stagnationRate is a number for percentage display): { "pureSpeakingSpeed" : 322 , "pureSpeakingSpeedEvaluation" : "slightly fast" , "stagnationRate" : 0 , "stagnationRateEvaluation" : "few" } Haiku's only job is to translate these numbers and labels into warm, c

Built a Local AI Agent That Controls My Phone — Completely Free, Completely Private somin254 somin254 somin254 Follow Jun 18 Built a Local AI Agent That Controls My Phone — Completely Free, Completely Private Add Comment 1 min read

📝 Originally published in Japanese on Zenn. This is the English version. Canonical: https://zenn.dev/uya0526_design/articles/satellite1_amivoice-bff 📚 This is satellite article #1 in my "Read-Aloud Speed Meter dev log" series. For the whole picture, see the main article . Where This Sits In the read-aloud speed meter app, this article covers the part that sends browser-recorded audio to the AmiVoice API to get back recognized text plus timestamps. The theme is calling an external API without exposing your API key to the browser — in other words, implementing a BFF (Backend for Frontend). The main article only touched the highlights, so here I go down to a level you can reproduce yourself. Specifically, four things: Why you must not call AmiVoice directly from the browser (why a BFF is needed) AmiVoice's synchronous HTTP auth, parameters, and multipart order Why the browser's MediaRecorder output (WebM/Opus) passes through as-is Reshaping the raw JSON with a pure-function mapper and testing it with fixtures 💡 I'm an ex-Java engineer learning TypeScript in public, so I drop in comparisons to Java here and there. Why a BFF Is Needed Using the AmiVoice API requires an API key. And that key must never appear in browser-side code. Frontend JavaScript is fully inspectable by the user, so writing the key there leaks it instantly. So I insert a relay that holds the key. [Browser] ──audio Blob──▶ [Next.js API Route (BFF / holds key)] ──▶ [AmiVoice API] record / display audio field reshape into u / d / a speech → text The browser only calls my own API Route ( /api/recognize ), and that Route attaches the key server-side and forwards to AmiVoice. The key is just read from process.env and never ends up in the bundle shipped to the browser. ☕ Java comparison: This is the same as a Spring @RestController reading an external API key from application.yml (env vars) and relaying without showing it to the client. Think "a thin Servlet that hides the secret and relays an external API."

A few months ago I started building small tools as single HTML files - no npm, no React, no backend. Just one file that opens in a browser and works offline. I built 4 real products this way: DarkenAmber IT Tools - 17+ developer tools in 194KB ZeroOffice - PDF, image, AI tools in one file PrivacyKit - Photo privacy tools, no upload required ElectroKit - Electrical calculator + cost estimates for CIS market Every single one: one .html file. Works offline. Opens instantly. No server. The problem with AI coding assistants Every time I asked Claude or Copilot to build something simple, I got: A React project with src/ folder package.json with 12 dependencies webpack config TypeScript setup ...before writing a single line of actual logic. I kept manually correcting it. "No, one file. No npm. Vanilla JS." Then I realized - I should just teach it once and reuse that knowledge. What is a Claude Skill? A skill is a Markdown file with YAML frontmatter that changes how Claude thinks for a specific context. It is not a prompt. It is not a system message. It is a reusable set of rules that shapes how Claude reasons, what it prioritizes, and what it avoids. yaml--- name: single-file-app description: "Build complete web tools as a single HTML file - vanilla JS, inline CSS, localStorage, offline-first." tags: html vanilla-js offline version: 1.2 --- The two skills I built single-file-app Teaches Claude to build complete web tools in one HTML file. What changes: No React, no npm, no build tools unless truly justified Vanilla JS first, always localStorage for data persistence Dark/light theme with system preference detection Accessibility built in (labels, aria, keyboard nav) XSS prevention for user input Export/import for user data Anti-patterns it prevents: ❌ "Let me set up a React project" ❌ Creating src/ folder for a simple tool ❌ Suggesting npm install for a calculator ✅ "Here is your complete HTML file" ship-it Teaches Claude to bias toward shipping over planning for early-stag

📝 Originally published in Japanese on Zenn. This is the English version. Canonical: https://zenn.dev/uya0526_design/articles/main_article_reading-speed-meter Introduction — What I Built I built a web app that lets you read a Japanese passage aloud, measures your speed and fluency, and has an AI coach return a one-line piece of feedback. 🌐 Demo: https://reading-speed-meter.vercel.app/ 📦 Repository: https://github.com/uya0526-design/reading-speed-meter The flow is simple. You read a passage aloud into the mic (up to 10 seconds) while looking at the script — I prepared the opening lines of two Japanese classics, The Tale of the Heike and Hōjōki — and when you press "Measure," : AmiVoice API recognizes the audio, the code computes your pure speaking speed (characters/min) and stagnation rate from that result, and Claude Haiku returns coaching as "one compliment + one improvement." (Measurement starts on a button press after recording — it never runs automatically.) This article aims to be a single, self-contained piece covering the whole picture, the design decisions, and the reproduction steps . 💡 Where this sits in my journey I'm an ex-Java engineer learning TypeScript and Python in public. This was my first project where I deliberately adopted "AI-collaborative development" as a clear mode. Throughout, I'll drop in comparisons to Java — hopefully useful for anyone coming from a similar background. What You'll Get From This Article How to design evaluation logic that fully exploits the per-word timestamps AmiVoice returns How to build a BFF (Backend for Frontend) so API keys never reach the browser A "two-stage" design where code does the math and Claude Haiku only does the wording First-hand findings you only learn by verifying — e.g., "I thought I'd optimized it, but it wasn't actually working" I include concrete endpoints, parameters, and environment variables so you can reproduce it yourself. My Learning Style (AI Transparency) 💡 Learning companions & how this art

Everything you need in one native macOS command bar Discussion | Link

One of the oldest axioms of software engineering is that code is written primarily for humans to read, and only secondarily for machines to execute. Clean code, expressive variable names, and architectural elegance all serve a single purpose: to ensure that the next developer - or our six-months-older self - can understand what on earth happened. Code has always been a cultural artifact, a shared language, a bridge between human intent and silicon. But what happens to this bridge in the era of vibe coding? We are rapidly moving toward a reality where code is generated by LLMs and pull requests are reviewed by LLMs. When the resulting string of characters is spawned by a machine and audited by a machine, human readability immediately ceases to be a primary metric of quality. This forces a radical question upon us: If code no longer needs to be human, does the code itself need to change? Why do we still cling to Python, to micro-frontends, or to neatly structured repositories? We invented these structures to accommodate the cognitive limitations of the human brain - to keep ourselves from drowning in complexity. An AI doesn’t need these training wheels. To an LLM, a 50,000-line monolithic spaghetti-code mess, completely impenetrable to a human eye, is just as easy to parse as the most pristine clean architecture. So, what is the point of the code itself? Is it possible that code is merely a transitional, obsolete interface—a form of "digital carbon monoxide" that we will soon phase out entirely, replacing it with pure intent and mathematical weights? I ran this exact thought experiment in practice recently when I built a tiny, native macOS utility called Portia over a single weekend (you can check it out here: getportia.app ). The app's function is dead simple: when a port gets stuck (EADDRINUSE), it frees it up with a single click. Throughout development, I was almost exclusively in vibe coding mode. I wasn’t thinking about syntax; I was thinking about the problem an

Most AI coding assistants do not really remember your project . They remember just enough to be dangerous . They see the latest prompt, skim a few files, improvise, and then forget the reasoning that made the answer useful five minutes ago. That is fine for toy demos. It breaks down fast inside a real software codebase. In Knotic I take an harder line . Instead of treating memory like a chat log with extra lipstick, I treat memory as infrastructure . Project knowledge is separated from session knowledge. Source material is separated from condensed understanding . Old context is compressed instead of blindly dragged forward. The result is a system that feels less like autocomplete with a caffeine habit and more like an AI engineering partner that can stay oriented over time. If you care about AI coding assistant memory , context engineering , persistent project memory , or long-term memory for software development , this is the part worth paying attention to. The Real Problem With AI Memory in Coding Tools The average AI IDE has the same failure mode . It looks smart on the first turn and shaky on the fifth . Why? Because software work is not just about answering the latest question. It is about carrying forward constraints, architecture, naming conventions, decisions, tradeoffs, dead ends, file relationships , and the exact context of the change in progress. When an assistant does not separate those layers, everything gets mixed together . Stable project facts sit next to temporary tool output. Important decisions compete with random noise. The model burns tokens re-reading the same files, or worse, works from partial memory and starts making up the missing pieces . Knotic solves this by splitting memory into distinct layers , each with a clear job. That design choice sounds simple. In practice, it changes everything . Knotic Does Not Use One Memory. It Uses Three. Knotic's memory model is built around three different kinds of context . The first is long-term projec

I've been an engineer for almost 9 years, and I know from experience how much coding has changed over the years. Right now Im working in a big blockchain company and honestly I feel pretty exhausted. BUT NOT FROM THE TASKS I EXECUTE. I think with AI now, my work is more like being a human API. Lol. I got to slack, emails, JIRA and zoom calls to interact with people and gather all the context needed in order to make sure that when I will use AI the results will be relevant and accurate. And I feel that this is actually draining me. And i realized that this because every time we open PRs and it is about time to review things, CIs are freaking failing everywhere and then I have to go back and forth with people on slack to get the missing context. And all that even if we have already done scoping, architectural decisions. I feel we rush so much to deliver things fast, due to the AI-speed pressure, that is causing all this. I actually found many articles online talking about this. Anthropic also did their own index for checking if the fatigue is real from AI usage. I linked a medium article that resonated with me on the topic. Are you also facing this issue at your job? If so, how are you dealing with this, apart from taking more walks at the park lol. submitted by /u/LeopardAfter493 [link] [留言]

Simon Brown explains that the C4 Model started not as a grand design theory, but as a practical answer to an embarrassing problem. Furthermore, he answers the question on how to handle microservices in C4 and explains the important distinction between modeling and diagramming. submitted by /u/goto-con [link] [留言]

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

Autonomous penetration testing platform Discussion | Link

This is today’s edition of The Download, our weekday newsletter that provides a daily dose of what’s going on in the world of technology. The search for dark matter has been blown wide open For decades, physicists have hunted for weakly interacting massive particles (WIMPs), a leading candidate for dark matter. But their search has…

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