Kycha Blog.About

Beyond the Chatbot: How to Build Software Using AI Agents and Skills in 2026

Cover Image for Beyond the Chatbot: How to Build Software Using AI Agents and Skills in 2026
Andrii Kycha
Andrii Kycha

Beyond the Chatbot: How to Build Software Using AI Agents and Skills

A few years ago, coding looked very different.

You opened an editor, created a file, and started typing. Every function, every edge case, every error message came from your head. Tools helped, but they did not think with you.

Today, many people first meet AI in the form of chat. You ask a question. It answers. You paste the code. Sometimes it works. Sometimes it breaks in confusing ways.

What is changing right now is not just code generation. It is a new way of working with AI called agent based coding. At the center of this approach is a simple idea: instead of writing everything yourself, you give agents structured responsibilities using something called skills.

This article explains what AI agents are, what agent skills mean, and how this changes the way we plan, design, and implement software. No deep coding knowledge required. Just fundamentals.

What is an AI Agent? (The Simple Version)

An AI agent has a specific goal, such as producing software, and is designed to help you achieve that goal.

If a standard LLM (Large Language Model) is a brilliant librarian, an AI Agent is a project manager with a library card.

💡 Note from the dev desk: I have been spending a lot of time at the Edmonton Public Library lately, taking advantage of everything from their book stacks to their audio recording studios to record a few songs of mine. That's probably why this analogy hit home for me while writing this - it's the difference between someone who knows where the information is and someone who has the tools to go get it and put it to work for you.

An agent doesn't just answer questions; it uses Skills to perform tasks in a specific sequence to reach a goal. For beginners and product people, this is the "secret sauce." You aren't just getting text back; you are triggering a workflow.

The New Standard: Skills as Markdown Files

A Skill is a Markdown file (.md) that acts as a manual for the AI.

In late 2025, the way we interact with AI changed. Anthropic introduced a standardized way for agents to handle tasks, and by December 2025, this was promoted to an open standard. Now, all major models (from Claude to GPT) can speak the same "Skills" language.

How the Agent Uses a Skill

Think of your project repository as an office. Inside that office, there is a hidden folder (like .codex or .claude). This is where the Agent's "training manuals" live.

When you give an instruction to an agent like Claude Code or Codex, the workflow looks like this:

  1. The Trigger: You ask, "Build a new checkout page."
  2. The Lookup: The Agent checks the .codex/skills folder.
  3. The Loading: It finds a file named spec-generator/SKILL.md, reads it, and loads those specific instructions into its "brain" (context) before it types a single word.

The Skills Folder Structure for codex:

my-cool-app/
├── src/ # Your actual code
├── package.json
├── .codex/ # The Agent's "Brain" folder
│ └── skills/ # The Skills Library
│ ..├── spec-generator/
│ . │ ├── SKILL.md # The "Product Manager" instructions
│ . │ └── templates/
│ . │ └── prd_template.md
└── .gitignore

What a Skill File Looks Like

Because these are just Markdown files, anyone on the product team can read, reason about, and refine them - just like regular documentation. That's intentional. These skills aren't hidden inside prompts or locked inside a tool. They live in the codebase, where real engineering decisions happen.

Here's a simplified example of what a Spec Generator Skill might look like:

# Skill: Spec Generator

## Role

You are a Senior Product Manager specializing in user-centric web design.

## Instructions

1. When a user asks for a new feature, do not write code immediately.
2. Interview the user to define the “Acceptance Criteria.”
3. Identify potential edge cases (e.g., “What if the user is offline?”).
4. Capture accessibility requirements (baseline vs extended).

This may look simple - but this is where the leverage comes from. Instead of relying on vibe-based prompts, the agent now follows a reusable decision pattern the same way an experienced engineer would. Over time, these skills evolve into a shared language for the team: how we plan features, how we reason about risk, how we avoid scope drift.

I've been using this approach in my own day-to-day development work, and it has consistently helped my agents produce more predictable, spec-aligned output with fewer rewrites. The best part? Once a skill proves itself in production, it becomes an asset the entire team can reuse.

I've published a collection of these battle-tested Agent Skills on GitHub - the same ones I rely on when building features with AI-assisted workflows. If you want to try them in your own projects, you can grab them here:

Andrii Kycha's GitHub Link

What is Spec-Driven AI Development and Why it's a Game Changer

Most AI coding workflows today still follow a vibe-coding pattern.

Describe what you want, let the agent generate code, and hope nothing breaks. It feels fast - until drift creeps in, edge cases slip through, and you find yourself debugging decisions the agent invented on its own.

Spec-driven AI development flips that dynamic completely.

Instead of reacting to bad output at the end, you guide the agent at the beginning by shaping the work through a living Markdown spec. Every change, constraint, assumption, and edge case is clarified before the agent touches the code - which means fewer surprises and far less rework.

This approach becomes a force multiplier because:

  1. Less Drift - More Control The spec acts as the contract. The agent isn't "guessing your intent" - it is executing against an explicitly defined source of truth.

  2. You Catch Problems Early (When They're Cheap) Ambiguity, risky assumptions, missing dependencies - they surface while editing the spec, not during implementation. Fixing them takes minutes instead of days.

  3. Development Time Shrinks The AI isn't wandering through the solution space. It follows a deterministic plan - making progress faster and with fewer corrective loops.

  4. Output Quality Becomes Predictable Because the spec and implementation plan lock the direction, feature delivery stops feeling random and starts feeling like engineering again.

In practice, this shifts teams from "let's see what the AI produces" to "we design the outcome, and the agent executes it."

And when features are delivered this way - with clarity, structure, and repeatable reasoning - the result isn't just faster development.

It's higher-quality software with fewer failures, fewer rewrites, and far more confidence in every release.

Stitching Skills and Spec-Driven Development Together

If you want your AI-assisted development workflow to feel predictable instead of chaotic, this is where everything starts - with the SPEC.md file generated by the AI agent before the feature implementation.

  1. Add the skill definition from my GitHub repo to your project.
  2. Run your agent with the feature-spec-generator skill enabled.
  3. Provide a high-level feature idea (e.g., "Let's generate a spec for the next feature: Login Page with SSO integration").
  4. Review the generated SPEC.md and lock it before development begins.

On your next feature, try it - you'll notice the difference immediately. The implementation phase becomes calmer, cleaner, and far more aligned with intent.

I've published the exact skill definition I use daily in my own production workflows - you can grab it here and drop it into your .claude|.codex/skills folder to experiment with it on your next feature implementation:

GitHub Link: feature-spec-generator/SKILL.md

Backend Integration In Front-End Projects Without Drift (The "Contract Keeper")

If specs keep the feature aligned, then backend integration keeps the system aligned.

This is where most AI-assisted development quietly falls apart. The agent builds a UI that assumes one response shape, while the backend returns another. A field is renamed. A DTO changes. A null sneaks in. Suddenly the end-to-end flow breaks - not because the model failed, but because the contract drifted.

To prevent that, I treat API contracts as first-class artifacts in the development process.

When I start working on a new end-to-end feature, I ask the agent to generate an ENDPOINTS.md file - a single source-of-truth document that defines every endpoint, request DTO, response payload, status code, and constraint involved in the feature. The agent saves it to:

.claude|.codex/skills/backend-integration/ENDPOINTS.md

This file becomes the shared language between the frontend, backend, and the agent. Before any code is written, the contract is locked.

The magic is not the agent guessing how the API works - it's the opposite. We give the agent real context about the backend architecture, data models, and constraints so its decisions match reality instead of hallucinating assumptions.

Here's the workflow I use in production:

  1. Ask the agent to inspect the system and generate ENDPOINTS.md with:
    • endpoint paths
    • request DTOs
    • response schemas
    • authentication rules
    • edge cases & invariants
  2. Save the file into the backend-integration skill directory.
  3. On the next feature, mention backend-integration in the spec (or directly in the prompt).
  4. The agent automatically loads the skill and develops end-to-end changes against the contract, not vibes.

That means when the agent writes React code, it imports the exact field names from the documented DTO - not guessed ones. When it updates backend logic, it respects the response schema already defined. Integration becomes deterministic instead of improvisational.

GitHub Link: backend-integration/SKILL.md

The real win isn't the skill itself - it's the discipline of maintaining a living ENDPOINTS.md contract that keeps humans and agents building the same system instead of three slightly different ones.

AGENTS.md - The Entry Point for Project Context

Before an AI agent starts working on a feature, it needs the same thing a new developer needs - a clear entry point into the project's context. That's exactly what the AGENTS.md (or CLAUDE.md) file provides.

This file is scanned every time the agent begins a task, so it always works from the latest shared understanding of the system. It acts as the root context loader for the project - not a prompt, but a persistent knowledge hub.

When you run initialize (or /init), the agent doesn't just wake up - it:

  • scans the repository structure
  • reads architectural patterns and conventions
  • captures key domain concepts and constraints

From there, the agent develops features with context instead of assumptions.

The power of AGENTS.md is that it grows with the project. Instead of repeating the same information in prompts, you add it once to this file - and every agent benefits from it on every feature.

Think of AGENTS.md as the place where the project teaches the agent how to behave. The richer this file becomes, the less you repeat yourself - and the more consistent the outputs across every end-to-end feature.

Final Note: Skills vs. MCP and Why You Need Both

There's a growing misunderstanding on X that skills will replace MCP, but that's far from true.

You might have heard of MCP (Model Context Protocol), another breakthrough from Anthropic. If Skills are the "instructions," MCP is the "infrastructure."

It is important to understand that Skills are not here to replace MCP. They work together.

The Technical Difference

  • MCP (The API Layer): Think of MCP as an API interface for LLMs. Instead of calling REST endpoints, the LLM calls tools, and those tools let it read, write, and interact with the real world in a controlled way.

  • Skills (The Local Context Module): Think of Skills as lazy-loaded prompts used for very specific tasks (e.g., testing, design, backend integration) that the agent loads only when needed to stay aligned with project rules.

The Bottom Line

When teams rely on vibe-driven coding, AI output drifts, requirements get re-interpreted, and features quietly diverge from how the system is actually supposed to behave. The way to fix that is not "more prompting" - it's structured context and spec-driven development.

By adopting a spec-driven development workflow you shift AI from improvisational coding to disciplined, constraint-driven execution. This is the approach that consistently delivers minimum drift, higher-quality outputs, and features that behave exactly as intended.

Here's the foundation of this workflow:

  • Spec-Driven Development (The "What") - Every feature begins with a clearly defined SPEC.md that captures requirements, constraints, edge cases, and data contracts. The spec becomes the single source of truth and prevents drift before implementation even starts.

  • Skills as Reusable Context (The "How") - Instead of repeating prompts, the agent loads structured SKILL.md definitions that encode domain rules, development conventions, and decision-making patterns. Skills ensure the agent reasons and executes consistently across features.

  • AGENTS.md as Project-Wide Context (The "Why & Where") - The agent reads the AGENTS.md file to understand the broader system: architecture, design principles, naming conventions, and integration boundaries. This gives the AI the project awareness it needs to produce output that fits the real codebase.

Together, these pieces give the agent rich, stable context - enabling feature development that is predictable, aligned with intent, and resistant to drift.

If you liked this article, consider checking my previous AI-related article:

Inside the AI Harness: Engineering Techniques for Predictable and Deterministic AI

Until next time - happy coding! 🧑‍💻