Add a third-party API integration via Devin PR
Posted on Feb 14, 2025 • Originally published at pratik.pa.tel. Task: Posted on Feb 14, 2025 • Originally published at pratik.pa.tel I recently took Devin AI for a spin on a real development task, and the experience felt like something between magic and mentorship. I had a straightforward job: implement an API endpoint to generate user access tokens for a third-party service. Normally I’d crank this out in ~15 minutes of coding. This time, I decided to hand it off to my new “AI teammate” and see what happened. Here’s how it went, step by step. The Task & Initial Plan 🚀 My instruction to Devin was simple: Implement the backend API based on this documentation [link to 3P website] Add it to [microservice API name] Utilize the existing CDK secrets logic to store the 3P API Key. Devin’s response was almost immediate: Understanding the goal: It parsed my request and the service docs, and quickly outlined a plan to create the token-generation endpoint. Collecting details: Devin identified required endpoints and data (thanks to the link I gave) and noted it would need to handle authentication, token storage, etc. Generating a plan: Before writing code, Devin presented a high-level game plan. This included creating a new route in our backend, calling the third-party API for the token, and returning the result to our app. I was impressed – the plan was thorough and made sense given the task. In essence, Devin did a great job figuring out what needed to be done without me hand-holding the requirements. It felt like I was working with an autonomous engineer who eagerly drafts a design spec after a short request. From Prompt to Pull Request 💻 With the plan in place, I gave Devin the green light. It jumped into coding mode. Within minutes, Devin had opened a GitHub pull request on our repository with the new API implementation. I could follow its progress in real-time through Devin’s interface. (The UI actually provides a step-by-step log of what the AI is doing – very cool!). Watching Devin work was surreal. The UI/UX of the tool is amazing – it felt seamless and intuitive to use. As one early user noted, “Devin feels UI/UX first, not GenAI first,” emphasizing that the surrounding experience is the star. I have to agree. In my case, giving instructions felt as easy as chatting with a colleague, and I could see Devin’s thought process and actions clearly. The combination of a chat interface, an embedded code editor, and live updates made it feel like pair-programming with a supercharged junior dev. Soon, the PR was ready for review. The code Devin produced was surprisingly solid for a first pass. It had set up the new API endpoint, made calls to the third-party service, and hooked everything into our backend. All of this happened while I was hands-off. Hiccups and Iterations 🛠️ Of course, it wasn’t perfect out of the box. Upon reviewing the pull request, I spotted a few issues that needed addressing before this code could go to production. Notably: Missing API key logic: Devin forgot to include the authentication API key when calling the third-party service. A human engineer knows that’s a must for the request to succeed, but the AI overlooked this detail on the first try. Code style differences: Some of the naming conventions and formatting didn’t match our project’s style guidelines. (Minor issue, but something we’d fix in any code review – even with human contributors.) Best practice tweaks: I noticed that the API logic for calling the 3P service should have been abstracted into our "clients" library. While Devin’s solution was functional, integrating this logic into the shared library would improve maintainability and align with our standards. The great thing was that, addressing these issues felt very natural. I went into the PR on GitHub and dropped comments exactly like I would for a human colleague. For example, I pointed out where the API key should be injected, suggested where to move code around, and reminded to clean up some unneeded additions. Devin took this feedback in stride. It truly felt like collaborating with a keen junior developer: I’d leave a note, and Devin would go off to fix it. Devin was eager to improve and quickly pushed new commits to the PR, incorporating my suggestions.; tools: Devin. Human role: The original post does not say how a person stayed involved.; limitations: Devin initially missed critical authentication details and required human intervention for code style and architectural best practices, such as abstracting logic into shared libraries. The workflow is slower in real-time than manual coding for simple tasks, making it suitable for parallel work rather than urgent single-task completion. Human expertise remains crucial for quality control, context understanding, and catching subtle requirements that the AI might overlook..
Tools
Published on Agent Work Atlas:
Overview
Posted on Feb 14, 2025 • Originally published at pratik.pa.tel
Workflow
Posted on Feb 14, 2025 • Originally published at pratik.pa.tel I recently took Devin AI for a spin on a real development task, and the experience felt like something between magic and mentorship. I had a straightforward job: implement an API endpoint to generate user access tokens for a third-party service. Normally I’d crank this out in ~15 minutes of coding. This time, I decided to hand it off to my new “AI teammate” and see what happened. Here’s how it went, step by step. The Task & Initial Plan 🚀 My instruction to Devin was simple: Implement the backend API based on this documentation [link to 3P website] Add it to [microservice API name] Utilize the existing CDK secrets logic to store the 3P API Key. Devin’s response was almost immediate: Understanding the goal: It parsed my request and the service docs, and quickly outlined a plan to create the token-generation endpoint. Collecting details: Devin identified required endpoints and data (thanks to the link I gave) and noted it would need to handle authentication, token storage, etc. Generating a plan: Before writing code, Devin presented a high-level game plan. This included creating a new route in our backend, calling the third-party API for the token, and returning the result to our app. I was impressed – the plan was thorough and made sense given the task. In essence, Devin did a great job figuring out what needed to be done without me hand-holding the requirements. It felt like I was working with an autonomous engineer who eagerly drafts a design spec after a short request. From Prompt to Pull Request 💻 With the plan in place, I gave Devin the green light. It jumped into coding mode. Within minutes, Devin had opened a GitHub pull request on our repository with the new API implementation. I could follow its progress in real-time through Devin’s interface. (The UI actually provides a step-by-step log of what the AI is doing – very cool!). Watching Devin work was surreal. The UI/UX of the tool is amazing – it felt seamless and intuitive to use. As one early user noted, “Devin feels UI/UX first, not GenAI first,” emphasizing that the surrounding experience is the star. I have to agree. In my case, giving instructions felt as easy as chatting with a colleague, and I could see Devin’s thought process and actions clearly. The combination of a chat interface, an embedded code editor, and live updates made it feel like pair-programming with a supercharged junior dev. Soon, the PR was ready for review. The code Devin produced was surprisingly solid for a first pass. It had set up the new API endpoint, made calls to the third-party service, and hooked everything into our backend. All of this happened while I was hands-off. Hiccups and Iterations 🛠️ Of course, it wasn’t perfect out of the box. Upon reviewing the pull request, I spotted a few issues that needed addressing before this code could go to production. Notably: Missing API key logic: Devin forgot to include the authentication API key when calling the third-party service. A human engineer knows that’s a must for the request to succeed, but the AI overlooked this detail on the first try. Code style differences: Some of the naming conventions and formatting didn’t match our project’s style guidelines. (Minor issue, but something we’d fix in any code review – even with human contributors.) Best practice tweaks: I noticed that the API logic for calling the 3P service should have been abstracted into our "clients" library. While Devin’s solution was functional, integrating this logic into the shared library would improve maintainability and align with our standards. The great thing was that, addressing these issues felt very natural. I went into the PR on GitHub and dropped comments exactly like I would for a human colleague. For example, I pointed out where the API key should be injected, suggested where to move code around, and reminded to clean up some unneeded additions. Devin took this feedback in stride. It truly felt like collaborating with a keen junior developer: I’d leave a note, and Devin would go off to fix it. Devin was eager to improve and quickly pushed new commits to the PR, incorporating my suggestions.
Reported result
The task took approximately one hour via Devin, compared to an estimated 15 minutes for manual coding, resulting in a 4x increase in wall-clock time. However, the author's active involvement was minimal, requiring only a few minutes for instructions and about five minutes for review and commenting. This allowed the author to perform other tasks concurrently, such as reviewing teammate PRs and brainstorming, effectively parallelizing their workload rather than reducing total task duration.
Human role
The original post does not say how a person stayed involved.
Limitations
Devin initially missed critical authentication details and required human intervention for code style and architectural best practices, such as abstracting logic into shared libraries. The workflow is slower in real-time than manual coding for simple tasks, making it suitable for parallel work rather than urgent single-task completion. Human expertise remains crucial for quality control, context understanding, and catching subtle requirements that the AI might overlook.
Try it
I need to implement a new API endpoint for [replaceable: specific service name] using Devin. Here are the requirements: [replaceable: paste documentation link or API spec]. Please create a plan first, then generate a pull request in [replaceable: GitHub repo name]. I will review the code for authentication logic and style compliance. If issues are found, I will comment on the PR; please iterate and push fixes. Do not merge until I approve. Start by outlining the steps you will take.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.