You can ask an AI to build an application and quickly get forms, pages and an API that seems to work. But what data does that API send? Does an employee receive only the information they need, or does the entire user profile end up in their browser?
This guide to DTOs with AI starts with a simple situation: a manager and an employee use the same application, but need different information. You will understand what a DTO does and, above all, what to ask Codex, Claude or Grok for to get an implementation that fits your project.
You do not need to memorise complicated definitions. You need to describe who is requesting the information, what they are allowed to receive and how you will check the result.
DTOs with AI: what to understand before writing your prompt
What does DTO mean in plain language?
DTO stands for Data Transfer Object: an object used to transfer data between parts of a system. In an API, it can describe the shape of the data being received or sent. Martin Fowler explains this pattern as an object that carries data and can be converted into a format transmitted over a network.
Imagine an internal file and two extracts prepared from it. The file is the source of information. One extract contains three fields and the other contains five. You are not creating two new users or two accounts. You are preparing two representations of information about the same user.
A DTO can be implemented as a class, a record or another structure suited to the language. The exact form depends on the project. To begin with, what matters is the list of fields you define.
The entity, the DTO and the API response
In our example, the User entity is the internal model the application works with. The DTO describes the data selected for a particular exchange. The API response is what the client actually receives, often as JSON.
These things are related, but they are not identical. The DTO must actually be used when building the response. Simply having a class called UserDTO does not automatically change the data the API sends.
A simple example: one user, two responses
What can the employee see, and what can the manager see?
Suppose we are developing an internal application. We set the following fictional rule: an employee can view their own profile, while a manager can view the profiles of members of their own team.
| Field | Employee DTO | Manager DTO |
|---|---|---|
| ID | Yes | Yes |
| Name | Yes | Yes |
| Address | Yes, in this example | Yes, in this example |
| Work email | No | Yes |
| Department | No | Yes |
| Password hash | Never | Never |
| Password reset token | Never | Never |
The address is included to keep the example easy to follow. In your application, include it only if the function needs it and the access policy allows it. A manager role does not, by definition, grant access to every piece of information about a person.
Why does a DTO not replace permissions?
Authorisation determines whether a person can access a particular resource and particular fields. The DTO defines the shape of the data the application sends after applying those rules.
A DTO with three fields can disclose information if it is sent to the wrong person. For example, an employee must not be able to read another employee's profile simply by changing the ID in the address. OWASP describes this as a separate object-level authorisation problem.
Hiding a field in the interface does not solve the problem either. If the server sends it, it can be read in the API response. OWASP's recommendations on access to object properties call for explicitly selecting the data appropriate for the recipient.
Tell the AI what you are building
Replace a vague request with a concrete situation
“Make me some user DTOs” leaves many decisions unstated. The AI does not know whether you are building a public directory, an internal dashboard or an application for multiple organisations. The class name does not tell it who should be able to see addresses or emails either.
Start with the purpose of the function:
I am working on an internal application for a company. We have employee and manager roles. Employees view their own profiles. Managers view the profiles of members of their own teams. I want different API responses for these situations, using DTOs or the equivalent mechanism already present in the project.
Your request now describes an observable result. Alongside a code object, you are asking for a specific behaviour in the application.
Provide the project context
With code access or in a regular conversation
If the assistant has access to the project, point it to the relevant module and ask it to inspect the existing implementation: the user model, routes, authorisation and tests related to the function. If you are using a chat without file access, attach the relevant excerpts using fictional data.
You can write:
First check how API responses and permissions are implemented in this project. Identify the relevant files and follow existing conventions. If you cannot access the code, tell me exactly which excerpts I need to provide. Do not invent the application's structure.
The same request can be used in Codex, Claude or Grok. What the assistant can actually execute depends on its environment and available tools. A code example in a chat does not mean your project has been changed or tested.
Define the allowed fields precisely
Write the inclusion list
“Hide sensitive information” is too vague. In one project, an email address may be public; in another, it may be visible only to the team. State which fields are approved for each response.
For the employee response, include exactly: id, name, address. For the manager response, include exactly: id, name, address, workEmail, department. Adapt the names to the project's conventions. Do not include other properties of the internal model.
An inclusion list helps avoid an often overlooked situation: you later add a new field to the model and it accidentally appears in the response. In this example, the new field must remain outside the contract until it is explicitly approved.
Ask for an example of the result
Before implementation, ask for two examples using fictional data. Check that the employee response has only the three fields, and the manager response has only the five. If the AI automatically adds salary, a phone number or other information, correct the contract before continuing.
A small example makes the discussion clearer than a long explanation about “complete data”.
Specify the access rules
Who is requesting the data, and whose data is it?
These are two different questions. In our example, an authenticated employee can request their own profile. A manager can request the profile of a member of their own team. Being a manager does not automatically allow someone to read profiles from any team.
Add this to the prompt:
Determine the requester's identity and role from the application's verified authentication mechanism. Check access to the requested user. Do not grant rights based on a role parameter received from the client. Deny access when the rules do not allow the profile to be read.
Two endpoints can organise the function clearly, but their names do not grant permissions. A route containing the word “manager” still needs server-side access checks. If the application already has a suitable route, you do not have to create two more.
Ask for an implementation that fits the project
How does the data get into the DTO?
Transferring internal data into the response fields is often called mapping. For example, the application reads the name from the model and places it in the corresponding DTO field.
You can ask for two clear mapping methods, one for each contract. However, that detail is not a universal rule. Some projects already use mappers, serialisers or other response mechanisms. What matters is that field selection is explicit and can be checked.
Implement explicit mapping of the approved fields. Integrate the DTOs into the actual API responses and preserve the existing separation between authorisation, application logic and response construction. Avoid introducing libraries or restructuring that this change does not need.
Separate reading data from changing it
A profile returned by the API and a form submitted to the API do not necessarily have the same fields. Being allowed to see the department does not mean being allowed to change it.
If the function includes profile editing, request a separate input contract, with validation and authorisation for fields that may be changed. If you are working only on reading data, keep the task limited to responses. This boundary helps the AI avoid expanding the implementation unnecessarily.
Ask for checks that can demonstrate the result
What should the tests prove?
For this function, useful tests check the responses and access rules, as well as whether a DTO can be created. Give the assistant concrete situations:
- An employee requests their own profile and receives exactly the three approved fields.
- An employee requests someone else's profile and access is denied.
- A manager requests a team member's profile and receives exactly the five approved fields.
- A manager requests a profile outside their team and access is denied.
- An unauthenticated request receives no profile data.
- Changing a role parameter in the request does not grant additional rights.
- Password hashes, reset tokens and additional internal fields are absent from responses.
HTTP codes and error formats should follow the project's contract. Do not require a particular code simply because it appears in an example if your application intentionally uses a different behaviour.
Ask for evidence of the checks that were run
Run the relevant checks available in the project. At the end, state which commands you executed, what results you obtained and what you could not verify. If you only wrote tests without running them, say so explicitly.
A response saying “I added the tests” describes a change. The result of running those tests provides additional evidence. You need to know which of the two actually happened.
Ask for an explanation you can check
How do you assess the result without being an expert?
After implementation, ask for a short explanation of the data's path: who makes the request, where permissions are checked, where fields are selected and how the response is built. Also ask which files changed and why.
Explain the implementation in plain language. Show where access is checked and where returned fields are selected. Give an example for each role and identify the tests that confirm the behaviour. Mention any business assumptions that remain unconfirmed.
If the explanation does not match the response examples, ask for a focused review. You do not need to understand every instruction in the code to notice that the employee DTO contains a field you did not approve.
A complete prompt for Codex, Claude or Grok
Copy and adapt the request
Replace the fictional rules with your application's rules. If you have not decided who may see a particular field, clarify that decision before asking for implementation.
I want to implement DTO-based API responses for user profiles in the existing application.
Context: we have employee and manager roles. Employees can view only their own profiles. Managers can view the profiles of members of their own teams. These are the rules for the function we are building.
Employee contract: exactly id, name, address. Manager contract: exactly id, name, address, workEmail, department. Use the equivalent names from the project. Passwords, hashes, reset tokens and other internal data must not be returned.
Inspect the existing implementation and follow the project's conventions. If you cannot access the files, ask for the necessary excerpts. Identify authentication, authorisation, the user model, response construction and relevant tests.
On the server, check the requester's identity, access to the requested profile and the fields they may receive. Do not use a client-supplied role to grant rights. The DTO does not replace authorisation.
Explicitly build the approved responses using DTOs or the equivalent mechanism already present. Integrate them into the actual endpoints. A field later added to the model must not automatically appear in the response. Keep the change limited to this function.
Test the responses for both roles, unauthorised access to other profiles, unauthenticated requests, attempts to change the role through the request and the absence of internal fields. Follow the project's error format.
If you have working access to the project, implement the change and run relevant checks. If you can only provide a proposal, say so explicitly. At the end, present the changed files, response examples, check results and assumptions that require a decision from me.
How do you continue the conversation after the first result?
Use concrete observations: “The employee response also includes the email; remove it from the contract and check the corresponding test” is more useful than “this is wrong”. For a review, you can ask: “Follow the actual response path and check whether any path returns the internal model directly”.
The formula purpose, context, rules, examples and checks can also be applied to bookings, orders or invoices. Clear context and criteria appear in OpenAI's guide to working with Codex, in Anthropic's recommendations for Claude and in xAI's guide for Grok. The prompt above is our example of applying those ideas to DTOs.
Frequently asked questions about DTOs and AI
Do I need to know how to code to ask an AI for DTOs?
You can start by defining roles, fields and response examples. To assess the implementation, you need checks and someone who can review the code when a change goes beyond your level of understanding.
Is a DTO a new database table?
No. Creating a DTO does not automatically mean creating a table. It describes data being transferred. Do not ask for a database migration simply because you need a different API response.
Are two DTOs mandatory for two roles?
No. The example uses two contracts to make the difference visible. In a real project, contracts can be organised by function or use case, and roles can share a contract when the rules allow it.
Does a DTO protect information on its own?
No. Data selection must be accompanied by authorisation. Check both who may receive the response and what information it contains.
Can I use the same prompt in Codex, Claude and Grok?
Yes, the business requirements remain the same. Adapt the context you provide and the execution request to the assistant's actual access: a conversation, attached files or an environment connected to the project.
What if the AI says the implementation is finished?
Ask for response examples and the results of the checks that were run. Compare them with your rules. A confirmation message does not replace checking the application's behaviour.
Start with the data you want to send
To work more clearly with AI, describe the result first: who is requesting the data, which profile they may view and which fields they may receive. Then ask for the implementation and evidence that it follows those rules.
DTOs are a useful example of this approach: a technical idea becomes easier to request when you turn it into concrete rules and results you can check.