DEV Community

I built a radio station with one listener, and it runs in a terminal

zhiyi guo — Sun, 13 Sep 2026 03:23:31 +0000

The film above is 86 seconds, and the middle of it is a real on-air moment. There is a longer unedited recording at the top of the repo README. Watch either first, with the sound on. The rest of this post is why it exists and how it is put together.

What it is

murmur runs in a terminal window and behaves like a radio station whose only listener is you. It picks a topic on its own and talks about it in a voice that sounds like a person. Then it plays a song, comes back, and keeps going. At the right hours it says good morning and good night. You do not have to answer any of it.

When you do type something, the host replies in character. You chat for a bit. Then it eases back into the program.

There is one host. A few questions on the first run write its character to a file. After that, nothing rewrites that file except you. What grows over time is a separate thing: what it knows about you.

Why I built it

Every AI tool on my machine wants me to go faster. That is fine for work, and it is exhausting as company. I wanted something that sits closer to the person than to the task. A late-night radio host does that. They talk whether or not you are listening, they never ask you to respond, and when you do call in, they are glad and then they get back to the show.

Nothing I found did the proactive half. Chat assistants wait for a prompt. Voice tools want to drive my editor. So the bet was simple: what if the AI speaks first and needs nothing back?

How it is built

It is TypeScript on Node 24, no build step, run straight from source.

The brain is Claude, opened through the Claude Agent SDK. It reuses your local Claude Code login, so there is no API key and no separate bill. It is a harnessed agent rather than a one-shot call. murmur gives it a small set of its own tools: search for a song, judge the candidates, commit a pick, update memory, run the setup guide. It is sealed off from your own Claude Code setup. None of your CLAUDE.md files, skills, MCP servers, or hooks reach it.

The voice is fish-speech, reached over a hosted HTTP endpoint you point it at. That is the reason it sounds like a person and not a screen reader. It is also the reason murmur is not a local tool, and I want to say that plainly: the brain and the voice are network services. What stays on your machine is the program logic, the keyboard, the mixer, the persona, and the memory.

Music comes through yt-dlp. The rules it picks by live in a markdown file under ~/.murmur. The pick task re-reads that file before every song, so if you write "more Cantonese, no covers" while a track is playing, the change reaches the next pick or the one after.

The mixer is a Web Audio graph on node-web-audio-api. Voice and music share one output stream. A gain envelope ducks the song under the host, so the lead-in is spoken over the head of the track and the back-announce over its tail. The song never stops for the voice.

Two processes. The engine owns the program and the audio. The TUI is a separate process on OpenTUI under Bun, attached over a unix socket carrying newline-delimited JSON. Without Bun it falls back to a plain text host in the same process, and every command still works typed in full.

The decision people ask about

The host's character does not evolve. I built the evolving version first. A background loop watched the conversation and rewrote the persona to fit the listener better. Within days it had drifted into the same generic assistant voice every chatbot has. Language-model rewrite loops mean-revert, and there was no checkpoint where a person could catch the drift.

So the persona is frozen. It is a text file. You can open it and rewrite it whenever you like, and nothing changes it behind your back. The memory of you is a separate tier that does grow, with dates the code owns and citations back to the conversation that produced each fact.

What is rough

It needs a Claude Code subscription for the real brain. --brain stub gives you a canned stand-in brain for a look around, and that is all it is.
The voice is hosted. If you have no endpoint configured, it prints its lines instead of speaking. A local TTS is on the list, not in the code.
Music picks sometimes stall or run long. There is an open issue with measurements.
It is developed on macOS. Linux should be fine. Windows is untested.
Onboarding is still being tuned by ear, and one path after /quit misbehaves.

Try it

Node 24 or newer:

npm install -g murmur-radio
murmur

It launches even with pieces missing and offers to walk you through installing ffmpeg, yt-dlp, and a voice endpoint by talking to you. Say no once and it stops asking.

Repo: https://github.com/wine-fall/murmur (MIT). Landing page: https://wine-fall.github.io/murmur/.

If you leave it on for an afternoon, I would like to know one thing: did it feel like radio, or like a chatbot with a timer?

From SkillCheck to TraceMantle: Tracking Agent Skill Changes and Test Evidence

Brad Kinnard — Sun, 13 Sep 2026 03:22:03 +0000

I’ve renamed SkillCheck to TraceMantle and expanded its scope. The original project focused mainly on validating AI agent skill files. TraceMantle retains that functionality and adds support for tracking the files in a skill package, comparing changes, and checking whether previous test evidence still applies.

The rename resolves a conflict with another project using the SkillCheck name. It also better reflects the tool’s broader purpose: helping developers assess both the contents of an agent skill and the evidence used to approve a particular version. The project is available on GitHub.

Why I expanded the scope

An agent skill can include more than its main SKILL.md instruction file. Supporting scripts, reference documents, templates, and schemas can all affect how it behaves.

Consider a skill that uses a Python helper to process a document. The instructions remain unchanged, but someone modifies the helper. A passing test report from the previous version may no longer cover the current behavior. Checking only the instruction file would miss an important part of that change.

TraceMantle addresses this by connecting package changes with the evidence supplied for its checks. The aim is to make it easier to identify which earlier results remain relevant and which checks need to run again.

What changed

Skill validation remains part of the tool. TraceMantle checks frontmatter, file references, size limits, and compatibility advice. These checks help identify structural problems before a skill is committed or released.

The expanded functionality adds three related capabilities:

Bundle manifests: A manifest records the files in a skill package and their content fingerprints. This allows TraceMantle to detect changes to supporting resources even when SKILL.md stays the same.
Evidence imports: The tool can import results from a supported, version-pinned Promptfoo export format. It preserves the original export and records information about the evaluated inputs, configuration, checks, and execution context.
Evidence comparison: A comparison checks supplied evidence against the package and a trusted policy. It reports changed inputs, incompatible results, and checks that require another run.

The commands support text, JSON, and GitHub annotation output, allowing the same information to be used during local development or within a CI workflow.

How the approval rules work

An imported report does not become trusted simply because it contains a passing result. The project owner or trusted automation must approve the evidence through a policy that identifies the required checks and their inputs.

TraceMantle reads that policy from a specific trusted Git revision. Changes in the candidate package cannot replace the selected policy or quietly make a required check optional.

The comparison also distinguishes a failed check from missing or unsuitable evidence. An unknown result means the available evidence does not establish a pass. That distinction helps avoid treating an incomplete evaluation as either a successful release check or a confirmed failure of the skill itself.

The evidence workflow documentation explains the supported format, approval process, and comparison states.

Engineering changes behind the features

The work also included improvements to parsing, configuration, reporting, and history storage. Analysis stages share a parsed document model to reduce repeated work, while file-size and parser limits help control resource use when processing external input.

New history records are stored individually outside the evaluated bundle. Migration from the older history format is explicit and preserves the original files. The release workflow also checks built packages through clean installations, alongside tests, linting, and strict type checking.

These changes support the broader workflow while keeping TraceMantle a local Python CLI and library.

What the tool establishes

TraceMantle analyzes files and supplied evidence. It does not run agent skills or evaluators itself, and a structurally valid skill is not proof that an agent will perform a task correctly.

Its dependency analysis also has defined limits. It cannot infer every runtime dependency or arbitrary programming-language import. Trusted checks still need accurate input declarations, and incomplete coverage should require further evaluation.

Live agent performance remains unverified in the project’s current evaluation record. Static checks, imported model judgments, and synthetic test fixtures have separate meanings and should remain distinguishable.

Current status and migration

TraceMantle 1.6.0 is published, with subsequent changes recorded under Unreleased. A recent audit identified two remaining defects involving Markdown dependency detection and numeric JSON input handling. One can cause a required rerun to be missed; the other can crash an import. Those corrections remain necessary before calling the implementation complete.

Existing SkillCheck users should follow the migration guide. TraceMantle is a separate Python distribution, so installing it is not an automatic upgrade of the old package.

The repository contains the source, examples, tests, and implementation records for anyone interested in reviewing or contributing to the project.

Day 8 - Relational Database 101 - PostgreSQL Internals

Monirul Islam — Sun, 13 Sep 2026 03:20:00 +0000

আপনি এবং আপনার friend একটা seminar-এ গেছেন, seminar-এ speaker-রা তাদের মতামত share করছেন। মাঝে মাঝে কিছু important কথা বলছেন। এই কথাগুলো আপনার friend note করছে, কিন্তু আপনি কিছুই note করেননি। Seminar শেষ হওয়ার পরের দিন আপনি সবকিছুই ভুলে গেছেন, আবছা আবছা মনে আছে কিন্তু সম্পূর্ণ মনে করতে পারছেন না। উপায় না পেয়ে আপনার friend-কে জিজ্ঞেস করলেন। ও সবকিছুই সুন্দর করে বলে দিলো। কারণটা নিশ্চয়ই বুঝতে পারছেন। ও কেন সবকিছু মনে রাখতে পারছে? কারণ ঐ friend সবকিছুই note করে রেখেছে বা save করে রেখেছে।

একবার একটু technological দিকে আসি, আপনি যখন Facebook বা LinkedIn-এ কাউকে message করেন তখন সেটা সরাসরি তার কাছে send হয়। Reason হচ্ছে আপনারা connected। এখানে আপনি directly message তার কাছে send করছেন; network to network। কিন্তু মজার বিষয় হচ্ছে আপনি পরে যখন disconnected তখনও message-গুলো দেখতে পারছেন। হিসেব অনুযায়ী পরে message-গুলো থাকার কথা না। তাহলে হচ্ছেটা কী?

আপনি বা অন্য কেউ যখন message send করছেন তখন সেই message-টা first-এ server-এ আসে, সেই server message-টা save করে। Save করার পর তারপর receiver-এর কাছে message-টা forward করে দেয়। সেই জন্য আপনি message-টা দেখতে পারছেন।

এখন যেখানে বা যার মাধ্যমে save করা হচ্ছে, সেটাই হচ্ছে Database।

Database কী এবং কেন?

সহজভাবে বললে database হচ্ছে data রাখার জায়গা। এখন বলতে পারেন file system-এর মাধ্যমে তো hard drive-এ data রাখা যেতেই পারে। তাহলে separate database-এর দরকার কী? এই question একদম valid। মজার ব্যাপার হচ্ছে database behind the scene-এ এই file system use করেই data store করে। এই শুনে আপনার মনে হতে পারে তাহলে direct file system use করলেই তো হয়।

আসলে file system-এ data রাখাই যায়, কিন্তু problem হয় যখন search করা হয়। 1 million data থেকে একটা specific data খোঁজার জন্য file system প্রত্যেকটা file check করে তারপর আনতে হবে। তাহলে কতটা time লাগবে বুঝতে পারছেন? এত time লাগলে আপনার use কী থাকবে?

এবার database কীভাবে কাজ করে এবং এই problem-টা solve করে সেটা জানার try করি। Database মূলত file system-এর ওপরে একটা layer তৈরি করে। এখানে শুধু file store করা ছাড়া আরও অনেকগুলো কাজ করা হয়ে থাকে। For example, database-এ indexing নামে একটা feature আছে। ওপরে যে 1 million data-এর ভেতরে searching করার যেই বিষয়টা বললাম, indexing করার পরে এই operation-এ time direct file system-এর থেকে 10x-20x কম লাগবে। কীভাবে লাগবে সেটা নিচে একটা section আছে ওখানে বুঝতে পারবেন।

Hopefully database সম্পর্কে idea হয়ে গেছে।

Relational Database কী?

একটা simple question করি? আপনার পিতা-মাতা ছাড়া logically আপনার কি কোনো অস্তিত্ব থাকবে? আপনার তো জন্মই হবে না। এর মানে আপনি তাদের ওপর dependable। তারা যদি history-তে exist না করে আপনিও করবেন না। এরকম অনেক রকম জিনিস আছে, আপনার ভাই বোন, দাদা দাদি।

এখানে একটা জিনিস খেয়াল করেন, ২টা আলাদা type-এর জিনিসের মধ্যে একটা relation থাকছে। এখানে relation-গুলো কিন্তু একেকটা একেকরকম, কিন্তু কিছু limit বা কিছু জিনিস বাদ দিয়ে দিলে, কয়েকটা relationship থেকে যাবে।

আসলে relational database-গুলো অনেকটা এভাবেই connected। এখানে প্রত্যেকটা entity-এর জন্য একটা করে table থাকে, table-এ column থাকে এবং row wise database add হয়। এই column-এই কিছু data রাখা হয় যাতে relation create করা যায়।
For example, parent & children table আছে। এখন children table-এ row add করার সময়, একটা extra field add করবো, for example parent। এই parent-এর value দিয়ে determine হবে ঐ children-এর parent কে বা কারা।

আসলে database একটা long long topic। এর syllabus অনেক long। অনেকটা সমুদ্রের মতন। আমি just একটা ধারণা দিয়েছি। নিচে অনেক অনেক topic নিয়ে আলোচনা করা হয়েছে। সেগুলো পড়লে অনেক কিছু শিখতে পারবেন hopefully।

ACID: Four Pillars of Database

একটা জিনিস চিন্তা করেন, যখন কোনো কিছু standard হয়ে যায়, তখন তার required characteristics set করা হয়। যাতে same way-তে alternative নিয়ে আসা যায়। এরকমভাবে relational database-এর required characteristics হচ্ছে ACID। ACID মূলত ৪টা word-এর সংক্ষিপ্ত form: Atomicity, Consistency, Isolation & Durability। একটা relational database-কে এই ৪টা জিনিস provide করতে হবে। নিচে এগুলো নিয়ে একটু আলোচনা করলে বুঝতে পারবেন।

Atomicity

একটা ছোট্ট গল্প বলি, তাহলে relate করতে easy হবে। ছোটবেলায় আমার আম্মা আমাকে টাকা দিয়ে দোকানে পাঠাতো এবং বলতো এই জিনিসটা নিয়ে আসবি আর বাকি টাকা দিয়ে cake কিনে খাবি। এটাও বলতো যদি ঐ জিনিস দোকানে না থাকে তাহলে পুরো টাকা ফেরত নিয়ে চলে আসবি, cake কিন্তু কিনবি না। এখন একটা জিনিস লক্ষ্য করুন। হয়তো ২টা কাজই হবে, না হলে একটাও হবে না।

Relational database-এর ক্ষেত্রে যখন কোনো transaction-এর (এটা নিয়ে এখন bother হওয়ার দরকার নেই) ভেতরে either সবগুলো operation successful হবে or কোনো operation-ই হবে না। যদি fail করে, তাহলে তা automatic rollback হওয়ার feature থাকতে হবে। এই behavior-টাই হলো Atomicity।

Consistency

কিছু কিছু public আছে যাদের mind খুব দ্রুত swing হয়। একবার এই তো আরেকবার অন্যটা। এরকমটা যদি আপনার store করা information-এর ওপর হয় তাহলে কী হতে পারে একটু চিন্তা করুন।
Suppose, আপনার system-এ কেউ একজন একটা payment initiate করেছে। এই data-র status swing হচ্ছে, একবার failed, একবার success, কখনো pending। এমন হলে আপনি কি বলতে পারবেন, যে আসলে payment-টা হয়েছে কি না? বলা possible না। এই জন্য database-এ যে value store করেছি সেটা always সেই value provide করতে হবে। এটাই Consistency। সব সময় correct value provide করবে।

Isolation

একটা জিনিস চিন্তা করুন, আপনার application-এ same time-এ ২-৩ জন user payment start করলো। Normal ভাবেই এগুলো transaction-এর মধ্যে দিতে হবে। কারণটা তো বুঝতেই পারছেন। এখন ১ জন user-এর একটা problem হওয়ায় একটা operation fail করলো। এই কারণে বাকি user-দের payment-ও fail করলো। এখন আপনার কাছে question, এটা কি ঠিক হলো?

না, ঠিক হয়নি, তারা তো single user না, তারা আলাদা, সবকিছু আলাদা। তার problem শুধু তার payment-টা failed দেখাবে, বাকিগুলো নিজের মতো চলবে। এটাই তো হওয়া উচিত, তাই নয় কি? এই concept-টাই হচ্ছে Isolation। Isolation প্রত্যেকটা transaction-কে isolate করে রাখে। কেউ কাউকে interfere করতে পারবে না।

Durability

একটা scenario চিন্তা করুন, আপনার application-এর একটা user একটা data add করলো। প্রথম ২-৩ দিন সেই data দেখালো কিন্তু ৪ দিনের মাথায় যেয়ে সেই data আর নেই। তাহলে এখন সেই user কি আপনার system use করবে?
এখন মজার বিষয় হচ্ছে, এই data কেউ delete করেনি। System থেকে automatic হারিয়ে গেছে। অনেকটা RAM-এর মতো behavior। Power চলে গেলেই সব ভুলে যাওয়ার মতো অবস্থা।
এখানে solution কী হতে পারে? যাই হয়ে যাক, user-এর data database-এ store থাকতে হবে। এই জিনিসটাই হচ্ছে Durability।

এই topic-গুলো Relational Database-এর জন্য খুবই important। আমি just একটু idea দেয়ার try করেছি, আপনার mental model-টা create করার try করেছি। আপনার যদি ইচ্ছা হয় তাহলে আপনি পড়তে পারেন। তবে এটুকু বলতে পারি এগুলো আপনাকে ফেলে চলে যাবে না।

PostgreSQL কীভাবে Data Store করে?

PostgreSQL data রাখে pages (8KB block) হিসেবে। প্রতিটা table-এর data এই pages-এ থাকে। একটা row যদি multiple pages-এ ছড়িয়ে পড়ে, PostgreSQL সেটা handle করে TOAST mechanism দিয়ে।

Index: ডেটাবেসের সূচিপত্র

indexing-এর ব্যবহার তো একটু আগে একবার বলেছি। indexing জিনিসটা আসলে কী সেটা বোঝার try করি চলেন।

মনে করুন আপনার library আছে, সেখানে হাজার ২-এর মতো বই আছে। এখন আপনার প্রতিনিয়তই কোনো না কোনো বই লাগে। সেই বই খুঁজতে আপনার অর্ধেক time চলে যায়। তো এই problem-এর solution-এর জন্য আপনি চমৎকার কাজ করলেন। আপনি book-এর নামের শব্দের ওপর base করে সাজিয়ে রাখলেন। For example, প্রথম A দিয়ে start হওয়া বইগুলো, then B, then C, এভাবে। এতে সুবিধা কী হবে?
যখন আপনার কোনো বই দরকার হবে তখন, আপনি just সেই বইয়ের letter-এর কাছে চলে যাবেন। ব্যাস আপনার ২৬ ভাগের ২৫ ভাগ কাজ কমে গেলো।

ঠিক same concept-টা database indexing করার সময় use করে। একটা range তৈরি করে নেয় (for example)। যখন কোনো data insert করা হয় তখন ঐ indexing করা field-টা কোন range-এর ভেতরে যাবে সেটা select করে, ঐ range-এর ভেতরে push করা হয়। এখন ঐ field দিয়ে যখন কোনো query run করা হবে তখন তো সে ঐ range-এর ভেতরে যেয়ে খুঁজে আনবে।

PostgreSQL indexing-এর জন্য, B-Tree data structure use করে থাকে। এর search complexity অনেকটা binary search-এর মতো।

CREATE INDEX idx_users_email ON users(email);

এখানে users table-এর email field-এ indexing করা হয়েছে। এখন email দিয়ে query অনেক কম সময় নিবে।

আপাতত এই পর্যন্তই কারণ database indexing নিয়ে একটা dedicated article আসবে।

EXPLAIN ANALYZE

মনে করুন একটা system আছে যেখানে ৩-৪ রকমের আলাদা আলাদা system একসাথে মিলে কাজ করছে। এখন কোনো কারণে আপনার application slow হয়ে গেলো। তাহলে বুঝবেন কীভাবে? testing করে। আপনি সবকিছুই check করে দেখলেন, সব ঠিকঠাক। তারপরেও slow। আপনি কি আপনার SQL check করেছেন? আপনার SQL query-তে problem নেই সেটা আপনি sure? এখন হয়তো বলবেন এই তো, sure না।

এই জিনিসটা বোঝার জন্য default একটা feature থাকে, EXPLAIN ANALYZE। এটার মাধ্যমে আপনার query কোথায়, কীভাবে, কতক্ষণ run হয়েছে তা আপনাকে in-details দিয়ে দিবে। তখন easily determine করতে পারবেন, আসলে SQL-এ problem আছে কি না। নিচে একটা example দেয়া হলো।

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com';

এটা run করলে বুঝতে পারবেন email-এর জন্য আসলে indexing use হয়েছে কি না।

Connection Pool

আপনি যখন কোনো application develop করবেন তখন, backend থেকে database-কে connect করে database থেকে data fetch করবেন। Normal-ভাবে, যখন কোনো data fetch করতে হয় তখন প্রথমেই database connect করতে হয়, then needed operation-গুলো করা হয়। At last connection close করতে হয়। Close না করলে আপনার database server এই connection-গুলো memory-তে store করবে, একসময় যেয়ে দেখা যাবে memory শেষ হয়ে গেছে। আর তখন server crash করবে।
এখানে আরেকটা বিষয় আছে, এখন প্রতিবার connect-disconnect করার কারণে কিছু latency create হচ্ছে। এই latency যদি কমানো যায় তাহলে user experience increase হবে।

Connection pool-টা হলো এই দুইটার মাঝামাঝি একটা solution। Connection pool জিনিসটা active connection যা always database-এর সাথে connected হয়ে থাকবে। যখন দরকার তখন এই pool use করে data fetch করবে। এই হচ্ছে connection pool-এর basic concept। একটা example দিলে বুঝতে পারবেন।

মনে করুন আপনি ৫টা connection pool create করেছেন। এর বাইরে database connection-এর আর way নাই (for now)। এখন ৬ জন user একসাথেই request করলো, তখন এই ৫টা connection pool ৫টা user-এর request handle করবে, যখন এই ৫টা user-এর মধ্যে কারো কাজ শেষ হয়ে যাবে তখন ঐ connection pool-টা release হয়ে যাবে। Release হওয়ার সাথে সাথে ৬ নম্বর user-এর request-এ এই connection pool-টা use হয়ে যাবে। আর যদি কোনো request না থাকে তখন connection pool idle হয়ে থাকবে।

সহজভাবে বললে, connection pool হচ্ছে active database connection, যা always connect হয়ে থাকে। আর database query-এর জন্য এগুলো reuse হয়।

এখন বলতে পারেন তাহলে connection pool size একটা বড় number দিয়ে দিলে বেশি ভালো হবে? No, it's not like that। বেশি connection দিলে তো 1st situation-এর মতো memory শেষ হয়ে যেতে পারে। এই pool size-টা depend করে আপনার application-এর active user, আপনার database server এর memory + cpu, server এর read/write অপারেশন ইত্যাদি-এর ওপর। তাই pool size ঠিক করার আগে একটু calculation করা প্রয়োজন।

বটম লাইন

Database related concept প্রত্যেকটা developer-এর জানা উচিত। কারণ আপনি যত ভালোভাবে আপনার data-কে সাজিয়ে গুছিয়ে securely রাখতে পারবেন + সেগুলো efficiently serve করতে পারবেন, ততই আপনার application বা system-এর performance + longevity বাড়বে।

যদি আপনি Database নিয়ে আরও বিস্তারিত পড়তে চান তাহলে পরামর্শ হচ্ছে এই বই গুলো পড়ার,
১। Database Management System
২। Database Internals

একটা মজার কোথা বলি, প্রথম দিকে এই গুলো পড়তে আমার খুবই বোরিং লাগত, কিন্তু যখন একবার এর বেসিক এবং কোর বিষয় গুলো আয়ত্তে করে ফেলবেন তখন তখন আসল মজা টা পাবেন।

Database is the center point of backend system.

আপনার সবচেয়ে কঠিন database debugging experience কী ছিল? কমেন্টে শেয়ার করুন! 👇

EC2 Instance Unreachable via SSM Session Manager

Rafagross — Sun, 13 Sep 2026 03:12:04 +0000

Summary

This runbook resolves the situation where an EC2 instance is running and visible in the console but either does not appear in the Systems Manager Fleet Manager inventory, or returns a connection error when you attempt to start a Session Manager session.

When to Use This Runbook

Use this runbook when you observe any of the following:

Session Manager shows "Instance not connected" or "Unable to start session"
The instance does not appear in Systems Manager → Fleet Manager → Managed Nodes
ssm:StartSession returns TargetNotConnected
A previously working instance stopped responding to SSM after a restart, IAM change, or network modification

Step 1: Verify Instance State

Console path: EC2 → Instances → [Instance ID]

Confirm the instance is in running state and that both Status checks show 2/2 passed.

If status checks are failing, stop here and use the EC2 Status Check runbook. SSM is irrelevant if the instance itself is impaired.

Expected result: Instance state = running, 2/2 status checks passed.

Step 2: Check SSM Managed Node Status

Console path: Systems Manager → Fleet Manager → Managed nodes

Search for the instance ID. If it does not appear, or shows Connection Lost, the issue is one of: missing IAM role, stopped SSM agent, or blocked network path.

Expected result: Instance appears with status Online. If missing or Connection Lost, continue to Step 3.

Step 3: Verify IAM Instance Profile

Console path: EC2 → Instances → [Instance ID] → Security tab → IAM Role

The instance must have an IAM role attached with the AmazonSSMManagedInstanceCore managed policy (or equivalent custom policy granting the minimum SSM actions).

Minimum required IAM actions if using a custom policy:

ssm:UpdateInstanceInformation
ssm:ListInstanceAssociations
ssm:DescribeInstanceProperties
ssm:DescribeDocumentParameters
ssmmessages:CreateControlChannel
ssmmessages:CreateDataChannel
ssmmessages:OpenControlChannel
ssmmessages:OpenDataChannel
ec2messages:AcknowledgeMessage
ec2messages:DeleteMessage
ec2messages:FailMessage
ec2messages:GetEndpoint
ec2messages:GetMessages
ec2messages:SendReply

Note: IAM propagation delay:
IAM role changes applied to a running instance take effect on next SSM agent heartbeat, typically within 2-3 minutes. If you just updated the role, wait 5 minutes and re-check Fleet Manager before continuing.

Expected result: IAM role attached with AmazonSSMManagedInstanceCore or equivalent. If missing, attach the role and wait 5 minutes.

Step 4: Check SSM Agent on the Instance

Console path: EC2 → Instances → [Instance ID] → Actions → Monitor and troubleshoot → Get system log

Look for lines referencing amazon-ssm-agent. A healthy agent shows:

amazon-ssm-agent.service: active (running)

Errors to look for:

Failed to start Amazon SSM Agent — agent start failure, likely OS-level issue
Error connecting to endpoint — network path problem (proceed to Step 5)
No SSM lines at all — agent not installed or not running

If the agent is not running, you can use EC2 Run Command with AWS-RunShellScript to restart it — but only if the instance is already registered (partial connectivity). If it's fully unreachable, use EC2 Instance Connect or serial console (if available) to restart manually.

Expected result: SSM agent running. No connection errors.

Step 5: Diagnose the Network Path

SSM Session Manager requires outbound HTTPS (port 443) from the EC2 instance to three regional endpoints:

Endpoint	Purpose
`ssm.{region}.amazonaws.com`	Agent registration
`ssmmessages.{region}.amazonaws.com`	Session data channel
`ec2messages.{region}.amazonaws.com`	EC2 message delivery

For private instances (no NAT Gateway, VPC endpoint required):

Console path: VPC → Endpoints

Verify that all three interface endpoints exist, are associated with the correct VPC, and have status available. Check that the endpoint security group allows inbound HTTPS from the instance's security group.

Console path: VPC → Security Groups → [Endpoint SG]

Inbound rule required:

Type: HTTPS (443)
Source: [Instance security group ID]

For instances with NAT Gateway:

Console path: VPC → Route Tables → [Instance subnet's route table]

Confirm a 0.0.0.0/0 route pointing to the NAT Gateway exists and the NAT Gateway is in available state.

Note:
If the instance has a public IP and is in a public subnet with an IGW route, outbound port 443 directly to AWS endpoints is sufficient. No VPC endpoints needed in that case.

Expected result: Either VPC endpoints present and available, or valid NAT/IGW route exists. Instance SG allows outbound 443.

Step 6: Check Instance Security Group Outbound Rules

Console path: EC2 → Instances → [Instance ID] → Security tab → Security groups → [SG ID] → Outbound rules

Confirm outbound HTTPS is allowed. The default AWS SG allows all outbound traffic. If rules have been tightened:

Type: HTTPS (443)
Destination: 0.0.0.0/0

OR (preferred, more restrictive):

Type: HTTPS (443)
Destination: [VPC endpoint prefix list or specific endpoint IPs]

Expected result: Outbound 443 allowed from instance security group.

Step 7: Force SSM Agent Re-Registration (Last Resort)

If all above checks pass but the instance still doesn't appear in Fleet Manager, the agent's registration may be stale (common after AMI snapshots or instance cloning).

Use EC2 Run Command with AWS-RunShellScript:

# Amazon Linux 2 / AL2023
sudo systemctl stop amazon-ssm-agent
sudo rm -rf /var/lib/amazon/ssm/registration
sudo systemctl start amazon-ssm-agent
sudo systemctl status amazon-ssm-agent

Wait 2 minutes, then re-check Fleet Manager.

Validation Checks

Check	How to Verify	Expected Result
Instance in Fleet Manager	SSM → Fleet Manager → search instance ID	Status: Online
Session starts	SSM → Session Manager → Start session → select instance	Terminal opens
Agent heartbeat	CloudWatch Logs → /aws/ssm/amazon-ssm-agent	Recent heartbeat log entries

Rollback

No destructive changes are made by this runbook. If you attached a new IAM role that you want to remove:

Console path: EC2 → Instances → [Instance ID] → Actions → Security → Modify IAM role → No role

Escalation

Condition	Next Action
All steps pass but instance still unreachable	Open AWS Support case — provide instance ID, region, VPC endpoint IDs, and CloudWatch agent logs
Agent crashes immediately on start	Check OS disk space (`df -h`), memory, and `/var/log/amazon/ssm/amazon-ssm-agent.log` for errors
Instance in private subnet, no VPC endpoints, no NAT	Network path is broken by design — work with network team to add VPC endpoints or NAT

Kimi ครอง Design Arena, แต่แพ้ 4 ใน 5 รอบในคลิปเดียวกัน

Nokka — Sun, 13 Sep 2026 03:10:03 +0000

Kimi ครอง Design Arena, แต่แพ้ 4 ใน 5 รอบในคลิปเดียวกัน

โดย Nokka (นก-กา) | 12 กันยายน 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ตรวจสอบและเรียบเรียงโดย Nokka

ชื่อคลิปบน YouTube บอกว่า "ทำไมนักพัฒนาที่ฉลาดถึงเลือกใช้ Kimi ทำงานออกแบบ" [1]

คำโปรยของคลิปยิ่งหนักแน่นกว่านั้น

Kimi อยู่บนสุดของ Design Arena เหนือกว่าโมเดลทุกตัวจากค่ายใหญ่ ดังนั้นผมจึงจับ Kimi K3 มาชนกับ Fable และ Astra ในงานออกแบบห้าชิ้น

ผมดูคลิปนั้นจบ และผลลัพธ์ที่ได้กลับไม่ตรงกับชื่อคลิปเลย

วิดีโอนี้ทดสอบอะไร

ช่อง Better Stack มีผู้ติดตาม 202,000 คน เผยแพร่คลิปความยาว 6 นาที 36 วินาที เมื่อวันที่ 12 กันยายน 2026 และมียอดชม 4,632 ครั้งในวันแรก [1]

การทดสอบคือจับสามโมเดลมาทำงานห้าชิ้นแบบครั้งเดียวจบ หรือ one-shot คือให้โจทย์แล้วใช้ผลลัพธ์ครั้งแรกโดยไม่แก้อะไร [1]

งานทั้งห้าคือหน้าแลนดิ้ง ฉากสามมิติ ไลบรารีคอมโพเนนต์ แอปมือถือ และเกมที่ต้องสร้างแอสเซตเอง [1]

ผลที่ออกมา

สรุปผลทีละรอบ

ผมสรุปผลทั้งห้ารอบไว้ตรงนี้ เพราะนี่คือส่วนที่ชื่อคลิปไม่ได้เล่า [1]

รอบที่หนึ่ง หน้าแลนดิ้ง: Kimi ชนะ ได้คำชมเรื่องแอนิเมชัน การจัดตัวอักษร และความลื่นไหลของประสบการณ์ใช้งาน [1]

รอบที่สอง ฉากสามมิติ: Astra ชนะ ได้ผลลัพธ์ที่กลมกลืนที่สุดเมื่อเทียบกับอีกสองตัวที่ออกมาเป็นบล็อก ๆ [1]

รอบที่สาม ไลบรารีคอมโพเนนต์: เสมอกันทั้งสามตัว ผู้ทำคลิปบอกว่าคุณภาพใกล้กันจนตัดสินเป็นเรื่องของรสนิยมล้วน ๆ [1]

รอบที่สี่ แอปมือถือ: ไม่ให้คะแนนใครเลย ผู้ทำคลิปตัดสินว่าทั้งสามตัวได้ผลลัพธ์ที่จืดชืด เป็นบล็อก ๆ และคุณภาพแย่ [1]

รอบที่ห้า เกมพร้อมแอสเซต: Claude ชนะ ได้แอนิเมชันและรายละเอียดที่เรียบร้อยที่สุด Kimi ได้ที่สอง ส่วน Astra อ่อนที่สุดในรอบนี้ [1]

นับรวมแล้ว Kimi ชนะหนึ่งรอบ Astra ชนะหนึ่งรอบ Claude ชนะหนึ่งรอบ เสมอหนึ่งรอบ และไม่มีใครชนะหนึ่งรอบ

ไม่มีโมเดลไหนนำใครได้เลย

แล้วคำว่า "อยู่บนสุดของ Design Arena" หมายถึงอะไร

ตัวเลขที่ผมตรวจจากหน้าเว็บจริง

ตอนนี้เป็นส่วนที่ผมไปตรวจสอบเอง เพราะคำกล่าวอ้างนี้ถูกต้องตามข้อมูล แต่ต้องอ่านให้ครบ

หน้าโปรไฟล์ Kimi K3 บน Design Arena ระบุว่าเป็นโมเดลที่ "ถูกจัดอยู่ในอันดับหนึ่งบ่อยที่สุด" จากทั้งหมด 8,650 การแข่งขัน โดยมีอัตราชนะรวม 64% และคะแนน Elo 1383 [2]

ตัวเลขรายหมวดน่าสนใจกว่า และตรงกับที่ผมเห็นในคลิป [2]

หมวด	อันดับ	อัตราชนะ
หน้าแลนดิ้ง	ที่ 1 จาก 172	61%
การแสดงข้อมูล	ที่ 1 จาก 160	64%
ฉากสามมิติ	ที่ 2 จาก 152	69%
แอปมือถือ	ที่ 2 จาก 159	58%
เกม	ที่ 3 จาก 164	63%
ไลบรารี UI	ที่ 4 จาก 159	63%

ดูตามนี้จะเห็นว่าคำกล่าวอ้างในคลิปถูกต้อง เพราะ Kimi ครองอันดับหนึ่งในหมวดหน้าแลนดิ้งและการแสดงข้อมูลจริง และอยู่อันดับสองหรือสามในหมวดอื่น

แต่ "อันดับหนึ่งบ่อยที่สุด" กับการชนะทุกครั้งเป็นคนละเรื่องกัน และนั่นคือสิ่งที่คลิปนี้พิสูจน์โดยไม่ตั้งใจ

บริบทที่ทำให้เรื่องนี้น่าสนใจขึ้น

Kimi K3 ไม่ได้เพิ่งเป็นที่พูดถึงแค่ใน Design Arena

The New Stack รายงานว่าเมื่อ Kimi K3 เปิดตัว ภายในไม่กี่ชั่วโมงมันไต่ขึ้นเป็นอันดับหนึ่งบน leaderboard ด้าน frontend coding ของ Arena โดยเอาชนะระบบปิดชั้นนำในผลการประเมินแบบ blind [4]

และหลายสำนักระบุตรงกันว่าเป็นครั้งแรกที่โมเดลเปิดน้ำหนักขึ้นอันดับหนึ่งบน leaderboard ที่ตัดสินด้วยความชอบของคน [6][7]

ตัวเลขบน leaderboard หมวด code ของ Arena เองก็ยืนยันทิศทางเดียวกัน โดย Kimi K3 ได้คะแนนเหนือคู่แข่งในกลุ่มโมเดลปิด [5]

ส่วนคะแนนที่ Vals AI ซึ่งเป็นผู้ทดสอบอิสระวัดได้ Kimi K3 ทำได้ 95.10% บน SWE-bench Verified และ 91.27% บน Vibe Code Bench ซึ่งเป็นชุดย่อยของ Vals Index ทั้งคู่ [8]

ตัวเลขเหล่านี้ทำให้คำโปรยของคลิปที่ว่า "Kimi อยู่บนสุดของ Design Arena" ไม่ใช่คำกล่าวอ้างลอย ๆ แต่มันเป็นความจริงที่ต้องอ่านให้ถูกบริบท

ประเด็นที่ผมคิดว่าสำคัญที่สุด

คำโปรยของคลิปคือ "โมเดลที่คุณจ่ายเงินอยู่ อาจไม่ใช่ตัวที่คุณควรใช้" [1]

ผมเห็นด้วยกับประโยคนี้ แต่ผมคิดว่าคลิปนี้ให้บทเรียนที่ตรงกว่าตัวเอง

งานออกแบบหนึ่งชิ้นไม่ใช่การวัดที่แม่นพอจะบอกว่าโมเดลไหนเก่งกว่า เพราะหนึ่งชิ้นงานมีตัวแปรเยอะ ทั้งการสุ่มของโมเดล ลักษณะโจทย์ และความชอบส่วนตัวของผู้ตัดสิน

นี่คือเหตุผลว่าทำไม leaderboard ถึงใช้การแข่งขันหลายพันครั้งในการจัดอันดับ แต่คลิปใช้แค่ห้าครั้ง

ทั้งสองแบบมีประโยชน์ต่างกัน leaderboard บอกว่าค่าเฉลี่ยของโมเดลอยู่ตรงไหน ส่วนการทดสอบห้าชิ้นบอกว่าครั้งนี้เกิดอะไรขึ้น

ถ้าผลออกมาไม่ตรงกัน สิ่งที่ผิดไม่ใช่ข้อมูลชุดใดชุดหนึ่ง แต่วิธีที่เราเอาข้อมูลชุดหนึ่งไปสรุปอีกชุดหนึ่งต่างหาก

ปัญหาทางเทคนิคของคลิปเอง

ช่องนี้เปิดให้แสดงความคิดเห็น และมีข้อวิจารณ์หนึ่งที่ตรงประเด็น

ผู้ชมคนหนึ่งตั้งข้อสังเกตว่าคลิปไม่ได้ระบุชื่อโมเดลที่ใช้อย่างชัดเจน [1]

ผมตรวจสอบแล้วพบว่าเรื่องนี้เป็นจริงในระดับหนึ่ง คลิปใช้ชื่อ "Kimi", "Claude" และ "Astra" ลอย ๆ โดยไม่บอกเวอร์ชันของแต่ละตัวในเนื้อหาหลัก

สำหรับ Claude คลิปไม่ได้บอกว่าใช้ Fable 5.1 หรือรุ่นไหน ส่วนคำโปรยบอกว่า "Fable และ Astra" แต่ในเนื้อหาพูดถึง Astra ในฐานะ GPT-6 Astra [1][3]

จุดนี้สำคัญเพราะเมื่อไม่ระบุเวอร์ชัน ผลการทดสอบจะเปรียบเทียบกับอะไรก็ไม่รู้ และไม่มีใครทำซ้ำได้

ข้อวิจารณ์ที่ผมคิดว่าน้ำหนักดีที่สุด

ในคอมเมนต์ใต้คลิป มีผู้ชมเขียนไว้ประมาณว่า [1]

เวลาโมเดลใหม่เปิดตัว ทุกคนจับจ้องแต่ส่วนติดต่อผู้ใช้ ทั้งที่ส่วนติดต่อไม่ใช่งานวิศวกรรมจริง ๆ ตรรกะที่อยู่ข้างในต่างหากที่สำคัญ ส่วนที่เห็นสวย ๆ มีประโยชน์แค่ในงานโชว์และพอร์ตโฟลิโอ

ผมคิดว่าคอมเมนต์นี้ตรงกับสิ่งที่ผมเห็นในคลิปมาก เพราะห้าจานทดสอบของคลิปนี้เป็นงานที่มองเห็นผลทันทีทั้งหมด ไม่มีงานที่ต้องแก้บั๊กซับซ้อนหรือดูแลโค้ดระยะยาวเลย [1]

ผลจากการวัดแบบนี้จึงบอกความสามารถเรื่องหน้าตาได้ดี แต่บอกความสามารถเรื่องความทนทานของโค้ดไม่ได้

มุมมองจากคนที่ทำงานกับโมเดลทุกวัน

ผมเจอสถานการณ์แบบนี้ตลอด เพราะผมเลือกโมเดลตามงาน ไม่ได้เลือกตามอันดับ

โมเดลที่ตัวเลขสูงสุดบน leaderboard อาจเขียนงานประเภทนี้ได้แย่กว่าโมเดลที่อันดับต่ำกว่าสองสามอันดับ เพราะความถนัดเฉพาะทางของแต่ละตัวต่างกันจริง

สิ่งที่ผมทำเวลาอ่านผลทดสอบคือถามสามข้อ

หนึ่ง งานที่ทดสอบเหมือนงานที่ผมจะทำไหม งานออกแบบหน้าแลนดิ้งกับงานเขียนบทความยาวเป็นคนละทักษะ

สอง ทดสอบกี่ครั้ง ห้าครั้งต่างจากแปดพันครั้งมาก และผลที่ได้ควรถูกอ่านให้ต่างกัน

สาม ผู้ตัดสินเป็นใคร ถ้าเป็นคนเดียว ความชอบส่วนตัวของคน ๆ นั้นคือตัวแปรที่ใหญ่ที่สุดในผลลัพธ์

สิ่งที่ทำได้ตั้งแต่วันนี้

วิธีอ่านผลทดสอบให้เป็น

อย่างแรก ถ้าคุณเห็นคลิปหรือโพสต์ที่บอกว่าโมเดลหนึ่งชนะ ให้ดูจำนวนงานที่ทดสอบก่อน ถ้าน้อยกว่าสิบครั้ง ให้อ่านเป็นกรณีศึกษา ไม่ใช่การจัดอันดับ

อย่างที่สอง ถ้าคุณใช้ AI ออกแบบงานจริง ลองทดสอบกับงานของคุณเองสักห้าชิ้นแล้วตัดสิน โดยใช้ leaderboard เป็นแค่ตัวช่วยกรองตัวเลือกแรก ไม่ใช่คำตัดสินสุดท้าย [2]

อย่างที่สาม ระวังการจับคู่ชื่อคลิปกับคำโปรย เพราะชื่อคลิปเป็นเรื่องการตลาด ส่วนคำโปรยเป็นเรื่องของคนทำคลิปที่ต้องขายไอเดีย และส่วนที่บอกความจริงคือเนื้อหาข้างใน

ข้อควรระวัง

หนึ่ง ผมไม่ได้ดูวิดีโอทั้งคลิปด้วยเสียงของตัวเอง เพราะ YouTube บล็อกการเข้าถึงจากเซิร์ฟเวอร์ที่ผมใช้ดึงข้อมูล สิ่งที่ผมอ่านได้คือชื่อคลิป คำโปรย บทบรรยาย และคอมเมนต์ที่แสดงบนหน้าเว็บ ซึ่งรวมผลการตัดสินทั้งห้ารอบและช่วงเวลาของแต่ละรอบ [1]

สอง ผมไม่ทราบว่าโมเดลที่ใช้ในแต่ละรอบเป็นเวอร์ชันใดแน่ชัด คลิปใช้ชื่อ Kimi, Claude และ Astra โดยไม่ระบุเวอร์ชันในเนื้อหาหลัก และนี่เป็นข้อจำกัดที่ผมวิจารณ์ไว้ในบทความเองด้วย [1]

สาม ตัวเลข Design Arena ที่ผมยกมาเป็นข้อมูล ณ วันที่ 12 กันยายน 2026 ซึ่งเป็นวันเดียวกับที่คลิปเผยแพร่ และเป็นวันที่ผมตรวจหน้าเว็บ ตัวเลขนี้เปลี่ยนได้ทุกวันตามการแข่งขันใหม่ [2]

สี่ ผมพบว่าชื่อ Astra และ Fable ที่คลิปใช้ ตรงกับโมเดลจริงที่เปิดตัวต้นเดือนกันยายน 2026 คือ GPT-6 Astra ของ OpenAI และ Claude Fable 5.1 ของ Anthropic [9] แต่ผมไม่ยืนยันว่าคลิปใช้เวอร์ชันหรือค่าระดับความพยายามใดในการทดสอบ เพราะคลิปไม่ระบุ [1]

ห้า ข้อวิจารณ์ในคอมเมนต์ที่ผมยกมาเป็นความเห็นของผู้ชม ไม่ใช่ข้อเท็จจริงที่ตรวจสอบได้ และผมไม่ได้ยืนยันว่าผู้เขียนคอมเมนต์ทำงานในวงการนี้หรือไม่ [1]

สรุป

คลิปนี้ตั้งชื่อว่า "ทำไมนักพัฒนาที่ฉลาดถึงเลือก Kimi" แต่เนื้อหาข้างในกลับแสดงให้เห็นว่า Kimi ชนะหนึ่งในห้ารอบเท่ากับคู่แข่งอีกสองตัว

ผมไม่คิดว่านี่เป็นข้อบกพร่องของคนทำคลิป เพราะคำโปรยของเขาบอกไว้ตรง ๆ ว่าอยากให้คนตั้งคำถามกับโมเดลที่ตัวเองจ่ายเงินอยู่ [1]

แต่ผมคิดว่านี่คือบทเรียนที่ดีกว่าที่คลิปตั้งใจจะสอน นั่นคือ อันดับหนึ่งบน leaderboard กับการชนะในงานที่คุณกำลังทำอยู่ เป็นสองเรื่องที่แยกกัน

คำถามที่ผมคิดว่าควรถามเวลาอ่านผลทดสอบแบบนี้คือ ถ้าผลออกมาตรงข้ามกับที่คุณคาด คุณจะเชื่อตัวเลข หรือเชื่องานที่วางอยู่ตรงหน้าคุณ

ถ้าคุณเคยเจอเคสแบบนี้ คือผลทดสอบบอกอย่าง แต่ใช้งานจริงได้อีกอย่าง ลองแชร์ให้ผมฟังได้ เพราะกรณีแบบนั้นสอนได้มากกว่าตัวเลขบน leaderboard

แหล่งอ้างอิง

[1] Better Stack, "Why Smart Developers Use Kimi For Design" (YouTube, 12 ก.ย. 2026), https://www.youtube.com/watch?v=zx9xhp7wB9M

[2] Design Arena, โปรไฟล์และอันดับของ Kimi K3 (สืบค้น 12 ก.ย. 2026), https://www.designarena.ai/models/kimi-k3

[3] Design Arena, รายชื่อโมเดลที่ประเมิน (สืบค้น 12 ก.ย. 2026), https://www.designarena.ai/models

[4] The New Stack, "Kimi K3 tops Arena's coding leaderboard and it's open-weight" (2026), https://thenewstack.io/kimi-k3-open-weight-coding/

[5] Design Arena, leaderboard หมวด Code (สืบค้น 12 ก.ย. 2026), https://www.designarena.ai/leaderboard/code

[6] Kilo, "Kimi K3 Just Took the #1 Spot for Frontend. We Put It Against Claude Fable 5 on 10 UIs" (2026), https://blog.kilo.ai/p/kimi-k3

[7] Data Science Dojo, "Kimi K3 vs Claude Fable 5: Benchmarks compared" (2026), https://datasciencedojo.com/blog/kimi-k3-vs-claude-fable-5/

[8] Vals AI, ผลการประเมิน Kimi K3 บน Vals Index (16 ก.ค. 2026), https://www.vals.ai/models/kimi_kimi-k3

[9] DataCamp, "GPT-6 Astra vs Claude Fable 5.1: Benchmarks and Pricing" (ก.ย. 2026), https://www.datacamp.com/blog/gpt-6-astra-vs-claude-fable-5-1

Designing a deterministic browser-side photo analysis flow

chang zhong — Sun, 13 Sep 2026 03:05:45 +0000

Photo-analysis products are easy to make look more certain than they are. A single number can feel authoritative even when the user has no way to tell what changed between two runs, where the calculation happened, or whether their image left the device.

While building a small browser-based facial-proportion tool, I found that a few engineering choices matter more than adding another model.

Keep the calculation repeatable

The pipeline starts with 478 detected facial landmarks and derives four displayed proportions: harmony, symmetry, eye area, and jawline. The important constraint is that the scoring formula is fixed. Given the same landmarks, it produces the same output.

That sounds ordinary, but it changes how a result can be discussed. A user can repeat a run after changing the photo and know that a changed score came from changed measurable input, not a different sampling path or an opaque model response. It also makes debugging possible: the ratio behind each score can be displayed alongside the score instead of asking users to trust a label.

Repeatability does not make a score universally meaningful. It only makes the mechanism inspectable. In this case, the tier labels are still being calibrated against real photos, so the labels may move as the calibration set grows. Keeping that limitation visible is part of the interface, not a footnote for later.

Reject bad input before calculating

A deterministic formula still produces misleading output if the input photo is unsuitable. The browser checks angle, sharpness, exposure, framing, and face size before the scoring step. A photo that does not meet those conditions should be rejected with a useful reason, not pushed through so the product can always return a number.

This is a product decision as much as an engineering one. A refusal is less satisfying than a result, but it makes the boundary of the system legible. It also prevents a score from being mistaken for advice or a medical conclusion. The tool measures image-derived proportions; it does not recommend treatments, surgery, or behavior changes.

Treat the image as local data

For a tool that starts with a face photo, the default data path should be easy to explain. Detection and scoring run in the browser, and the uploaded image is read locally rather than sent to an application server. If a user chooses to share a result, the shared record contains the four scores and photo-quality values, not the original image or landmark coordinates.

Local processing does not remove every privacy question, but it narrows the one users care about first: whether a personal photo has to leave the device to get a measurement. Making that answer simple also keeps the system architecture simpler.

The useful takeaway

For small analysis tools, reliability often comes from making fewer promises. A fixed calculation, visible inputs, a clear rejection path, and a local-first data flow give users something they can inspect and repeat. They do not turn a measurement into a verdict.

The working product is Looksmax Scale. I am its builder; the link is included as a concrete implementation reference, not as a substitute for the article.

Disclosure: this post was drafted with AI assistance and reviewed by the product builder.

Stop Making Your React Components Reusable | React Design

Nainik Mehta — Sun, 13 Sep 2026 03:01:21 +0000

The Reusability Trap: Why Your React Components Are Becoming Unmaintainable

In the modern React ecosystem, "reusability" has been elevated from a best practice to a full-blown theology. We are taught from our first tutorial that DRY (Don't Repeat Yourself) is the ultimate virtue. If you write the same button twice, you’ve failed. If you copy-paste a layout block, you’re a junior developer.

But this obsession with premature abstraction is quietly killing our codebases. In our relentless quest for perfect React component design, we have fallen victim to "componentitis"—the tendency to abstract UI elements for hypothetical future needs that, nine times out of ten, never actually materialize.

The Symptom: The "God Component"

We have all seen it. A component that starts its life as a simple Card eventually morphs into a fragile, sprawling web of conditional props. It starts with showIcon, then adds isHeaderCompact, then disableShadow, until you are staring at an API that looks like this:

<Card 
  showIcon={true} 
  isHeaderCompact={false} 
  disableShadow={true} 
  hasWarningBorder={status === 'pending'}
  variant="primary"
  size="md"
  // ...and 15 more props
/>

This is not component design; this is configuration. Every new boolean prop you add creates an exponential matrix of untested UI states. When you have five boolean props, you don't just have five features; you have 32 potential combinations of states. Most of those combinations are never tested, never used, and eventually, they break in ways that are impossible to debug. This is the definition of a "God Component"—a fragile, monolithic entity that everyone is afraid to touch.

The Root Cause: Solving Problems That Don't Exist

The core issue is that we are designing for a future that hasn't happened yet. We are trying to build a "universal" component that can handle every possible edge case, just in case we need it later. This violates the core principle of YAGNI (You Aren't Gonna Need It).

When we force reusability where it doesn't belong, we increase the cognitive load for every other developer on the team. To use a component, they now have to read through a massive prop-types definition or TypeScript interface to understand which combination of flags will render the specific UI they need.

The Solution: A Pragmatic Taxonomy

Instead of striving for maximum reusability, we should aim for appropriate reusability. I suggest categorizing your components into three distinct buckets:

1. Universal Primitives

These are your building blocks. They are highly reusable, contain minimal styles, and share core behavioral logic. Think Button, Input, Checkbox, or Typography. These components are allowed to be highly configurable because their scope is narrow and well-defined.

2. Global Patterns

These are app-specific constraints. They handle complex interactions that need to be consistent across the entire application. Think Modal, Navigation, or ToastContainer. These are reusable, but they are bounded by your application's specific design system.

3. View Components

These are your feature-specific components. They are strictly non-reusable. If you need a UserDashboardProfileCard, build it for the dashboard. If you need a similar card for the Settings page, do not try to merge them. Let them be "duplicate" and simple. If you find yourself needing to reuse them later, that is the perfect time to refactor—not before.

Favor Composition Over Configuration

When you do need flexibility, stop reaching for more props. Instead, favor composition. React’s children prop and dedicated "slots" (passing components as props) are powerful tools that allow you to inject behavior and structure without polluting the parent component's API.

By keeping feature-specific code in its own folder and embracing duplication as a temporary state, you keep your components lean, testable, and, most importantly, maintainable. The next time you find yourself adding a prop to a component to satisfy a "what if" scenario, stop. Build it twice, see how it evolves, and only abstract when the pattern is undeniable.

Your future self (and your teammates) will thank you.

When a Zero-Parameter Cache Overtakes a Transformer

Seth Wheeler — Sun, 13 Sep 2026 03:00:00 +0000

The question this series exists to answer, put in a form that can be measured: a transformer sees a fixed 64-token window, a count table over the current document sees the whole document, and as documents get longer, how much of the trained model does the free mechanism replace?

An earlier experiment had established that the document cache is worth up to +0.106 top-1 on a long coherent document, against +0.014 for every improvement to corpus modelling from Witten-Bell all the way to a full Gibbs-sampled hierarchical Pitman-Yor model. But that comparison had no neural network in it, so it could not ask the question that matters. This one does: six systems, identical positions, one continuous text cut into documents of length L so that length and coherence grow together. The research repo is not public, so the numbers come from its own harness.

The table

Out of distribution, 1.43M-parameter transformer, 64-token window.

system	params	L=60	L=250	L=1000
corpus only, WB-4 on 4M tokens	0	0.128	0.129	0.124
cache only, this document and nothing else	0	0.103	0.172	0.213
corpus + cache, no neural network	0	0.139	0.201	0.228
transformer only	1.43M	0.152	0.143	0.149
transformer + corpus	1.43M	0.147	0.156	0.153
transformer + corpus + cache	1.43M	0.161	0.214	0.230

Paired tests on the headline comparison, same positions:

L=60    transformer 0.152  cache 0.103  delta -0.050  CI [-0.067,-0.032]  SIGNIFICANT (transformer)
L=250   transformer 0.143  cache 0.172  delta +0.029  CI [+0.010,+0.049]  SIGNIFICANT (cache)
L=1000  transformer 0.149  cache 0.213  delta +0.064  CI [+0.044,+0.083]  SIGNIFICANT (cache)

The test reports both directions, because a confidence interval entirely below zero is a significant win for the transformer, and describing that as "not significant" would be wrong. At L=60 the transformer wins and the write-up says so.

One mechanism is flat and the other is not

The transformer goes 0.152, 0.143, 0.149 across the three lengths. No trend, and the reason is structural rather than statistical: a 64-token window makes a 1000-token document literally invisible. The cache goes 0.103, 0.172, 0.213; it doubles.

Document length is a resource one mechanism can spend and the other cannot, and that is the entire result in a line. Everything below is arithmetic on it.

The crossover is early. Below roughly 100 tokens the trained model wins decisively. Somewhere between 60 and 250 tokens a count table built over the current document, with no parameters, no training and a construction cost in microseconds, overtakes 1.43 million trained parameters, and by 1000 tokens it wins by 0.064 top-1, a 43% relative margin.

These are also genuinely different mechanisms rather than two variants of one. The two systems disagree on 20 to 25% of positions, against the 3% seen between two hybrids in an earlier experiment. They are not converging on the same predictions by different routes. They disagree, and one of them is right more often as the document grows.

The parameters stop contributing

What adding the transformer buys on top of corpus plus cache:

	L=60	L=250	L=1000
gain from adding 1.43M parameters	+0.022	+0.013	+0.002

At L=60 the transformer is carrying real weight; at L=1000 it contributes 0.002 top-1 on top of two count tables, and the substitution is close to complete.

The mixture weights agree without being told to. The cache's optimal weight climbs from 0.25 to 0.70 to 0.85 as documents lengthen, so at L=1000 the best system is 85% document and 15% corpus. That is a fitted parameter arriving at the same conclusion as the ablation, which is the sort of agreement worth more than either alone.

What this does not say

It says nothing about a model whose context window covers the document. The comparison is parameters at a fixed short context against a count table over the document, which is the realistic small-model setting and the one this project's tools actually live in. A long-context model would read the document itself, and this experiment cannot see that at all.

It also does not escape the finding it sits next to. Counting still does not scale with corpus data; that axis is closed. What scales here is the amount of current document available, which is a different axis, and this experiment says the returns are on the second one.

And it is out of distribution by construction: a Gutenberg book against a TinyStories corpus model and a TinyStories transformer. Both trained components face the same shift, so the comparison is internally fair, and an earlier finding already said the cache pays most out of distribution. In-domain the transformer would be stronger and the crossover would move right. Measuring that needs a long-document in-domain corpus, which this project does not have, and it is the clearest gap in this line of work.

Two smaller caveats belong with the numbers rather than after them. The L=1000 cell has 74 documents and is the noisiest of the three. And the cache at L=60 has a high top-5 of 0.546 alongside its low top-1, because a 60-token document supplies about 30 distinct types, so the distribution is concentrated on a few candidates without being right about which. That is a real property of a short document rather than an artefact, and it inverts as documents lengthen.

What generalises

The useful shape here is not "counting beats neural networks", which is not what the table says at any length below about 100 tokens. It is that two mechanisms can look like competitors while depending on completely different resources, and that comparing them at one operating point tells you almost nothing.

At L=60 the honest headline is that a 1.43M-parameter transformer beats a zero-parameter cache by a significant margin. At L=1000 the honest headline is the reverse, by a larger one. Both were measured on the same day with the same harness; either could have been published alone.

The general version: before comparing two systems, find the axis one of them can spend and the other cannot, then measure along it. If you cannot name that axis, you are probably measuring at whichever point you happened to build first.

O que é Cloud Computing? (A visão de um estudante de tecnologia)

Davi Pereira — Sun, 13 Sep 2026 02:58:16 +0000

Olá, pessoal! Sou o Davi.

Este é o meu primeiro artigo no DEV Community. Sou estudante universitário da área de tecnologia e decidi começar a escrever para fixar o que venho aprendendo nas aulas e nos estudos individuais.

Quando comecei a estudar, ouvia falar sobre "Nuvem" ou "Cloud Computing" a todo momento, mas o termo parecia meio abstrato. Se você também está no início da faculdade ou migrando para a área e quer entender esse conceito sem complicação, este post é para você!

A frase que fez o "estalo" nos meus estudos

No começo, a palavra "nuvem" faz parecer algo invisível solto no ar. Mas a definição mais simples que encontrei no início das minhas leituras foi:

"A nuvem é apenas o computador de outra pessoa ao qual você se conecta pela internet."

Em termos práticos, Cloud Computing é o aluguel de recursos computacionais — como servidores, armazenamento de arquivos e bancos de dados — através da internet.

Em vez de uma empresa (ou você) comprar um servidor físico caro, colocar na sala e pagar pela energia/manutenção, você simplesmente contrata a capacidade computacional de grandes provedores (como AWS, Google Cloud ou Azure).

Comparando o modelo tradicional com a Nuvem

Para entender por que isso virou o padrão da indústria, me ajudou muito fazer essa comparação direta:

Comprar Servidor Próprio	Usar Computação em Nuvem
Alto custo inicial para comprar hardware	Zero investimento inicial em equipamentos
Demora para comprar e instalar novas peças se o sistema crescer	Aumenta ou diminui a capacidade em segundos pela internet
Você cuida do ar-condicionado, energia e manutenção física	O provedor cuida de toda a infraestrutura física
Custo fixo, mesmo se ninguém estiver usando o sistema	Pagamento por uso (paga apenas pelo que consome)

Os 3 níveis da Nuvem (A analogia da moradia)

Nos cursos e disciplinas de infraestrutura, aprendemos que a nuvem se divide em três modelos principais. Uma analogia simples me ajudou a memorizar:

IaaS (Infraestrutura como Serviço): É como alugar um apartamento vazio. Você recebe a estrutura bruta (servidor e rede) e precisa instalar o sistema operacional e configurar tudo do seu jeito.
PaaS (Plataforma como Serviço): É como alugar um quarto mobiliado. O ambiente para rodar o código já vem pronto; você só precisa enviar seu programa e mandar executar.
SaaS (Software como Serviço): É como se hospedar em um hotel. O sistema está 100% pronto para uso e você só acessa pelo navegador ou aplicativo. (Ex: Google Drive, Notion, Canva)

Conclusão

Entender a nuvem me fez perceber que, hoje em dia, tão importante quanto escrever código é saber onde e como esse código vai rodar quando estiver pronto para os usuários.

Como este é meu primeiro texto e ainda estou na jornada de aprendizado da faculdade, adoraria receber feedbacks e conselhos nos comentários! Como foi o seu primeiro contato com Cloud Computing?

IND-TECH WEEKLY #3: Pixxel's $100M Rocket Ride, Jio's Investor Roadshow Kicks Off, and Oracle's Next Layoff Wave 🇮🇳

Dhruv Jani — Sun, 13 Sep 2026 02:57:39 +0000

Hey 👋

Last issue introduced Jobs Watch, and it's sticking around — this issue keeps that structure and adds one change to Developer Corner (more on that below).

This issue covers India tech news from Sunday, Sep 6 to Saturday, Sep 12.

What's Inside

📰 The Big Headline — Pixxel's $100M Rocket Ride
💰 This Week in Funding
📌 Quick Hits, Worth Knowing
🌐 The Bigger AI Picture
💼 Jobs Watch — Stats, Layoffs, and Who's Hiring
💻 Developer Corner

- 🗳️ What Do You Want in Issue #4?

📰 The Big Headline — Pixxel's $100M Rocket Ride

Bengaluru-based space-tech company Pixxel closed a $100 million Series C on September 7 — co-led by Temasek and Seraphim Space, with new investors 360 ONE Asset and South Korea's IMM Investment joining existing backers Radical Ventures and growX Ventures (source).

A few things worth knowing:

This takes Pixxel's total funding to $195 million, making it the best-capitalised private space-tech company in India's history.
Founded in 2019 by Awais Ahmed and Kshitij Khandelwal, Pixxel builds hyperspectral satellites that capture far more detail about Earth's surface than conventional optical imaging.
The round is being read as a signal that Indian deep-tech — not just fintech and consumer apps — can now pull in serious late-stage capital.

Jio update, since we've been tracking it: investor outreach for Jio Platforms' IPO is starting this week, with roadshows planned across the US, Singapore, Hong Kong, London and the Middle East. Reports now peg the target valuation at around $137 billion, with the Navratri window (announced last issue) still the plan (source).

Why it matters for devs: Pixxel's round is a good data point if you're weighing a deep-tech/hardware path over the usual SaaS-or-fintech default — the capital is clearly there for it now.

💰 This Week in Funding

Startup	Raise	What's Notable
Pixxel	$100M (Series C)	Co-led by Temasek and Seraphim Space; India's largest-ever space-tech round; total funding now $195M
QNu Labs	₹200 Cr (~$21M, Series A1)	Led by India's National Quantum Mission and Speciale Invest; takes the Bengaluru quantum-cybersecurity company's total raised to ₹375 Cr

Tracker check, continuing from last issue: the gap between trackers was much smaller this week than the ~$127M gap we flagged in Issue #2.

Tracker	Window	Total Raised	Deals
Entrackr	Sep 7 – Sep 12	$356.8M	~21
Inc42	Sep 7 – Sep 11	$321.9M	20

Why do Entrackr and Inc42 never quite agree?
Neither tracker is wrong — they just draw the week's boundary differently and classify deals differently. Entrackr's window this week ran Sep 7–12 (six days); Inc42's ran Sep 7–11 (five days), so Entrackr had one more day to catch late-reported deals. On top of that, "verified" vs "reported" rounds, and what counts as a growth-stage deal versus early-stage, differ slightly between the two. Neither is doing anything wrong — it just means a single "$X raised this week" number is always somebody's specific methodology, not a neutral fact.

💡 Takeaway: ~$35M apart this time, mostly explained by Entrackr's window running one extra day. Compare that to last week's ~$127M gap — the size of the discrepancy isn't constant, which is itself a useful reminder not to treat any single "$X this week" headline as precise.

📌 Quick Hits, Worth Knowing

A few smaller things from the same week that didn't need a full section but are worth knowing:

PB Pay is live. PB Fintech's payment aggregator platform has launched operations, open for merchant sign-ups under the RBI license it received in February 2026.
Mahindra Finance × Sarvam AI, deeper this time. Their voice-AI partnership now spans sales, collections, and employee engagement — voice agents built on Sarvam's platform operate across 12 Indian languages and have handled over 1 crore customer calls so far.
Xflow × HSBC, announced at Global Fintech Fest 2026. The partnership lets global businesses collect payments from Indian customers via cards, net banking, and UPI, without needing to set up a local entity in India.

(All three via Entrackr's weekly report.)

🌐 The Bigger AI Picture

SEMICON India 2026 is now just days away — September 17–19 in New Delhi, themed "Silicon to Systems." We flagged this last issue as one to watch; it's arriving right after this issue goes out.

Also worth connecting here: QNu Labs' raise above isn't just a funding story — it's tied to India's National Quantum Mission, which has set a target of quantum resilience across critical infrastructure by 2029. Part of QNu's new capital is earmarked for a government-backed project to build the technology backbone of India's Quantum Secure and Sensing Networks (source).

Why it matters for devs: semiconductors, quantum, and AI infra are increasingly being funded and framed as one connected pipeline rather than separate policy tracks. If you're picking a deep-tech niche, that's worth factoring in.

💼 Jobs Watch — Stats, Layoffs, and Who's Hiring

The Big Picture

Naukri's JobSpeak report for August 2026 (published Sep 9) showed white-collar hiring up 14% YoY, with the index at 3,028 versus 2,664 a year earlier. Fresher hiring (0–3 years) grew 15% YoY, and AI-ML roles led all categories at 31% YoY growth. IT hiring specifically grew 11% (source).

One honest caveat in the same report: the index was actually down ~6% month-on-month from July, because the festive hiring bump shifted later in the calendar this year. So "14% up" and "6% down" are both true at once, depending on whether you're comparing to last year or last month.

Layoffs This Week

The macro picture: more than 6,300 tech jobs were cut globally in just the first 10 days of September, with Uber, PayPal, Apple, Zomato, and Oracle all named. Layoffs.fyi puts the global 2026 total at 128,536 tech employees across 299 companies as of September 10 (source).

The India-specific one to watch: Oracle India is reportedly bracing for another 2,000–3,000 job cuts, expected around September 15 — just after this issue's window closes. This would follow an earlier 2026 round that already affected roughly 12,000 Oracle employees in India (source). Oracle hasn't officially confirmed a date.

💡 Takeaway: the same industry capex boom driving AI infrastructure spending (Alphabet, Amazon, Microsoft, and Meta are expected to spend ~$725 billion on capex in 2026, up 77% from 2025) is part of the reason companies are simultaneously cutting headcount elsewhere. Growing revenue and shrinking teams aren't contradictory anymore.

Who's Actually Hiring

Zooming into the Naukri numbers above: auto (+19% YoY), healthcare (+16%), and retail (+15%) led sector hiring growth in August — not IT. If you're a fresher and only tracking tech-sector headlines, it's worth knowing that some of the strongest hiring momentum right now is happening outside pure-play tech companies altogether.

💻 Developer Corner

Starting this issue, Developer Corner is changing format. Instead of me sourcing opportunities myself each week, I asked @hemapriya_kanagala, who runs the excellent Dev Opportunity Radar series, whether I could just point readers to her weekly post. She said yes — so going forward, every issue of IND-TECH WEEKLY will carry a Liquid tag to that week's Radar edition here.

Includes reader-submitted hacks and site updates

Hemapriya Kanagala for The DEVengers

Sep 11

Dev Opportunity Radar #16: $15K AI Agent Hackathon, AI Education Fellowship, and AWS Student Rewards

#discuss #community #opportunities #resources

11 min read

🔍 Browse every past Radar edition

If you're after hackathons, fellowships, and other opportunities worth applying to, that's the one to check every week now.

🗳️ What Do You Want in Issue #4?

A couple of questions:

1️⃣ The tracker-discrepancy callout in Funding — useful as a recurring bit, or was once enough to make the point?

2️⃣ Anything you want more depth on — the Jio IPO as it gets closer, more on the layoffs wave, or something else entirely?

Thanks for reading, and see you next Sunday.

And in case you missed it — #4 for The DEV Guide I Wish Existed is LIVE. Check it out below if you haven't already:

Features a pre-application vetting framework

Dhruv Jani

Sep 10

The Internship That Taught Me to Read Between the Lines of a Job Offer

#discuss #career #devjournal #showdev

8 min read

🇮🇳 Follow for the next drop — Indian tech doesn't slow down.

Dhruv JaniFollow

Upcoming Trainee Engineer @ Simform 🚀 Building, experimenting, and writing my way through tech. AI • Web • Open Source • Challenges If I find something interesting, I'll probably write about it. 😄

Why Type Safety Matters More as a Codebase Grows

khg5293 — Sun, 13 Sep 2026 02:54:50 +0000

When a project is small, type safety can feel like extra work.

If you only have a few files and you wrote most of the code yourself, it is often easy to remember what each function expects and what each object contains.

That changes quickly as a project grows.

More components, more API responses, more shared utilities, and more contributors all create opportunities for assumptions to drift.

One of the biggest benefits of static typing is that it turns many of those assumptions into something the compiler can check.

For example:

type User = {
  id: number
  username: string
  isActive: boolean
}

const user: User = {
  id: 5293,
  username: "khg5293",
  isActive: true
}

Now a function that expects a User has a clear contract.

function displayUser(user: User) {
  console.log(user.username)
}

displayUser(user)

If the structure changes later, TypeScript can point out the places that need to be updated.

This becomes especially useful during refactoring.

Without type checking, changing a shared object or function signature can create bugs in parts of the application that may not be immediately obvious.

With TypeScript, many of those problems become compile-time errors instead.

Type safety does not eliminate bugs, and it does not replace testing.

But as a codebase becomes larger, it reduces the amount of information developers have to keep in their heads.

That is where I think TypeScript becomes most valuable.

It is not just about preventing simple mistakes.

It is about making larger systems easier to change with confidence.

Why Parameterized Queries Matter for SQL Security

khg5293 — Sun, 13 Sep 2026 02:52:44 +0000

SQL injection is one of the classic examples of what can happen when an application mixes user input directly into a database query.

The underlying problem is simple.

The application expects data.

The database may interpret part of that data as SQL code.

That is why parameterized queries are such an important security control.

The unsafe approach

Imagine a simple project lookup page where a user submits a project name.

An unsafe query might be built like this:

const projectName = request.body.projectName;

const query =
  "SELECT * FROM projects WHERE name = '" +
  projectName +
  "'";

db.query(query);

If the input is:

khg5293-json-formatter

the final query becomes:

SELECT * FROM projects
WHERE name = 'khg5293-json-formatter';

That looks fine.

The problem is that the application is directly combining input with SQL syntax.

Why this becomes dangerous

An attacker is not required to submit the value the application expects.

They may provide input containing characters that change the meaning of the query.

Once user input becomes part of the SQL statement itself, the database may interpret it as executable SQL instead of ordinary data.

That is the security boundary we want to preserve.

The application should control the SQL structure.

The user should only control the values being supplied to that structure.

Parameterized queries separate code from data

A safer version looks like this:

const projectName = request.body.projectName;

db.query(
  "SELECT * FROM projects WHERE name = ?",
  [projectName]
);

Here, the SQL statement and the user supplied value are passed separately.

The database driver handles the parameter as data rather than inserting it directly into the SQL syntax.

This is much easier to reason about and significantly safer.

Another example

Imagine a page that retrieves a project using a numeric ID.

A parameterized query could look like this:

const projectId = Number(request.params.id);

if (
  !Number.isInteger(projectId) ||
  projectId <= 0
) {
  throw new Error("Invalid project ID");
}

db.query(
  "SELECT * FROM projects WHERE id = ?",
  [projectId]
);

This combines two useful controls.

First, the server validates that projectId is actually a positive integer.

Second, the value is passed into the SQL query as a parameter.

Validation and parameterization solve different problems, but they work well together.

Input validation alone is not enough

It is tempting to think that filtering suspicious characters is enough to prevent SQL injection.

For example:

const input = request.body.projectName;

if (input.includes("'")) {
  throw new Error("Invalid input");
}

This is not a good primary defense.

Attack techniques can vary, database syntax can vary, and maintaining a list of every dangerous pattern is difficult.

The safer approach is to design the query so that user input is never interpreted as SQL syntax in the first place.

That is exactly what parameterized queries are designed to do.

Avoid building queries manually

Consider this:

const owner = request.body.owner;
const status = request.body.status;

const query =
  "SELECT * FROM projects WHERE owner = '" +
  owner +
  "' AND status = '" +
  status +
  "'";

db.query(query);

The more values that are concatenated into a query, the harder the code becomes to reason about safely.

A parameterized version is much cleaner:

db.query(
  "SELECT * FROM projects WHERE owner = ? AND status = ?",
  [owner, status]
);

The SQL structure stays fixed.

Only the values change.

Parameterized queries also improve readability

Security is the main benefit, but parameterized queries usually make code easier to read as well.

For example:

const project = {
  owner: "khg5293",
  language: "TypeScript",
  status: "active"
};

db.query(
  "INSERT INTO projects (owner, language, status) VALUES (?, ?, ?)",
  [
    project.owner,
    project.language,
    project.status
  ]
);

It is immediately clear which values are being inserted and where they belong.

The developer does not have to manually worry about quoting or concatenating each value.

Parameterization is not the entire security model

Parameterized queries are extremely important, but they are still only one layer.

Applications should also consider:

Input validation
Authentication
Authorization
Least privilege database accounts
Secure error handling
Logging and monitoring
Rate limiting where appropriate

For example, a perfectly parameterized query is still a problem if any user can access data they are not authorized to see.

Security controls solve different parts of the problem.

A useful mental model

I like to think of it this way:

SQL belongs to the application.

Data belongs to the user.

The application should never let user supplied data become part of the SQL language itself.

For example:

db.query(
  "SELECT * FROM projects WHERE owner = ?",
  ["khg5293"]
);

This is fundamentally safer than constructing the SQL statement by combining strings.

Final thought

Parameterized queries are not complicated, but they solve an important problem.

They create a clear separation between SQL instructions and user supplied data.

Input validation is still valuable.

Authorization is still necessary.

Other defensive layers still matter.

But when an application interacts with a SQL database, parameterization should be the default way to handle values.