I started my career as a programmer using IEF — the Information Engineering Facility, Texas Instruments' implementation of James Martin's Information Engineering methodology. From there it was Composer, COOL:Gen, Advantage Gen, AllFusion Gen, CA Gen, and eventually just Gen. One product, four owners, seven names, and the same ambitious premise throughout: raise the abstraction level above code, model the business, generate the system.
Decades later, after a career in solution and enterprise architecture, always keeping pace with J2EE, .NET, frontend frameworks, and backend patterns, I've found myself doing something I never quite managed before: writing production-quality frontend code. Not because I suddenly found time to master React. Because of Claude Code.
The more I use it, the more it feels like CASE 2.0. The same ambition, finally delivered, but through a completely different mechanism. And with a risk the industry hasn't fully reckoned with yet.
What CASE Promised — and Mostly Delivered
Information Engineering was genuinely visionary. The core idea was that data structures are more stable than processes, so you model the data first and derive the processes from it. The IEF encyclopedia was a governed repository of everything the tool knew about your system: entity models, process models, action diagrams, stored as a single integrated source of truth. Objects defined during analysis carried forward into design without redefinition. The encyclopedia held the model; the code was generated from it.
The toolchain didn't stop at generation. Code generation was target-aware — the tool knew whether it was generating for a CICS region, a DB2 database, a batch JCL environment. Deployment wasn't an afterthought; it was part of the methodology. The chain ran from business model to running system, and the tool maintained awareness across the whole of it.
The generated code worked. It was often verbose, harder to read than hand-written code, and nobody really owned it. You maintained the model, not the output. But it compiled, it ran, and for enterprise systems at scale, that was what mattered.
CASE tools were trying to solve a real problem: how do you let people who think at the architecture level build systems without having to master every implementation detail? The answer in the 1980s and 90s was formal models and code generators. It was the right question. The answer was just too rigid.
What Claude Code Actually Delivers
Claude Code solves the same problem, but the abstraction layer is natural language rather than formal models. You describe what you want in terms of intent, context, and constraints, and it produces working code. The conversation replaces the model.
The output is readable, which matters more than it sounds. CASE-generated code was essentially write-once — you maintained the model, never the code. Claude Code produces clean, readable code you can actually own and modify. You can also push back in ways you never could with a code generator: "simplify this", "why did you add that layer?", "just do it directly." The conversation is the refinement loop.
It also teaches as it builds. One of CASE's quiet failures was that developers never really understood the generated code. Claude Code has been how I've finally internalised frontend patterns I never had time to master — seeing clean, well-structured React written in the context of my own problems, with the reasoning visible. And unlike the CASE encyclopedia, there's no proprietary lock-in. The code it produces is just code.
For someone with an architecture background who thinks in systems and integration patterns but couldn't always execute the frontend detail, Claude Code closes that gap. The abstraction has finally caught up to where the vision always pointed.
The Democratisation Problem
Here's where it gets uncomfortable.
CASE tools were powerful, but they were also gatekept. To get anything near production on an IEF project, you needed a trained IEF developer, a DBA, a systems programmer, and a mainframe operator. The barriers were high. The toolchain enforced discipline partly through its complexity — you couldn't accidentally deploy a half-finished system to a CICS region because you didn't know what a CICS region was.
Claude Code removes those barriers. That's the point. That's also the risk.
Anyone with enough domain knowledge to describe what they want can now produce working application code and IaC at pace. Domain experts are automating their own workflows. Architects are building frontends. Startups are shipping systems without hiring the specialists who would previously have been mandatory. And increasingly, there's no developer in the room at all — the business owner is the developer. Claude Code means you don't need to hand it to anyone, which is exactly when the discipline gap becomes most dangerous.
This is genuinely transformative. It's also genuinely dangerous, because the thing that previously enforced discipline was needing to involve people who knew what production-ready actually meant. That enforcer is gone.
Claude Code has no persistent system-wide awareness. What it knows is limited to what's in context for that session. If you don't explicitly provide your existing architecture, deployment state, and security posture, it has no visibility into any of them. The result is that application code and IaC can look perfectly reasonable in isolation while being inconsistent with what's already deployed: exposed ports, over-privileged service accounts, secrets in environment variables, missing audit logging. Not because the developer was careless, but because the tool had no visibility into the broader environment and the developer didn't know to provide it.
This is the gap the CASE toolchain never had. The encyclopedia, the code generator, and the target environment configuration were a single governed chain. Claude Code is a powerful generation capability, but generation only. The rest of the chain is your responsibility to assemble, and nothing will tell you if you haven't.
The Discipline Gap Is Structural
This isn't about experience level or intent. The gap is structural — it's built into how the tool works.
Claude Code removes the friction that previously made involving specialists mandatory. You no longer need a DBA to get a schema designed, a security engineer to review what you've built, or an infrastructure engineer to get something deployed. The tool handles enough of it that those conversations never happen. That's precisely the problem, because those specialists weren't just doing technical work — they were providing a governance layer. They were the people who asked what the blast radius of a change was, where the secrets were going, who had access to what.
Claude Code doesn't ask those questions. It answers the question you asked and moves on.
The faster it lets you move, the faster you can build something that looks finished but isn't safe. Because the code itself is clean and well-structured, there's no obvious signal that anything is wrong. The discipline gap isn't visible in the application layer. It's invisible until something goes wrong in production.
A Partial Answer Exists Today
There is a mechanism that helps. CLAUDE.md is a file Claude Code reads automatically at the start of every session — your persistent system context: architecture decisions, infrastructure guardrails, security rules, what already exists. Claude Code reasons within it rather than around it, which reduces the risk of producing code that's inconsistent with your environment.
But it's only as good as what you put in it. Knowing what to put in it requires exactly the kind of production systems experience that the democratisation argument says is no longer being invoked. It's a tool for people who already know what discipline looks like, not a substitute for that knowledge.
That topic warrants its own treatment. The next post in this series looks at how to structure a CLAUDE.md as a governance instrument, not just a project readme.
CASE 2.0 — Unfinished Business
The CASE era ended partly because the tools were too rigid and the methodologies too slow for the agile movement that followed. It also ended because the encyclopedias were proprietary silos — they knew your system, but only within their own walls, and they didn't survive the shift to distributed, cloud-native architecture.
Claude Code is a generation tool, not a governed repository, and that comparison only goes so far. But the gap is real regardless of how you frame it. No single tool today gives you natural language generation and persistent, governed awareness of the full system. Those capabilities exist separately. Assembling them into a coherent chain is still the practitioner's job.
Until that changes, the responsibility sits with the person holding the keyboard. Use AI responsibly — know its limits and yours!
Shaun Crouch is the founder of Pragmatix, a Brisbane-based digital transformation consultancy. His career spans programming, solution architecture, and enterprise architecture across healthcare, government, and financial services. Pragmatix helps organisations adopt AI-assisted development practices with the governance and architectural discipline that production systems demand.
Pragmatic Agentic AI — Shaun's free eBook on building autonomous AI systems pragmatically — is available at pragmatix.com.au/agentic-ai. The Pragmatix Advisory Portal at portal.pragmatix.com.au provides access to expert AI advisors for governance, cyber security, and solution architecture.