What Is an IDE? And What Domain Experts Need When AI Writes the Code

I came to programming late. I was trained as a research chemist, and I learned to code on the job at several companies, as what is now called a citizen developer or citizen data scientist. That was long before generative AI. The learning curve was steep. The hardest part was learning to structure code so that others could use it, and to work iteratively towards something maintainable and scalable instead of scripts that only worked for me. I had no formal training in how code is developed, maintained and shared, and the tools assumed I had.

Subject matter experts now face a new version of that problem. A coding agent can write the code for them in minutes, but the IDE it works in was built for developers, and most of what happens there means little to someone who has never maintained code. Give the agent a request with no context and no framework to start from, and it fills the gaps with its own assumptions.

People who build software are not one group. Professional developers should keep their IDE, and with the right extensions it can become their path to deployment too. Then there are the people who don’t read code but still build applications that add value through their expertise. What they build has to be something IT can pick up and maintain from the source code. For them, the environment has a different job: making the right way of doing things the easy way. And the people best placed to build that environment are the developers themselves.

This article starts with the short answer to what an IDE is, then looks at what domain experts actually need when an AI agent writes the code.

What is an IDE?

An IDE, or integrated development environment, is software that brings the tools for writing, running, testing and debugging code into one application. Instead of switching between a text editor, a terminal and a debugger, a developer does all of it in one place. Visual Studio Code, PyCharm and JupyterLab are common examples.

What does an IDE include?

Most IDEs combine the same core tools:

• A code editor with syntax highlighting, autocompletion and error hints as you type.
• Build and run tools that compile or interpret the code without leaving the application.
• A debugger that pauses a running program so you can inspect values and step through it line by line.
• Version control, usually Git, to track changes, compare versions and merge work from colleagues.
• A terminal, plus extensions for languages, frameworks and cloud services.

Common examples are Visual Studio Code, JetBrains IDEs such as PyCharm and IntelliJ IDEA, and JupyterLab for notebook-based data work.

All of them assume the same user: a developer who writes the code, understands it and is responsible for it.

What changes when an AI agent writes the code

Recently I’ve sat in first meetings with IT and data leaders at several large Nordic organisations. Every one of them had rolled out Copilot, and most had Claude Code or Codex in pilots. None needed convincing that agents can write code. They were all stuck at the same step: experiments that work but can’t go into production. The concern I heard most was concrete. IT expects to inherit whatever gets built.

They are right to worry. When a domain expert directs an agent without a framework, a predictable set of things goes wrong:

• Business logic gets invented. The agent fills gaps with its own definition, calculation or version of a rule the organisation already has. The app looks right, so wrong numbers can drive decisions for months.
• Every app is built differently. Ask for the same app twice and you can get two different stacks. IT can’t maintain dozens of one-off designs.
• Access gets widened. Credentials land in the code, or the app gets broader data access than its users have.
• Nobody defined done. Without a written statement of what the app must do, nobody can check that it does.
• Apps have no home. The result lives on one laptop, with no owner, no review and no way for colleagues to find it. This is where shadow AI starts.

The most common objection is fair: structure feels premature when people are still waiting for their first working solution. But the foundation is cheapest at the start. An app built on a weak foundation usually gets rebuilt underneath later, and by then it has users who depend on it.

Neither the IDE nor the coding agent is the right tool

A classic IDE assumes its user reads code. Claude Code, Codex and Copilot drop that assumption, but they bring their own: a chat window or a command line, and an agent that out of the box knows nothing about the organisation it works in. It doesn’t know your databases, your policies, your guidelines or your branding. A developer can configure that context. A domain expert can’t be expected to, so everything that makes the organisation unique ends up in a prompt, written by someone who may not know it matters.

App builders like Lovable or Replit come closer, but they are generic, run outside your infrastructure and know your organisation no better.

What a domain expert needs sits in between: an environment that already knows the organisation, puts guardrails around the choices that matter and helps the author make the right ones, so they can move fast and still trust the result.

And there isn’t just one. A finance analyst building a reporting app and a scientist building a data pipeline need different starting points, different data and different rules. That gives professional developers a new job: designing these environments for their colleagues. Developers decide what the templates contain, which data and building blocks the agent can use, and what has to pass before anything ships. Domain experts bring the ideas and the expertise.

A classic IDE integrates the tools a developer needs. This one integrates the organisation.

What developers should build into it

When the author can’t review the code, the environment has to carry the guarantees the author can’t check. In practice that means five things, all set up by the developers and platform team.

1. A spec the author can review. The domain expert describes the need in plain language, and the agent writes a spec before any code: who uses the app, their journeys, the requirements, the acceptance criteria and what is out of scope. The expert reviews something they can actually read.
2. Templates that carry identity and access. Every app starts from a template the developers maintain, so the foundation is right before the business logic goes on top. A web app runs as the signed-in user. An API or agent passes the caller’s identity along, so every call is attributed to a real person. A scheduled job gets a service identity and a run log. The template also protects its own foundations, so neither the author nor the agent changes them by accident.
3. Inherited permissions, never new ones. The app reads data as the person using it, so it can never show someone more than they could already see. The agent works under the same identity as its user, so a named person stays accountable for what gets built. Credentials are supplied by the platform at run time and never written into the code.
4. The organisation’s own building blocks, cited. The developers make the shared business-logic libraries, internal APIs, documentation, policies and brand guidelines available to the agent, and the agent reuses them instead of writing its own versions. Each requirement in the spec names where it came from, so a reviewer can trace every rule to its source.
5. Release gated on tests, and published for reuse. Acceptance criteria become tests, and the app only goes live if they pass. The author chooses who can open it, and the app is listed in a shared catalogue so the next person finds it instead of building it again.

This approach has two limits. An app that inherits its user’s permissions is only as safe as those permissions: if people have access they shouldn’t have, so does everything they build. And it suits internal tools used by a team or a department. Software sold to customers or built for very large user bases still needs professional engineering.

An example: an AI system register

Take a request that many IT and risk teams will recognise:

“An AI system register: every model, agent and app we run, what data each one touches, who owns it, and when it was last reviewed. Anyone can register one; security sees the whole list.”

In an environment built on these principles, the author works through five steps:

1. Describe. The author writes the request in plain language and picks the web application template the developers provide, which already handles sign-in.
2. Connect data. The author picks the sources the app needs, such as the vendor list, the AI and data policies and the IT system inventory. The app reads them with the author’s own permissions.
3. Choose building blocks. The author points the agent to the shared risk classification, the directory of teams and owners, and the review policy.
4. Build. The agent reads those sources before writing anything. It reuses the organisation’s existing risk tiers and looks owners up rather than letting people type names in. It writes a spec where each requirement names its source, then the code, with one test per acceptance criterion and no credentials in the code.
5. Ship. The tests run first, and the app goes live only if they pass. The author decides who can open it, and the app is listed where colleagues can find it.

The author never opens a code editor. They review a spec in plain language and a list of data and building blocks they already understand. The security team can rely on the result because the environment enforces what the author can’t check line by line. And IT can maintain it, because it was built the same way as every other app from that template.

Code editor vs. IDE vs. coding agent vs. an environment built for domain experts

Which one do you need?

If you write code and are responsible for it, a classic IDE is still the right tool, and a coding agent inside it will make you faster.

If you are a developer who wants to hand more of the typing to an agent, Claude Code, Codex or Copilot work well, because you can review what they produce.

If you know the domain but don’t read code, neither is built for you. Before you start, ask your IT or platform team four questions:

• Is there a template for the kind of app I want to build?
• Which data can the app use, and will it only see what I’m allowed to see?
• Which existing business rules and building blocks should it reuse?
• What has to pass before colleagues can use it, and where will they find it?

If nobody can answer, close that gap before the first app is built. It is much harder after the fiftieth.

Frequently asked questions

Is VS Code an IDE? Strictly, Visual Studio Code is a code editor. With extensions for languages, debugging and Git it works as a full IDE, which is why most developers call it one.

Is GitHub an IDE? No. GitHub hosts code, version history and collaboration around it. GitHub Codespaces does give you a full VS Code environment in the browser, but that is a separate product built on top of GitHub.

Is Claude Code an IDE? No. Claude Code is a coding agent. It runs from the command line and inside IDEs such as VS Code, and it writes and edits code on your behalf. It relies on a developer to review what it produces.

What is a good IDE for Python? PyCharm and VS Code with the Python extension are the most common choices. JupyterLab suits notebook-based data work, and Spyder is popular in scientific computing.

Do non-developers need an IDE? They don’t need a code editor. They do need what an IDE gave developers: one controlled place where work is specified, built, tested and shipped. With AI agents writing the code, that place has to be designed for them, and the people best placed to design it are the developers they already work with.

Can a domain expert safely ship an app built by an AI agent? For internal tools, yes, when the environment enforces what the expert can’t check line by line: inherited permissions, no credentials in code, tests before release and a named owner. It also depends on the organisation’s own identity and access setup being right, because the app inherits it.

Where Adamatics fits

The Adamatics Platform gives teams a governed environment inside their own infrastructure. Platform teams set up the templates and shared building blocks, apps run with the user’s own identity and are deployed with controlled access. We are building towards the full agentic workflow described here. Explore the platform.