Moshood A. Fakorede
Doctoral Researcher · LSU
Contact
Doctoral researcher in Computer Science at LSU, advised by Dr. Umar Farooq. I build program analysis techniques, benchmarks, and evaluation methods that measure and improve how large language models write, migrate, and reason about real-world code.
We are what we repeatedly do. Excellence, then, is not an act, but a habit.Scroll
Developing novel techniques to automatically detect and prevent software defects, improve system stability, and enhance overall software quality.
I build and release benchmarks (MobileDev-Bench, LintBench) that measure how far LLMs actually get on real mobile development, static analysis, and code migration tasks.
I mine large-scale repositories to study how developers actually build and maintain software, from bugs in quantum simulators to the adoption of post-quantum cryptography.
I study how large language models can be paired with deterministic program analysis and formal verification to move AI-assisted software engineering from pattern matching to proof.
My work spans static analysis (AutoComply) and benchmarking (MobileDev-Bench, LintBench), measuring how far LLMs actually get on real mobile development and lint generation.
Before my PhD, I spent over three years as a software engineer, shipping SaaS features at Cadana Inc. and building production systems at ARM Pensions PFA, including remediating 20+ CVEs across the OWASP Top 10. That practitioner's eye for what breaks in production shapes the research questions I ask now.
Work on program analysis, AI4SE, and code migration: two accepted including one oral presentation, three under review, one in submission, two in preparation.
Only a few hundred Android apps support Android Auto (363 as of March 2025) because of platform-specific compliance requirements. Android Auto needs a service-based architecture where the vehicle invokes app callbacks, which is very different from standard Activity-based Android development.
AutoComply, a static analysis framework that builds a Car-Control Flow Graph (CCFG) to model the service-based architecture and detect compliance violations.
An empirical study of 98 issues across 14 Android Auto app repositories found three failure categories: media playback errors, UI rendering issues, and voice command integration failures. AutoComply was evaluated on 31 open-source apps.
AutoComply detected 27 violations, 13x more than Android Lint, with no false positives observed and 2x faster analysis. Developers acknowledged 14 of the violations and 8 fixes have been implemented.
Existing issue-resolution benchmarks focus on library-style repositories. Mobile development, with its framework-specific build systems, mixed artifact types, and multi-file fixes, is largely unexplored.
MobileDev-Bench, a benchmark of 407 verified issue-resolution tasks from 19 production Android Native (Java/Kotlin), React Native (TypeScript), and Flutter (Dart) apps, each paired with developer-written tests and a containerized build environment. Fixes modify 12.9 files and 334.6 lines on average, and 41% span multiple artifact types.
A compilation-aware validation procedure keeps tasks whose tests only compile after the fix introduces the symbols they reference (Non-executable-to-Pass tests). Four LLMs (Claude Sonnet 4.5, GPT-5.2, Gemini 2.5 Flash, and Qwen3-Coder) were evaluated with the single-pass Agentless pipeline, extended to Java, Kotlin, TypeScript, and Dart, under automated and oracle retrieval, and with the interactive mini-SWE-agent.
Under Agentless, the models resolve only 3.19% to 4.18% of tasks with automated retrieval and at most 5.65% with oracle retrieval. With mini-SWE-agent, the best model, GPT-5.2, resolves 12.53% of tasks, compared with 69.0% for the same model and agent on the SWE-bench Verified leaderboard.
Writing a custom Android Lint check takes detailed knowledge of the analysis framework. Prior LLM approaches also need extra inputs such as bug-fix patches or test suites, and no prior work measures whether an LLM can produce a working check from a description alone.
LintBench, a human-validated benchmark of 113 real-world Android Lint checks, each paired with a natural language description and its original test suite as a held-out oracle. Prompting strategies were evaluated first, then API retrieval and execution-guided repair were added.
Four LLMs (Claude Sonnet 4.6, Gemini 3.5 Flash, Qwen3.6-Max-Preview, and Kimi K2.7 Code) were first tested with zero-shot, few-shot, and structural-scaffolding prompts, sampled five times each. A generate, run, repair loop then compiles each candidate check, runs the held-out tests, and feeds back only compiler errors and failing-test messages, keeping the test code hidden. Retrieval from the Lint API reference and developer guide adds framework knowledge. Pipeline and prompting results are compared at a matched budget of five model calls.
Prompting alone reached 30% to 65% (pass@5). Adding retrieval and execution-guided repair raised it to 57% to 85%, with compile rates up to 99%. Of the checks that compile but fail their tests, 87% have false negatives, so getting the issue-detection logic right remains open.
How well coding agents migrate entire repositories from Java to Kotlin is not well measured.
J2KMigBench, a benchmark for evaluating coding agents on repository-level Java-to-Kotlin migration. This work is in preparation.
PQC standards define quantum-safe algorithms, but there is little empirical evidence on how software projects implement and maintain PQC support.
Mined 114,361 commits and 5,713 issues across 179 open-source repositories, using human annotation and validated LLM classification to identify PQC algorithms, adoption status and deployment mode, and technical challenges.
Repositories came from 50 curated PQC projects plus 129 found through GitHub topic, metadata, and organization searches. Human annotators labeled a sample of commits and built the issue taxonomy to create reference labels. Eight LLMs were compared against those labels, and the best performer, frozen after a single held-out evaluation, classified the remaining records. Time-series analysis and first implementations of each algorithm were then examined around NIST standardization milestones.
90% of PQC commits concern maintenance of existing support. An 11-category taxonomy shows build, packaging, and dependency failures plus functional defects account for about half of categorized issues. After the 2024 finalization, standardized algorithm names appeared in over 80% of PQC changes, though earlier names like Kyber continued to appear. No significant increase in first implementations was found around the milestones.
Studying how post-quantum cryptography software is built and maintained needs its development history collected in one reusable, documented dataset.
PQC-Corpus, a dataset of the development history of 179 public GitHub repositories about PQC, covering commits, issues, pull requests, and repository metadata.
A scripted pipeline collected the repositories between 21 and 24 September 2026 and mined commits with full patches, issues and pull requests with their discussions and reviews, and repository metadata. Fixed rules then filter commits from 114,361 to 47,729 and issues from 5,713 to 5,687.
Released with checksums under CC BY 4.0 on Hugging Face, with the build pipeline archived on Zenodo.
How well LLMs can produce post-quantum cryptographic implementations is not well measured.
PQCImpl-Bench, a benchmark for evaluating LLMs on post-quantum cryptographic implementations. This work is in preparation.
Quantum simulators are widely used to develop and test quantum software, yet little is known about the bugs they contain.
An empirical study of 394 confirmed bugs from 12 open-source quantum simulators.
Candidate simulators came from the QOSF open-source list, keeping standalone simulators and excluding full quantum SDKs. From 3,108 closed issues in 15 candidate repositories, issues linked to merged fixes were manually filtered to remove feature requests, documentation, refactoring, and cleanup changes. At least two authors independently labeled each bug by root cause, failure manifestation, affected component, and discovery mechanism, with Cohen's kappa of 0.88 for manifestations and 0.78 for categories on a 100-issue calibration.
Most bugs are found by users after deployment rather than by automated testing. Logical correctness failures are common and often silent, producing plausible but wrong outputs. Many serious failures come from classical simulator infrastructure such as memory management, indexing, configuration, and dependency compatibility, rather than core quantum execution logic.
Chosen from 150 ISSTA AE 2026 committee members for high-quality reviews, active discussion, and timely evaluation.
View certificateAwarded to attend the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA) 2026.
Recognized by the AIR Program at Louisiana State University, February 2026.
Program and artifact evaluation committees across software engineering, AI and security venues, plus hands-on work with students at LSU.
Serving on the Shadow Research Track Program Committee for ICSE 2027 and the Junior Program Committees for TechDebt 2027 and MSR 2027.
Serving on Artifact Evaluation Committees for ASE, ISSTA, OOPSLA, SOSP, CAIS, WWW, CCS, PETS, MobiSys, and ISSRE.
Accepted as a Student Volunteer for SPLASH/ISSTA 2026 in Oakland, California. View certificate
Judged the Undergraduate Research & Creativity Conference at Louisiana State University.
Judged the High School Summer Research poster competition, LSU College of Engineering.
Mentored undergraduate students on benchmark construction, design, and evaluation.
Guiding students and collaborating on research projects, from dataset construction to publication.
Collaborating on a post-quantum cryptography adoption study and evaluating LLMs for post-quantum cryptographic implementations.
Contributing to dataset construction, benchmark design, and evaluation of a large-scale code migration corpus.
Working on an empirical study of how Android developers migrate their user interfaces.
Contributed to translating the HumanEval benchmark from Python into Kotlin, supporting dataset construction for evaluating LLMs on Kotlin code generation.
If you're interested in collaborating or being mentored on research in program analysis, formal verification, AI4SE, or code migration, please reach out.
Whether it's a research collaboration, an internship opportunity, or a conversation about any of my works, I'd love to hear from you.