Developer Agent is now generally available. Intuit’s Sreenivas Raman shares how it’s changing where he spends his engineering time—shrinking the distance between an idea and an experiment while letting him focus more on architecture, judgment, and what to build next.
In this article we discuss:
At Rising 2026, Workday announced that Developer Agent is generally available.
The news caught my attention because I’ve been building in the Workday developer ecosystem for years, particularly with Workday Extend. As a Workday Developer MVP and an active contributor to the developer community and forums, I’m probably not the person you’d picture needing an AI agent to teach them the basics of Extend. That’s exactly why I was curious.
General-purpose AI coding assistants were already part of the landscape. When Workday first introduced Developer Agent, I was interested in a more specific question: what happens when you give an AI development partner with Workday context to someone who already knows the platform? And does it actually change how an experienced developer works?
At the June DevCon hackathon, my team built Lighthouse, an Extend application that served as a multi-agent early-warning system. It pulled together Workday signals, ran them through several focused agents and a synthesizer, and turned the results into actionable insights. It was ambitious for a hackathon: an Extend experience, multiple agents, orchestration, data modeling, and a workflow running from signal to human action.
We used Developer Agent to build the Extend side through App Builder and Claude, and experimented with agents and skills. But what I remember most isn’t an artifact or code it generated. It’s how quickly we moved from an ambitious idea to something we could build, inspect, demonstrate, and evaluate.
That’s one of my biggest takeaways so far: Developer Agent lowers the cost of experimentation.
Developers have ideas all the time. Traditionally, there can be a large distance between saying, "I wonder if this could work," and having enough built to find out. There’s data modeling, scaffolding, documentation, APIs, implementation, debugging, and all the other mechanics of turning an idea into software. When that loop speeds up, ideas that might have remained on a backlog become ideas you can prototype and evaluate.
The distance between "I wonder if this could work" and "let's build enough of it to find out" has become much smaller.
Scaffolding is one place where Developer Agent saves time. But saying "it generates scaffolding faster" dramatically understates the value, particularly for an experienced developer.
The bigger benefit is everything surrounding implementation. I might need to understand an unfamiliar section of an application, explore an approach, remember the right Workday construct, compare options, understand an error, generate an initial implementation, or iterate on something I already built.
Traditionally, each of those moments can break context: leave the development environment, search documentation, find an example, search the developer forum, read several things, come back, reconstruct the context in my head, and continue. Developer Agent allows more of that discovery to happen inside the development loop.
What I notice most is developer flow. I spend more time thinking about the problem and less time servicing the mechanics around the problem.
I spend more time thinking about the problem and less time servicing the mechanics around the problem.
Developer Agent isn’t just helping me type faster; It’s helping me stay in the engineering problem longer.
AI development tools make people think about generating something new. But one of the most useful things to ask Developer Agent is: "Explain this."
Enterprise developers don’t spend all of their time on greenfield applications. We inherit applications, modify things somebody else built, and revisit something our own team built months ago. Occasionally, we look at something we personally wrote six months earlier and wonder why we did it that way.
Being able to interrogate an application is powerful: What does this section do? Where is this data coming from? What depends on this? What happens when this action executes? Why might this have been implemented this way?
As an experienced developer, I’m not asking the agent to make the engineering decision for me. I’m using it to compress the time required to build the context I need to make that decision myself.
As an experienced developer, I’m not asking the agent to make the engineering decision for me. I’m using it to compress the time required to build the context I need to make that decision myself.
Developer Agent makes the entry point into Workday development easier. A new developer to Extend may already know how to program. What they don’t yet have is the mental map of the platform: the terminology, the patterns, how the pieces fit together, where to find things, and what question to ask.
Developer Agent makes that learning process more interactive. Instead of being handed an existing application and told, "Go learn this," developers can interrogate it: “Explain what this application does.” “Walk me through this page?” “Where does this data come from?” “Why is this implemented this way?” “What would happen if I changed this?”
For an experienced developer, the conversation changes. I’m less likely to ask, "How does this work?" and more likely to say, "Here is what I am trying to accomplish. Help me get there, show me the tradeoffs, and let me iterate quickly." Expertise doesn’t reduce the agent’s usefulness. It changes what I ask the agent to do.
For a new developer, Developer Agent accelerates understanding. For an experienced developer, it accelerates execution.
For a new developer, Developer Agent accelerates understanding. For an experienced developer, it accelerates execution.
Developer Agent doesn’t replace mentoring; it can make mentoring more effective. If the agent can answer many of the small contextual questions immediately, limited time with an experienced engineer can move from "Where do I find this?" to "Is this the right design?"
There’s an important distinction between generating something that works and engineering something that belongs in an enterprise.
Getting to a working implementation is only part of the job. Data modeling still matters. Security and privacy still matter. Performance and maintainability matter. Understanding the business process matters. Knowing where AI should—and shouldn’t—be used matters.
Because I understand Extend and the platform, I can describe what I want more precisely. I can evaluate an approach Developer Agent proposes, recognize when something doesn’t look right, and redirect it. I can also spend more attention on architecture, security, and user experience.
My attention moves higher in the stack. Instead of spending all of it on "How exactly do I construct this?" I can spend more on "What should I construct, and why?"
When you lower implementation costs, good architecture becomes more valuable.
Developer Agent can help you build the right thing faster. But speed doesn’t replace judgment about what to build. The developer still owns the data model, security boundaries, privacy decisions, performance considerations, and judgment about how the pieces fit together.
Initially, I approached Developer Agent entirely through the lens of an Extend developer: can this help me build an Extend application faster?
After working with agents and skills, I started asking a different question: what capability am I actually building?
In Lighthouse, we didn’t create one giant agent and ask it to reason about everything. We used smaller, focused agents with clear responsibilities and composed their outputs through a synthesizer. That architecture was easier to reason about, test, tune, and explain. It reinforced something familiar from traditional engineering: good agent architecture looks surprisingly similar to good software architecture—focused responsibilities, clear contracts, and composition.
Now I think beyond pages and applications. A capability might be implemented through code, represented as a skill, exposed through a tool, used by a focused agent, composed with other agents, or presented to a human through an Extend experience. The application still matters, but it may be one consumer of a broader capability.
The definition of a Workday developer is expanding. For years, we’ve built applications, integrations, and experiences around Workday, and now AI helps us build them faster. But another layer is emerging: capabilities consumed not just by humans, but by agents.
That’s why I am excited about Developer Agent. Faster scaffolding is useful. Code generation is useful. Staying in flow is useful. But those may turn out to be the least interesting consequences. Developer Agent gives us a chance to rethink how Workday software is built, how developer expertise is reused, how quickly we can evaluate ideas, and what developers spend their time doing.
I’ve spent years learning how to build on Workday. Now I am increasingly interested in what it means to build on Workday when the developer isn’t the only one writing—and the human isn’t the only one consuming—what we create.
Ready to try Developer Agent yourself? Join the Workday Developer Program to build with it today, in your very own Workday tenant.
Workday customers get access to Developer Agent through Workday Extend AI.
More Reading
Workday is opening its platform to every builder. Build your first enterprise agent in minutes with Developer Agent, get your own development tenant (beta), and build your career and business in a thriving global ecosystem.
At Workday Rising, we announced that Agent Passport is in early access. Instead of asking whether an agent is safe, IT teams can now check a signed record of what it was tested for, by whom, and to what standard. Watch a quick demo.
Today, Workday is announcing Workday Data Cloud, a new architecture that opens the System of Record directly to AI agents—which means teams no longer have to extract data, duplicate it, or rebuild security.
