DEV Community: AK DevCraft

“Skills” in Claude Aren’t About Prompts — They’re About Context Design

AK DevCraft — Mon, 13 Apr 2026 16:58:59 +0000

Introduction

When I first came across “Skills” in Claude Code, it looked like just another abstraction over prompts. I kept repeating the same instructions to Claude — code review rules, API patterns, formatting — across multiple sessions.

But after spending some time with it, the interesting part wasn’t what skills are, but what problem it's trying to solve.

Demo

In the demo above, a code-review skill is defined. When I ask Claude to “review modified files”, it automatically matches the request to the skill and executes it — without needing explicit invocation.

Skills GitHub Repo - .claude/skills/code-review

Context Window Challenge

One of the biggest challenges with LLM usage in real workflows is:

Context keeps growing
Instructions get repeated
Conversations lose focus over time

Most people try to fix this by writing better prompts or adding more context. However, that approach doesn’t scale. As more context/prompt is provided, more of the context window will be consumed.

Definition

First, let’s go over the official definition of Skills.

Skills are folders of instructions and resources that Claude Code can discover and use to handle tasks more accurately. Each skill lives in a SKILL.md file with at least a name and description in its frontmatter.

A little more about Skills

Skills can be created in different locations based on the user's or the project's settings. At the end of the day, skill is created at .claude/skills/code-review/SKILL.md. Only difference is where the .claude directory is created.

User's personal skill: Create .claude directory in your home directory, e.g., ~/.claude/skills/code-review/SKILL.md
Project-specific skill: create .claude directory in the root of the project, e.g., project/.claude/skills/code-review/SKILL.md

Apart from the user and project, skills can be stored at the Enterprise and plugin levels. And if you have the same skill with the same description in all locations (not a desire approach, but hypothetically), then the skill is applied based on the following precedence order:

1. Enterprise — managed settings, highest priority. All users in your organization.
2. Personal — your home directory (~/.claude/skills/<skill-name>/SKILL.md). All your projects.
3. Project — the .claude/skills/<skill-name>/SKILL.md directory inside a repository. A particular project only.
4. Plugins — installed plugins <plugin>/skills/<skill-name>/SKILL.md, lowest priority. Where the plugin is enabled.

Skills Flow Diagram

User Request
     ↓
[Skill Description Match]
     ↓
[Skill Loaded]
     ↓
[Context Applied]
     ↓
Claude Response

What Skills Actually Change

At a surface level, skills look simple:

Reusable instructions that Claude can apply

But the real shift is deeper:

Skills separate “when to use context” from “what the context is.”

That’s a big deal, instead of loading everything up front or manually injecting instructions. You define a trigger (description) and a payload (instructions).

Skills work best for specialized knowledge that applies to specific tasks:

Code review standards
Commit message formats
Debugging checklists for a project

Claude handles the rest.

When you find yourself repeating again and again, then most likely you need a skill.

The Most Important Part: Description

If there’s one thing that matters more than anything else:

Your Skills description is the entry point to your system

This is effectively a semantic matcher and routing mechanism. In practice, this means:

Two skills with similar descriptions will conflict
A vague description won’t trigger
An overly broad one will trigger at the wrong time

👉 You’re not just writing instructions — you’re designing intent matching

Skills as a Context Control Mechanism

What changed my thinking was this:

Skills are not a convenience feature
They are a context management strategy

Because they are lazy-loaded only when needed, scopes are not always present, and multiple composable components can activate together.

This directly impacts:

Response quality
Token usage
System predictability

Designing Skills (What Actually Matters)

Let's see how we can design the Skills to harvest the best out of it.

1. Skill Schema (Only Important Ones)

The skills open standard supports many fields in the SKILL.md frontmatter. However, only two fields are required:

name (required) — Identifies your skill. Use lowercase letters, numbers, and hyphens only. Maximum 64 characters. Should match your directory name.
description (required) — Tells Claude when to use the skill. Maximum 1,024 characters. This is the most important field because Claude uses it for matching.
allowed-tools (optional) — Restricts which tools Claude can use when the skill is active.
model (optional) — Specifies which Claude model to use for the skill.

2. Keep the core small

Don’t treat a skill like a knowledge dump. Keep instructions focused and push details to supporting files.
Think of this as an entry point, not an encyclopedia.

3. Use constraints intentionally

Parameters like tool restrictions aren’t just configuration. They’re guardrails.

Examples:

Read-only analysis skills
Restricted execution environments
Safer automation workflows

4. Structure for scale, not just usage

The real challenge isn’t creating a skill — it’s managing many of them.

Things that start to matter:

Naming clarity
Description uniqueness
Conflict avoidance
Ownership (personal vs project vs org)

👉 This becomes closer to system design than prompt design

Skills vs Everything Else

A common mistake is trying to use skills for everything. But each feature solves a different problem. Claude Code has several ways to customize behavior. Skills are unique because they're automatic and task-specific. Here's a quick comparison:

CLAUDE.md file is loaded into every conversation. If you want Claude to always use a certain file formatting, that goes in CLAUDE.md.
Skills load on demand when they match your request. Claude only loads the name and description initially, so they don't fill up your entire context window. Your code review checklist doesn't need to be in context when you're debugging — it loads when you actually ask for a review.
Subagents run in isolated execution contexts — use them for delegated work. Skills add knowledge to your current conversation.
Hooks are event-driven (fire on some event like file saves). Skills are request-driven (activate based on what you're asking Claude to act)
MCP servers provide external tools and integrations — a different category entirely from skills
Slash commands require you to explicitly type them. Skills don't. Claude applies them when it recognizes the situation.

How does this shift thinking

Without Skills, we were thinking in terms of:

“How do I write better prompts?”

Now it’s more like:

“How do I design context that shows up at the right time?”

That’s a different level of control.

Practical Takeaways

If you’re starting out:

Don’t create many skills — create one good one
Spend more time on the description than the instructions
Keep skills narrow and intentional
Treat conflicts as a design problem, not a bug

And most importantly:

👉 If context is growing uncontrollably, skills are probably the penetrating layer.

Conclusion

👉 “Skills are not a feature. They’re a shift in how you structure AI systems.”

But the idea behind them is bigger:

👉 Moving from prompt writing → to context system design

And that’s where LLM usage starts becoming predictable, not just powerful.

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share any corrections.

My Other Blogs:

Trying MCP for the First Time — What Stood Out

AK DevCraft — Mon, 30 Mar 2026 18:40:40 +0000

Introduction

I spent some time exploring the Model Context Protocol (MCP). Not a deep dive—just a hands-on attempt to understand how it actually works.

So I built a minimal client + server setup:
👉 https://github.com/an1meshk/claude-chat-cli

In a real-world project, we will build client and server separately; however, as this was just a demo project, everything was built in the same project

A few things stood out more than I expected.

Demo

🧠 Context

The goal wasn’t to learn everything about MCP. It was to answer a simpler question:
How hard is it to actually build something with it?

Before moving further, here is a quick MCP client and server architecture diagram:

⚙️ What I Tried

Went through the MCP intro course - course link
Built a minimal client and server in Python using the course’s startup kit
Connected it to a simple CLI chat client that already came with the startup kit

Nothing complex—but enough to see how things fit together.

💡 What Stood Out

1. Setup Is Simpler Than Expected

I was expecting some heavy setup. But, instead:

Basic server setup was straightforward
The Python MCP library abstracts most of the complexity

👉 It felt closer to:
“Define a few handlers, and you’re up.”

than:

“Learn a new framework.”

2. The Real Concept Is Context Flow

The interesting part wasn’t the server setup. It was understanding:

How context flows
How tools are exposed
Exposing resources
How the model interacts with them

That’s where the mental shift is.

🧠 What Helped Me Understand It

This simple mental model made things click:

image credit Anthropic academy course

Client → MCP Server → Tool → Response → Client

Client sends a request
MCP server routes it
The tool executes logic
Response flows back

Once this clicked, everything else made more sense

⚡ If You Want to Try It

The setup is intentionally minimal:

Basic MCP server using Python
A simple tool
CLI client to trigger it

That’s enough to understand the core idea

Repo:
https://github.com/an1meshk/claude-chat-cli

You will need an Anthropic API key, as this project uses Claude

⚙️ One More Thing That Helped

Project uses uv for dependency management. That helps in a few ways:

Fast installs
Clean environment setup
Minimal friction

It removes a lot of the usual setup overhead

⚠️ What I Haven’t Explored Yet

This was just a first pass. Still curious about:

Structuring tools cleanly
Scaling MCP servers
Real production use cases

🧠 Initial Take

My early impression:

MCP isn’t hard to start with
But the real value is in how you design interactions

The setup is easy.
The thinking is where the work is.

🏁 Final Thought

Sometimes the best way to understand a new concept is:
Build the simplest possible version of it

This was one of those cases.

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share any corrections.

My Other Blogs:

Git Commands Workflow

AK DevCraft — Sun, 29 Mar 2026 06:11:00 +0000

⚡ Git Commands Workflow

When I started using Git, I tried to learn as many commands as possible.

But over time, I realized something:

You don’t need to know everything.
You need to master the workflow.

Most of my day-to-day work revolves around a small set of commands—used repeatedly in different contexts.

🧠 The Real Git Workflow

At a high level, Git revolves around three stages:

Working directory → where you make changes
Staging area → where you prepare changes
Repository → where changes are committed

Understanding this flow matters more than memorizing commands.

🔄 1. Starting Work

git pull
git checkout -b feature/my-feature

What this does:

Sync latest code
Create a new branch

👉 This is usually how I start my day.

✍️ 2. Making Changes

git status
git add .

git status → shows what changed
git add → stages changes for commit

👉 I check the status a lot more than I expected.

💾 3. Saving Work

git commit -m "Add feature X"

Creates a snapshot of your changes
Helps track history over time

👉 Good commit messages matter more than the command itself.

🚀 4. Syncing with Remote

git push
git pull

push → sends your changes
pull → brings latest updates

👉 This is where most conflicts show up.

🌿 5. Working with Branches

git branch
git checkout main
git merge feature/my-feature

Branching helps isolate work
Merging brings changes together

👉 Simple concept—but causes most real-world issues.

🧰 6. Commands I Started Using Later

These didn’t make sense early on—but became useful over time:

git stash
git log
git diff

stash → save work temporarily
log → view history
diff → see changes

👉 These are workflow boosters, not essentials.

⚠️ What Actually Matters (Not the Commands)

Over time, I realized:

Git problems are rarely about commands
They’re about understanding state and flow

Most issues come from:

Not knowing what’s staged
Working on the wrong branch
Pulling at the wrong time

🧠 What I’d Do Differently

If I were starting again:

Focus on workflow, not commands
Learn:
- status
- add
- commit
- branch
- merge

👉 That’s enough for most real work.

⚡ Practical Takeaways

You don’t need 50 Git commands
Master the core workflow first
Use advanced commands only when needed

🏁 Final Thought

Git feels complex when you try to learn everything.

It becomes simple when you think in terms of:
“Where are my changes right now?”

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share any corrections.

My Other Blogs:

JMeter vs Gatling: Comparison for Modern Performance Testing

AK DevCraft — Sun, 22 Mar 2026 05:45:13 +0000

Introduction

Performance testing has been around for a long time. And if you’ve worked in this space, chances are you’ve used Apache JMeter.

It’s popular.
It’s reliable.
And it has served the industry well.

But is it still the best way to approach performance testing today?

🧠 The Shift: From Tooling → Engineering

Traditional performance testing tools like Apache JMeter are largely:

UI-driven
Configuration-heavy
File-based (XML test plans)

This works… until it doesn’t.

As systems become more complex and teams move toward:

CI/CD
Version-controlled infrastructure
“Everything as Code”

👉 Performance testing needs to evolve, too.

That’s where Gatling starts to stand out.

⚔️ JMeter vs Gatling — Key Differences

1. 🧩 Configuration vs Code

JMeter

Test plans are GUI-driven
Stored as .jmx files
Harder to review in pull requests
Merge conflicts are painful

Gatling

Fully code-based (Scala/Java/Kotlin)
Lives naturally in your codebase
Easy to version, review, and refactor

👉 This is the biggest shift:

Gatling treats performance tests like real software, not configuration.

2. 🚀 Learning Curve & Developer Experience

JMeter

Requires learning the tool + UI
Debugging can be unintuitive
Configuration becomes overhead over time

Gatling

Uses familiar programming languages
Easier for developers to adopt
Better IDE support

👉 You’re not learning a tool—you’re applying existing skills.

3. 🔄 CI/CD Integration

JMeter

Integration is possible, but not seamless
Often requires additional scripting

Gatling

Fits naturally into build pipelines
Works like any other test suite

👉 This aligns perfectly with modern DevOps practices.

4. 📊 Reporting & Insights

JMeter

Provides reports, but often requires interpretation
User ramp-up behavior isn’t always obvious
Some level of “guesswork” is involved

Gatling

Rich, interactive HTML reports out of the box
Clear visualization of:
- Active users
- Ramp-up patterns
- Response time distribution

👉 Observability is significantly better.

5. ⚙️ Maintainability at Scale

JMeter

Large test plans become difficult to manage
Reusability is limited
Refactoring is cumbersome

Gatling

Modular, reusable code
Easier to scale scenarios
Cleaner structure

👉 This becomes critical in large systems.

Here is a quick comparison:

🏁 So… Is JMeter Still Relevant?

Absolutely.

Apache JMeter is still:

Mature
Widely adopted
Backed by a strong community

For:

Quick testing
Non-developer teams
Legacy setups

👉 It still does the job very well.

💡 My Take

If your team is moving toward:

Microservices
CI/CD pipelines
Engineering-driven quality

Then:

👉 Gatling feels like the natural next step

Not because JMeter is bad…
…but because the way we build software has changed.

🔥 Final Thought

We’ve already embraced:

Infrastructure as Code
Tests as Code
Pipelines as Code

👉 Performance testing as code is the next logical step.

And in that world, Gatling has a clear edge.

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share any corrections.

My Other Blogs:

Practical Tips When Working with AI Coding Assistants

AK DevCraft — Sat, 14 Mar 2026 22:22:13 +0000

Background

Modern AI coding assistants like Claude, GitHub Copilot, and ChatGPT can dramatically accelerate development. Recently, while working on a feature update, I had to modify an existing API to fetch data from a new system while maintaining backward compatibility.

The migration was gradual. Some clients would continue using the old system for a while, while others would start using the new one. Because of that, the implementation had to support both behaviors during the transition period.

Like many developers today, I used an AI coding assistant to speed up the implementation.

At first, it seemed straightforward.

But the process turned out to be more interesting than expected.

The First Iteration Looked Correct… But Wasn't Ideal

The AI-generated code worked functionally. It handled the new system integration, preserved backward compatibility, and integrated with the existing service.

But after reviewing the code carefully, a few issues surfaced:

Extra conditional branches that were unnecessary
Redundant logic left over from earlier iterations
Code paths that technically worked but were not optimal
Some defensive checks that were never needed for the actual use case

In other words, the code worked, but it wasn't clean.

It took multiple iterations and careful review before the implementation reached a version that was both correct and maintainable.

This experience reinforced something important.

AI Accelerates Coding — Not Thinking

AI assistants are excellent at generating working code quickly. They help remove boilerplate, explore possible implementations, and reduce the time spent writing repetitive logic.

However, they do not fully understand the context of your system.

They don't know:

The long-term architecture decisions
The migration strategy
The constraints of your system
What future developers will have to maintain

Because of this, AI often generates code that is technically correct but contextually imperfect.

And that is where code review becomes critical.

In the AI Era, Code Review Becomes a Core Skill

When development speed increases, the risk of suboptimal code entering the codebase also increases.

If developers accept AI-generated code in the first iteration, teams may gradually accumulate:

Unnecessary abstractions
Redundant logic
Hidden technical debt
Dead code paths

Over time, these small issues compound, making systems harder to maintain.

This means developers must become even better reviewers than before.

Good code review is no longer just about catching bugs. It is about evaluating whether the code truly fits the system.

Questions We Should Now Ask During Code Review

When reviewing AI-assisted code, now intentionally ask a few additional questions.

1. Does the code solve the problem exactly, or more than necessary?

AI often introduces extra flexibility that the use case does not require.
Extra flexibility today can easily become unnecessary complexity tomorrow.

2. Is there redundant or leftover logic?

Because AI suggestions often evolve across multiple prompts, some intermediate logic can remain even after the final version is generated.
This can result in code paths that are never actually used.

3. Is the implementation optimal for the system architecture?

AI may suggest patterns that work in general but do not align with your system's architecture.

Examples include:

Introducing unnecessary abstractions
Overusing defensive checks
Adding layers that increase complexity without real benefit

4. Will the code still make sense to the next developer?

Maintainability matters.
Even if the code works, the question remains:

Would another engineer understand this logic six months from now?

AI Changes the Development Workflow

One interesting shift I’ve noticed is that development is starting to look more like collaboration between a developer and an AI assistant.

The workflow increasingly looks like this:

Developer defines the intent
AI generates an implementation
Developer reviews and refines
AI proposes improvements
Developer validates architecture and constraints

The developer's role shifts slightly from writing every line of code to evaluating, refining, and validating generated code.

The Real Skill Shift for Engineers

As AI becomes more capable at writing code, the value of engineers will increasingly come from their ability to:

Review code critically
Evaluate trade-offs
Optimize implementations
Ensure architectural alignment

In other words, the skill of thinking about code becomes even more important than writing code.

Development Flow Diagram

Here is a quick comparison between Traditional and AI-Assistent development flow.

Traditional Development

Developer
↓
Write Code
↓
Code Review
↓
Merge

AI-Assisted Development

Developer Idea
↓
AI Generates Code
↓
Developer Reviews & Refines
↓
AI Iteration
↓
Code Review
↓
Merge

AI accelerates code generation, but developers are still responsible for validating the architecture, reducing unnecessary complexity, and ensuring maintainability.

Wrapping up

AI tools are powerful accelerators for software development. They can help teams move faster and explore solutions more quickly.

But speed should not come at the cost of quality.

If anything, the rise of AI in development makes strong code review practices more important than ever.

Ultimately, AI can generate code, but engineers are still responsible for the systems they build.

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share any corrections.

My Other Blogs:

☁️ Private Cloud vs Public Cloud — still one of the most misunderstood topics in cloud computing. Many discussions focus only on cost or control, but the real differences go deeper

AK DevCraft — Thu, 12 Mar 2026 05:37:00 +0000

AK DevCraft

Dec 12 '21

Private vs Public Cloud: Key Differences, Architecture, and Cloud Service Models

#cloud #cloudcomputing #containers #docker

Comments 1

5 min read

Do you know how to stream Kubernetes log from multiple pods concurrently?

AK DevCraft — Fri, 27 Feb 2026 05:14:43 +0000

AK DevCraft

Jan 3 '23

Streaming Kubernetes logs of more than one pod concurrently

#kubernetes #containers #docker #softwareengineering

Comments

2 min read

From DEV in 2021 to Substack Today: Continuing the Writing Journey

AK DevCraft — Sun, 22 Feb 2026 00:13:28 +0000

From DEV to Substack: Continuing the Writing Journey

I started writing technology articles in 2021.

My first blog was published on DEV on May 30, 2021. At the time, the intention was simple: document my research and findings in one place, and share what I was learning along the way.

I have always believed that technical knowledge should be free and accessible. That belief is one of the reasons I chose DEV instead of Medium. DEV felt open, community-driven, and aligned with the idea that engineering insights should not sit behind paywalls.

Over the years, writing has helped me in ways I didn’t initially expect.

✅ It forced me to structure my thinking more clearly.
✅ It made me revisit assumptions.
✅ It pushed me to explain production trade-offs more deliberately.

Many of my posts, on resilience patterns, distributed systems, Git workflows, and engineering discipline, started as personal notes or project reflections. Writing turned those notes into structured knowledge.

And for that, I’m grateful to the DEV community.

What I Started Missing

As I continued writing, I began to notice something🤔

While DEV provides visibility and discovery through its feed, I rarely receive direct or ongoing feedback from readers. Conversations are often limited to comments under a post. There isn’t a consistent way to stay connected with people who genuinely want to follow deeper discussions.

Publishing on DEV sometimes feels like releasing something into a stream; it flows through the feed, gets engagement for a while, and then moves on.

There’s nothing wrong with that model. It works well for discovery.

But for topics like:

Production engineering decisions
Resilience strategies
Delivery discipline
Architectural trade-offs
The subtle choices that influence DORA metrics

I started feeling the need for a more direct and intentional channel.

Why I’m Expanding to Substack

Recently, I started a Substack publication. ⭐️Substack Publication⭐️

This is not a move away from DEV. I will continue writing here.

But Substack provides something different: direct communication.

When a new article is published, subscribers receive notifications or emails. That creates a consistent and intentional connection between writer and reader. Instead of depending entirely on feed algorithms or timing, there is a direct channel for ongoing dialogue.

For deeper engineering discussions, that matters.

I’m hoping it allows:

⭐️ More thoughtful feedback
⭐️ More structured conversations
⭐️ A recurring audience interested in production-grade engineering topics

It feels like the next natural step in this writing journey.

Still Believing in Free Knowledge

My core belief hasn’t changed.

Knowledge should be free.
Engineering insights should be accessible.

I will continue publishing openly. Expanding to Substack is about communication and continuity — not exclusivity.

DEV remains where this journey started. And it will continue to be part of it.

Looking Ahead

Over the past few years, my writing has increasingly focused on the invisible decisions that shape software quality:

⭐️ Branching strategies that quietly impact delivery velocity
⭐️ Default configurations that hurt production performance
⭐️ Resilience patterns that determine system stability
⭐️ Engineering discipline that influences long-term scalability

Substack gives me room to explore these themes more deeply while building a direct connection with readers who care about production-first engineering.

Starting in 2021 on DEV was the first step.

Expanding to Substack feels like the next one.

If you’ve been reading my posts over the years, thank you!
And if you’d like to continue the journey in a more direct format, you’re welcome to join me there. ⭐️Substack Publication⭐️

How Poor Git Branching Practices Quietly Damage Software Quality

AK DevCraft — Mon, 16 Feb 2026 23:27:30 +0000

Your QA Didn’t Miss It — Your Branching Strategy Did

A production bug that never appeared in QA is one of the most frustrating experiences in software engineering. Or a code commit that was never released in production.

QA validated the feature.
Staging looked stable.
The release was approved.

And yet, production behaved differently.

The immediate reaction is predictable:

QA/Dev missed it.
We need more regression coverage.
Testing wasn’t thorough enough.

But in many enterprise systems, the real issue isn’t testing.

It’s a branching strategy.

I’ve seen cases where QA tested one version of the code, staging had subtle differences, and production ran yet another variation; all because environment-specific long-running branches quietly drifted apart over time.

The result?

Production-only bugs
Patch-on-patch hotfix chaos
Loss of release confidence

This isn’t a test coverage problem.
It’s a version control discipline problem.

The Hidden Anti-Pattern: Environment-Based Branching

In many enterprise setups, the repository looks something like this:

main
qa
staging
prod

Or worse

feature → qa branch
feature → staging branch
feature → prod branch

Each environment maintains its own long-running branch.

On paper, it sounds controlled.

In reality, it creates code drift across environments.

Over time:

A hotfix is applied directly to prod
A feature merges into qa but not yet into main
Staging carries experimental tweaks
Merge conflicts accumulate
Re-merging the same logic across branches becomes routine

Now QA is testing one commit history.
Production is running another.

And when a production bug appears, it cannot be reproduced in QA because QA never tested that exact commit.

Quality becomes non-deterministic.

Why This Directly Impacts Software Quality

Branching strategy is not just a Git preference.
It is a quality control mechanism.

When environments run different commit histories, several things break:

1️⃣ Deterministic Releases Disappear

If the code in QA is not the exact same commit that goes to production, you lose release predictability.

You are no longer promoting tested code — you are reconstructing it.

2️⃣ Regression Risk Increases

When features are re-merged into multiple long-running branches, subtle behavioral differences can emerge.

Same logic. Different surrounding context.

That’s where elusive bugs are born.

3️⃣ Debugging Becomes Harder

When production fails:

Which branch is it running?
What hotfix was applied?
Was that merged back?
Is QA aligned?

Instead of investigating business logic, teams spend time investigating Git history.

CI/CD Maturity: Build Once, Promote Everywhere

Modern delivery pipelines introduce a simple but powerful principle:

Build once. Promote everywhere.

The flow becomes:

feature → main
CI builds an artifact
Artifact promoted → QA → Staging → Prod

No re-merging.
No environment-specific code.
No rebuilding for each environment.

Only configuration changes across environments — not code.

This ensures:

Same commit
Same artifact
Same behavior

That is real quality assurance.

Trunk-Based Development vs Branch-Heavy Models

This is not about declaring one model universally superior.

GitFlow and release branches can work in certain contexts, especially release-heavy or versioned products.

The real problem emerges when:

Branches are long-lived
Integration is delayed
Environments maintain independent code histories

Trunk-based development, or short-lived feature branches, reduces that risk by:

Encouraging frequent integration
Minimizing merge conflicts
Reducing change size
Increasing feedback speed

The smaller the batch size, the lower the failure probability.

And that directly affects quality.

The DORA Metrics Connection

Branching strategy quietly influences engineering performance metrics.

🚀 Lead Time for Changes

Long-running branches delay integration and validation.

🔁 Deployment Frequency

Manual environment merges slow down releases.

💥 Change Failure Rate

Branch drift increases production-only defects.

⏱️ Mean Time to Recovery

Hotfix chaos increases recovery time because fixes must be reconciled across multiple branches.

Branching discipline isn’t just a workflow preference; it directly impacts delivery performance.

But What About Incomplete Features?

One common fear is:

“If we merge early, unfinished features might go live.”

This is where feature flags become essential.

Instead of isolating code in environment branches, you:

Merge into main early
Guard incomplete features with toggles
Enable features selectively per environment

Now you get:

Continuous integration
Safe rollout control
No branch drift

You preserve quality without sacrificing flexibility.

What a Quality-Centric Branching Strategy Looks Like

A simplified, quality-focused model:

Single source of truth (main)
Short-lived feature branches
Mandatory pull request + CI validation
Single artifact build
Progressive promotion across environments
Immediate merge-back of hotfixes into main

The principle is simple:

The same code commit version should run across all environments (QA, Staging, and production).

Anything else introduces risk and sets up the team for failure.

Final Thought

When a production bug appears that QA never saw, when we miss a commit to promote in prod, the instinct is to question testing. But sometimes, the tests were fine.
The code that reached production was not the same as the code QA validated.

Version control is not just a developer workflow decision. It is a software quality strategy.

And if your environments are running different histories, you don’t have a testing problem; you have a branching problem.

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share any corrections.

My Other Blogs:

Modern DevSecOps Needs More Than One Tool: Secure SDLC Strategy

AK DevCraft — Sat, 14 Feb 2026 06:24:34 +0000

🧠 Background: Why Multiple Analysis Tools Became Necessary

Not long ago, software delivery was simpler. Teams wrote code, ran a static analysis tool like SonarQube during the build, and deployed artifacts into controlled environments. Security checks were often centralized and performed toward the end of the release cycle, primarily focused on code-level defects.

But modern software engineering has expanded far beyond source code.

Today we ship containers, infrastructure-as-code, open-source dependencies, APIs, and increasingly AI-assisted code. Applications run across distributed systems and cloud-native platforms where risks can originate from many layers, base images, dependency chains, configuration drift, or exposed secrets.

Because of this shift, relying on a single tool is no longer enough. Instead, teams need a layered analysis strategy, combining tools specialized for different risk areas across the SDLC.

🔄 Security Tools Significance Across the SDLC

Modern engineering teams embed analysis throughout the lifecycle, not just at release time, to reduce risk and provide fast feedback to developers.

🧑‍💻 Development Phase – Code Quality & Secure Coding

During local development and CI builds, static analysis tools help engineers catch issues early.

Typical tools include:

SonarQube/SonarCloud → Static code quality and maintainability checks
Checkmarx/Fortify → SAST-focused security scanning
Semgrep → Lightweight rule-based code and security analysis
ESLint/PMD/SpotBugs → Language-specific linting and bug detection

These tools enforce coding standards and surface vulnerabilities before code even reaches pull requests.

🔍 Pull Request Phase – Dependency & Supply Chain Security

Most modern applications rely heavily on third-party libraries, making dependency scanning essential.

Common tools used here:

Snyk → Dependency vulnerability scanning integrated with Git workflows
OWASP Dependency-Check → Open-source vulnerability scanning
Dependabot/Renovate → Automated dependency updates and alerts
GitHub Advanced Security → Secret scanning and dependency insights

These tools prevent vulnerable libraries from silently entering production systems.

📦 Artifact & Repository Phase – Binary & Policy Enforcement

Once code is built, artifacts stored in repositories need governance and vulnerability checks.

This is where tools like:

JFrog Xray → Binary analysis, supply chain security, and policy enforcement
Nexus IQ (Legacy in many organizations) → Repository scanning and governance
JFrog Artifactory Policies → Artifact lifecycle enforcement

With container-based deployments growing rapidly, JFrog Xray has gained strong adoption due to its seamless integration with Docker images and artifact repositories, often replacing older repository-only tools.

🐳 Container & Infrastructure Phase – Image and Runtime Security

In cloud-native environments, vulnerabilities frequently originate from base images or OS layers rather than application code.

Popular tools here include:

JFrog Xray → Container image scanning integrated with repositories
Trivy → Lightweight container and IaC vulnerability scanning
Anchore/Grype → Deep container image analysis
Aqua Security/Prisma Cloud → Runtime and container platform security
Checkov/tfsec → Infrastructure-as-Code scanning for Terraform & cloud configs

These tools extend security coverage beyond code into the deployment ecosystem.

⚙️ Final Thoughts

Fast-moving teams often face pressure to ship quickly while maintaining security and quality. Large pull requests, distributed teams, and frequent releases increase the chance of issues slipping through unnoticed.

⚡ TL;DR

A multi-tool strategy transforms analysis from a gatekeeping exercise into a continuous feedback loop:

Static analysis catches code defects early
Dependency scanners protect against supply chain risks
Artifact scanning enforces governance
Container and IaC tools secure deployment environments

Rather than slowing development, these tools collectively enable teams to move faster with confidence, supporting a true shift-left and shift-everywhere mindset.

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share any corrections.

My Other Blogs:

Spring Boot API Performance Automation Testing: Shift-Left With Gatling

AK DevCraft — Sun, 23 Nov 2025 01:58:58 +0000

Introduction

Performance testing often comes too late in the Software Development Lifecycle, either after the code is merged, deployed, or when something starts slowing down in production.

But what if performance testing doesn't have to wait until the end?
What if it could run right inside your Spring Boot CI/CD pipeline, every time the code changes?

That’s the essence of Shift Left Performance Testing, bringing load and latency validation closer to developers.
And when you combine Gatling (for load simulation) with mocked dependencies (for stability), you get both speed and consistency in your performance results.

📬 I also write about production engineering and real-world system behavior in my newsletter.

If topics like resilience, distributed systems, and performance tuning interest you, you can subscribe here:

📬 Subscribe to Newsletter🙏🏻

The Problem

One of the biggest challenges with API performance testing is uncontrolled variables:

External APIs fluctuate in response time
Databases may have inconsistent caching or data sizes
Network latency varies per environment

When these factors change, your test results become inconsistent.
You’re left wondering: Is my API slow, or was it the dependency this time?

To catch genuine performance regressions, you need stable and repeatable test conditions, which means mocking what’s not under test.

⚙️ Setting the Ground for Controlled Perf Testing

To get predictable results, mock or simplify dependencies before running load tests.

Mock External APIs with WireMock

If your Spring Boot API calls other services, say for authentication, pricing, or inventory, mock those dependencies using WireMock or any other mocking framework.

Wiremock example:

@AutoConfigureWireMock(port = 8089)
@SpringBootTest
class ProductServiceIntegrationTest {

  @BeforeEach
  void setupMocks() {
    stubFor(get(urlEqualTo("/inventory/123"))
      .willReturn(aResponse()
        .withFixedDelay(200)  // Simulate 200ms latency
        .withHeader("Content-Type", "application/json")
        .withBody("{\"available\": true}")));
  }
}

Now, every test run behaves exactly the same - same delay, same data, same outcome.
That’s controlled performance testing.

Note - You can also use Wiremock's recording feature to record the response in a file so you don’t have to stub large object responses.

Use H2 for Database Mocking

When your test focuses on the application or API layer, you don’t always need a full production-grade database.

Using an in-memory database like H2 ensures consistency and isolation:

spring:
  datasource:
    url: jdbc:h2:mem:testdb
    driver-class-name: org.h2.Driver
    username: test
    password:
  jpa:
    hibernate:
      ddl-auto: update

You can preload the same dataset before each run for reproducibility.
It eliminates variability from query performance, network I/O, and DB load.

Gatling: Performance as Code

Once your environment is stable, define your performance tests in Gatling.

Maven Configuration for Gatling (Java DSL)

pom.xml

<project>
  <dependencies>
    <!-- Gatling core and HTTP modules -->
    <dependency>
      <groupId>io.gatling</groupId>
      <artifactId>gatling-java</artifactId>
      <version>3.11.5</version>
      <scope>test</scope>
    </dependency>

    <dependency>
    <groupId>io.gatling</groupId>
      <artifactId>gatling-http</artifactId>
      <version>3.11.5</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <!-- Gatling Maven Plugin -->
      <plugin>
        <groupId>io.gatling</groupId>
        <artifactId>gatling-maven-plugin</artifactId>
        <version>4.9.2</version>
        <executions>
          <execution>
            <phase>verify</phase>
            <goals>
              <goal>test</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Performance test

You can create a separate folder in the project structure and organize all of the performance tests. Treat performance test just like production code.

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

public class ProductApiSimulation extends Simulation {

    // Define the HTTP protocol
    HttpProtocolBuilder httpProtocol = http
        .baseUrl("http://localhost:8080") // Base URL of your Spring Boot service
        .acceptHeader("application/json");

    // Define the scenario
    ScenarioBuilder scn = scenario("Get Products Scenario")
        .exec(
            http("Get All Products")
                .get("/api/products")
                .check(status().is(200))
        );

    {
        setUp(
            scn.injectOpen(
            rampUsers(50).during(2 * 60), // ✅ Warm-up over 2 mins
            constantUsersPerSec(20).during(15 * 60) // ✅ Sustain load for 15 mins
            )
        )
        .protocols(httpProtocol)
        .maxDuration(17 * 60); // ✅ Hard stop for safety
        // ✅ Add assertions for automated performance gating
        .assertions(
           global().responseTime().percentile(95).lt(500),  // 95% under 500ms
           global().successfulRequests().percent().gt(98.0) // Error rate < 2%
       );

    }
}

Code Explanation

rampUsers(50).during(2 * 60) → Simulates a gradual load (50 users in 120 seconds).
constantUsersPerSec(20).during(15 * 60) → maintain the load for 15 mins, quite obviously this is a high number, but we need to strike a balance between pipeline duration and enough load duration to perform the performance test on the application.
check(status().is(200)) → Verifies each request returns HTTP 200.
Assertions → Define performance thresholds. If breached:
- The test fails,
- The pipeline breaks,
- Developers are notified before the code moves to the upper environment.

To avoid a long pipeline run:

✅ Run smoke performance tests on every PR for (30–60 sec)
✅ Run long tests only on:

main branch
nightly builds
release candidates

GitHub action example

on:
  push:
    branches:
      - main
  schedule:
    - cron: "0 2 * * *"  # nightly

Why Assertions Matter

These assertions turn your performance test into a quality gate.
If response times exceed 500 ms or error rates go beyond 2%, the test fails automatically.

This instantly alerts developers that a recent change has caused a performance regression — before it ever reaches production.

No manual analysis, no post-deployment surprises.

Note - “Define your performance thresholds/assertions based on realistic SLAs or baseline metrics, and review them periodically as your service evolves.”

🚀 Running the Test

Once configured, you can run performance tests using:

mvn gatling:test

This will:

Launch your Spring Boot API (if already running locally or in CI)
Run the Gatling simulation (ProductApiSimulation.java)
Generate an HTML report under:

target/gatling/productapisimulation-<timestamp>/index.html

Fail the build automatically if assertions fail (e.g., high latency, low success rate)

🧩 Bringing It into the CI/CD Pipeline

The real power of Shift Left testing comes when performance runs automatically in your pipeline — just like unit or integration tests.

Here’s an example using GitHub Actions:

name: Performance Tests

on:
  push:
    branches:
      - "release/*"   # Run only on release branches to avoid long runs on every commit
      - "main"
  workflow_dispatch:  # Allow manual trigger

jobs:
  performance-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: "17"
          distribution: "temurin"

      - name: Build Spring Boot app
        run: ./mvnw clean package -DskipTests

      - name: Run Gatling performance tests
        run: ./mvnw gatling:test

This setup:
✅ Runs automatically on main or release branches
✅ Can be triggered manually for controlled environments
✅ Produces Gatling HTML reports as pipeline artifacts
✅ Fails the pipeline automatically if performance thresholds are breached

To keep pipelines lean, run these tests only on main, release, or nightly builds — not every feature branch.

Why This Approach Works

When you combine stable mocks, assertions, and CI integration:

You get consistent metrics across builds
You isolate application performance from dependency noise
You catch regressions early with automatic thresholds
You build confidence without extending pipeline times unnecessarily

This is how teams move from reactive performance firefighting to proactive performance assurance.

🏁 Wrapping Up

Shift-left performance testing isn’t about running massive load tests earlier; it’s about running smarter, smaller, and stable tests continuously.

By combining:

Spring Boot for your core service
WireMock for predictable external calls
H2 for stable DB interactions
Gatling for performance-as-code
Assertions to enforce performance budgets
CI/CD filters to run tests only where needed

You achieve repeatable, reliable, and developer-owned performance validation.

That’s not just testing earlier — it’s building performance culture into the pipeline.

⚡ TL;DR

Shift left = move performance testing closer to code commits.
Mock dependencies (WireMock, H2) → get stable, repeatable results.
Use Gatling → define performance as code.
Add assertions → fail builds when thresholds break.
Configure CI/CD → run only on main/release branches.
Focus on early detection, not end-stage firefighting.

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share with corrections.

My Other Blogs:

Spring RestClient Defaults Don’t Scale in Production: Improve API Performance

AK DevCraft — Sun, 12 Oct 2025 07:58:58 +0000

🚨 Problem Introduction

Imagine you’re building a SpringBoot Order API that calls three downstream services:

Inventory Service
Pricing Service
Shipping Service

You decide to use Spring’s new RestClient (Spring 6 / Boot 3). Locally, everything works perfectly fine. But in production, under load, issues appear:

Requests pile up
Threads block waiting for connections
Users face delays and even timeouts

How would you prevent the performance impact, or in other words, improve the performance of your application?

📬 I also write about production engineering and real-world system behavior in my newsletter.

If topics like resilience, distributed systems, and performance tuning interest you, you can subscribe here:

📬 Subscribe to Newsletter🙏🏻

What’s going on?

🔎 As most likely you know, based on my previous blog Avoid Spring RestTemplate Default Implementation to Prevent Performance Impact. The
RestTemplate defaults to only 2 total global connections (without Apache HttpClient tuning).

Welp! RestClient defaults do slightly better with 5 per-host connections.

👉 But that’s still tiny for production load.
If 100 users call your service simultaneously:

Only 5 calls to downstream services can proceed
95 calls sit waiting in the connection queue
Latency spikes
Errors creep in

This is why things work locally but fail under load — you’re bottlenecked by the connection pool defaults.

🧪 Conceptual Benchmark

Scenario: 100 concurrent requests from OrderService → InventoryService

With Default RestClient (5 connections/host):

Only 5 requests proceed at a time.
95 requests wait
Latency grows
Timeouts are likely under heavy load

Tuned RestClient (150 total, 50 per-host):

Pool size reflects expected traffic — e.g., ~150 active users per second.
Up to 50 concurrent requests per external service can proceed in parallel.
The remaining requests queue briefly, but overall throughput remains smooth.
Response times stay predictable and stable.

The point isn’t the exact number (150 or 50) — it’s about matching pool capacity to your app’s concurrency profile.
Your pool size should be proportional to peak concurrent users and downstream service latency.

✅ The Solution

Add Dependency

Apache HttpClient 5 dependency in the project, maven example:

<dependencies>
 <!-- Apache HttpClient 5 (for advanced pooling, timeouts, etc.) -->
    <dependency>
        <groupId>org.apache.httpcomponents.client5</groupId>
        <artifactId>httpclient5</artifactId>
    </dependency>
</dependencies>

Code Update

Configure your own HTTP connection pool

import org.apache.hc.client5.http.impl.classic.CloseableHttpClient;
import org.apache.hc.client5.http.impl.classic.HttpClients;
import org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager;
import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
import org.springframework.web.client.RestClient;

public class RestClientConfig {

    public RestClient restClient() {
        PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();

        connectionManager.setMaxTotal(150);          // total connections
        connectionManager.setDefaultMaxPerRoute(50); // per-host connections

        CloseableHttpClient httpClient = HttpClients.custom()
                .setConnectionManager(connectionManager)
                .build();

        return RestClient.builder()
                .requestFactory(new HttpComponentsClientHttpRequestFactory(httpClient))
                .build();
    }
}

⚙️ Bonus: Don’t Forget the Timeouts

Even with connection pooling tuned, your app can still hang if remote services become slow.
That’s where timeouts come in — they protect threads from waiting indefinitely.

import org.apache.hc.client5.http.config.RequestConfig;
import org.apache.hc.client5.http.impl.classic.CloseableHttpClient;
import org.apache.hc.client5.http.impl.classic.HttpClients;
import org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager;
import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
import org.springframework.web.client.RestClient;

public class RestClientConfig {

    public RestClient restClient() {
        PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
        connectionManager.setMaxTotal(150);
        connectionManager.setDefaultMaxPerRoute(50);

        RequestConfig requestConfig = RequestConfig.custom()
                .setConnectTimeout(2000)            // time to establish connection (ms)
                .setResponseTimeout(3000)           // time waiting for server response (ms)
                .setConnectionRequestTimeout(1000)  // time to wait for connection from pool (ms)
                .build();

        CloseableHttpClient httpClient = HttpClients.custom()
                .setConnectionManager(connectionManager)
                .setDefaultRequestConfig(requestConfig)
                .build();

        return RestClient.builder()
                .requestFactory(new HttpComponentsClientHttpRequestFactory(httpClient))
                .build();
    }
}

💡 Quick Notes

Timeouts above are in milliseconds (2000 ms = 2 seconds)
connectTimeout: protects you from unresponsive hosts.
connectionRequestTimeout: stops threads from waiting too long for a pooled connection.
responseTimeout: prevents hanging on slow downstream responses.

Combined with a tuned connection pool, these timeouts make your RestClient fast, safe, and production-hardened.

Conclusion - Key Takeaways

RestTemplate default = 2 global connections.
RestClient default = 5 per-host connections.
Configured pool = production-safe scaling.

⚠️ Never trust defaults for HTTP clients. They’re tuned for safety in local/dev, not performance in production.

TL;DR

RestClient (Spring Boot 3 / Spring 6) is better than RestTemplate, but still not production-ready out of the box.
Default pool size = 5 per host → easily becomes a bottleneck under load.
Always configure:
- ✅ Connection pool size (maxTotal, maxPerRoute)
- ✅ Timeouts (connect, request, read)
Keep your RestClient tuned, and it’ll handle thousands of concurrent requests gracefully.

💡 In short:
Spring’s RestClient is powerful — but like any engine, it needs tuning before you take it to production.

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share any corrections.