Practical AI Coding Tools for Developers: CLIs, Skills and Semantic Kernel

Where do you start with AI tooling? Install an extension in your IDE, start chatting? In my experience, this is exactly where most development teams are: leaning into AI, delegating coding tasks, and embracing this new way of working.

But the conversations I have with client dev teams are rarely about cutting-edge agentic workflows or spinning up models in Azure AI Foundry. They're simpler than that. What's the difference between models? How does an MCP server help me code better? What's Copilot CLI, and how is it different from the Copilot IDE extension?

This article summarises the practical AI coding tips I've shared with my client team. Their positive feedback is why I'm writing this blog, and I hope this advice helps you, too.

What are AI Coding CLIs and why are Developers switching to them?

It's funny how with AI, what is old feels new again. I never thought we'd ditch the IDE for the terminal; I had nightmares at uni learning to code with vi, which felt as complex as the language I was meant to be learning. But here we are in 2026, back in the CLI.

Claude Code is probably the best known, but almost every coding assistant that used to live in the IDE now has a CLI equivalent:

• Copilot CLI

• Cursor CLI

• Gemini CLI

• Codex CLI

In my opinion, these are LLMs in their truest form. An IDE assistant tries its best to integrate with your current solution; it knows which files exist and helps you edit them, but it feels constrained because it's supposed to be an IDE assistant. Coding CLIs aren't bound to your IDE or a particular project.

So, start a session from anywhere on your machine. There are two practical benefits worth calling out.

Why context is everything for AI Coding Agents

The more an AI agent knows, the smarter its outputs. I keep an llm-context folder on my laptop and run all my coding sessions from there. I copy my git repos into this folder before starting. The agent automatically discovers the contents of the working directory, so when you're working on a web app with your API and UI in separate repos, putting both in one folder makes the agent significantly smarter. It understands that the API and UI are related and can make changes across both that work together.

You might ask: why not just start the agent from the parent folder of all your repos? The answer is token usage and memory management. A typical change takes a day or more to get your head around, code, and test. One long-running chat brings two problems. First, context grows and grows, consuming tokens (and therefore usage). Second, the LLM will recall previous instructions from the same session at unexpected moments, like a reminder to check before committing, which fires when you're in the middle of something else.

This is how LLMs work, and it's great when you want the recall and maddening when you don't. Starting fresh sessions from a clean, scoped folder saves your sanity and a lot of typing.

How to use AI CLIs to build Apps that don't have a home

At my current client, teams are responsible for deploying and monitoring their own apps. Zendesk tickets come straight to us, so speed matters. For any repetitive production support task, we now rely on coding agents to build a small app that automates manual steps.

Deliberate vibe coding is genuinely fun. It's almost like rolling the dice to see what you'll get. Our team, including BAs and other non-technical members, use coding agents to build bespoke tools for one-off problems. We keep a shared git repo called shared-support-tools where these live. The benefit of the CLI over an IDE is that it's arguably simpler: no license required, runs from PowerShell, which means Windows users have access out of the box. Scaffolding the repo with checked-in agent instructions gives non-technical users guardrails when they're prompting on their own.

When should you call an LLM from code? The case for C# Semantic Kernel

Every time I've needed to call an LLM from code: a chat app, text analysis, anything, I reach for Microsoft.SemanticKernel NuGet package. In short, it's an SDK for calling LLMs that handles authentication, system prompts, and streaming responses. It supports models hosted on Azure, AWS, GCP, or directly with providers like Anthropic and OpenAI.

Two practical use cases stand out.

Using Semantic Kernel for text classification

At SixPivot, we have a Slack app that reminds billable staff to submit their weekly timesheets. It monitors our #movements channels, where people post when they're on leave or sick. The app sends those messages to a gpt-4o-mini model hosted in Azure AI Foundry, alongside a system prompt that asks the LLM to classify whether the person is away:

You are an AI that helps interpret messages about leave in a Slack channel. Given the text of a message and the date it was posted, determine if the message indicates that the person is sick or otherwise not working. Respond with the result as a JSON array of ISO-8601 dates that the person will be away.

The Semantic Kernel handles the model call, the system prompt, and the response parsing, hiding almost all of the plumbing code.

How to expose your App Code as AI tool calls

Tool calling is what you see every time your CLI assistant edits a file, searches across a codebase, or runs a command. You can expose your own code as a tool call using the Semantic Kernel KernelFunction attribute. Add it to any function, give it a name, add a [Description] annotation explaining what it does, and you have a tool call.

When you call an LLM from code, the Semantic Kernel makes the LLM aware of all your KernelFunction methods. This gives the LLM enough context to understand your codebase and how to interact with it. One practical outcome is natural language chat: let users talk to your app, with an LLM answering their questions by calling your existing code and summarising the output in plain language. It's a quick way to add AI chat to an existing product without starting from scratch.

AI skills vs MCP servers: what's the difference?

When AI tooling exploded, we quickly needed a way for LLMs to call tools and interface with live data. MCPs established a technical protocol for LLM applications to connect with external tools. Popular MCPs we use at SixPivot include:

• Serena — semantic code retrieval for LLMs (find by symbol, method name, etc.)

• Context7 — pulls in docs for the framework or API you're building with

• Playwright MCP — browser automation, built by Microsoft

One thing you'll notice with MCPs is greater use of context. MCP servers expose their tool instructions to the AI agent at startup, so the agent knows when to call them. That context is stored for the entire session.

Popular MCP servers for developer workflows

Skills are a newer alternative. They extend AI agents with reusable capabilities documented in markdown files, with optional supporting scripts. Skills are loaded just-in-time by the agent, which means lower context usage. A good example is the Playwright skill, which provides the same capability as the Playwright MCP and is documented with CLI examples. The skill itself is just a collection of markdown files, viewable on GitHub.

If you're trying an MCP and there's an equivalent skill available, it's worth trying. Most CLIs support a /skills command to list installed skills. If you install them at .agents/skills/<skill-name>, they'll be discovered by any AI agent.

How to write your own AI skill

Because skills are markdown files, they're straightforward to write yourself. My colleagues Gert and Gary use an Atlassian CLI skill, which documents the acli tool for interfacing with Jira and Confluence from the terminal. To start work on a ticket, they'll type something like: "inspect jira ticket ABC-123 and let's plan what we need to implement." The skill tells the agent how to use acli to load the ticket, and from there, the Jira context is live in the chat session, ready to begin implementation, all without leaving the agent.

If you'd like the acli skill or want to dig further into any of these tips, get in touch with the SixPivot team.