Model selection. First point: free. Second point: when did you last reach for Haiku?

Pick the right model for your task:

In interactive sessions, use /model to switch. In skills and agents, set it in frontmatter.

Dig deeper: Models pricing, Model configuration, Skill frontmatter, Sub-agent frontmatter

Yes. Claude is writing a dissertation about your variable renaming.

Thinking tokens count as output tokens. The priciest kind. A single request can burn tens of thousands of them. For a complex architectural decision, worth every token. For "add a missing semicolon," not so much.

In interactive sessions, use /effort low or /effort medium for straightforward tasks, and /effort high when it actually matters. In skills and agents, set it in frontmatter so nobody has to remember.

Dig deeper: Models pricing, Effort configuration, Skill frontmatter, Sub-agent frontmatter

A lot. The fix is simpler than you think: be specific.

Claude starts by figuring out what your codebase even is. That means reading files until it has enough context to act. And every file it reads stays in context, getting re-sent with every follow-up message. You’re paying for that exploration whether you asked for it or not.

Specificity isn’t just for interactive sessions. In skills and agents, every word in the spawn prompt loads on top of everything the agent auto-loads, from turn one. Vague instructions are just as expensive there.

Free points. You’re welcome.

Impressive documentation. Expensive documentation.

Everything in CLAUDE.md loads at session start and gets re-sent on every single request, whether it’s relevant or not. That beautifully written section explaining the history of your repository pattern? Claude reads it before fixing a typo. Every. Single. Time.

Dig deeper: Path-specific rules, Extend Claude with skills

/clear. Seriously.

Every request re-sends the full conversation history as input tokens. Once a task is done, that history is dead weight: old file reads, debugging logs, that long exchange where Claude went down the wrong path. You’re carrying a suitcase full of things you don’t need anymore.

/clear drops it.

/compact, but with instructions.

Just running /compact summarizes the conversation, but Claude decides what to keep. You can do better: /compact Focus on modified files and unresolved errors tells Claude exactly what matters. You can also make it permanent in CLAUDE.md so it applies every time Claude compacts automatically.

Dig deeper: Compact with a focus

In the main context, if you’re not careful.

Test runners, log processors, and doc fetchers can generate a lot of output. If that output lands in the main session, Claude re-sends it on every subsequent turn. Subagents run in their own isolated context window. The parent session gets a summary, not the raw output.

In skills and agents, structure workflows to delegate verbose operations to subagents. The main agent stays lean. In interactive sessions, Claude will usually make that call on its own, but you can always ask explicitly.

Dig deeper: Isolate high-volume operations

Pre-written scripts and hooks let you preprocess data before Claude sees it. Feeding Claude a raw test report when all you needed was the failures means Claude processes a lot more than necessary.

A 2026 study filtered low-value output from agent trajectories and found 40-60% fewer input tokens and 21-36% lower costs, with no impact on task success. Scripts and hooks are a simpler way to act on the same idea. The pattern scales well for agent-heavy workflows, but for small tasks the overhead isn’t worth it.

Dig deeper: AgentDiet, FSE 2026

It should have.

Skip the plan and Claude might build the wrong thing entirely. You pay for the wrong implementation, then pay to fix it. Plan mode makes Claude explore and propose an approach before touching any code. You review it, adjust it, then let it implement.

In interactive sessions, press Shift+Tab before giving Claude a large or ambiguous task. In skills, bake it in: structure the definition to include an explicit planning step before execution.

Dig deeper: Plan mode

Surprise: it’s not free.

The 1M context window costs the same per token as the default. It just holds 5x more tokens, so sessions stay uncompacted much longer and every turn carries a heavier payload. Stick with 200K unless you actually need it.

Dig deeper: Extended context

You can’t improve what you can’t measure.

Run /usage in Claude Code to see token usage and cost for the current session. Watch those numbers across sessions as you apply these practices. The difference is visible.

Running the API or tracking team usage? The Claude Console breaks it down by model, date, and API key.

Dig deeper: Using the /usage command, Claude Console

Scored 15 or above? Genuinely impressive.

Below that? You’re one or two practices away from making a real difference. Start with model selection, and go from there.

Thanks for reading!

The loop has two phases:

Set the following variables under the env key in .claude/settings.json for team-wide use, or in .claude/settings.local.json to keep them local.

All skills and scripts described in this post and the previous one are available as a Claude Code plugin in the gwenneg/blog-ai-friction-loop repository.

Clone it and start Claude Code with the plugin from your target project:

Then run /setup-friction-capture, which handles the full installation:

The .claude/ directory mixes things that should be committed (hooks, scripts, skills, shared settings) with things that should never be (friction logs, local settings, worktrees, lock files). The allowlist pattern looks like this:

The PR includes a note for reviewers about what data is sent and how to opt out.

As AI agents take on more of the coding work, keeping context docs accurate becomes critical. Friction will always exist. The question is whether it gets captured and fixed, or silently repeated across sessions.

I’m deploying this across several repositories at Red Hat and collecting feedback. This is one approach to the problem, and I expect it to change as teams adapt it to their own workflows.

The capture is purely reactive right now: it catches what went wrong, not what could go wrong. A major refactor can silently invalidate parts of the guidelines, and the loop only notices once an agent stumbles. That’s a known gap and something I want to address.

I’m also working on the developer experience, exploring ways to further minimize the effort required from devs while keeping the docs updated automatically. That could eventually mean getting rid of the manual step entirely.

If you try this or build something different, I’d love to hear about it. What breaks, what works, and what the next step looks like for your team. Feel free to share in the comments.

The /init-context-docs skill assesses a repository’s readiness for AI-assisted development, then bootstraps a layered set of context files. While AGENTS.md and the guideline files work with any tool that supports the standard, the loading behaviors described here are specific to Claude Code:

The unconditional layer is the most expensive in terms of context window tokens: it’s loaded every session regardless of the task. Files loaded at Claude’s discretion are the cheapest, but come with no guarantee. Path-scoped rules sit in between: deterministic loading, but only for matching files.

Several studies point in the same direction: longer context alone hurts LLM performance, even when the content is relevant (Du et al., 2025). Models pay the most attention to the beginning and end of their input; everything in the middle gets less (Liu et al., 2024; Wu et al., 2025). Anthropic frames context as "a precious, finite resource". On the flip side, well-formed AGENTS.md files are associated with ~29% faster execution (Lulla et al., 2026). But more isn’t better: LLM-generated context files with unnecessary content actually reduce task success rates compared to no context at all (Gloaguen et al., 2026).

This is why every file in the system is capped (200 lines for guidelines and AGENTS.md, 100 for CLAUDE.md), the most critical rules go first, verification commands go last, and everything in between is kept ruthlessly short.

Every layer is a tradeoff between loading guarantee and token cost. The question for each file is: does the agent need this every session, only for certain files, or only sometimes?

The skill starts by scanning the repo against the five layers described above and presents a baseline status showing what already exists and what’s missing. It then matches the repo against a curated list of guideline domains (e.g., security, testing, database), drops any that aren’t relevant, identifies additional domains not on the list (e.g., GraphQL, machine learning), and lets you adjust the final selection.

Once the domains selection is final, the skill launches one generation agent per domain, each focused exclusively on its area. An agent that only needs to produce a testing guideline can dig deep into your test patterns, rather than spreading its attention across the entire project. The same pattern applies to AGENTS.md, CLAUDE.md, and README: each gets its own generation agent. If a file already exists, the generation agent reads the existing content first and incorporates it, updating with new findings while preserving what’s still accurate.

Each generation agent reads a quality checklist before writing anything. The checklists enforce constraints like the 200-line cap, the necessity test ("Would removing this cause an agent to make a mistake?"), a ban on absolute language without evidence, and the requirement that every file reference actually exists in the codebase. Generation and verification agents share the same checklists, so both are measured against the same standard.

A separate agent handles verification. The one that wrote the content is biased toward believing it’s correct: research shows that LLMs systematically favor their own output (Panickssery et al., 2024) and fail to correct their own errors while successfully correcting identical ones from external sources (Tsui, 2025). There’s a catch, though: both studies examine self-bias within a single model. The skill uses a different model for verification (Sonnet instead of Opus), but both belong to the same Claude family, so some bias may carry over. Still, a fresh agent with a clean context checks file references against the actual codebase, validates factual claims with WebSearch, looks for contradictions across files, and flags duplication across layers. It only corrects inaccuracies. It doesn’t add new content.

After all agents finish, an automated-checks.sh script validates the generated files (line counts, imports, docs index, secret detection) and re-runs until all checks pass.

The skill finally offers to create a pull request with all the changes, so the generated docs go through the team’s normal review process.

Want to see how this works on your own project? Clone the gwenneg/blog-ai-friction-loop repository, then start Claude Code with the plugin from your target project:

Then type /init-context-docs. The skill will walk you through each layer, ask what to include, and let you skip anything that doesn’t apply. Expect it to take anywhere from a few minutes to about half an hour depending on the size of your codebase.

In my own testing, the generated docs clearly improved how agents work with projects: fewer wrong assumptions, less time spent correcting output. I don’t have metrics to back that up yet. It’s based on what I observed across a handful of repositories.

But even after all of this, the output is imperfect. Guidelines can sound plausible while being wrong about specifics, and some conventions only reveal themselves when the agent actually tries to follow the docs.

These are friction events, moments where the docs failed the agent:

Each one is a signal that the docs have a gap, something a concrete rule or example could have prevented.

In a follow-up post, I introduce an experiment to capture these friction events automatically at the end of every session and turn them into targeted doc improvements.

If you try /init-context-docs on your own codebase, I’m curious what it gets right, what it misses, and what you end up changing. Feel free to share your experience in the comments.

Thanks to Jiří Bönsch for helping me test and improve the /init-context-docs skill.

Add an optional final step to your skills that asks Claude to look back at what just happened and suggest improvements. Not to the code it produced — to the skill definition, CLAUDE.md, or any other project documentation that would have made the execution smoother.

Think of it as a mini retrospective that runs every time, at near-zero cost.

Here’s what I append to my skills:

A few things worth noting:

In my experience, most executions produce no suggestion — which is the right outcome. But when it does flag something, it’s usually a missing convention in CLAUDE.md or a step in the skill that assumed context Claude didn’t have. Those are exactly the kind of issues you’d never bother tracking down yourself.

It won’t revolutionize your workflow, but it’s a small investment that compounds over time.

Remote pipelines from Tekton let you reference pipeline definitions stored in external Git repositories instead of defining them locally in each project. They make it easier to share and maintain pipelines across multiple repositories.

Konflux is built on top of Tekton. Let’s see how we can leverage remote pipelines in a Konflux build pipeline!

Nothing shows it better than a good PR: gwenneg/blog-remote-konflux-pipeline#2. If you don’t have time to review the whole thing, here’s the TL;DR:

If the repository that hosts the remote pipelines publishes releases on GitHub, your repository can depend on a specific release instead of always using the latest version.

With this approach:

MintMaker works out of the box in repositories onboarded to Konflux and doesn’t require any additional configuration files. However, it is possible to customize MintMaker’s settings by adding a renovate.json file at the root of your repository. The default configuration is detailed in the Konflux doc.

If you plan on creating a repository to host remote pipelines, there are two things you’ll need to do:

Special thanks to Jiri Popelka for suggesting the Pipelines as Code annotation as an alternative to the Tekton Git resolver.

Imagine a centralized meteorological system that collects daily weather reports from 100 weather stations. Each station produces 10,000 reports every day, which are stored in the database and automatically deleted after 30 days.

Here’s what the SQL schema looks like:

The system depends on two essential SQL queries that require optimal performance:

Now, let’s see how we can make these queries faster!

You’re not just reading another post about PostgreSQL query performance. This post comes with a repository I created and used to test all the content discussed below: gwenneg/blog-postgres-execution-time. Hopefully, this repository will make it easier for you to experiment with different optimizations, possibly using your own schema and generated data.

If you’re not interested in testing optimizations, feel free to skip this section and jump to the next one. Otherwise, I’ll show you how to use my repository to run your own tests.

Clone the gwenneg/blog-postgres-execution-time repository. Open a terminal in either the single-table folder (no partitions) or the partitioned-table folder (with partitions) from the repository, depending on which approach you want to test. Then, start a container with:

The database initialization is complete when the following message appears:

You can now connect to the database.

Congrats! You’re now ready to run the SQL scripts provided in the repository or any other SQL queries:

These are the SQL scripts included in the repository:

When you run a SQL query in PostgreSQL, it isn’t executed immediately. First, the query planner analyzes the query structure, table sizes, indexes, joins, filtering conditions and available statistics to generate multiple execution plans. Then, PostgreSQL selects the most efficient plan and executes the query.

The EXPLAIN command displays the execution plan for a given query, providing details on execution time, row counts, indexes usage and more. That command is crucial for identifying slow queries, missing indexes, inefficient joins or outdated statistics. We’ll rely on it heavily throughout this post.

Reading an execution plan used to require highly specialized knowledge before the rise of Large Language Models. Today, if you submit your execution plan to an LLM, it can help identify weaknesses and suggest fixes. However, as with any LLM, be cautious of hallucinations and always double-check its recommendations.

Besides LLMs, tools like explain.dalibo.com can also help you visualize and understand your execution plan:

Let’s see what the execution plans for our two essential queries look like without indexes (except for primary keys) and using the default PostgreSQL settings.

More than 2 seconds to run each query - that doesn’t look good, right? But it’s no surprise since the weather_report table contains 30 million records and we’re filtering on unindexed columns.

Our queries both include a condition on the received_at and weather_station_id columns from the weather_report table, which contains 30 million records. Indexing these columns should help speed up the queries.

Run this query to check how much disk space your indexes are using:

Covering B-Tree indexes can be quite expensive and sometimes use nearly as much disk space as the table itself. On the other hand, BRIN indexes use a very small amount of disk space.

Indexes also slow down INSERT, UPDATE and DELETE queries. Every time a row is modified, PostgreSQL must update the corresponding index entries. This overhead on write operations is especially noticeable with high insert-rate workloads.

Indexes can really boost performance, but they can’t automagically fix a poorly written query.

In the current "fetch" query, PostgreSQL retrieves 89,992 rows and then filters out 89,092 of them. That doesn’t look right. Let’s see what happens if we replace the join with a subquery:

Wow, that’s an incredible improvement! The query that originally took 2069 ms without an index now runs in under 1 ms. How is that even possible?

The subquery helped move filtering before scanning. Because of that, PostgreSQL no longer has to fetch 89,992 rows and perform a materialized lookup for each one. That was a lot of unnecessary work. It’s gone now.

What about the "count" query? Could a subquery help reduce its execution time as well?

It’s not as impressive as the "fetch" query, but the subquery still significantly improves performance by allowing parallel scans and aggregation.

Covering B-Tree indexes can greatly improve query performance, but they have a weakness you should be aware of: heap fetches. A covering index allows a query to retrieve data entirely from the index without accessing the main table (heap), which would otherwise be expensive. However, this only works efficiently if the visibility map marks all necessary heap pages as "all-visible". If tuples are updated or deleted from a page and vacuum has not run, that page gets marked as "dirty" in the visibility map and PostgreSQL is forced to fetch rows from the heap, slowing down the query.

By default, PostgreSQL analyzes tables using the default_statistics_target setting, which defaults to 100. You can change this value globally or tweak it for specific columns if needed. Before you do, keep in mind that ANALYZE samples approximately 300 x statistics_target rows. With the default configuration, PostgreSQL samples around 30,000 rows.

Here’s how statistics can be changed for a specific column:

Increasing statistics on a column can help the query planner generate better execution plans and speed up queries, but it will also make ANALYZE slower. Consider it when:

The work memory can be increased at different levels:

If you see external merge or disk batches in an execution plan, it means PostgreSQL had to rely on disk instead of keeping operations in memory. That’s how you know the work memory could be increased.

There are other ways to optimize PostgreSQL query performance. Partial indexes and tuning WAL settings, for example, can be powerful tools depending on your workload. But this post should already give you a solid foundation with some of the most impactful techniques.

Thanks for reading! Hopefully, you’ve learned a thing or two that you can apply in your own environment to make your queries faster. If you’ve got tips or experiences to share, I’d love to hear them!

Happy optimizing!

Channels from SmallRye Reactive Messaging are not pausable by default. This can be changed from the Quarkus configuration:

This post will demonstrate two different ways to interact with the PausableChannel API. First, let’s create a CDI bean that will be injected in the code examples in the following sections.

The PausableChannel API can easily be exposed through a REST API which would typically be restricted to administrators of the application.

Sometimes, exposing a REST endpoint to interact with the PausableChannel API is not an option. Here’s an alternative based on Unleash and the quarkus-unleash extension. It’s very similar to my other post Changing the Quarkus loggers level from Unleash which contains a lot more details than this post.

The current version of the PausableChannel API doesn’t handle messages that were already requested before a channel is paused. As a result, your app might still process a few messages after initiating a pause, before the channel fully stops. The SmallRye Reactive Messaging team is actively working on an enhancement to address this issue in the near future.

Thanks for reading this post. Happy pausing!

First, let’s set up a GitHub repository for your blog with the template I created from my own blog. That template depends on Jekyll, AsciiDoc, the Minimal Mistakes theme and GitHub Actions. Don’t worry about the technical details yet, we’ll cover that later in this post.

For now, simply follow the steps below to use the template:

You will be asked for a repository name. Please make sure the value you provide matches the following pattern:

After your repo is created, GitHub will immediately try and fail to deploy your blog from a GitHub Action:

Don’t worry about that failure. We’ll set up the actual deployment of your blog later.

We’re done initiating your blog and it already has its own repo! Be sure to clone the repo before proceeding to the next section.

Before your blog can be deployed, you’ll need to make a few adjustments to the _config.yml file in your repo. Pay special attention to any lines marked with # FIXME […​] as these require immediate action. Most comments should be self-explanatory, and the file also includes many links to relevant sections of the Minimal Mistakes documentation. These links should help address any questions you might have.

Until now, the deployment of your blog was intentionally disabled in the jekyll GitHub workflow provided by the template repo. It’s time to enable it by deleting this line in your repo. Once removed, GitHub will immediately start deploying your blog. You should soon see a successful GitHub Action run similar to this one:

Although GitHub just deployed your blog using a GitHub Action, it will still try (and fail) to deploy it "from a branch" as well. We need to let it know that the blog will exclusively be deployed through the GitHub Action. Here’s how you can do that:

That’s it for the minimal deployment config of your blog! From now on, as long as you don’t modify the jekyll workflow in your repo, GitHub will automatically redeploy the blog whenever you push changes to the main branch.

If you want to better understand or customize the deployment configuration, the GitHub doc should have all the information you need. Finally, here is the source of the jekyll workflow provided by the template repo.

Before diving into theme customization for your blog, have you explored all the skins offered by Minimal Mistakes? If you haven’t made any changes yet, your blog is currently using the default skin:

Once you’ve chosen a skin, you may want to further customize your blog’s style by adding or overriding CSS rules. While the Minimal Mistakes documentation covers this thoroughly, I opted for a different approach. It may not be as polished as the recommended method, but requires significantly less effort when only minimal changes are needed.

Minimal Mistakes provides an empty _includes/head/custom.html file that you can use to customize the HTML content within your blog’s head tag. That’s how I introduced my own CSS rules:

You might also consider customizing the layouts offered by Minimal Mistakes. However, that requires more effort than I aimed for with this blog, so what you’re reading now uses the default layouts with no custom changes.

Comments are not enabled in your blog posts yet. To enable them, you’ll need to update the _config.yml file in your repo:

You will also need to select and configure a comment provider supported by the Minimal Mistakes theme. I chose Giscus which relies on GitHub Discussions to manage comments. It’s open source, free and highly customizable. If you plan on using that provider, I recommend reviewing this documentation from Minimal Mistakes first.

Here’s how your _config.yml file should look like after adding the config values provided by giscus.app:

That’s all you need to do to enable comments in your posts.