Modernizing financial
services with autonomous
AI engineers

Hey Devin,

Please upgrade the BankOfDevin/BankingServer repository from Java 8 to Java 17. Here’s your task breakdown:

Required Changes

Update build.gradle

• Change sourceCompatibility and targetCompatibility from ‘8’ to ‘17’

<ref_file file="/home/ubuntu/repos/BankOfDevin/BankingServer/build.gradle" />

Update GitHub Actions workflow

• Update the JDK version in .github/workflows/gradle.yml from ‘8’ to ‘17’

<ref_snippet file="/home/ubuntu/repos/BankOfDevin/BankingServer/.github/workflows/gradle.yml" lines="20-24" />

Update README.md

• Update the Java version requirement in the README from ‘8’ to ‘17’

<ref_snippet file="/home/ubuntu/repos/BankOfDevin/BankingServer/README.md" lines="47-47" />

Check for deprecated APIs or language features

• Review the codebase for features removed or changed since Java 8
• Pay attention to:
• Internal JDK APIs removed in Java 17
• Deprecated methods no longer available
• Reflection and security model changes

Test the application

• Run the full test suite to confirm compatibility with Java 17
• Perform manual testing to verify runtime behavior

Implementation Approach

• Create a new branch for the Java 17 upgrade
• Apply changes to build files, CI workflow, and documentation
• Replace or refactor deprecated API usage
• Run all tests and confirm parity with Java 8 outputs
• Open PR with the changes, migration notes, and CI results

You only need to look in the following repo: BankOfDevin/BankingServer.

Hey Devin,

Please migrate the ASP.NET MVC 5 backend from the COG-GTM/angularjs-asp-net48-mvc5 repository to an ASP.NET Core 8 Web API project. Here’s your task breakdown:

Create a new ASP.NET Core 8 Web API project

• Set up the project structure following ASP.NET Core conventions.
• Add Program.cs and Startup.cs for configuration.

Migrate controllers

• Convert all MVC controllers (e.g., LandingController.cs) into API controllers.
• Ensure all endpoints return JSON responses with appropriate status codes.
• Keep the same route patterns to avoid frontend changes.

Handle configuration files

• Replace App_Start/BundleConfig.cs and App_Start/RouteConfig.cs with ASP.NET Core equivalents.

Update views and static files

• Remove Razor views (e.g., Views/Landing/Index.cshtml).
• Serve the AngularJS app (HTML, JS, CSS) as static files from the wwwroot folder.

Enable CORS

• Add middleware to allow requests from the current AngularJS frontend at http://localhost:51267/.

Set up dependency injection

• Register services in Program.cs using the DI container.

Match frontend expectations

• Preserve AngularJS app structure (WebApp/app.js, WebApp/Components/test.component.js, etc.).
• Maintain route compatibility so the frontend doesn’t break.
• The AngularJS app is initialized as angular.module('app', []); this should remain unchanged.

Deliverables

• New ASP.NET Core 8 Web API project with migrated controllers.
• Static file serving configuration for the AngularJS frontend.
• CORS configuration to enable frontend requests.
• Documentation of any route changes or adjustments.

References

• The original project structure is defined in angularjs-asp-net48-mvc5.csproj, and AngularJS dependencies are in package.json.
• You only need to look in the following repo: COG-GTM/angularjs-asp-net48-mvc5.

Hey Devin,

Please connect to the SonarQube API server for the BankOfDevin/BankingServer repository.

Identify and extract issues for the following critical vulnerability SonarQube tags:

• SQL Injection
• XSS attacks

Implement targeted fixes

• Resolve 2 issues from the SQL Injection category.
• Resolve 2 issues from the XSS category.

Validate remediation

• Run regression tests and lint checks.
• Ensure all fixes pass SonarQube’s Quality Gate for high-severity issues.

Deliverable

• Open a pull request with the fixes.
• Include SonarQube issue links and test results in the PR description.
• Use ticket ID SonarQube-42 in the PR description.

You only need to look in the following repo: BankOfDevin/BankingServer.

Let me know if you need any clarification on the requirements.

Hey Devin,

Please create a Java implementation of the COBOL control file for investment account balances from the Devin-Bank/Cobol-Investment-App repository. Here’s your task breakdown:

Create these core Java classes

• AccountBalanceRecord — Java POJO mirroring the COBOL record layout (use exact field sizes/types from the PIC clauses in the source):
  • accountId (e.g., 10 chars)
  • asOfDate (e.g., 8 chars, YYYYMMDD)
  • currency (3 chars)
  • txnType (1 char; e.g., D/C)
  • amount (signed, 2-decimal fixed width; support COMP-3 if present)
  • runningBalance (signed, 2-decimal fixed width)
• FixedWidthFileReader / FixedWidthFileWriter — Utilities that reproduce COBOL fixed-width I/O semantics:
  • Space/right padding, truncation rules, and collating sequence
  • Packed/zoned decimal (COMP-3/COMP) parsing if used; otherwise DISPLAY numeric
  • File status mapping (e.g., 00, 10, 23) to Java exceptions with recoverable handling
• BalanceControlProcessor — Implements the COBOL “control” logic:
  • Open/read sequential input(s), perform control-break processing on accountId (and asOfDate if the COBOL does so)
  • Apply debits/credits to compute running balances exactly as in COBOL
  • Emit headers/trailers and control totals (record counts, sum of debits/credits, final balances)

Implement the program workflow

• Use the same file names as the COBOL program (inputs, outputs, and any work files).
• Example (adjust to match the source):
• Inputs: INVESTMENT-TXN.DAT, ACCT-MASTER.DAT
• Outputs: BALANCE-REPORT.TXT, CONTROL-SUMMARY.TXT, ERROR-LOG.TXT
• Maintain fixed-width record format end-to-end (identical field widths and alignment).
• Replicate control breaks and totals exactly: emit group totals when keys change; reproduce header/trailer lines byte-for-byte where feasible.
• Numeric rules: match COBOL rounding/truncation and sign handling (assume scale 2; implement half-up unless the PIC/usage dictates otherwise).
• Error handling: on malformed records, log to ERROR-LOG.TXT with record image + reason, then continue.
• Deterministic results: for identical inputs, outputs must match COBOL outputs.

Match COBOL’s file handling

• Use identical file names/paths expected by the control file.
• Respect open modes, end-of-file semantics (AT END), and status codes.
• Preserve any sort/merge steps if present (use in-memory stable sort keyed exactly as in COBOL).

Implement verification

• Create golden-file tests that run the Java flow against sample inputs from the repo (or ones you generate to mirror the COBOL examples) and byte-compare outputs to the COBOL program’s results.
• Include unit tests for:
  • PIC/usage → Java parsing (including COMP-3 if applicable)
  • Control-break emission
  • Totals/rounding parity

Repository scope

• You only need to look in the following repo: Devin-Bank/Cobol-Investment-App.
• The original COBOL control file is located in the investment_balance directory (use it as the source of truth for record definitions, file names, and control logic).

Deliverables

• Production-quality Java source with README explaining:
  • Field mappings (PIC → Java), rounding/sign rules, and any assumptions
  • How to run the job and the tests
• A PR with the description including ticket ID MBA-18 and a brief summary of parity test results.

Let me know if you need any clarification on the requirements.

Hey Devin,

Please create a standalone, event-driven microservice that extracts the load_transaction_data pipeline from the Devin-Bank/ETL repository. Here’s your task breakdown:

Core Functionality

• Monitor and extract data from banking.transactions and banking.customer_accounts tables in the olist source database.
• Load this data into b_data.transactions and b_data.customer_account tables in our data warehouse.
• Support concurrent loading of both tables (parallel processing).

Event-Driven Architecture

• Implement listeners for database change events (new transactions, account updates) or scheduled triggers.
• Publish transaction-data-loaded events when loads complete successfully.
• Publish failure events with retry capabilities when errors occur.

Technical Requirements

• Create connection management for both olist (source) and dwh (target) databases.
• Implement schema initialization for the b_data schema before loading data.
• Add data validation to ensure transaction and account integrity during the copy process.
• Implement monitoring for load times, record counts, and failures.

Migration Considerations

• Maintain backward compatibility so the service can still be called by the existing ETL pipeline during transition.
• Implement idempotency to allow safe re-runs without duplication.
• Provide a rollback strategy to revert failed loads.

The new microservice should preserve the same data flow and transformation logic as the current ETL, but replace the monolithic pipeline structure with an event-driven architecture.

Deliverable

• Create a PR with your implementation and include the ticket ID ETL-42 in the PR description.

The original load_transaction_data pipeline is in the Devin-Bank/ETL repo. Use this as your reference for exact functionality matching.