Alden Lemberg

Alden
Lemberg.

I build accessible software and tools for AI agents.

Ablr
Built an accessibility review platform
Met with the executive team
Sculptor AI
Deployed an agent code-execution engine
Built with Judge0 for education
VetrAI
Engineered an autonomous research pipeline
With hallucination mitigation
View my work ↗
Alden Lemberg wearing a dark suit and purple tie

Selected work.

Ablr Accessibility Platform

An AI accessibility review engine across the development workflow.

I built Ablr Accessibility Platform for the Ablr project: a platform that brings accessibility scanning, Docker-based analysis, and AI code review into one workflow.

My contribution

A custom CodeRabbit-style engine connects findings to source code, posts inline GitHub suggestions, prepares requested fix pull requests, and supports human review and rechecks.

Positive feedback led to a meeting with Ablr’s executive team about developing an additional product.

Explore the build & review workflow

The problem

Accessibility findings can be scattered across tools, difficult to interpret, and disconnected from the code that needs to change. A review environment should also be usable by blind and low-vision auditors.

What I built

I built the tool for the Ablr project. The platform brings websites, application builds, code review, and PDF material into a shared review workflow. I developed Docker-based software analysis and included AI-assisted code review and analysis tools.

The implementation combines automated scanners with Gemini-assisted explanations and fix suggestions. It includes a keyboard-oriented dashboard, named-color descriptions, and an emulation architecture intended to support human review.

“I received great feedback and had a personal meeting with Ablr’s executive team about moving forward with an additional product.”

My CodeRabbit-style accessibility review engine

I also built an AI code-review engine focused on accessibility throughout the development flow. Like a pull-request review bot, it connects findings to source code, explains the issue, and proposes a fix where the developer is already working. “CodeRabbit-style” describes the workflow; this is my own implementation, not a CodeRabbit integration.

  1. Review the source: analyze UI source for accessibility issues, including when a preview or application build is unavailable.
  2. Inspect the running application: use a preview or Docker-built application to gather scanner evidence and review configured user flows. PDF review material follows its document-analysis path.
  3. Connect findings to the diff: give Gemini findings and numbered changed files, then validate the proposed file and line ranges before posting inline GitHub suggestions.
  4. Propose actionable fixes: provide explanations and replacement code. On request, gather applicable suggestions into a fix pull request; skip replacements when the original code has changed.
  5. Escalate and recheck: support human-auditor requests and Jira re-verification. When an issue marked Done still reproduces, the integration can reopen it.

My contribution was building the connected review workflow around the AI: source context, scan evidence, structured suggestions, validation, and follow-through. Human testing remains essential across the workflow.

Designed for review, not blind acceptance

The engine checks that suggestions apply to the code under review, skips outdated replacements, and provides a path to a human auditor. Developers keep control of changes, while follow-up scans help establish whether an issue still reproduces.

Feedback and next steps

Positive feedback led to a meeting with Ablr’s executive team to discuss developing an additional product.

NotePro

PDF annotation, collaborative notes, and Gemini study assistance in one workspace.

EmbedPDF supports annotation; BlockNote and Yjs support text editing and collaboration. Gemini adds page-based explanations and study materials through an authenticated API.

Read the NotePro case study ↓

TrueFans CONNECT

A music platform with artist workflows, CRM, and AI-assisted outreach proposals.

The artist assistant uses platform data to prepare relevant campaign proposals. A person approves outreach before it is sent, keeping creative assistance separate from execution.

Design principle: give people control over actions taken on their behalf.

Experience.

JUN — JUL 2025PART-TIME · REMOTE

Sculptor AI

Contributor Seattle, Washington · Remote

I engineered serverless code-execution tools that let AI agents run and evaluate student code on demand. I built a custom Judge0-based execution engine and deployed it into the Sculptor AI platform for use in educational settings.

Open-source integration

Judge0 supplied the code-execution foundation; my contribution was the custom engine and its integration into an agent workflow. This connected AI-generated requests to actual code execution and evaluation.

Outcome: successful deployment into the educational platform.

Explore the Judge0 open-source project ↗
JUN — NOV 2025ASSOCIATED WITH XENPAC

VetrAI Research Platform

Autonomous research agents AI · AI for research

I engineered an autonomous agent pipeline for deep research with built-in hallucination mitigation. The project focused on the speed of a complete research cycle as well as the reliability of the resulting output.

Agent workflow development

Designed the research workflow to combine autonomous execution with hallucination mitigation, making speed and output reliability central engineering priorities.

Research & evaluation: Compared research-cycle performance with contemporary tools through head-to-head benchmarking.

Explore the tools & integrations

The tools behind the work

The foundations I connected to build these products.

Tools and their role in the product
Tool or platformRoleWhat the integration adds
Judge0Open-source code-execution foundationIntegrated into a custom serverless engine that enables Sculptor AI agents to run and evaluate student code on demand.
Playwright + axe-coreBrowser automation and rule-based accessibility checksConnects reproducible browser evidence to the review process.
HTML_CodeSniffer + LighthouseAdditional web audit enginesNormalizes findings and avoids counting overlapping axe/Lighthouse results twice.
Docker + Oobee + veraPDFIsolated application builds and containerized analysisRuns software and document checks in a repeatable environment.
PDF.js + React AriaDocument processing and accessible interface componentsSupports review material and keyboard-oriented interaction; interaction still needs to be tested with people and assistive technology.
Gemini APIHosted generative AI serviceProduces structured review fields and proposed fixes.
Supabase + PostgreSQLStorage, authentication, queues, and realtime updatesConnects scans to organizations and review workflows.

Scan. Interpret.
Then verify.

A guided architecture walkthrough of Ablr Accessibility Platform. Explore how a finding becomes a proposed fix and a verified change.

01

Prepare the software

Use a deployed preview when one exists. Otherwise build a selected repository commit in Docker, start the application, and wait for it to respond.

A repeatable environment keeps analysis connected to the software being reviewed.

AI & accessibility.

Research informing my approach to accessible software and applied AI.

Explore the research

How AI is being used

Generative AI can turn visual information into descriptions and conversations. Be My AI’s desktop tools describe screens, image files, clipboard images, and camera pictures, with follow-up questions.[4]

In my own projects, AI interprets accessibility findings, proposes code changes, and helps students work with document content. Open-source scanners provide a separate layer of repeatable checks.[3]

Emerging directions and concerns

Multimodal assistance is moving beyond isolated descriptions toward interaction with a person’s context and intentions. A 2025 research preprint reports interviews with 14 Be My AI users and identifies hallucinations, contextual misinterpretations, and difficulty responding to user intentions.[5]

For my work, this points to a clear priority: make evidence, uncertainty, and correction part of the interface. NIST’s generative AI profile provides a framework for incorporating trustworthiness across design, development, use, and evaluation.[2]

Be My AI: visual assistance

Screen and image descriptions show a practical use of generative AI in accessibility. This matters because visual content can become available through a conversational interface. Research also shows why confident descriptions need scrutiny.[4][5]

Ablr Accessibility Platform: AI-assisted review

My project connects open-source testing with AI explanations and proposed code changes. axe-core is an automated accessibility engine; Gemini adds generative interpretation. W3C cautions that some checks require manual intervention, so the workflow retains a human review path.[1][3]

Three layers of trustworthy accessibility reviewEach layer answers a different question. AI assistance does not replace either technical checks or lived user experience.
  1. 01

    Automated evidence

    What can a reproducible rule detect?

    Scanners and browser tests
  2. 02

    AI interpretation

    What explanation or fix might help?

    Context, uncertainty, proposals
  3. 03

    Human validation

    Does the experience actually work?

    Keyboard, assistive technology, users

Automated checks, AI interpretation, and human validation serve complementary roles.[1]

Research checkpoints

CHECK 01

Automated tools cannot complete every accessibility check. W3C’s evaluation-tools transcript explicitly describes checks requiring manual intervention. [1]

CHECK 02

Be My AI on desktop supports screen descriptions and follow-up questions. Both capabilities appear in its official desktop guide. [4]

What I learned.

Three lessons from building, testing, and refining AI tools.

Read the lessons behind the work
01

Integration is more than connecting an API.

What I learned. a useful AI review needs a dependable environment, scanner evidence, source context, and an understandable result. Docker-based analysis made those pieces part of one workflow.

How I applied it. I treat AI as one part of the review process and preserve a route to human verification. This supports my goal of building useful accessible software.

Ablr review decision flow

Automated finding AI explanation Human review

02

The model needs to show what it read.

What I learned. handwritten content can be misread before the reasoning even begins. NotePro’s current prompt asks for a transcription before solving and its UI exposes that reading.

How I applied it. I make the input interpretation visible so a student can identify a wrong symbol before trusting the solution. This connects software design to learning rather than answer generation alone.

NotePro prompt excerpt
“Transcribe first, into ‘read’, before you solve.”

Showing the transcription gives the student an opportunity to catch an input mistake.

03

A proposed action needs a clear boundary.

What I learned. generating outreach and sending it are separate responsibilities. TFRC’s artist assistant instructs the model to propose campaigns and wait for approval.

How I applied it. I make the distinction between a draft and a completed action explicit. This supports accountable product development when software acts on behalf of people.

Outreach approval flow

Prepare a draft Review and approve Send

Tools and skills in practice

Gemini API

Application: structured review fields in Ablr Accessibility Platform and page-based study responses in NotePro.

Strength: context-sensitive explanation and draft generation.

Limit: plausible output may still be wrong; image interpretation can fail.

My role: define schemas, inspect the original evidence, test the behavior, and decide whether a proposed change is justified.

Playwright + axe-core

Application: browser-based accessibility findings in Ablr Accessibility Platform.

Strength: repeatable rule checks that complement AI interpretation.

Limit: automated testing does not establish full accessibility.[1]

My role: choose meaningful flows and manually check interaction. These are testing tools, not generative AI.

Docker

Application: application builds and containerized scanning workflows.

Strength: repeatable environments for analysis.

Limit: builds can fail and infrastructure needs careful configuration.

My role: configure runtime behavior and distinguish a source-only review from a running-app audit. Docker supplies infrastructure for the AI workflow.

Choosing models for the task

I have also used Kimi K2 and Claude to improve the efficiency of outputs for specific tasks, worked with agents specialized for particular jobs, and built custom small language models with fewer parameters for specialized tasks that run in the browser.

Kimi K2

Use: task-specific work where I sought more efficient outputs.

Skill: choosing a model and shaping instructions for a particular task instead of treating every request the same way.

Approach: evaluate the response against the task and refine the instructions when the output falls short.

Claude

Use: producing outputs tailored to specific tasks, with efficiency as a selection goal.

Human judgment: decide whether the response fits the task and check its accuracy before using it.

Approach: adapt instructions to the task, inspect the result, and revise before integrating it into a workflow.

Task-specific agents

Use: agents specialized for particular jobs within a larger workflow.

Skill: define a focused responsibility, provide relevant context, and assess the result against the task.

Consideration: a focused agent can still make mistakes; specialization does not remove the need for review.

Small language models in the browser

What I built: custom models with fewer parameters for specialized, specific tasks that run in browsers.

Design: small language models (SLMs) with fewer parameters, designed around a focused task.

Focus: matching model size and task scope to the constraints of a browser environment.

NotePro.
Keep the learning visible.

PDF annotation, collaborative notes, and contextual AI study tools.

Read the project story

Problem and audience

Students working with PDFs and handwritten notes need to annotate material, ask contextual questions, and inspect reasoning without repeatedly switching tools. NotePro brings those activities into a document workspace.

What I built

NotePro combines PDF annotation with EmbedPDF, collaborative text notes with BlockNote and Yjs, and Gemini assistance. The study flow includes Ask, Guide, and Solve modes, with controls for revealing answers and adding results to the page.

Keeping the student in control

Students can inspect the model’s transcription and reasoning before accepting an answer. I designed the workflow around relevant page context, visible explanations, and controls for revealing answers and adding them to the document.

A broad prompt

“Solve the problem in this image.”

Illustrative baseline: a broad request leaves the model’s interpretation of the image hidden.

A more inspectable response

“Transcribe first, into ‘read’, before you solve.”

The implemented prompt also checks lookalike symbols and requests structured fields. Exposing the transcription makes input mistakes easier to notice.

Testing the experience

NotePro’s testing covers saved annotations, document collaboration, and how the application responds when AI assistance is unavailable. I separate those product checks from answer quality: a dependable interface still needs accurate, useful explanations.

Making mistakes easier to spot

A model can reason from the wrong reading of a handwritten symbol. NotePro asks for a transcription before a solution and shows that interpretation alongside the reasoning. This gives the student a clear point to question the output instead of accepting an unexplained answer.

This design addresses a potential failure mode; it is not a claim that every handwriting error is detected.

What comes next

The product brings annotation, collaboration, and contextual study assistance into one workspace. My next priorities are evaluating a wider range of handwritten pages, gathering student feedback, and improving how the interface communicates uncertainty.

Build assistance.
Keep accountability.

Read my responsible AI statement

In accessible software development, I see generative AI as a way to make complex information easier to understand and to help developers identify possible improvements. It can explain findings, draft code changes, and support document-based learning. However, an incorrect explanation or inaccessible interaction can create new barriers, especially when a user depends on the output to understand content they cannot easily inspect another way.

Before using AI output, professionals should verify the original evidence, the relevant accessibility requirement, and the behavior of the proposed change. A clean automated scan or confident model response should never be treated as proof that a product works for everyone. Keyboard testing, assistive technology testing, and feedback from people with disabilities should inform acceptance decisions.

I would not upload credentials, private customer records, confidential source code, disability or medical information, or classmates’ personal material to a public AI system without appropriate authorization and safeguards. Data should be minimized, and access should be limited to the task.

Responsible systems should explain when AI is involved, make uncertainty visible, and provide ways to correct or challenge results. Developers should investigate bias across users and contexts rather than assuming one successful demonstration represents everyone. Final decisions about accessibility acceptance, consequential communications, and changes to other people’s information should remain under accountable human control. My principles are to protect privacy, preserve user choice, test with diverse users, document limitations, and treat AI-generated work as a proposal that must earn trust through evidence.

Research references.

View the source list
  1. W3C Web Accessibility InitiativeEvaluation Tools Overview ↗Standards organization · automated and manual evaluation · Accessed November 8, 2026
  2. Autio, C., et al. / NIST (2024)Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1) ↗Government report · Accessed November 8, 2026
  3. Deque Systemsaxe-core: Accessibility engine for automated Web UI testing ↗Official open-source project · Accessed November 8, 2026
  4. Be My Eyes (2026)Using Be My AI on desktop ↗Official product documentation · updated July 1, 2026 · Accessed November 8, 2026
  5. Xie, J., Yu, R., Zhang, H., Billah, S. M., Lee, S., & Carroll, J. M. (2025)Beyond Visual Perception: Insights from Smartphone Interaction of Visually Impaired Users with Large Multimodal Models ↗Academic preprint · Accessed November 8, 2026

Built to be readable.

This portfolio uses descriptive links, structured headings, keyboard-accessible controls, visible focus states, and text alternatives for meaningful imagery. Layout checks covered desktop and mobile widths. The research visual uses real text, and information is not communicated through color alone.

Accessibility is an ongoing practice. Full assistive-technology testing remains part of the work ahead.

Let’s build something useful.

Connect on LinkedIn