Understanding Why AI Development Struggles with PeopleSoft

The same thing that made PeopleSoft successful also makes it hostile to AI-assisted development.

PeopleSoft’s architecture is “low-code” and database-centric, and that was a deliberate choice. Decades ago, when almost nobody had a clean story for code deployment, PeopleSoft did. Objects live in the database. App Designer and project copy made moving them between environments routine. That was a real strength, and it’s a big part of why the platform has lasted this long in higher ed and elsewhere. That was a good design for the time, and it still works well for the platform’s core use cases. This was all developed before Git, Github and modern version control practices were widely adopted. The platform was designed to be a system of record, not a system of iteration.

But that same design, with everything in the database and almost nothing meaningful on disk, is exactly what modern AI code generation cannot currently do well. There is a proprietary IDE with lack of version control, no meaningful diff, and no cheap rollback. The IDE cannot be driven by an AI agent.

Additionally, the frontier models that power AI code generation are trained on text, not database rows. They are trained on GitHub, Stack Overflow, and other sources of text-based code. PeopleSoft’s database-centric architecture is simply not what these models were trained to work with. There are scant examples of PeopleSoft code in the training data, and the models have no understanding of the platform’s unique architecture. There are under 20 quality Blogs/knowledge bases on the web that discuss PeopleSoft development, and the models have no way to know which of those are authoritative. The result is that the models are not well-equipped to generate code for PeopleSoft, and they cannot iterate on their own in a meaningful way. What about PeopleBooks? Don’t get me started on that topic. 😢 It is extremely hard to train a new PeopleSoft developer to become productive without hands-on experience and guidance from seasoned developers which can take years for them to truly understand best practices and the many paths to problematic approaches.

How LLMs actually write code

The reason AI coding tools work isn’t that the model gets it right the first time. It almost never does. What makes them useful is the loop around the model: iterate quickly, branch to try an idea, use a work tree to compare approaches, roll back a bad change, inspect the diff, and search commit history for the regression. Increasingly, the model or the coding harness around it does this on its own. It commits, checks its diffs, bisects history, and reverts mistakes and writes tests.

That entire workflow assumes one thing: your code is text, on disk, under version control.

  gitGraph
    commit id: "Initial code"
    branch experiment-1
    checkout experiment-1
    commit id: "Try approach A"
    commit id: "Refine A"
    checkout main
    branch experiment-2
    checkout experiment-2
    commit id: "Try approach B"
      branch experiment-3
    checkout experiment-3
    commit id: "Try approach C"
    checkout main
    merge experiment-2 tag: "B worked!"
    commit id: "Add tests"
 

In file-based development, branching and experimenting is cheap and fast. AI tools leverage this constantly.

PeopleSoft breaks the loop

In PeopleSoft, most of what you’d want to change isn’t text on disk. It’s configuration stored as rows in the database. PeopleCode you can sort of get away with because it is text, so you can extract it, diff it, even merge it by hand. But everything around it like service operations, pages, components, and especially Fluid pages for mobile is config living in the database. There’s no meaningful diff. There’s no branch. There’s no work tree. There’s no cheap rollback.

  graph TD

        AD[App Designer]
        AD --> PC[PeopleCode] --> DB[PeopleCode<br/>config in DB rows]
        AD --> SVC[Service Operations] --> DB[Service Operations<br/>config in DB rows]
        AD --> PG[Pages/Components] --> DB[Pages/Components<br/>config in DB rows]
        AD --> FP[Fluid Pages] --> DB[Fluid Pages<br/>config in DB rows]

    
        DB[(Database)]    

         A@{ shape: brace-l, label: "Coding is tedious 'clicking of boxes' in App Designer" }

    style DB fill:#cce5ff
    style AD fill:#ccffcc
  

To experiment safely in PeopleSoft, you stand up a separate database: a full clone. There is no lightweight local sandbox or ephemeral environment you can spin up in seconds, and no branch to throw away when an idea doesn’t pan out. Once the change works in that clone, there’s no clean merge back. You migrate the whole object, configuration included.

Now drop an LLM into that loop. The model wants to try five variations of a Fluid page. In PeopleSoft, each attempt is a full-clone-and-migrate cycle. You can’t realistically A/B test two implementations, and there is no history to bisect when a page breaks. The tight, cheap iteration loop that makes AI coding tools valuable simply doesn’t exist here.

And then there’s the web

It gets harder at the presentation layer. The web frameworks, CSS frameworks, and baseline user expectations that define a modern web application are simply not available inside PeopleSoft. It’s not that they’re hard to use there — they don’t fit at all:

• You don’t own the HTML. PeopleSoft generates the markup and stylesheets from component definitions. Modern CSS frameworks like Bootstrap or Tailwind assume you control the page structure. You can’t drop one in; you can only fight the generated output with override styles.
• No modern interactivity. Users now expect live search, instant validation, drag-and-drop, and screens that update without a full page round trip. PeopleSoft’s request/response model and JavaScript restrictions make these patterns somewhere between painful and impossible.
• No component ecosystem. Elsewhere, a date picker, a chart, or a data table is an import away, with thousands of maintained options. In PeopleSoft you get what the tools render, and extending it means hacking around the framework rather than working with it.

Even if you solved the iteration problem, you’d still be asking an AI to generate against a target that can’t express most of what modern web development takes for granted. AI models have seen millions of examples of standard HTML, CSS, and JavaScript; almost none of that knowledge transfers into PeopleSoft’s rendering model.

What about Oracle’s LLM?

Oracle has signaled that a PeopleSoft LLM is coming, starting with read-only capabilities. I’ll be honest: I’m skeptical it changes the fundamental picture. Read-only help that summarizes configuration or answers questions about an environment is genuinely useful, but it doesn’t touch the core problem. The issue was never that the model can’t see your PeopleSoft objects. The platform gives neither the model nor the developer a place to iterate, branch, diff, and roll back the way AI-assisted development requires.

I hope I’m wrong about this, and I’d like to be proved wrong. If Oracle ships something that makes PeopleSoft objects behave like versioned, diffable, branchable artifacts, that would be a big deal. But I’m not betting on it.

That said, the read-only side is real and useful today, and it’s where I’m building. psLens reads PeopleSoft data and metadata and serves it to an LLM as Markdown — no writes back into the system, no App Designer involved. It’s a practical example of what read-only AI access to PeopleSoft looks like right now, without waiting on Oracle.

One Path Through

Here’s the more hopeful part, and the subject of a follow-up post. You don’t have to make PeopleSoft itself AI-friendly to get the benefits of AI. Keep PeopleSoft as the system of record, expose it through APIs, which is what I built the SWS framework to do, and build user-facing work in a modern stack where AI code generation fits. In my case I’ll recommend a hypermedia approach , but there are other options. That’s how psLens is structured . For a detailed look at how to connect AI agents to PeopleSoft using SWS , I’ve documented the pattern in a separate post.

  graph LR
    subgraph PS["PeopleSoft Core"]
        DB[(System of Record)]
        SWS[APIs<br/> Consider SWS]
        DB --> SWS
    end
    
    subgraph MOD["Modern Layer Outside of PeopleSoft"]
        VC[Git<br/>Version Control]
        CODE[Text Files<br/>Hypermedia]
        AI[AI Code Gen<br/>Fast Iteration]
        
        VC <--> CODE
        CODE <--> AI
    end
    
    SWS -->|JSON/REST| CODE
    
    style MOD fill:#ccffcc
    style PS fill:#cce5ff

The hybrid approach: PeopleSoft stays as the system of record, modern AI-friendly development happens in a separate layer.

The point is straightforward. When user-facing code is text on disk under version control, the AI workflow comes back: branches, work trees, diffs, rollbacks, and history. PeopleSoft keeps doing what it does well. The modern layer can work the way current AI tooling expects.

More on that in the next post.