DEV Community: Konstantin Konovalov

You Don't Need a Better Prompt. You Need a Brief.

Konstantin Konovalov — Fri, 07 Aug 2026 06:15:04 +0000

Every few days someone asks me for the prompt that makes the model behave. The secret opener, the magic system message. I used to hunt for it too. It doesn't exist, and looking for it kept me stuck longer than it should have.

What actually moved my results was treating the model like a contractor I hired an hour ago. Fast, literal, no context about my codebase, and it will do exactly what I write down, including the parts I only meant.

Watch a vague ask fall apart

Say I want to parse a date out of some messy user field. The lazy version:

Parse the date from this string.

The model returns something. It handles 2024-03-01 fine and quietly falls over on 1/3/24, or March 1st, or an empty cell. Not because it's dumb. Because "parse the date" didn't say which formats exist, what a two-digit year means, or what to do when there's no date at all. I had answers to all of those in my head. I just never wrote them down, so the model guessed, and its guess came from the average of the internet, not from my data.

Here's the same task as a brief:

Write a function parseDate(s) that accepts these formats:
YYYY-MM-DD, D/M/YY, and "Month Dth".
Two-digit years are 2000-2099.
Return null if the string has no recognizable date. Don't throw.
Return a Date object, UTC, time set to midnight.
Example: parseDate("1/3/24") -> 2024-03-01T00:00:00Z

Same model. The output is now something I can actually check, because I said what "done" looks like and what the weird inputs are. That's the whole trick, and it isn't a trick.

The four gaps that ruin most prompts

When output disappoints me, I can nearly always trace it to a decision I made silently. So before I send anything, I check four things:

The input, and its ugly version. Empty, huge, wrong type, wrong encoding.
What happens when something's missing. Fail loud, skip it, or substitute a default.
What must not change. The signature, the existing behavior, the file I didn't mention.
What done looks like. One concrete input paired with the output I expect.

The last one carries more weight than the other three together. A single worked example pins down intent that a paragraph of adjectives never will.

The expensive failure nobody warns you about

The costly mistake isn't the model refusing or spitting out junk. You catch those immediately. The expensive one is the model helpfully fixing something you never asked it to touch. You said "add a field to this form," and it also tidied the validation, and two days later a different flow is broken and you have no idea why.

One line prevents it: say what stays put.

Add the phone field. Leave the email validation, the submit
handler, and the styles exactly as they are.

Models are eager. Unbounded eagerness looks like helpfulness right up to the moment it rewrites a working thing. Naming the untouchables costs five seconds and saves the debugging session where you diff two files hunting for what moved.

Small steps you can actually verify

The other habit: stop asking for the whole feature at once. Not because the model can't produce it, but because you can't check it. One function with clear edges, you read and run in a minute. "The whole auth flow" comes back as a plausible wall of code that takes longer to verify than it would have taken to write. You didn't get leverage, you got a thing you can't inspect.

Break the work into steps small enough that each has an obvious pass or fail. Get one right, build on it. Slower to type, much faster to finish, because you're not unpicking a wrong assumption baked in three layers deep.

The point

If you tried these tools, got mush, and blamed the model, check the ask first. Most of the time the ceiling was the brief, not the model. The skill that matters now isn't clever phrasing. It's thinking one level more carefully about what you want and saying it in order: the input, the constraints, the thing that must not move, and one example of done.

Pick one annoying task and write it up that way. The output changes, and it won't be because the tool got smarter.

Written by the team behind AGINE Academy, an independent product by AGINE AI (not affiliated with Anthropic). We teach building with Claude by doing the work rather than watching lectures.

Inbox and Calendar on Autopilot with Claude: What's Actually Safe to Automate

Konstantin Konovalov — Wed, 05 Aug 2026 14:30:00 +0000

The pitch: connect Claude to Gmail, Calendar, and Drive and let it run your day. What you actually get is smaller and more useful. It reads across your workspace, pulls the right context, summarizes it, and prepares actions. You still press the buttons that matter.

Here is what works today, how to wire it up without handing over the keys, and the places you should never take yourself out of the loop.

What connectors actually do

Claude reaches Google Workspace through connectors built on the Model Context Protocol (MCP). Once you authorize access, it can search your mail, read threads, check your calendar, and open files in Drive, all inside a normal conversation. No glue code, no cron job to babysit.

The split that matters is read versus write. Reading (search, summarize, list events, pull a doc) is where connectors are strong and the risk is low. Writing (sending mail, creating or moving events, editing files) is where you slow down and add checks.

Think of it as a well briefed assistant who can see everything but has to ask before touching anything.

Three workflows that hold up in real use

1. The morning brief. Instead of opening five tabs, ask for one summary.

Look at my calendar for today and my inbox from the last 18 hours.
Give me: meetings that need prep, emails waiting on a reply from me,
and anything with a deadline this week. Keep it to one screen.

You get a scannable digest. Claude reads across mail and calendar and stitches them together, which is the part that normally eats the start of your day.

2. Inbox triage. Not auto-archiving, just sorting your attention.

Group my unread mail into: needs a reply from me, FYI only,
and can wait. For the "needs a reply" ones, draft a short response
I can edit. Do not send anything.

The "do not send" line matters. Triage is a read-plus-draft task, and the draft is a starting point, not an outbound message.

3. Thread and meeting summaries. Long threads and prep docs are what this is best at.

Summarize this thread, list who is waiting on what, and pull the
relevant doc from Drive if one is referenced. Flag any open decision.

Highest value, lowest risk. You are asking Claude to compress information you already have access to.

Setting it up without regret

A few habits keep this safe.

Least privilege. Authorize only the scopes you need. If your goal is briefs and drafts, you may not need write access to Drive at all. Read-only is a real, useful mode.
Start read-only, add write later. Live for a week on summaries and drafts before you let anything create or send. You learn fast where it is reliable and where it is not.
Watch what it retrieves. Search can miss. When Claude says "no urgent emails," read that as "none in what it found," not a guarantee. Verify anything critical.
Mind the data. You are sending email content to a model. Know your org's policy, and keep genuinely sensitive threads out of scope.

Where the human stays in the loop

Draw a hard line at anything that leaves your machine or changes shared state.

Sending email. Always review. A confident draft to the wrong person is worse than no draft.
Scheduling and calendar edits. Confirm times, guests, and time zones yourself. A time booked in the wrong zone is a real meeting someone missed.
Deleting or moving anything. There is no upside to letting a model archive mail unattended.
Anything involving other people. If the action reaches a colleague, a client, or your boss, you approve it.

One rule covers most of it: Claude drafts, you dispatch.

Where this is weaker

Retrieval is the soft spot. On a large or messy inbox, search-based access does not see everything, and a summary can quietly drop the one email that mattered. Claude can also state a detail with more confidence than the source supports, so a "confirmed for Tuesday" in a summary is a cue to go check, not a fact.

There is latency and cost. Reading across a big mailbox is slower and pricier than a native filter. For simple rules ("label everything from billing"), a plain Gmail filter still wins. Use Claude where judgment and synthesis help, not where a deterministic rule already does the job.

And it drifts. The same prompt on a busy day and a quiet day can format differently. If you want a stable daily brief, save the prompt and reuse it verbatim instead of rephrasing each morning.

The pattern worth keeping

The version of "inbox and calendar on autopilot" that actually ships is narrow and a little boring: Claude gathers and drafts, you decide and send. That covers the morning brief, triage, and summaries, which is most of the daily overhead anyway. The sending, scheduling, and deleting stay human decisions until you have watched it behave long enough to trust it. Even then, keep the send button yours.

I write about turning AI from a chat toy into a working tool. I help build AGINE Academy, a game-based academy for learning Claude by real practice. It is an independent product and is not affiliated with Anthropic.

Turn Your Routine Into an Assistant: A Practical Guide to Small AI Helpers

Konstantin Konovalov — Tue, 04 Aug 2026 15:20:00 +0000

AI is not a genie. Treat it like a function.

Most people use AI the way they use a search box: type a question, read the answer, move on. That works for one-off curiosity. It is a bad fit for the work you repeat every week, because you re-explain the context every time and never build anything you can trust.

A small assistant is different. It is one narrow task, wired up once, with a fixed input and a fixed output shape. You run it, check it, improve it. After a few iterations it stops being a demo and starts pulling real weight.

Here is how to build one without drowning in frameworks.

Start narrow: one task, one input, one output

Do not build "an assistant for my job." Build the thing that turns a messy meeting note into three bullet points. Pick a task that is:

Repetitive (you do it weekly or daily)
Boring (nobody will miss the manual version)
Verifiable (you can look at the output and know if it is wrong)

That last one matters most. If you cannot tell good output from bad in ten seconds, you cannot trust the assistant and you cannot improve it.

Good starter tasks: drafting reply emails, summarizing documents, normalizing scrappy data, extracting fields from text.

Example: an email draft as a function

Think of your prompt as a function signature. Inputs go in, a structured draft comes out.

def draft_reply(incoming_email: str, tone: str = "friendly, brief") -> str:
    prompt = f"""
    You are drafting a reply on my behalf. Do not invent facts.
    If information is missing, leave a [PLACEHOLDER].

    Tone: {tone}
    Incoming email:
    ---
    {incoming_email}
    ---
    Write only the reply body.
    """
    return llm(prompt)   # any model client you like

Two lines do the real work: "Do not invent facts" and the [PLACEHOLDER] rule. Together they turn a confident hallucination into a visible gap you can fill. The goal is to make errors loud instead of silent.

Example: summaries you can actually trust

The failure mode of summaries is a plausible sentence that never appeared in the source. Force evidence and it disappears.

Summarize the document below in 5 bullets.
For each bullet, quote the exact sentence it is based on.
If a claim has no supporting quote, drop it.

Now checking takes seconds: skim the quotes, confirm they exist in the text. You are not leaning on the model's judgment, only on its ability to copy, which is far more reliable.

Example: data cleanup, with a safety net

Cleaning inconsistent data (country names, job titles, date formats) is a great fit, and also where silent errors hide. Never let the model rewrite your data in place. Have it output a mapping you review first.

Input values: ["USA", "u.s.a", "United States", "Amrica"]
Return JSON: {original: normalized}.
Do not merge values you are unsure about; mark them "REVIEW".

You keep the original column, apply the mapping in code, and eyeball anything marked REVIEW. The model proposes, your code decides.

Verify outputs (the step everyone skips)

Before you rely on an assistant, build a tiny golden set: ten to twenty real inputs paired with the output you actually wanted. Re-run them every time you change the prompt. This is the difference between "it feels better" and "it got better."

Cheap checks that catch most problems:

Assertions in code: valid JSON? required fields present? no placeholders left behind?
A spot-check habit: read one in five outputs, even after it "works"
A refusal path: when the model is unsure, it should say so, not guess

Add an agent only when there are real steps

An agent is just an assistant that takes more than one step and calls a tool or two. Reach for it when a task genuinely has stages: fetch, then decide, then act. A triage helper that reads an inbox, classifies each message, and drafts replies for the easy ones is a reasonable first agent.

Keep the non-AI parts deterministic. Let the model classify and draft; let ordinary code do the fetching, sending, and looping. Every step you hand to the model is a step that can drift.

Where this is weaker

Be honest about the limits.

Tasks with no cheap verification (strategy, judgment calls, anything with legal or financial stakes) are a bad fit. If checking the output takes as long as doing the work yourself, you saved nothing.
Outputs drift once real inputs get weirder than your test set. The golden set slows this down; it does not stop it.
Volume amplifies mistakes. A small error rate is fine for ten drafts you read by hand and a disaster for a thousand you send unread.

None of this kills the approach. It just means verification is not optional garnish. It is the load-bearing wall.

Iterate: promote good runs into the spec

When a run comes out great, do not just enjoy it. Copy what worked back into the prompt as a rule or an example. Over a few weeks the prompt turns into a small spec of how the task should be done, and the assistant gets boring in the best way: predictable.

Pick one task this week. Ship the narrow version, verify it, and let it earn the next feature.

Teach Claude one repeatable job: a field guide to Skills and Plugins

Konstantin Konovalov — Mon, 03 Aug 2026 14:00:00 +0000

You keep re-explaining the same job

If you use Claude for real work, you have probably noticed a pattern. Every new chat starts with the same paragraph. "Here is how we format commit messages." "Use our error-handling style." "Summarize this the way I like." It works, and then the session ends and the knowledge is gone.

Skills and Plugins are the two ways to make that knowledge stick. They are easy to confuse because both "extend" Claude, but they answer different questions. A Skill answers how do I do this job? A Plugin answers how do I ship this to a team and wire it to my tools?

A Skill teaches Claude how to do a job

A Skill is a folder with a SKILL.md file at its root. The file has a small YAML header and a body of instructions:

---
name: pr-description
description: Write PR descriptions in our team format. Use when the user opens a PR or asks to summarize a branch.
---

# PR description writer

1. Run `git diff main...HEAD` to read the changes.
2. Group them by area (API, UI, migrations).
3. Fill in `template.md`. Keep the risk section honest.

You can drop extra files next to it: a template, a reference doc, a script Claude can run. The trick worth understanding is progressive disclosure. The one-line description is always in front of Claude. The body loads only when the task matches. Larger files load only if the body points to them. So a skill can carry a lot of detail without burning context on every message.

The consequence that matters: skills are model-invoked. Claude reads the description and decides whether the skill is relevant. You are not calling a function, you are writing a note-to-self that Claude picks up when the moment fits. That makes the description the most load-bearing line in the whole file.

Reach for a Skill when you find yourself explaining the same procedure, format, or set of conventions more than twice.

A Plugin ships capabilities and connects to tools

A Skill lives in your setup. A Plugin is how you package it and hand it to other people. In Claude Code, a plugin can bundle several things at once:

Skills (the know-how above)
Slash commands (e.g. /deploy, /triage) for jobs you trigger on purpose
Subagents for delegated tasks
Hooks that run at defined points, like before a commit
MCP servers that connect Claude to external systems (a database, an issue tracker, an internal API)

Someone installs the plugin from a marketplace and the whole set arrives together. That is the real value: one install gives a teammate the same commands, the same conventions, and the same connections you have. Where a Skill teaches a job, a Plugin distributes a workflow and plugs Claude into the systems that workflow touches.

Reach for a Plugin when the thing you built should be repeatable across a team, or when the job needs to talk to a live tool rather than just follow instructions.

A mental model: three layers

Think of extending an assistant as three layers, from throwaway to permanent:

Context: what you paste in the moment. Fast, precise, gone when the chat ends.
Skills: repeatable know-how Claude loads when relevant. This is the "job."
Plugins and MCP: packaged capabilities and live connections to your tools. This is the "workflow," and it is shareable.

Most people live entirely in layer one and wonder why they keep repeating themselves. Moving a recurring task down a layer is usually the win.

Where this is weaker (the honest part)

A few things bite in practice.

Skills are instructions, not guarantees. Because Claude decides when to load one, a vague description means it fires at the wrong time or not at all. If a step must happen every time (a lint pass, a redaction step), encode it as a script or a hook, not a paragraph of prose the model may skim.

Skills also compete for attention. Ten overlapping skills with fuzzy descriptions will misfire more than three sharp ones. Curate. Delete the ones you do not use.

Plugins and MCP add moving parts. An MCP server can be down, needs permissions, and comes from someone you are choosing to trust. Installing a plugin from a marketplace is a supply-chain decision, so read what it does before you wire it into your workflow.

And there is a boring failure mode: building a skill for a job you only do once. If you will not repeat it, a good prompt is cheaper than a folder you have to maintain.

Start small

Pick one task you have re-explained this week. Write a ten-line SKILL.md for it. Use it for a few days and fix the description until it triggers when you expect. If it turns out your team needs it too, that is when a plugin earns its place. Teach one repeatable job well before you try to ship a whole toolbox.

Pick Your AI by the Task, Not the Hype (A Simple Routing Framework)

Konstantin Konovalov — Sun, 02 Aug 2026 16:10:00 +0000

The wrong question

Open any tech feed and someone is crowning a new "best AI." A model tops a leaderboard, the post goes viral, and a week later a different model tops a different leaderboard. If you pick your tools this way, you are optimizing for a number that was never about your job.

The useful question is not "which model is smartest." It is "what does this task punish when it goes wrong?" A marketing email punishes a robotic tone. A migration script punishes a failed build. A finance sheet punishes an off-by-one column. A logo punishes looking generic. Those are four different failures, and they point to four different tools.

Classify the task, then the tool

Before you open a chat window, name two things: the type of work, and how you will know it failed. The failure mode does most of the picking for you.

Here is a compact map. Treat the tool names as families, not gospel, because specific rankings shift every few months.

Task	Tool that tends to fit	Why
Long-form writing, editing, tone	A general chat model with long context (Claude, GPT, Gemini)	Prose quality is about voice and coherence. There is no unit test for "sounds human," so you judge by reading, and long context lets it hold a whole doc in view.
Code, refactoring, debugging	A coding-focused model wired into your editor or terminal	Code has a hard pass/fail. The model that sees your repo and can run tests beats a smarter model guessing at files it cannot read.
Data, spreadsheets, analysis	A model that writes and runs code (Python execution)	LLMs are weak at arithmetic done in their head. One that executes code is correct by construction, not by luck.
Images, mockups, design	A dedicated image model (diffusion tools, plus the image modes of the big labs)	Different architecture entirely. Text models describe a picture. Image models render one.
Research, current facts	A tool with real retrieval and citations (browsing modes, Perplexity)	Any model without live retrieval will invent recent facts with full confidence. Citations are the point.

The pattern behind the table

Two ideas do most of the work here.

First, match the tool to the failure the task cannot tolerate. If the task has a hard check (it compiles, the numbers add up, the fact is real), pick the tool that connects to that check: code execution, repo access, web retrieval. A model that guesses is fine for a first draft and dangerous for a payroll formula.

Second, general chat models are generalists. They are the right default for open-ended work with soft criteria, like writing and thinking out loud. They are the wrong default the moment the task has a mechanical ground truth, because then you want the tool holding the ground truth, not the one with the highest leaderboard score.

A quick example. Ask a plain chat model to "sum column C where region is EU" over pasted data and it will often produce a confident, slightly wrong number. Ask a code-executing tool the same thing and it writes:

df[df.region == "EU"]["C"].sum()

runs it, and returns a number you can trust. Same request, different failure surface.

The only benchmark that counts: your own work

Public benchmarks are averaged over tasks that are not yours. The model that wins on a coding benchmark may lose on your codebase, your naming conventions, your weird legacy module.

So run a small bake-off on tasks you actually own. It costs an afternoon, and the result reflects your work instead of an average of everyone else's.

Pick three real tasks you actually do, one per category that matters to you.
Run each on two or three candidate tools with the same prompt.
Score on what you care about: correctness, edits needed, time saved. Not vibes.
Keep a note of which tool won which category. That note is your real leaderboard.

Re-run it maybe twice a year, or when a tool you use ships a major update. The rankings move, but your test does not, so re-checking is cheap.

Where this framework is weaker

Two honest caveats.

The categories blur. A lot of real work is mixed: a data task that ends in a written summary, a coding task that needs current library docs. For mixed work, split the job and route each part, or accept that one tool will be merely good at all of it instead of great at one.

And "tends to fit" is a starting bet, not a verdict. The labels above reflect how these tool families are built, not a guarantee for your exact prompt. If your own bake-off disagrees with the table, trust your bake-off. That is the whole point of running it.

Pick by the task, verify on your own work, and let the leaderboards crown whoever they like.

Stop Re-Explaining Yourself to Claude: Structure a Project That Remembers Your Work

Konstantin Konovalov — Sat, 01 Aug 2026 15:00:00 +0000

Every new chat makes Claude a stranger again

You explain the codebase. You paste the style guide. You re-describe the client, the constraints, the one legacy decision you have to live with. Then the chat gets long, you start a fresh one, and you do it all again.

That re-briefing tax is a big part of why AI assistants still feel like a demo instead of a coworker. Claude Projects exist to remove it: a workspace where your instructions, files, and context live in one place, so every conversation inside it starts already knowing your work.

What a Project actually is

A Project bundles three things:

Custom instructions that apply to every chat in the Project.
Project knowledge: files and text you upload once (docs, specs, schemas, style guides).
A shared context boundary: every conversation you start inside the Project can draw on those instructions and that knowledge, without you pasting anything.

A Project is not a longer chat. It is a room: you walk in, the reference material is already on the shelves, the house rules are on the wall, and each conversation is a separate desk. What you learn at one desk does not carry to the next, but the shelves and the rules are shared.

Write instructions like a job description, not a wish

The weakest Projects have instructions like "You are a helpful assistant for my startup." That tells Claude nothing it did not already assume.

Treat the instructions as onboarding for a competent new hire. Cover role, constraints, and output shape:

Role: You help maintain a Django + Postgres API for a logistics app.
Audience: mid-level backend devs on our team.
Rules:
- Match our style guide (see knowledge). Type hints required.
- Prefer stdlib and existing deps; ask before adding a package.
- When unsure about business logic, ask instead of guessing.
Output: code first, then a short "why" note. No filler intros.

Constraints do more work than encouragement. "Ask before adding a package" prevents more bad output than any amount of "be smart and thorough."

Curate knowledge, do not dump a drive

It is tempting to upload everything. Resist it. Project knowledge is signal you are handing the model, and noise dilutes it. An outdated PRD sitting next to the current spec gets cited as if both are true.

Good candidates: the current architecture overview, the API schema, the style guide, a glossary of domain terms, a few representative examples of "good" output. Bad candidates: entire meeting-note archives, superseded drafts, anything you would not want quoted back at you as fact.

If a file has a stale section, trim it before uploading. You are curating a reference shelf, not backing up a folder.

Add a map file

One small file earns its place fast: a short index, something like _START_HERE.md, that says what every other file is and when to trust it.

- architecture.md : current system design. Source of truth.
- style-guide.md  : code conventions. Always apply.
- glossary.md     : domain terms (a "shipment" != an "order").
- old-spec.md     : historical only. Do NOT treat as current.

This gives Claude a way to weigh sources instead of averaging them, and it forces you to notice what is actually in the Project.

Keep it fresh (the step everyone skips)

A Project is manual memory. Nothing updates itself. The schema changes, the file does not, and now your assistant is confidently wrong in a way that is harder to catch than an obvious blank.

Build a small habit: when a decision changes, update the one file that records it, the way you would a README. Stale context is worse than no context, because it reads as authoritative.

Where Projects are weaker

The honest limits, because they change how you use it:

Not a live knowledge base. A Project reflects what you last uploaded, not your repo's current state. For code that changes hourly, it drifts fast.
Retrieval is not exact. Large knowledge sets get drawn on selectively, not read cover to cover on every message. Ten focused files beat a hundred loosely relevant ones.
Scope is a boundary, not a brain. Context does not carry between Projects. That is good for isolation, but it means you maintain each one by hand.
Sensitive material is still material you put somewhere. Client data and secrets in a Project deserve the same judgment you would apply to any shared workspace.

None of this makes Projects less useful. You just want to know the edges before you lean on them.

A minimal starting point

Create one Project per real domain (one codebase, one client, one book), not a single mega-Project. Give it three files to start: a map, an architecture or overview doc, and a style guide. Write ten lines of real instructions. Then start a chat, watch what it still gets wrong, and fix the file instead of the prompt.

Do that for a week and the pattern changes: you stop introducing yourself, and Claude starts picking up where you left off.

Stop Reaching for a Bigger Model. Fix the Prompt First.

Konstantin Konovalov — Thu, 30 Jul 2026 13:50:00 +0000

Every time an AI feature disappoints, the reflex is the same: swap in the newer, bigger model. Sometimes that helps. More often, the same model would have nailed it if the prompt had actually told it what to do.

I've watched teams burn a sprint on model comparisons when the real problem was a two-line prompt doing four jobs badly. The boring truth: for most day-to-day tasks, the gap between a weak prompt and a strong prompt is larger than the gap between two adjacent models. And the prompt is free to fix.

Four fundamentals do the heavy lifting. None of them are clever tricks.

1. Give it context, not just a task

Models don't know your situation. They know language. If you skip the context, the model fills the gap with the statistical average of the internet, which is almost never what you wanted.

A task without context ("summarize this") forces the model to guess your audience, length, and purpose. Every guess is a place it can be wrong.

Context worth adding: who reads the output, what they'll do with it, what to leave out, and any hard constraints (tone, length, forbidden words). Treat it like briefing a new contractor who is fast, literal, and has zero memory of your company.

2. Show examples (few-shot)

Describing what you want is harder than showing it. One or two examples of input paired with the desired output pins down format, tone, and edge cases faster than a paragraph of instructions.

This is "few-shot" prompting. It's underused because it feels like more typing, but it isn't: a good example replaces three rounds of "no, not like that."

Classify the ticket. Match this style:

Input: "App crashes when I upload a PDF over 20MB"
Output: { "type": "bug", "severity": "high", "area": "uploads" }

Input: "Can you add dark mode?"
Output: { "type": "feature", "severity": "low", "area": "ui" }

Now classify:
Input: "Login page loads forever on mobile Safari"

The model now knows your schema, your severity scale, and your naming, none of which you had to explain in prose.

3. Demand an explicit output format

If you don't specify the shape, you get prose. Then you write a parser, the parser breaks on the model's next mood, and you blame the model.

Say exactly what you want back: JSON with these keys, a markdown table with these columns, three bullets and nothing else. "Return only valid JSON, no explanation" removes the friendly preamble that breaks JSON.parse.

Being explicit about format also quietly improves quality. A model forced into a structure has to commit to specific fields instead of hedging in paragraphs.

4. Set a role

"You are a senior security reviewer" is not theater. It shifts which patterns the model reaches for. A role narrows the space of plausible responses toward the vocabulary, priorities, and rigor of that persona.

Keep it concrete and functional. "A technical editor who cuts filler and flags unsupported claims" beats "a world-class genius writer." The first tells the model what to do; the second just flatters it.

Before and after

Here's a weak prompt most people actually ship:

Write release notes for these commits.
[commit log]

You'll get a generic changelog, probably too long, in whatever tone the model felt like, mixing internal refactors with user-facing changes.

Now the same job with all four fundamentals:

You are a product writer for a developer tool. Write release notes
for non-technical users of our billing dashboard.

Context:
- Readers are finance staff, not engineers.
- Skip internal refactors and dependency bumps entirely.
- Keep it under 120 words.

Format: markdown, grouped under "New", "Fixed", "Improved".
Each item is one sentence, plain language, no ticket numbers.

Example item:
- Invoices now download as PDF directly from the dashboard.

Commits:
[commit log]

Same model, completely different result. And it's reproducible, because you removed the guesswork instead of hoping the model guessed well.

The honest caveat

Prompting is not magic, and it has a ceiling. If the task needs knowledge the model doesn't have, better wording won't invent it. If it requires multi-step reasoning that strains the model's actual capability, a stronger model is the right call. For hard math, long-context work, or complex code, the model itself matters in ways no prompt can fix.

There's also a failure mode in the other direction: over-engineered prompts. Piling on contradictory instructions, five personas, and a wall of rules can make output worse and harder to debug. Start minimal, add only what fixes an observed problem, and cut anything that isn't earning its place.

The rule of thumb I use: before upgrading the model, spend fifteen minutes rewriting the prompt with these four fundamentals. If it's still failing after that, then it's a model problem. Most of the time, you never get there.

Prompting is a skill you can practice deliberately. Write the weak version, name what's ambiguous, and fix one thing at a time. It compounds faster than waiting for the next model release.

Claude vs Gemini: pick the model by the job, not the benchmark

Konstantin Konovalov — Wed, 29 Jul 2026 14:40:00 +0000

Nobody's "best model" survives contact with your actual work

The "which AI is better" debate is mostly noise because it skips the one variable that actually decides the outcome: what you're doing and where your data already lives. Claude and Gemini are both strong general models. They split apart in the boring, practical places: where your files sit, how you feed them context, and how much you trust the output without re-reading it.

Here's how I actually decide, task by task.

Gemini: when the work lives in Google's world

If your day runs through Gmail, Docs, Sheets, and Drive, Gemini has a structural advantage that has nothing to do with raw reasoning. It already sits inside those tools. Asking it to summarize a thread, draft a reply in context, or pull numbers from a sheet skips the copy-paste tax.

Three places it tends to win:

Google Workspace tasks. With access to your Gmail, Docs, and Drive context, there are fewer round trips. You're not pasting a document; the model can already see it.
Multimodal input. Feeding it images, screenshots, PDFs, and mixed media feels first-class, not bolted on. Good for "here's a screenshot of a dashboard, what changed?"
Search grounding. When the answer depends on something current, grounding the response against live web results cuts down the "confidently wrong about last week" failure you get from a static model.

If the question is "what's the current state of X" or "look at this image and tell me what's off," Gemini is usually my first reach.

Claude: when precision and long context matter

Claude's edge shows up when the job is reading a lot carefully and producing something you won't have to babysit.

Long-context precision. Drop in a big codebase, a long contract, or a messy transcript and ask for specific things across all of it. It tends to hold detail across the whole window instead of degrading into vibes by the end.
Careful editing. For rewriting, refactoring prose, or surgical code changes, it's more likely to change only what you asked and leave the rest alone. That "did you touch something I didn't point at" trust matters more than people admit.
Following instructions literally. Give it a format, a set of constraints, a house style, and it holds the line better under complex, layered instructions.

The kind of task I hand Claude without thinking twice:

Here are 40 pages of API docs and our current client wrapper.
Rewrite the wrapper to cover the endpoints we're missing.
Don't change the function signatures we already export.
Match the existing error-handling pattern.

That "don't change what I didn't ask about" clause is exactly where careful editing earns its keep.

A decision guide you can use in ten seconds

Match the job to the model:

Your task	Reach for
Summarize or reply inside Gmail/Docs	Gemini
"Look at this screenshot or PDF"	Gemini
Needs current, live info	Gemini (grounded)
Read a huge document, answer precisely	Claude
Refactor code without collateral damage	Claude
Rewrite prose, keep my voice	Claude
Follow a long, strict spec	Claude

Rough rule: Gemini for reach (into your data, the web, and images), Claude for depth (careful reading and careful writing).

The honest caveat

This split is a starting bias, not a law. Two things keep it from being clean.

These models leapfrog constantly. Any specific claim about which one edits better or grounds better has a short shelf life. Treat "Claude for editing, Gemini for grounding" as a current tendency, not a permanent truth, and re-test on your own tasks every few months.

Integration is a real cost. The "obvious" choice is often just the one already wired into your stack. If your whole team lives in Google Workspace, Gemini's convenience can beat Claude's editing edge for everyday work, because the friction of moving data out is a tax you pay on every single task.

And neither one gets you out of reading the output. Grounding reduces hallucination; it doesn't remove it. Long-context precision means fewer misses, not zero. The moment a task has real consequences, you check the work regardless of the logo on it.

How I actually run it

I don't pick one. I keep both open and route by job:

Anything touching my email, docs, or "what's true right now" goes to Gemini.
Anything that's read-this-carefully or write-this-precisely goes to Claude.
When I'm unsure, I run the same prompt through both and keep the better answer. Two minutes of comparison beats loyalty to a brand.

I'm not trying to crown a winner. I'm trying to stop treating "AI" as a single tool and start treating it as a small toolbox where I already know which one to grab for the job in front of me.

Claude Artifacts: When a Chat Answer Becomes a Running Tool

Konstantin Konovalov — Tue, 28 Jul 2026 15:10:00 +0000

What an Artifact actually is

An Artifact is what you get when you ask Claude for something buildable and it hands back a running thing instead of a code block you have to copy, paste, and wire up yourself. The chat generates a small, self-contained web page (HTML, CSS, and JavaScript, or a React component) and renders it live in a panel next to the conversation. You type, it runs. You ask for a change, it rebuilds in place.

That's the whole shift. The output stops being instructions for a tool and becomes the tool.

Under the hood, each Artifact runs inside a sandboxed iframe. That sandbox is the source of both its powers and its limits, so keep it in mind.

Where they actually earn their keep

The sweet spot is anything small, interactive, and self-contained:

Calculators. Mortgage, tip, unit economics, runway math: anything that goes inputs → formula → output.
One-page landing previews. Paste your headline and three bullets, get a laid-out page you can eyeball before a designer touches it.
Forms and their logic. Field validation, conditional questions, a multi-step wizard. You can click through the whole flow even though nothing submits anywhere.
Data views. Drop in a CSV or JSON blob and ask for a sortable table or a chart.
Tiny dev tools. Regex testers, JSON formatters, a color-contrast checker, a cron-expression explainer.

The common thread: things you'd otherwise spin up a CodePen or a throwaway repo for. Artifacts collapse that to one message.

How to prompt for a good one

Vague prompts give you vague apps. A few habits that consistently help:

Ask for one self-contained file. The sandbox won't reliably load external scripts, so ask for everything inline up front:

Build a mortgage calculator: principal, annual rate, term in years. Show the monthly payment and total interest. Single self-contained HTML file, inline CSS and JS, no external libraries.

Name the inputs and outputs explicitly. "A pricing calculator" is a guess. "Three sliders for seats, months, and discount %, output monthly and annual totals" is a spec.

Give sample data inline. Paste the actual CSV rows or JSON you want rendered. Claude builds around real shapes better than imagined ones.

Iterate in small steps. "Make the total bold and add a reset button" edits the same Artifact in place rather than starting over. Treat it like pairing, not one-shotting.

The sandbox rules that shape everything

Almost every limitation traces back to one fact: the Artifact runs isolated, with no server behind it and its network access locked down.

That means:

No external requests. It can't call a third-party API or pull a live exchange rate, and you can't count on an outside script loading. Everything has to be inlined or generated.
No real backend. Forms don't POST anywhere. There's no database, no auth, no place to keep a secret. A "login form" is a UI mockup, not a login.
State is ephemeral. Reload and you're back to defaults unless you explicitly save or publish it.

This isn't an oversight. Isolation is what lets an Artifact run safely the instant it's generated. It also draws the line between prototype and product.

Where Artifacts are weaker (the honest part)

I'd stop short of a few things:

Anything needing live or private data. No API keys, no fetching from your database. If the value is in the data source, an Artifact can only fake it with sample data.
Multi-screen apps with real routing and persistence. You can push it there, but it gets unwieldy fast and you're better off in a real project.
Production hosting. Publishing an Artifact shares a page. It is not a deploy pipeline, not versioned like git, not something to point a domain at and forget.
Pixel-exact design systems. It'll get you most of a layout quickly. The last stretch, brand tokens and edge-case responsiveness, is faster in your actual codebase.

A useful mental model: Artifacts are the fastest path from "idea" to "clickable," and a slow, wrong path to "shipped."

A workflow that holds up

The pattern that works for me is to use Artifacts to kill ambiguity early. Instead of arguing about how a calculator or a form should behave, build the clickable version in two or three messages, poke at it, and let the working thing settle the debate. Then, if it needs real data or real users, port the logic into your codebase where backends and version control live.

That keeps Artifacts doing what they're genuinely good at, turning a description into something you can press buttons on before you've committed a single line to your repo, and keeps your production code where it belongs.

Cheap Tokens or Reliable Work? Claude vs DeepSeek, Without the Hype

Konstantin Konovalov — Mon, 27 Jul 2026 13:20:00 +0000

Every few months a cheaper model shows up and someone in the team channel asks the same question: "Why are we still paying for Claude when DeepSeek costs a fraction of the price?"

Fair question. It's just the wrong metric. It compares what's easy to measure (price per token) against what actually pays the bills (cost per correct outcome). Here are the tradeoffs I keep hitting when I ship on both.

What DeepSeek genuinely wins on

Two things, and both are real.

Price. DeepSeek's hosted API is much cheaper per token, often by a large multiple. If your workload is token-dominated (bulk summarization, classification, offline batch jobs), that difference is real money, not a rounding error.

Open weights, self-hostable. This one gets underrated in these comparisons. If your data can't leave your VPC (health records, internal source code, anything under a strict data-residency clause), then a model you run yourself may be the only option that clears legal review, and cost barely enters into it. Claude is API-only. No budget lets you run it on your own hardware or audit the weights.

For a lot of teams that single point ends the debate before price even comes up.

What Claude charges you for

Consistency, mostly. Not raw intelligence: both models are smart enough for everyday code and text. The gap shows up in variance and instruction adherence across long, multi-step work.

Three places I feel it:

Structured output that feeds a machine. When the next step is JSON.parse() and not a human reading prose, a model that returns schema-correct output on the first try almost every time is worth a lot more than one that mostly gets there. The misses turn into failed pipelines and 3am pages.
Agentic chains. In a multi-step tool-using loop, per-step reliability compounds. If each step is 95% reliable, a five-step chain lands around 77% end to end (0.95 to the fifth). A reliability-first model holds that chain together; a less consistent one quietly drops a step, and the whole run is wrong in a way that's expensive to debug.
Long context that stays coherent. Both advertise large context windows. The real question is whether the model still uses the middle of that window sensibly. This is where I've seen cheaper models fade first: the tokens fit, the reasoning doesn't hold.

Cost per token is the wrong metric

Here's the model I actually use. Token price is the sticker. The number that matters is cost per successful task:

effective_cost = api_cost / success_rate
              + failure_rate * (retry_cost + human_review_cost)

Now plug in your own numbers. Suppose the cheap model is several times cheaper per call but succeeds less often on your task, and each miss costs a retry plus a few minutes of an engineer noticing and fixing it. The reliable model costs more per call but rarely needs manual cleanup.

On raw price the cheap model wins by a wide margin. Once you add review time on every failed output, the gap narrows fast, and for anything customer-facing the human-review term dominates everything else. The cheap model can end up costing more per shipped result.

The point isn't "Claude always wins the arithmetic." It's that you can't do the arithmetic with token price alone. You need your own success rate, on your own task, or you're guessing.

When cheap is the right call

Reach for the cheap or open model when:

The work is high-volume and variance-tolerant: first drafts, bulk tagging, internal tooling, anything a human reviews anyway.
You need self-hosting for privacy or data residency. Non-negotiable requirement, easy decision.
You have evals and retries wired up, so a bad output gets caught by a test, not a customer.
Cost genuinely dominates: lots of low-stakes calls where a few percent of failures is cheap to absorb.

Reach for the reliability-first model when:

Output is one-shot with no human in the loop: it goes straight to a user or a downstream system.
You're running long agentic chains where one wrong step poisons the rest.
You depend on strict structured output the pipeline can't recover from.
Correctness is regulated or reputational, and one bad answer costs more than the token savings.

The honest caveats

A few, because this isn't a Claude ad.

Self-hosting isn't free. "Cheap model" and "cheap to run" are different sentences. GPUs, inference ops, autoscaling, uptime: do that badly and you'll outspend any API bill, and now you own an on-call rotation too.

The gap is a moving target. Open models improve fast. Any specific claim about which one is "better" has a short shelf life, including this article. Re-run your own evals every quarter and don't trust a six-month-old comparison.

Most teams shouldn't pick one. The practical move is routing: cheap model for the low-stakes bulk, reliability-first model for the paths where a wrong answer is expensive. Tag requests by stakes and route.

def choose_model(task):
    if task.needs_self_host or task.stakes == "low":
        return "deepseek"
    if not task.human_in_loop or task.is_agentic:
        return "claude"
    return "deepseek"  # default cheap, escalate on failure

Measure success rate per model on your traffic, feed it back into the router, and let the data decide. "Cheap or reliable" was never really a versus. It's a routing problem you solve per request.

From One Task to a Working Agent: Trigger, Data, Action, Deliver

Konstantin Konovalov — Sat, 25 Jul 2026 16:00:00 +0000

"Agent" is doing too much work

The word "agent" now covers almost anything. A single chat prompt gets called an agent. A cron job with an LLM in the middle gets called an agent. So does a system that plans, calls ten tools, and retries on failure.

Strip the branding and most useful agents share the same small shape: something happens, the system gathers what it needs, does the work, and puts the result where a human or another system will see it. Four steps: trigger, data, action, deliver. If you can name each step for your use case, you can build it. If you can't, you don't have an agent yet, you have a vague hope.

The loop: trigger, data, action, deliver

Here it is as plain pseudocode:

on trigger:                 # a webhook, a cron, a new row, a message
    context = gather()      # read files, query APIs, pull the record
    result  = act(context)  # the LLM call, tool use, or computation
    deliver(result)         # Slack, a PR, a DB write, an email

Every reliable agent I've shipped fits this. The interesting engineering is almost never in the LLM call. It lives in the other three steps: making the trigger fire at the right time, feeding the model exactly the data it needs and nothing more, and delivering somewhere that fails loudly when it breaks.

A concrete example: "summarize new support tickets and flag the angry ones."

Trigger: a new row in the tickets table.
Data: the ticket text plus the customer's plan and last three tickets.
Action: classify sentiment, write a one-line summary.
Deliver: post to a Slack channel, add a label in the helpdesk.

No planning loop, no autonomy. It runs, and it's useful.

When a prompt is enough

Most tasks don't need an agent. They need a good prompt you run yourself.

Use a plain prompt when the task is one-shot, you're already at the keyboard, and you can eyeball the output. Rewriting an email, drafting a SQL query, explaining a stack trace: opening a chat and pasting context is faster than any pipeline you'd build, and you catch mistakes on the spot.

Building an agent has a real cost: a trigger to maintain, credentials to store, error handling, logging, and a new thing that can page you at 2am. That cost is worth paying only when the task repeats and the human in the loop is the bottleneck.

When it's worth building

Build the agent when three things are true:

It repeats. Same shape, many times a day or week. One-offs never earn back the setup.
The trigger is real, not you remembering. If a system event can start it (a webhook, a schedule, a file landing), it's a candidate. If the only trigger is "when I feel like it," keep it a prompt.
You can define "done." You know what good output looks like well enough to check it, automatically or at a glance.

If any of these is missing, you're building a toy that will quietly rot.

Keeping it reliable

The gap between a demo and something you trust is almost all error handling.

Narrow the job. One agent, one task. "Read the invoice, extract totals, write a row" beats "handle all our finance ops." Small scope means you can actually verify it.

Make deliver idempotent. Triggers fire twice. Retries happen. If your agent posts to Slack or writes a row, make a repeat run safe: check for an existing result, use an idempotency key, upsert instead of insert.

Constrain the action. Give the model tools with tight signatures instead of free-form shell access. A function that takes a ticket ID and a label is auditable. "Run any command" is not.

Log the whole loop. Store the trigger payload, the data you gathered, the model's output, and what you delivered. When it misbehaves you want to replay the exact run, not guess.

Fail loud. A silent agent that stopped working is worse than no agent, because you stopped doing the task by hand and nobody noticed. Alert on zero runs, not just on errors.

Where this is weaker

This loop is honest about its limits. It fits tasks with a clear trigger and a checkable output. It does not fit open-ended research, long autonomous planning, or anything where "done" is fuzzy and a wrong action is expensive. Multi-step agents that plan and self-correct are real and sometimes worth it, but they are much harder to keep reliable, and most teams reach for them long before they need to. If you can collapse a problem into trigger, data, action, deliver, do that first. Add autonomy only when the simple loop provably can't do the job.

Start with one task

Pick the single most annoying repetitive thing you did this week. Write down its four steps. If you can fill in all four, you have your first agent, and it'll probably take an afternoon, not a sprint. Ship that one. You build reliability on small loops, not by bolting it onto a big one.

The "what not to change" section: the cheapest fix for AI coding agents that quietly break things

Konstantin Konovalov — Sat, 25 Jul 2026 05:16:50 +0000

The scariest failure with an AI coding agent is not the one that throws an error. It is the one where the agent hands you code that runs, passes a quick glance, and quietly solves a slightly different problem than the one you had. Obvious failures you catch in seconds. This one you find in production, three days later, when something you never asked it to touch has changed.

I keep seeing the same root cause, and it has almost nothing to do with the model. It is the brief.

Why "make it better" goes wrong

When you hand an agent a loose instruction like "clean up this file" or "add caching here," you have not actually told it where the edges are. The model fills the gap with its own guess about scope. Usually that guess is reasonable. Sometimes it rewrites a function three files over, renames a variable that something else depended on, or "helpfully" swaps your logging library because it looked outdated. Each of those is defensible in isolation. Together they are a diff you now have to audit line by line, because you no longer trust that the change stayed inside the box you had in your head.

The model was not being careless. You never drew the box.

The habit: say what not to change

The fix is almost embarrassingly small. Alongside what you want done, write a short explicit list of what must stay untouched, plus the exact files or targets in scope. Two or three lines is enough:

Add a retry with backoff to the fetchOrders call in api/orders.ts.
Do not change the function signature, do not touch other files, do not add new dependencies.
If a retry still fails after 3 attempts, throw the existing OrderFetchError.

That is the whole trick. You have turned a fuzzy ask into something with edges. Now the output is checkable: either it stayed inside the box or it did not, and you can tell at a glance instead of reading every line with suspicion.

Notice what the "do not" lines are really doing. They are not there because the model is dumb. They are there because every unstated assumption is a place the model is free to improvise, and improvisation is exactly what you do not want in a change you have to trust.

Specificity beats cleverness

There is a bias, especially early on, toward writing clever prompts. Long, elaborate instructions, role play, "you are a senior engineer who cares deeply about clean code." Most of that does far less than one boring line naming the exact file and the exact thing not to touch.

The reason is simple. A clever prompt tries to make the model want the right outcome. A specific brief removes the room for the wrong one. The second is more reliable because it does not depend on the model reading your mind, it depends on you having said the quiet part out loud.

This is also the fastest way to get better at working with any coding agent, Claude included. The skill that actually transfers is not memorizing syntax or prompt tricks. It is learning to write a brief tight enough that you can check the result against it in seconds. Once you can do that, the model stops being a slot machine and starts being a tool you point.

A quick before and after

Before:

Refactor the checkout logic, it is getting messy.

After:

In checkout/total.ts, extract the discount math into a pure function applyDiscount(cart, code).
Keep the public behavior of getTotal identical, same inputs and outputs.
Do not touch the tax logic, do not reformat the rest of the file, do not add libraries.
If code is invalid, return the cart total unchanged, same as today.

The "before" invites the model to redesign your checkout. The "after" gets you one clean, reviewable change and nothing else. Same model, same day, completely different level of trust in the result.

Where this leads

Once the "what not to change" habit is automatic, a lot of downstream pain disappears. Your diffs shrink. Your reviews get faster because you are checking a small, bounded change against an explicit spec instead of reverse engineering the agent's intent. And you stop getting those quiet, three-days-later surprises, because there was never room for the agent to wander in the first place.

It is a small habit with an outsized payoff, and it is the kind of thing that is obvious once you have been burned by the alternative. If you are learning to build with Claude, this is one of the first instincts worth drilling: not a better prompt, a tighter box.