The New Full-Stack Developer: Building Applications for Humans, AI Assistants and Autonomous Agents

We’re kicking off a new series, AI Engineering Basics: From Full-stack Developer to AI Engineer. First, explore how the full-stack role is evolving and map out the skills that matter next.

The full-stack developer role has never stood still. Many of us started out rendering pages on the server, then learned to build single-page applications when the frontend exploded in complexity.

We picked up REST and GraphQL as APIs became products of their own. And we absorbed containers, CI/CD and cloud deployments when “you build it, you run it” became the norm. Each shift added a new layer to the job, and each time the developers who adapted came out ahead.

AI is the next in this series of shifts, but it’s different in an important way. Previous shifts changed how we build applications. This one also changes who (or what) uses them. The applications we build today are increasingly used not just by people clicking through a UI, but by AI assistants acting on a person’s behalf and by autonomous agents completing entire workflows on their own.

That’s the core idea behind this series, AI Engineering Basics: From Full-stack Developer to AI Engineer. AI isn’t replacing application development. It’s changing what applications are, who consumes them and what we as developers are responsible for. In this first article, we’ll look at how the full-stack role is evolving, clarify the difference between AI-powered apps, assistants and agents, and map out the skills that matter next.

AI-Powered Applications Are Becoming the Default

Not long ago, adding AI to an application meant one of two things: a recommendation engine built by a specialized machine learning team, or a chatbot bolted onto the corner of the screen. That has changed quickly.

With large language models (LLMs) available behind simple APIs from providers like OpenAI, Anthropic and Google, intelligent features are now something any full-stack developer can ship.

An AI-powered application is one where a model participates in the application’s core functionality rather than sitting off to the side. Some familiar examples:

• Conversational interfaces that let users ask questions in natural language instead of navigating menus and filters.
• Retrieval-augmented features that ground model responses in the company’s actual documentation, data or policies (a pattern known as RAG, or Retrieval-Augmented Generation, which we’ll cover in depth later in this series).
• Intelligent workflows that summarize, classify, extract or generate content as part of an existing process, like triaging support tickets or drafting a first pass of a report.
• Adaptive interfaces that reshape what’s on screen based on what the user is trying to accomplish.

The 2025 Stack Overflow Developer Survey found that 84% of developers are using or planning to use AI tools in their workflow. The same transformation is happening to the applications we ship. Users who talk to ChatGPT every day increasingly expect the software they use at work to understand natural language, remember context and do more of the work for them.

For full-stack developers, this is good news. The skills required to build these features (API integration, state management, data modeling, UX judgment) are the skills we already have. What’s new is the layer of model-related decisions sitting on top, and that’s what the rest of this series is about.

Assistants vs. Agents

Two terms come up constantly in this space, and they’re often used interchangeably when they shouldn’t be: assistants and agents.

An AI assistant helps a human do their work, one exchange at a time. The human asks, the assistant responds, and the human decides what happens next. A chat interface that answers questions about your product documentation is an assistant. So is the autocomplete in your editor. The defining trait is that a person stays in the loop for every meaningful step.

An autonomous agent is given a goal rather than a question. It plans the steps needed to reach that goal, uses tools to act (calling APIs, querying databases, updating records), evaluates the results and adjusts until the task is done. The human sets the objective and reviews the outcome, but the intermediate steps happen without them.

The table below summarizes how the two compare:

In practice, the line between the two blurs. Many products start as assistants and gain agent-like capabilities over time, like a support assistant that first only answers questions, then later gains the ability to issue refunds within a set limit.

Understanding where a feature sits on this spectrum matters, because the engineering demands (tooling, permissions, oversight, error handling) grow significantly as autonomy increases.

Our Users Are No Longer Only Human

The bigger shift, and the one this series is named after, is about who we build for. For the entire history of web development, we’ve built applications with one type of consumer in mind: a person looking at a screen. That assumption no longer holds. The applications we build now have three distinct types of consumers:

1. Humans, interacting through the UI the way they always have.
2. AI assistants, acting on a human’s behalf: answering questions about the app’s data, filling in forms or navigating flows for a user.
3. Autonomous agents, completing tasks end to end: an agent might book the meeting, file the expense report or reorder the inventory without a person touching the interface at all.

This changes how we design applications in concrete ways. A dropdown menu is self-explanatory to a human, but an agent needs to know what the options mean and what selecting one will do. A multistep wizard guides a person nicely, but an agent would rather skip the screens entirely and perform the operation directly. In other words, agents care less about our UI than about the capability behind it.

That’s the thinking behind structured actions: taking an operation that currently lives inside click handlers and form submissions and exposing it as a clearly defined, callable action with a name, a description and typed parameters. The description matters as much as the types, because it’s how a model decides when the action applies and what its limits are.

A structured action for a refund flow might look like this:

{
  "name": "create_refund",
  "description": "Issue a refund for a customer order. Refunds over $500 require human approval.",
  "parameters": {
    "order_id": { "type": "string", "description": "The order to refund" },
    "amount": { "type": "number", "description": "Refund amount in USD" },
    "reason": { "type": "string", "description": "Why the refund is being issued" }
  }
}

Nothing about this schema is unfamiliar. It’s the same discipline we already apply to good API design, applied to a new consumer.

Notice too that the description encodes a boundary (refunds over $500 require human approval), which points at the other half of designing for agents: permissions. An agent operating with a user’s full credentials is a serious liability, so autonomous consumers need scoped access and explicit limits on what they can and cannot do.

Standards are also emerging to make these connections consistent, most notably the Model Context Protocol (MCP), which gives models a standardized way to discover and use tools and data sources. We’ll dedicate a full article to MCP later in this series.

From Full-Stack Developer to AI Engineer

Where does all of this leave the full-stack developer? The answer isn’t a career change. It’s an expanded surface area, the same way frontend developers absorbed build tooling and backend developers absorbed infrastructure. The AI Engineer is a full-stack developer who has added a set of model-related responsibilities to their existing ones.

The encouraging part is that most of these responsibilities build on skills full-stack developers already have:

Notice what’s missing from all of this: training models, designing neural network architectures or anything that requires a research background. AI Engineering is an integration discipline. The models are built by someone else, and our job is to build reliable, trustworthy applications around them.

What’s Ahead in This Series

This article is the starting point for a series that will take these ideas from concepts to working systems. Upcoming articles will cover five broad areas:

• AI foundations: The modern AI stack (LLMs, embeddings, vector databases, RAG, agents, orchestration), how AI-powered applications are architected and why prompt engineering alone isn’t enough.
• AI-powered applications: Designing AI-native user experiences, building agent-ready interfaces and patterns for human-agent collaboration.
• Agent engineering: What makes an application agentic, giving agents tools, memory patterns, planning and reasoning, and single-agent vs. multi-agent systems.
• AI operations: Why most AI demos fail in production, understanding token costs, evaluation, observability, security and governance.
• AI-powered development: How coding assistants and agents are changing the way we build software itself.

Wrap-up

The full-stack role isn’t going anywhere, but it is expanding again.

The applications we build are gaining intelligent features as a baseline expectation, and they’re gaining new consumers: assistants acting on behalf of our users and agents acting on their own. Developers who treat AI as a new layer of the stack to master, the same way we once mastered the frontend, the API layer and the cloud, will be well positioned for what comes next.

You don’t need to become a machine learning researcher to make this transition. You need to understand how models behave, how to connect them to your data and your actions safely and how to apply the engineering judgment you already have to a new class of systems. That’s what this series is here to help with, one topic at a time.

For more on how Progress is approaching AI-powered application and agent development, check out the following resources:

• Progress AI Engineering Solutions
• Progress Software: AI-Powered Applications
• Progress Agentic RAG