Anton Adamson

AI SDLC Engineer

I design and deliver software that can be understood, checked, and shipped.

I combine engineering judgment, implementation depth, and AI-assisted delivery to move from a real problem to working software.

Discuss a role Discuss a project
14 years
Engineering and project leadership before software
Backend · Mobile · Infrastructure
Enough implementation depth to review what agents produce
Analysis → verified release
One accountable delivery loop

Selected work

Systems, process, and shipped products.

Three views of the same practice: control the work, improve the loop, deliver something real.

01 / Delivery system

Groundwork

A public set of evidence-first skills for moving from an unfamiliar codebase to an implementable plan without letting an agent invent architecture or silently expand scope.

Problem
Fast implementation can outrun understanding and review.
My role
Designed the workflow, instructions, guardrails, and verification model.
Proof
Three published skills with real document contracts for Claude, Codex, and Pi.
View Groundwork on GitHub
groundwork / pipeline public repository
01
codebase-analysis output: CURRENT_STATE.md
02
solution-design output: SOLUTION.md
03
planf3 output: implementation plan
Each stage consumes evidence from the previous one. Scope is a contract, not a suggestion.

02 / Feedback loop

AI Workday Analytics

A recurring analysis system for Claude and Codex work. It turns session history into concrete improvements for skills, instructions, hooks, runbooks, and verification habits.

Problem
Repeated friction stays invisible when every agent session is treated as disposable.
My role
Designed the deterministic collection and the evidence-led analysis workflow.
Proof
Daily Russian Markdown reports with ranked improvements and weak-evidence flags.
workday analysis redacted example
Daily review Where did the delivery loop lose time?
  1. High confidence

    A repeated tool failure needs a narrower runbook step, not another retry.

  2. Medium confidence

    A broad instruction belongs in a project skill with an executable check.

  3. Weak evidence

    Keep the observation, but do not automate until it repeats.

The output is a decision queue, not an activity dashboard.

03 / Product delivery

Product delivery

The process ends in working software: mobile products, backend services, and self-operated infrastructure. FlowTimer and bro-agent are public examples.

FlowTimer
Android day tracker, independently designed and shipped to RuStore as v1.1.0.
bro-agent
Child-facing AI assistant with persistent chats, parental event history, and fail-closed safety.
Backend
Payment, subscriptions, authorization, webhooks, and infrastructure across private systems.
Open FlowTimer in RuStore Open bro-agent
FlowTimer promotional screen for starting and tracking an interval
FlowTimer promotional timeline screen
FlowTimer promotional statistics screen
Current FlowTimer promotional mockups based on the shipping Android application.

About

Engineering judgment before software, delivery discipline after it.

I spent 14 years in engineering and project management before moving into software. Today I work across Python backend services, Swift and Kotlin applications, infrastructure, and AI-assisted delivery systems.

That background shapes how I use agents: clarify the constraints, make the work reviewable, verify the result, and stay accountable for what ships.

  1. Start with context

    Understand the real system, constraints, and current behavior.

  2. Keep the work bounded

    Choose a minimal solution and make the work easy to review.

  3. Verify what ships

    Use tests, evidence, and acceptance criteria before delivery.

  • Agentic engineering
  • Developer productivity
  • Backend systems
  • Mobile products
  • Delivery automation
  • VPS infrastructure

Contact

A role or a project. Both are good reasons to talk.

Email antony.adamson@gmail.com Telegram @Tony_Adamson GitHub tony-adamson LinkedIn Anton Adamson