Developer Tools

Ask a model to reply with JSON and most of the time json.loads() works fine. The failures are the ones that cost you a debugging session: a one-line comment inside the object, a markdown code fence wrapped around it, a key spelled userEmail when your code expects user_email. A stricter prompt (“reply with ONLY the JSON object, no other text”) makes these rarer. It doesn’t make them impossible, because the model can still ignore a request. Structured output removes the request from the equation: you hand the API a JSON Schema, and it constrains the model’s own token sampling so the reply has to match it. ...

You save a file, Prettier reformats it, and ESLint immediately flags an error on the line Prettier just touched. Both tools are configured, both are running, and they are fighting each other instead of helping you. The two tools do different jobs. The trouble is that both have opinions about one thing: how code looks on the page. What ESLint actually checks ESLint parses your code into an abstract syntax tree and runs rules against its structure. Most of its value comes from rules that catch real bugs: a variable that’s never defined, an unreachable return after another return, an unused import left over from a refactor, a duplicate object key that silently overwrites the first. These are semantic checks. ESLint is reading what the code does. ...

Why “it looks right” isn’t a test for a prompt You tighten the wording of a ticket-routing prompt, run it against the three examples open in your scratch notebook, and ship it. A week later, billing complaints that used to land in the right queue start landing in “question” instead. Not the three cases you checked: the other four hundred you didn’t. Nothing crashed. There’s no stack trace. The prompt still reads fine out loud. ...

What LLM function calling actually does Ask a model “what’s the weather in Austin right now” with no connection to the outside world, and it has two options: say it doesn’t know, or make something up. Function calling gives it a third option. It describes what it needs, hands that description to your code, and waits for a real answer before replying. The name is slightly misleading. The model does not call anything. It emits a block of structured data saying which tool it wants and with what arguments, and your application decides whether to run it and what to do with the result. “Tool use” is the more accurate term, and it’s the one Anthropic’s docs use; OpenAI and Google mostly say function calling. The mechanism is the same under both names. The model only ever produces a request, never the side effect. ...

Run npm install on a project, then pnpm install against the same package.json, and you get two different node_modules trees and two different lockfiles. Add a teammate who reaches for Yarn and the repo can end up with three lockfiles in its history, each describing a slightly different dependency tree. All three tools read the same package.json and pull from the same npm registry. They disagree about what to put on disk. ...

What a decorator actually does to your function You want to time every function that calls a slow external API. You can paste time.perf_counter() calls into each one, or write the measurement once and apply it everywhere. A decorator is the second option. It is a function that takes another function, wraps it in extra behavior, and returns the wrapped version under the original name. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import time def timed(func): def wrapper(*args, **kwargs): start = time.perf_counter() result = func(*args, **kwargs) elapsed = time.perf_counter() - start print(f"{func.__name__} took {elapsed:.3f}s") return result return wrapper @timed def fetch_price(ticker): time.sleep(0.2) # stand-in for a network call return 142.50 fetch_price("AAPL") # fetch_price took 0.201s @timed above def fetch_price is shorthand for fetch_price = timed(fetch_price). Python calls timed once, right after fetch_price is defined, and rebinds the name fetch_price to whatever timed returns. That’s all the @ does. ...

Install two Python projects on the same machine and the second one can break the first. One needs requests==2.28, the other needs requests==2.32, and pip has exactly one system-wide site-packages directory to write into. The last install wins, silently. You find out when the other project starts throwing errors that have nothing to do with the code you just changed. A virtual environment gives each project its own site-packages. Nothing global gets touched, and two projects can depend on incompatible versions of the same library without either one noticing. ...

What makes one CLI coding agent different from another Ask a CLI coding agent to fix a failing test and it won’t reply with a suggestion. It reads the test output, opens the file, edits a line, reruns the test, and reports back once it passes. That loop is the product, not the chat window. The model inside the loop gets most of the attention, and it’s also the part that changes fastest: vendors swap in new ones every few months, and several agents let you pick. What stays put is the harness wrapped around the model — which tools it can reach, how it manages context, what it may run without asking, and where those commands execute. Two agents running the same model can behave very differently because of it. The harness is what you’re actually choosing. ...