Build a deals page step by step with Devin
Devin AI review: Is this the first true autonomous AI coding agent? Task: Devin AI review: Is this the first true autonomous AI coding agent? Devin AI is an autonomous AI coding agent that works in its own environment. This environment is a virtual machine that has: Browser interface – it uses it to test UI locally or check out tools documentation Its VSCode instance A terminal – uses it to run all their commands A planner – where the main instructions are internally defined and executed It also has integrations with Slack and GitHub for a more complete workflow. Note: The Slack integration was not tested, and only the chat interface provided on the devin.ai site was used. The difference with other tools like Cursor or Copilot is that it is not an IDE nor a VSCode extension and does not act like one. Devin does provide a VSCode extension, but it is just a chat interface, and no code is interacted with in the user’s local environment. The changes in the code would still happen on Devin’s machine. What can Devin AI do?: Testing it with a case study of implementing a “deals” feature in a CRM system I tested Devin AI on one of Qubika’s clients projects with a simple task: adding a deals feature to the site’s CRM. Initial setup Using Devin’s Github integration, the repositories for both the backend and frontend projects were connected to Devin, which was prompted to clone the repositories and set up its environment locally. It managed to set up the local environment after prompting for the environment variables and asking for certain values on some of them. Task breakdown and planning for the deals page implementation in Devin AI For the initial prompt, Devin AI was provided with: The entire schema definition of the Deal-related entities An image of the DB schema During its planning, it was reminded of some ongoing work that was not merged but related (company). Thanks to the Github integration it only needed the PR numbers to be able to access them. It did find the task too large and recommended that it be separated into different sessions: This was good on one hand as it showed enough understanding of the task to break it down into reasonable smaller tasks. However, this kind of task separation ended up being a problem due to the sessions in Devin not sharing the same context, so parallelization of the task would not work here. In less than 10 minutes it had a PR opened for the first point of the breakdown plan. The PR failed its CI checks, and it made several attempts to fix the linting and typescript errors. It also recognized some typescript errors unrelated to the changes and asked for guidance on what to do with them, as they were outside the scope of the task. As it proposed to separate the task into other sessions, another session was created for another part of the breakdown. In this case, Devin was prompted to create its PR with the PR created before as its base. It did not have issues doing this. Other Sessions were created for the rest of the tasks. The PRs created for these were acceptable but contained extra unnecessary changes. When asked if a library was being used elsewhere in the code (Joi), it did not answer truthfully—it told me it was not used in other parts except where it added it, which was not true, causing unnecessary changes later on. It also assumed NestJS was being used, adding unnecessary libraries as the project was not using the framework. Devin AI limitations: Challenges faced by Devin AI in managing PRs and local environments The main issue when Devin AI created their PRs was that it did not check for build errors, just CI checks. When tasked with loading its local docker environment, it started failing and kept attempting unrelated fixes. In one attempt, it refactored the authentication methods unprompted because it thought the issue was on the login page. The last session, which was tasked with making the project run locally, did not finish as it hit session usage limits. After trying to fix it locally, I found that most of the docker issues came from the changes Devin introduced in the PRs. It made errors like importing a .js file when the file was a typescript file, and also errors on the migrations it created where it did not follow the TypeORM standard naming pattern. Key advantages of Devin AI in implementing the deals feature Devin AI has successfully shown some key advantages when implementing the Deals feature: It was able to quickly break down the complex task into more manageable parts, showing good project planning capabilities; tools: Devin. Human role: The original post does not say how a person stayed involved.; limitations: Devin sessions do not share context, preventing parallel task execution. It may hallucinate library usage or framework assumptions, requiring strict human code review. Session usage limits can halt progress, and the agent does not automatically validate local build environments, only CI checks..
Tools
Published on Agent Work Atlas:
Overview
Devin AI review: Is this the first true autonomous AI coding agent?
Workflow
Devin AI review: Is this the first true autonomous AI coding agent? Devin AI is an autonomous AI coding agent that works in its own environment. This environment is a virtual machine that has: Browser interface – it uses it to test UI locally or check out tools documentation Its VSCode instance A terminal – uses it to run all their commands A planner – where the main instructions are internally defined and executed It also has integrations with Slack and GitHub for a more complete workflow. Note: The Slack integration was not tested, and only the chat interface provided on the devin.ai site was used. The difference with other tools like Cursor or Copilot is that it is not an IDE nor a VSCode extension and does not act like one. Devin does provide a VSCode extension, but it is just a chat interface, and no code is interacted with in the user’s local environment. The changes in the code would still happen on Devin’s machine. What can Devin AI do?: Testing it with a case study of implementing a “deals” feature in a CRM system I tested Devin AI on one of Qubika’s clients projects with a simple task: adding a deals feature to the site’s CRM. Initial setup Using Devin’s Github integration, the repositories for both the backend and frontend projects were connected to Devin, which was prompted to clone the repositories and set up its environment locally. It managed to set up the local environment after prompting for the environment variables and asking for certain values on some of them. Task breakdown and planning for the deals page implementation in Devin AI For the initial prompt, Devin AI was provided with: The entire schema definition of the Deal-related entities An image of the DB schema During its planning, it was reminded of some ongoing work that was not merged but related (company). Thanks to the Github integration it only needed the PR numbers to be able to access them. It did find the task too large and recommended that it be separated into different sessions: This was good on one hand as it showed enough understanding of the task to break it down into reasonable smaller tasks. However, this kind of task separation ended up being a problem due to the sessions in Devin not sharing the same context, so parallelization of the task would not work here. In less than 10 minutes it had a PR opened for the first point of the breakdown plan. The PR failed its CI checks, and it made several attempts to fix the linting and typescript errors. It also recognized some typescript errors unrelated to the changes and asked for guidance on what to do with them, as they were outside the scope of the task. As it proposed to separate the task into other sessions, another session was created for another part of the breakdown. In this case, Devin was prompted to create its PR with the PR created before as its base. It did not have issues doing this. Other Sessions were created for the rest of the tasks. The PRs created for these were acceptable but contained extra unnecessary changes. When asked if a library was being used elsewhere in the code (Joi), it did not answer truthfully—it told me it was not used in other parts except where it added it, which was not true, causing unnecessary changes later on. It also assumed NestJS was being used, adding unnecessary libraries as the project was not using the framework. Devin AI limitations: Challenges faced by Devin AI in managing PRs and local environments The main issue when Devin AI created their PRs was that it did not check for build errors, just CI checks. When tasked with loading its local docker environment, it started failing and kept attempting unrelated fixes. In one attempt, it refactored the authentication methods unprompted because it thought the issue was on the login page. The last session, which was tasked with making the project run locally, did not finish as it hit session usage limits. After trying to fix it locally, I found that most of the docker issues came from the changes Devin introduced in the PRs. It made errors like importing a .js file when the file was a typescript file, and also errors on the migrations it created where it did not follow the TypeORM standard naming pattern. Key advantages of Devin AI in implementing the deals feature Devin AI has successfully shown some key advantages when implementing the Deals feature: It was able to quickly break down the complex task into more manageable parts, showing good project planning capabilities
Reported result
The source does not report measured business outcomes or success metrics. Devin generated PRs quickly but failed CI checks initially and introduced unnecessary code changes. It did not verify local build errors, leading to Docker issues that required manual intervention to fix file import and migration naming errors.
Human role
The original post does not say how a person stayed involved.
Limitations
Devin sessions do not share context, preventing parallel task execution. It may hallucinate library usage or framework assumptions, requiring strict human code review. Session usage limits can halt progress, and the agent does not automatically validate local build environments, only CI checks.
Try it
Act as a senior developer using Devin AI to implement a new feature in [replaceable: CRM system name]. 1. Connect [replaceable: GitHub repo URLs] to Devin. 2. Provide the [replaceable: database schema definition] and [replaceable: feature requirements]. 3. Instruct Devin to break the task into sub-sessions. 4. For each session, review the generated PR for unnecessary dependencies or incorrect framework assumptions. 5. Do not merge until a human verifies local build success. 6. If Devin fails to fix CI errors after 2 attempts, stop and manually debug. Output: A list of PR links and a summary of manual fixes required. Ask clarifying questions if the schema or repo access is missing.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.