标签：#tooling

I hit Ctrl-F more than any other key combination on this machine. It runs a shell function called fts — "find tmux session," which is not a good name but it's four years too late to change it. I press it, a fuzzy finder opens listing every project directory I have, I type a few characters, and I'm sitting in a tmux session for that project with the panes already laid out. If the session already existed, I'm back in it exactly where I left off. If what I typed doesn't exist yet, it offers to create it. Somebody watched me do this over a screen share recently and asked what was going on. So: here's the whole thing, the four tools it's built on, and a breakdown of every part that isn't obvious. What you'll end up with: One keystroke from anywhere to any project Fuzzy search across every repo you own, with a live directory tree preview Type a name that doesn't exist → it offers to scaffold and place it Never accidentally start a second tmux session for a project you already have open The same window/pane layout in every project, every time The problem it solves Before this, starting work looked like: cd ~/repo/work/some-project-i-half-remember-the-name-of tmux new-session -s some-project # split some panes, badly, slightly differently each time Three or four commands, one of which needed me to remember a path. None of it hard. All of it friction at exactly the wrong moment — the moment you've decided to start something, which is the moment you're most likely to get distracted instead. I'd also collected tmux sessions named 0 , 1 , 2 and some-project-2 , because I kept starting new ones instead of attaching to the one already running. So the goal wasn't really speed. It was making the right thing the automatic thing. Prerequisites Four tools plus zsh. All four are worth having on their own, and three of them are things you'll reach for daily once installed. Tool Version I'm on What it does here tmux 3.6a The terminal multiplexer. Holds the sessions, windows and panes. fz

Using one coding agent is simple. Using several across multiple projects is where the real mess begins. I often had Claude Code and Codex running side by side. One agent was working, another was waiting for approval, and yesterday’s useful session was buried under a different path, branch, or terminal window. The agents were capable. My workspace was not. That frustration led me to build Termexo , a local-first Windows workbench for coding agents. The problem was not the model The hardest part was no longer generating code. It was keeping track of context: Which agent is still working? Which one needs my approval? Where did I leave yesterday’s session? Which project, path, and branch did that terminal belong to? Which model profile was active? A pile of terminal windows can answer all of those questions—but only if you remember everything yourself. What I wanted instead I wanted one recoverable workspace where I could: run Claude Code and Codex in real PTY terminals; arrange terminals in custom grids; see when an agent needs attention; search and resume native sessions; restore a workspace after restarting the app; switch Claude-compatible model profiles without rebuilding environment variables; keep API keys in Windows Credential Manager. That became Termexo. Why keep the native CLI? Termexo does not replace Claude Code or Codex with a custom chat interface. The real CLI remains visible and usable. That matters because the terminal is still the source of truth. Existing commands, hooks, approvals, keyboard shortcuts, and session behavior continue to work. Termexo focuses on the coordination layer around those tools. A workspace should be recoverable A useful coding-agent session should not disappear just because the app restarted or a terminal was closed. Termexo treats terminals, layouts, projects, and native agent sessions as parts of the same workspace. The goal is simple: when you return, you should be able to understand what was happening and continue without

A suite of developer tools you run with the curl you already have: UUIDs, hashes, JSON End-points, JWTs, JSON, QR, File Transfers and more. Nothing to install, and no signup required. "curl curlhub.sh" to see list of commands or visit https://curlhub.sh to view all tools full details and soon contribute. root@web01:~# curl curlhub.sh curlhub.sh — CLI-first developer utilities Zero-setup tools you curl straight from the terminal. Generators /uuid RFC 4122 v4 UUID. /pass High-entropy password / API key / token. CLI: server-side CSPRNG over TLS; web: client-side. Never logged. ( https ) Utilities /qr ANSI/UTF-8 QR code from ?data. Nothing stored server-side; use HTTPS or pipe stdin for sensitive payloads ( a ?data = value appears in request URLs ) . Encoding /b64 Base64 encode / decode. (https) /hash MD5 / SHA-1 / SHA-256 / SHA-512 of input. (https) Developer /json Validate + prettify + colorize JSON. (https) /jwt Decode & pretty-print JWT header/payload. No verify; token never logged. ( https ) /status Explain an HTTP status code + troubleshooting. /cron Translate a cron expression to English + next run times. /ua Parse the User-Agent you sent (browser / OS / engine / device). /headers Echo the request headers you sent (+ the edge view). Your own request, not a remote audit. /hook Webhook inspector: mint a temp endpoint, inspect incoming HTTP. (https) Text & Logs /md Render Markdown to colorized ANSI (safe, bounded parser). (https) /p Pastebin: pipe text/logs to a short URL (plaintext in terminal, highlighted on web). (https) Network /cidr Subnet / CIDR math: range, netmask, broadcast, host count. /ip Your public IP (thin). Geo/ASN live at worldip.io. /whois Domain registration / registrar / dates (public OSINT; rate-limited + cached ) . Security /ssl Decode a PEM certificate or CSR you paste (expiry, issuer, SANs, key). No outbound connection. (https) File Transfer /u Ephemeral file drop (<=100 MB). ANSI QR; auto-purge after 1 download or TTL. ( https ) Docs /man Com

TL;DR: I tried to compile the TypeScript 6 compiler into a native binary with scriptc , and I failed — it got 90% of the way there and then hit an internal compiler error it couldn't get past, so there is no native tsc at the end of this story. But it's a failure worth having: I learned exactly where a week-old TypeScript-to-native compiler runs out of road, and I got some interesting numbers along the way. So when scriptc was released to the public a few days ago, I knew exactly how my week was going to end. If you haven't seen it yet, scriptc is a compiler that takes TypeScript — plain, ordinary TypeScript, no special dialect, no annotations — and turns it into a small, fast native binary. No Node.js. No V8. No JavaScript engine shipped alongside your code. A "hello world" comes out at around 320KB and starts in a few milliseconds. The pitch is bold: what compiles behaves byte-for-byte like Node . It does this with a three-tier model — most code lowers straight to native, anything too dynamic can opt into an embedded engine with a --dynamic flag, and the truly impossible fails at build time with a precise diagnostic instead of a surprise. It's experimental. It's early. It's exactly the kind of thing I can't leave alone. And almost immediately, a mischievous thought showed up: could I compile TypeScript itself? Not a toy. Not a fibonacci function. The actual compiler — tsc — the thing that has type-checked basically every line of TypeScript I've ever written. If scriptc can turn that into a native binary, it can turn anything into a native binary. It felt like the ultimate stress test, and I wanted to see it either fly or fall over. Why 6, and not 7? Here's where the timing gets interesting. If you've been following the TypeScript roadmap, you know the ground just shifted. TypeScript 6.0 shipped as the final JavaScript-based release of the compiler, and TypeScript 7 is the ground-up rewrite in Go — the "native" port the team has been building in the open. So we now

Not long ago, designers relied on AI mostly for generating images or experimenting with quick...

Every few months I hit the same wall. A client sends over a .mov file that needs to end up as an .mp4 for a web page, or someone drops a .heic photo in Slack and asks why it "won't open" on their Windows machine. My first instinct used to be brew install ffmpeg and then spend twenty minutes remembering the flags. These days I don't bother unless the job actually needs scripting or batch automation. Here's what's actually in my rotation, and when I reach for each one. When it's a one-off file and I just need it done If I'm not going to touch this format again for another six months, I'm not installing anything. Browser-based converters have gotten good enough that for a single file, they're just faster. CloudConvert is usually my first stop for anything document or spreadsheet related — it handles a wide range of formats and the interface doesn't get in the way. AhaConvert is what I use when it's image or audio work specifically; it's fully browser-based, no account needed, and it deletes uploaded files automatically after 24 hours, which matters if the file has anything client-confidential in it. Neither one requires me to think about dependencies or version conflicts, which honestly is 90% of why I use them. For quick audio grabs — pulling an MP3 out of a video file someone sent, or converting an old .wma voice memo — I've had good results with Online-Convert too. It's not pretty, but it's reliable and doesn't nag you to create an account. When I need to batch-process a folder This is where the browser tools stop being useful and FFmpeg earns its keep. If I'm converting 200 images or normalizing audio levels across a podcast archive, nothing beats a script I can rerun. for f in * .wav ; do ffmpeg -i " $f " -acodec libmp3lame " ${ f %.wav } .mp3" done I know this loop by heart at this point. If you're doing this regularly, it's worth the setup pain once and never thinking about it again. When it's part of a pipeline If file conversion is happening inside an app — sa

No pago $20/mes por Copilot. No tengo un Mac. Uso Linux Mint con un agente open-source, una API que cuesta céntimos y una terminal TUI. Este es mi setup real, lo bueno y lo que no te cuentan. No es postureo. Es pragmatismo. Mira, te voy a ser sincero. Cuando empecé a usar AI para programar probé de todo: Copilot, Cursor, Codeium, Continue... y cada uno tenía algo que no me cerraba. O era caro, o me ataba a un editor, o mandaba mi código a un servidor que no controlaba. Así que hice lo que haría cualquier developer cabezón: monté mi propio stack. Llevo unos meses con esta configuración y —spoiler— no he vuelto a abrir VSCode. Aquí te cuento qué uso, por qué, y lo que me costó que funcionara bien. El stack (sin humo) Linux Mint 22 ← SO base (porque funciona y no da guerra) └─ Hermes Agent TUI ← Agente open-source de Nous Research ├─ DeepSeek V4 Pro API ← El cerebro (1M contexto, $0.43/M tokens) ├─ Gemini API (free) ← Búsquedas y consultas web └─ Terminal (Alacritty) ← Donde vivo el 90% del tiempo Tres piezas. Sin IDEs de pago. Sin lock-in. Sin depender de que OpenAI no suba precios otra vez. ¿Por qué DeepSeek y no Claude/GPT? He probado los tres. Mi razonamiento: DeepSeek V4 Pro Claude Sonnet GPT-4o Precio (1M tokens in) $0.43 $3.00 $2.50 Ventana de contexto 1M tokens 200K 128K Calidad de código ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ Razonamiento largo ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ DeepSeek me da el 85-90% de la calidad de Claude por el 15% del precio. Para el 90% de las tareas diarias —refactorizar, debuggear, generar boilerplate, explicar código— la diferencia no se nota. Cuando necesito razonamiento ultra-profundo para algo muy complejo, cambio a Claude. Pero son momentos puntuales. El día a día es DeepSeek. 💡 El dato que nadie dice: Con DeepSeek V4 Pro gasto ~$5-8 al MES programando 4-6 horas al día. Con Claude o GPT estaría en $40-60. La diferencia paga mi VPS. Hermes Agent: el agente que no sabías que necesitabas Hermes Agent es un agente open-source (MIT) de Nous Research. 219K estrellas en GitHub

Why Your AI Agent Drowns in 50,000 Tokens of Tool Definitions Every time you connect an MCP server to your AI agent, you're adding thousands of tokens of tool definitions to your context window. Connect 10 servers? That's 50,000 tokens of tool schemas before you've even asked a question. Your agent is drowning in tools it doesn't need. The Problem Traditional MCP integration dumps every available tool into the context: { "tools" : [ { "name" : "file_read" , "description" : "Read a file..." }, { "name" : "file_write" , "description" : "Write a file..." }, { "name" : "shell_exec" , "description" : "Execute shell..." }, // ... 500 more tools ] } Your 200K context window is now 25% full of tool definitions. The model gets confused, response quality drops, and you're paying for tokens that add zero value. The Solution: Progressive Tool Routing HyperNexus implements a multi-layered progressive disclosure system: Semantic Search : Local vector embeddings match your prompt against a global MCP directory The Router : Only the top 3 most relevant tool schemas are injected into context Universal Parity : Byte-for-byte identical tool signatures across Claude Code, Cursor, Codex, Gemini CLI, Copilot, and Windsurf // Only inject what's relevant tools := router . FindRelevantTools ( prompt , 3 ) context . AddTools ( tools ) Results 95% reduction in tool-related context usage 3x improvement in tool selection accuracy Zero hallucinations from irrelevant tool noise Try It Yourself HyperNexus is open source and free for personal use: # Install go install github.com/HyperNexusSoft/HyperNexus@latest # Run hypernexus serve # Connect your MCP servers hypernexus mcp add filesystem hypernexus mcp add github Your AI agent will now only see the tools it needs for each request. This article was originally published on hypernexus.site

I gave an AI agent a calculator because I wanted one hard, inspectable point inside a probabilistic workflow. The model could interpret the request and explain the result. The calculator would perform the computation. It seemed like a clean division of labor. Then I changed one multiplication sign into addition. The calculator still passed 389 of the 390 tests in its Rust library harness. The sole failure compared its answer with NIST's certified results for the Longley regression dataset. That bothered me more than a completely broken build would have. I had treated deterministic computation as safer than asking a language model to improvise arithmetic. But deterministic does not mean trustworthy. A program can return the same wrong answer forever. “Source of truth” suddenly felt too comfortable. Before an AI agent delegates authority to a tool, that authority should be challenged—and remain revocable by evidence. The calculator is only the specimen. The larger idea is a way to place inspectable, replayable instruments inside probabilistic systems. The useful boundary is generation versus execution The interesting distinction is not model weights versus a “real CPU.” Model inference also runs on processors, and language models can learn genuine arithmetic procedures. The useful boundary is between generating an answer and executing a defined operation under a tested contract . Research on Program-Aided Language Models (PAL) makes a related split: the language model reads and decomposes a natural-language problem, while a runtime such as a Python interpreter executes the generated program. The model contributes flexible interpretation; the runtime contributes executable semantics. That is the division I want in an agent: At the semantic edge , the model interprets the request, chooses a procedure, identifies relevant quantities, and explains the result. At the computational edge , a narrow tool validates inputs, applies specified operations, enforces limits, and ret

Estimated reading time: ~11 minutes. No prior experience required. Fifty adapters in a drawer Remember the era when every phone, camera, and gadget had its own special charger? A drawer full of incompatible cables, and the one you needed was never there. Then USB (and later USB-C) arrived, and suddenly one port charged everything. The magic wasn't a better cable, it was an agreed-upon standard that every device and every charger followed. AI tools were living in that pre-USB drawer. Every time you wanted an AI assistant to talk to a new system, your files, a database, a ticketing tool, someone had to hand-build a custom connector for that specific pairing. Ten AI apps times ten tools meant a hundred bespoke integrations. The Model Context Protocol (MCP) is the USB-C moment for AI: one standard so any AI app can talk to any tool. By the end of this post you'll understand what MCP is, its core parts, how a connection works, the traps to watch, and why it matters for the future of AI. What is MCP, really? One sentence: The Model Context Protocol is an open standard that defines a common way for AI applications to connect to external tools, data sources, and services, so any compliant AI app can use any compliant tool without custom glue. It was introduced to solve the "N times M" integration explosion: instead of building a custom bridge for every AI-app-to-tool pair, everyone speaks one shared language. The USB-C analogy (in full) The AI app (a chat assistant, a coding agent, an IDE) is your laptop . A tool or data source (your files, a database, a calendar, a search engine) is a peripheral , a monitor, a drive, a keyboard. MCP is the USB-C port and cable standard between them. Before USB-C, connecting a new monitor to your laptop might need a special adapter made just for that model. After USB-C, you plug in any compliant monitor and it just works. MCP does that for AI: build your tool as an "MCP server" once, and every MCP-compatible AI app can use it, no per-app wo

I want to tell you about a tool I've been using for a few months now, that I can't believe that I ever went without. Recently, I've been more productive, experimental and I've learned more about my development environment just from using this tool. Alright, I'm done burying the lead. The tool is git worktrees . Worktrees is a feature built into git that allows you to have multiple working trees of a repository at once. That means you can have multiple branches checked out, with incomplete changes on each one. Instead of having one repository where your manipulation happens, you can have infinite copies (or, as many copies as you can hold on a hard drive)! Often, I am in the middle of working on a feature and I get an email about an urgent bug or a small change that needs made immediately. Before, I would have to either create a "wip:" commit or stash my changes, and I don't really like doing either one of them. Now, as long as my files are saved, I can safely close my editor, create a new worktree and leave all of my uncomitted changes waiting for me to return. How to set up your project for git worktrees In a normal project, your directory might look something like this: MyProject/ ├── .git/ <-- Git metadata in the project dir ├── bin/ ├── obj/ └── Program.cs After following just a few steps, our projects will look more like this: MyProject/ ├── .git/ <-- Git metadata ├── feature-x/ <-- Worktree #1 ├── bin/ ├── obj/ └── Program.cs └── bugfix/ <-- Worktree #2 ├── bin/ ├── obj/ └── Program.cs A full copy of the project's files. In order to set a project up this way, it's best to start in an empty directory, with your project hosted on a remote git server. First, create a directory for your project. mkdir MyProject && cd MyProject Once inside, we're going to clone a bare repository. A bare repository doesn't contain a working tree or any of the files of the project, just the git metadata. We pull that and put it in the .git directory by running the following command.

Every long-lived JS/TS project I've worked on accumulates the same three kinds of rot: Dependencies in package.json that nothing imports anymore. You added moment , migrated off it, and the line stayed. Exports nothing consumes. A function was public once, the last caller was deleted, the export is still there advertising an API with no users. Whole files that fell out of the import graph but never got deleted, so every new engineer reads them trying to understand code that runs nowhere. None of this breaks the build. That's exactly why it survives. The compiler is happy, the tests pass, and the dead weight compounds quietly until onboarding takes a week and your bundle ships code no user will ever execute. The tool I've settled on for this is knip (by Lars Kappert). I run it on the enterprise codebase I maintain and on basically every other TS project I touch. One command: $ npx knip Unused files (2) src/legacy/formatValue.ts src/hooks/useLegacyModal.ts Unused dependencies (3) lodash package.json moment package.json @types/uuid package.json Unused exports (5) parseLegacy src/parse.ts:42:14 toLegacyDate src/date.ts:9:14 ... Files, dependencies, and exports in one pass, cross-referenced against the actual import graph. It's the first tool I've used that treats all three as the same problem, which they are: something is declared, nothing uses it, delete it. The honest caveat Knip is not zero-config on a real codebase. Anything resolved dynamically, runtime import() , plugin systems, framework entry points it doesn't recognize (Next.js pages, a CLI bin, config files loaded by string), gets flagged as unused when it isn't. You will get false positives on day one. The fix is a knip.json that names your real entry points, and after that it's accurate. But budget an afternoon to tune it before you trust the output enough to delete on it. Anyone who tells you it's instant hasn't run it on a large app. What I actually want Here's the part that bugs me. This problem is not sp

Every AI writing tool does the same thing: you type a prompt, it spits out text, and you copy-paste it into Word. Then you spend the next 30 minutes manually applying headings, fixing list styles, rebuilding tables, and cleaning up formatting that broke on paste. Co-pilot lives inside Word, sure, but it's a writing assistant, not a formatting one. It drafts text, rewrites paragraphs. What it doesn't do is look at your messy 40-page report and restructure it with your actual Word styles, proper heading hierarchy, and correctly formatted tables. That's the gap we set out to close with Stylifyword. What Stylifyword Actually Does: Stylifyword is a Microsoft Word add-in paired with a companion desktop app. You give it a document, a messy draft, a copy pasted ChatGPT output, a stitched together report from five different authors and voila, it writes & edits your text when you ask it to (drafting, rewriting, summarizing the usual AI stuff). Also formats the entire document with your headings, lists, tables, and all. Outputs every change as a tracked redline in Word's Review tab. Nothing touches your document until you accept it. That third point is the key differentiator. It's non-destructive. The AI proposes, you dispose. Why Local-AI support Matters: Here's the thing that got me building this: most professionals who need AI the most can't use cloud AI tools. Corporate attorneys can't paste M&A deal terms into ChatGPT. Healthcare teams can't upload patient data to a cloud endpoint. Defense contractors, compliance officers, financial analysts, they're all locked out of the AI productivity wave because of legitimate data sovereignty concerns. Stylifyword's default mode runs entirely on your machine: 100% on-device inference via a companion desktop app. No Ollama, no command line, no model downloads to configure. Works offline, airplane mode, air-gapped networks, whatever. Zero data leaves your device, ever. Install the app, open Word, and it works. Three Ways to Run It: Not

The original concept behind this tool won the runner-up award for the Github CLI Challenge earlier this year. As a reminder, ReflectCLI is a tool to promote thoughtful coding through structured reflection. What does it do? Before each commit, answer reflective questions to build your personal developer knowledge dataset. The tool is local-first by design. It stores everything locally inside the current Git repo: .git/git-reflect/log.json No account, no cloud sync, no authentication, and no external AI API call. Why build it? AI-assisted development is powerful, but it can encourage cognitive offloading, letting tools do the thinking instead of developing deeper understanding. git-reflect interrupts this pattern by making reflection part of your workflow. Each answer becomes part of your personal knowledge base, documenting not just what you built, but why you built it that way and what you learned. Over time, this dataset reveals patterns in your thinking and helps you grow as a developer. If you want to read about the original tool, check out my previous post here . Since building the original version, I've spent months researching how AI changes the way developers learn, reason, and make technical decisions. Many of the ideas from those discussions have now been incorporated into ReflectionCLI 2.0. What started as a simple Git pre-commit reflection hook has evolved into a local-first thinking tool for developers working alongside AI assistants. What's New Comprehension debt tracking You can now record artifacts you shipped but don't fully understand yet. reflection debt add "Understand why the cache invalidates on user updates" \ --project api \ --tags cache,ai \ --context "AI generated most of the invalidation logic" These artifacts can easily be retrieved and resolved later. reflection debt list reflection debt resolve debt-001 Explain-back mode This workflow focuses on active recall and asks a series of questions to assess your ability to explain the piece of c

The evals for my agent skills scored 0% for as long as I had records. Not low. Not noisy. Exactly zero, every skill, every run. And I believed it. For months I thought my skills were bad, because the number said so and the number never wavered. Then one night I actually read the harness. It had fallen back to the wrong auth token. Every call it made came back 401, and it quietly graded each one a failure. The skills never got a chance to fail on their own. I was not measuring them at all. I was reading a broken thermometer. Real weakness is jagged Here is what took me too long to see. When a system is genuinely bad, it scores 40% one week and 60% the next. It passes the easy cases and trips over the hard ones. It has good days. Incompetence has texture, because an incompetent system is still in contact with the world, and the world varies. A flat number has no texture. A flat number means the measurement stopped touching the thing being measured somewhere upstream, and what you are reading is the instrument's resting state. Doctors know this. A heart monitor drawing a perfectly straight line does not mean the patient is calm. Only a broken thermometer writes the same number every time. Key insight: A performance number with no variance is a reading of the instrument, not of the thing being measured. The same bug in three industries I run systems in advertising, in healthcare billing, and in agent operations, and the same shape shows up in all of them. In advertising I found a dashboard figure that had been hardcoded for two years. Nobody questioned it, because it looked right, and it looked right because it never moved. In agent operations, an account-rotation bug in one of my pipelines overwrote every real error with the same generic message, "no active accounts," so for a while every distinct failure in that system looked identical. And in the denial-assessment engine I run for a medical-billing operation, an agreement metric came back at 44.7%, alarmingly low, un

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

This project was supposed to be a quick experiment. I had been reading about DNA storage and got carried away with the idea. DNA can pack a ridiculous amount of information into a tiny space. I started wondering if a database could behave a bit like a living system: the schema as its basic code, the queries as signals, and indexes changing as the workload changed. I spent two or three days building around that idea. Then I had to admit something fairly obvious. Most of what I was reading described DNA as an archival medium . It involves writing and reading physical DNA. That is nowhere near the speed or simplicity needed by a normal application database. Also, I am not a PostgreSQL expert. I was building an algorithmic-trading system, learning as I went, and trying to solve a problem I did not fully understand yet. When the sprint ended, I could not tell whether I had built something useful or just wrapped a lot of code around a clever-sounding metaphor. The literal DNA idea had to go. One smaller question survived: When somebody adds a new Postgres index, how do we know it is useful and not just valid-looking SQL? That question became IndexPilot. The problem I kept running into Adding an index looks simple: CREATE INDEX orders_customer_created_idx ON public . orders ( customer_id , created_at ); I could read that line. I could understand the intention. What I could not tell was whether the real database needed it. Maybe the query it is meant to help hardly ever runs. Maybe another index already covers the same columns. Maybe PostgreSQL would ignore it. Maybe it helps reads but adds more cost to every write. The SQL can look completely reasonable while the decision is still wrong. That felt like a useful place for a small tool. Not a tool that changes the database automatically. Just something that collects enough evidence to make the next review less guessy. What IndexPilot does IndexPilot reviews the exact CREATE INDEX statement in a migration. It can compare that

Why this matters I’ve worked on a few frontend projects where code reviews turned into style debates—tabs vs spaces, semicolons, quote styles… you name it. It slows everything down and adds zero value. At some point, I realized this shouldn’t even be a discussion. So now, whenever I start a project, I set up Prettier + ESLint + Husky on day one. No debates. No manual fixes. No messy PRs. This post is exactly how I do it. 🧰 What each tool actually does Prettier → formats your code automatically ESLint → catches bad patterns & enforces rules Husky → runs checks before commits (so no one skips them) Together → clean, consistent code without thinking ⚙️ Step 1 — Install dependencies npm install -D prettier eslint husky lint-staged 🎯 Step 2 — Setup Prettier Create: prettier.config.js module . exports = { semi : true , singleQuote : true , trailingComma : ' all ' , tabWidth : 2 , }; Create: .prettierignore node_modules dist build 🔍 Step 3 — Setup ESLint Initialize: npx eslint --init Then tweak your config: .eslintrc.js module . exports = { extends : [ ' eslint:recommended ' , ' plugin:react/recommended ' , ' prettier ' ], rules : { ' no-unused-vars ' : ' warn ' , ' react/react-in-jsx-scope ' : ' off ' , }, }; 👉 Important: "prettier" disables ESLint rules that conflict with Prettier. 🔗 Step 4 — Connect ESLint + Prettier Install: npm install -D eslint-config-prettier That’s it. Now ESLint won’t fight Prettier. 🐶 Step 5 — Setup Husky Initialize Husky: npx husky init Add pre-commit hook: npx husky add .husky/pre-commit "npx lint-staged" 🚀 Step 6 — Setup lint-staged Add to package.json : "lint-staged" : { "*.{js,jsx,ts,tsx}" : [ "eslint --fix" , "prettier --write" ] } 💡 What happens now? Every time you commit: ESLint checks your code Prettier formats it Only clean code gets committed No more: “fix formatting” PR comments broken lint rules in main branch inconsistent code styles 🧠 Real impact (from experience) After adding this to a team project: PR noise dropped a lot reviews

Every developer I know has the same reflex now. Hit an unfamiliar concept, paste it into ChatGPT, read the explanation, move on. I did this for months. It felt efficient. Then I noticed a pattern: I was reading a lot of clear explanations and retaining almost none of them. I could follow along perfectly in the moment and then draw a blank a week later when I actually needed the knowledge. The problem was not ChatGPT. The problem was using a general-purpose conversational tool for a job it was never designed to do. Here is what I switched to, and why it works better. The three failure modes of using a chatbot to learn Passive consumption feels like learning. Reading a good explanation triggers the feeling of understanding without the work that creates actual memory. You nod along, it makes sense, and nothing sticks. This is the biggest trap. There is no retrieval practice. The research on this is well established: you remember things by pulling them out of memory, not by putting them in repeatedly. A chatbot will explain the same concept ten different ways, but it will never make you answer a question you cannot immediately answer. That struggle is the mechanism. Confident hallucination is dangerous when you are the beginner. If you already know a topic, you can spot when an AI is subtly wrong. If you are learning it for the first time, you cannot, and you may internalize something incorrect with full confidence. For technical material, this is a real cost. What actually works better Tools that quiz you. Anything built around retrieval practice and spaced repetition beats passive reading by a wide margin. If a tool generates questions from your material and makes you answer them over spaced intervals, it is working with how memory actually forms rather than against it. Tools that read YOUR source material. This one is huge for technical learning. Instead of asking a model to answer from its general training data (which may be outdated or wrong for your specific libra

The issue was not the tools. It was opening five of them before deciding what the log file was for. The log file was already on the screen. A remote Windows workstation had failed a desktop build, and the relevant file was sitting in a local app directory, something like: C:\Users\<user>\AppData\Local\<app>\logs\build.log The remote session was working. The error was visible. The next step seemed small: get the log back to the local laptop, open it in a familiar editor, compare it with the issue notes, and pull out the part that mattered. That should have been a 30-second task. Instead, it turned into five context switches. The first context was the remote session The remote desktop session made sense. The build failed on that machine, the app was installed there, and the log path was easier to find visually than by guessing from memory. So far, nothing was wrong. The file was selected. The timestamp matched the failed run. The log looked useful. It probably had the stack trace, the missing dependency path, or the configuration mismatch that explained the build failure. Then came the small but surprisingly annoying question: How should this file leave the remote machine? That is where the workflow started to wobble. The second context was chat The first instinct in many teams is chat. Drop the file into a message to yourself, a teammate, or the debugging thread. It is fast, already open, and keeps the file near the conversation. For some files, that is the right move. A screenshot, a short error snippet, or a quick “does this look familiar?” artifact belongs naturally in the discussion. But a full log file is not always a chat artifact. If it goes into chat, will anyone know later whether it was the first failing run or the second? Will it be obvious which remote machine produced it? Will the file still be easy to find after the thread moves on? Chat was not wrong. It was just not clearly the right home for this specific file. So the workflow moved on. The third con