Three Types of AI Work in Software Development (And the one I think we should master)

We’re all using AI to code faster. GitHub Copilot suggests lines, Claude helps debug, ChatGPT explains complex concepts. But that’s just scratching the surface of how AI intersects with software development.

After spending months working with various AI tools and building AI-integrated applications, I’ve realized there are actually three distinct categories of AI in software development. Understanding these categories changes how you think about learning AI and where the industry is headed.

The Three Categories

Let me break this down the way I wish someone had explained it to me:

Category 1: AI Tools for Traditional Software Development

This is where most of us are today. You’re building a regular iOS app, a web service, or a backend system. AI is your coding assistant. It helps you write Swift code, suggests React patterns, debugs your SQL queries. The final product has zero AI in it. It’s just a normal app that tracks expenses, manages inventory, or processes payments.

Think of it like using an IDE with really smart autocomplete. The software you ship doesn’t care that AI helped build it. Users never interact with AI. Your expense tracker is still just Swift code hitting a SQLite database.

Examples: Using Claude Code to build your app, Copilot suggesting function implementations, Gemini Flash helping refactor legacy code.

Category 2: Software That Integrates AI Capabilities

Here, you’re building traditional software but adding AI as a feature. Your app works without AI, but AI makes it better. You call APIs like OpenAI, Claude, or Gemini to add intelligent features. Or you embed local models to enhance functionality.

A customer service platform that uses AI to draft responses. A code review tool that uses AI to suggest improvements. A photo app that uses AI to generate captions. An expense tracker that uses AI to categorize transactions and answer natural language queries about spending patterns.

The AI isn’t the product. It’s a capability that enhances your product.

Category 3: Building AI Systems Themselves

This is deep learning engineering. You’re training models, fine-tuning architectures, building the next ChatGPT or Midjourney. You’re working with neural networks, gradient descent, training pipelines, and MLOps infrastructure. The AI model is your product.

Building recommendation engines from scratch. Creating computer vision systems for manufacturing defect detection. Training language models for specific domains. This requires deep ML expertise and significant computational resources.

Why Category 2 is Where the Action Is

Let me be direct: I believe Category 2 is the future of mainstream software engineering. Not because the other categories don’t matter, but because this is where practical innovation happens at scale.

Category 1 is table stakes now. Every developer will use AI assistants. It’s like saying you use Stack Overflow or Google. Of course you do. But it doesn’t fundamentally change what you’re building.

Category 3 is specialist territory. Most companies won’t train their own models. They’ll use existing ones. Building AI from scratch requires ML PhDs, expensive infrastructure, and massive datasets. It’s important work, but it’s not what most software engineers will do.

Category 2 is where software engineering is heading. Every application will integrate AI capabilities. Not as a gimmick, but as core functionality that users expect. The question isn’t whether to add AI features but how to do it well.

Think about it: five years ago, adding real-time sync to your app was advanced. Now it’s expected. Video calls? Once cutting-edge, now basic. AI features are following the same path. Users will expect apps to understand natural language, provide intelligent suggestions, and adapt to their behavior.

The difference is you don’t need an ML PhD to do this well. You need to understand how to integrate AI capabilities thoughtfully, handle the tradeoffs, and build reliable systems around unpredictable AI models.

What Category 2 Actually Involves

When you start building Category 2 applications, you realize there’s a whole new set of patterns and practices to learn:

Embeddings and vector search let you build semantic search over your data. Instead of keyword matching, users can find information by meaning.

RAG (Retrieval Augmented Generation) lets AI answer questions based on your specific data rather than just general knowledge. You’re not asking ChatGPT trivia. You’re asking about your company’s documents, your user’s transaction history, or your product’s specific features.

Function calling and tool use turn AI from a chat interface into an intelligent orchestrator. The AI can query databases, call APIs, perform calculations, and chain operations together based on user intent.

Agentic workflows let AI accomplish complex tasks autonomously by breaking them into steps, using tools, and adapting based on results.

Prompt engineering and orchestration become crucial skills. How you structure prompts, manage context, and handle errors determines whether your AI features work reliably or frustrate users.

These aren’t academic concepts. They’re practical patterns that real applications need. And they’re distinct from traditional software engineering. You’re dealing with probabilistic systems, not deterministic ones. Your function might return different results for the same input. Your carefully written code might fail because the AI misunderstood something.

The Real Challenges

Building Category 2 applications isn’t just about calling an API. You face challenges traditional software engineering didn’t prepare you for:

Privacy and security matter differently when you’re sending user data to AI services. Can you anonymize it? Should you use on-device models? How do you handle sensitive information?

Cost management becomes critical when every user interaction might trigger multiple API calls at $0.01 each. A viral feature could bankrupt you.

Reliability is tricky when you can’t predict exact outputs. How do you test AI features? How do you detect when the model is confused or hallucinating?

User experience needs rethinking. How do you handle AI latency? What do you show when the AI is processing? How do you let users correct AI mistakes?

Architecture decisions have new dimensions. On-device versus cloud? Which model for which task? How do you chain operations? When do you fall back to deterministic code?

Where Category 2 Gets Interesting

The exciting part is that Category 2 work combines traditional software engineering with AI capabilities. You’re not training models from scratch, but you’re not just prompting ChatGPT either. You’re building systems.

You might use RAG to let users search their documents semantically. Function calling to let AI interact with your database. Embeddings to find similar items. Agents to automate complex workflows. All while handling the traditional concerns of scalability, reliability, security, and user experience.

Your DevOps background matters. Your API design experience matters. Your database skills matter. But now you’re adding AI orchestration, prompt engineering, and vector databases to your toolkit.

A Concrete Example: Beyond Simple AI Features

Let me ground this in something practical. Imagine building a financial application where users can ask questions about their spending.

Category 1 approach: You use Claude to help write the code faster. The app has traditional filters and reports. AI was your development assistant.

Category 2 approach: Users ask natural language questions like “Why was February expensive?” Your app:

• Uses embeddings to understand the question semantically
• Retrieves relevant transaction data (RAG)
• Calls functions to calculate totals and identify patterns
• Uses an LLM to generate a natural explanation
• Maybe uses an agent to dig deeper if needed

The app still has traditional features (budgets, categories, charts) but AI makes it genuinely more useful. Users don’t need to learn your interface. They just ask questions.

Category 3 approach: You’re training a specialized financial AI model from scratch. This is overkill for most applications.

See the difference? Category 2 is where practical innovation happens for most products.

The On-Device versus Cloud Decision

One of the first real decisions you face in Category 2 work is whether to use on-device models or cloud APIs. This isn’t just a technical question. It affects privacy, cost, reliability, and user experience.

On-device models run locally on the user’s phone or computer. No data leaves the device. No API costs. Works offline. But they’re smaller, less capable, and can’t handle complex tasks reliably yet.

Cloud models are powerful and reliable. They can orchestrate complex workflows, understand nuanced requests, and generate high-quality responses. But they cost money per call, require network connectivity, and mean user data leaves the device.

The tradeoff isn’t obvious. For simple tasks like text generation or classification, on-device might be fine. For complex orchestration where reliability matters, cloud is safer. For many applications, a hybrid approach makes sense: on-device for common cases, cloud for complexity.

Let me be specific about one challenge: function calling orchestration.

When you expose functions your app can perform (query database, calculate totals, create charts), can an on-device model reliably decide which functions to call and in what order?

For simple cases, maybe. “Show me January expenses” is straightforward enough. But “Which category am I overspending on, and what are the biggest transactions there?” requires multi-step reasoning: query categories, fetch budgets, compare spending, identify problems, then fetch detailed transactions for that category.

On-device models struggle with this kind of orchestration. They lose track of state, hallucinate parameters, or skip steps. Cloud models like Claude or GPT-4 handle it reliably because they’re specifically trained on function calling datasets.

This matters because it affects your architecture. Do you use on-device models with hardcoded workflows? Hybrid routing where simple queries stay local? Pure cloud with privacy safeguards? Each choice has implications for user experience, cost, and privacy.

Learning Category 2 Skills

If you’re convinced that Category 2 is worth learning (and I hope you are), where do you start?

The learning path is different from traditional software development. You need to understand:

Embeddings and vector databases: How text becomes numbers, why that enables semantic search, and how to work with vector stores like Pinecone or Chroma.

RAG patterns: How to give AI access to your specific data, chunk documents effectively, retrieve relevant context, and generate accurate answers.

Function calling: How AI decides which tools to use, extracts parameters, chains operations, and handles results.

Prompt engineering: How to structure prompts for reliability, handle edge cases, and get consistent outputs from probabilistic models.

Frameworks: LangChain for orchestration, LangGraph for explicit control flow, MCP for standardized tool access.

Agentic patterns: How to build AI that autonomously accomplishes goals by using tools, reasoning about results, and adapting its approach.

But here’s the key: you learn by building. Pick a project in a domain you understand. Add AI features incrementally. See where models excel and where they fail. Build guardrails. Handle errors. Measure reliability.

Your existing software engineering skills give you a huge advantage. You know how to build reliable systems, handle edge cases, design APIs, and think about users. You’re adding AI as a capability, not learning programming from scratch.

The Practical Reality

Let me be honest about something: building Category 2 applications is messy right now. The tools are evolving fast. Best practices are still emerging. What works today might be obsolete in six months.

But that’s also the opportunity. We’re figuring out patterns that will become standard practice. How to test AI features reliably. How to handle costs at scale. When to use on-device versus cloud. How to chain operations efficiently. What users actually want from AI features versus what’s just hype.

If you start learning now, you’re not behind. You’re early. Most developers are still in Category 1, using AI as a coding assistant. Some are chasing Category 3, trying to train models they don’t need. The pragmatic middle ground of Category 2 is wide open.

Where This is Headed

I believe in five years, integrating AI capabilities will be as fundamental as working with databases or calling APIs. Every software engineering role will involve some Category 2 work. Job descriptions will expect you to know about embeddings, RAG, and prompt engineering like they expect you to know SQL and REST APIs today.

The applications that win won’t be the ones with the most AI. They’ll be the ones that integrate AI thoughtfully to solve real problems. That understand when to use on-device models for privacy and when cloud makes sense for reliability. That handle AI failures gracefully. That make AI features genuinely useful rather than just impressive demos.

This is software engineering evolving, not being replaced. You’re building better applications by adding intelligence as a capability. Your product knowledge, domain expertise, and engineering judgment matter more than ever because you’re deciding how to use these powerful but unpredictable tools effectively.

What’s Next

If Category 2 interests you, start small. Pick a side project. Add semantic search over some documents. Build a simple chatbot that can query your database. Experiment with function calling. See where models excel and where they frustrate you.

Don’t wait for the perfect moment or the perfect tools. The learning happens in the building. Every failed experiment teaches you something about working with probabilistic systems. Every successful feature gives you confidence in patterns that work.

And as you learn, share what you discover. Write about the tradeoffs you face. Document the patterns that work. We’re all figuring this out together. The developers who contribute to this emerging body of knowledge will shape how software engineering evolves.

The future isn’t AI replacing developers. It’s developers building smarter software by thoughtfully integrating AI capabilities. That’s Category 2. That’s where the interesting work is happening.

What are you building? I’d love to hear about your Category 2 projects and what you’re learning along the way.