Make AI-assisted delivery reliable and measurable.
I help engineering teams find the context gaps, review bottlenecks, and missing checks that make AI-assisted software delivery harder to trust.
Assess one AI-assisted delivery workflow.
Start with one repository or workflow. We can discuss where context, review, and release checks create uncertainty, and whether a bounded assessment would help.
Inputs
A representative task or spec, its change and review history, the checks that already exist, and any baseline measures you keep, shared under an agreed scope and permission. Sanitized samples work when source or operational records cannot be shared.
Outputs
A map of context and decision boundaries, observed gaps with the evidence behind them, prioritized changes to checks and review, and a measurement plan for a small pilot. The plan sets the baseline window, the sample, cycle and review time, rework, escaped defects, cost, comparison limits, and stop criteria before anyone claims improvement.
Fit
A good fit is an existing engineering workflow with a named reviewer and permission to inspect bounded evidence. A poor fit is a demand for guaranteed autonomous delivery, a replacement for human accountability, investment advice, or an unbounded build request. Evaluating an AI application is a separate scope with its own dataset and criteria.
An inquiry starts a conversation. We would agree on scope, access, availability, and handoff before starting. The assessment excludes implementation, model training, production access, and audit or security certification. It does not promise a particular improvement. Please use sanitized descriptions in your first message.
Discuss a workflow assessmentThe method applied to the platform that runs it: versioned specs, an AI agent fleet, and an attested merge gate.
Context observations from the same fleet: scoped spec slices for agents instead of documentation dumps.
A separate evidence kind: a retrieval application whose refusals and faithfulness are scored by a committed eval gate.
Start here
- Evaluate the platform work
Ownership, tradeoffs, and safety checks in a production platform.
- Learn the method
Start the engineering team of one lesson series.
- Try an experiment
Public demos, visualizations, and games.
What this site is
The practice also maintains a working notebook: case studies, essays, and software from Eric Caskey, a Senior Software Engineer at Amazon. He owns a multi-region workflow orchestration control plane and an infrastructure monitoring platform. The rule behind both, and behind everything published here, is that automation at scale is only as safe as the checks that run before it acts. Every workflow on that control plane passes mandatory safety checks before an automated operation begins, and nobody can opt out of the environment isolation guardrail.
The site has three parts. Case studies document independent tools, the spec-driven engineering platform, and the infrastructure that runs it, alongside orchestration, monitoring, reporting, and self-service work at Amazon and Prudential Financial. The Writing archive records how the work gets done, with essays on spec-driven development, backtesting without fooling yourself, and running an AI-assisted engineering team of one. The Lab holds working software you can use without an account: a factor-scored public stock board, a set of 3D market visualizations, a marathon coach demo, and a grader for a sample portfolio.
How the work gets done
Every feature starts as a written spec in a versioned repository. AI coding agents implement against the spec, and a local-first CI gate runs the tests, the disclosure scan, and the voice check before a push is allowed. The method is documented in the lesson series and in the essays on institutional memory and model routing, and it is the same method used to build this site.
The finance material follows one more rule. The engine grades companies on quality, valuation, momentum, and health from public data, publishes its methodology, and keeps a pre-registered record of its forecasts so they can be scored later. It is an engineering exercise in measuring your own edge honestly. Nothing here is investment advice.
Common questions
- Who is Eric Caskey?
- Eric Caskey is a Senior Software Engineer at Amazon. He owns a multi-region workflow orchestration platform and an infrastructure monitoring platform. He worked at Prudential Financial from 2013 to 2022 on enterprise monitoring, reporting, and an MFA self-service platform. He writes at caskeycoding.com and ericcaskey.com.
- What is Caskey Engineering?
- Caskey Engineering is Eric Caskey's independent engineering practice, helping teams assess context, review, and release checks in AI-assisted software delivery. Eric Caskey is a Senior Software Engineer at Amazon, and the practice publishes its method and evidence on this site.
- What is spec-driven development?
- Spec-driven development means every feature begins as a written specification in a versioned repository, and code, tests, and AI agents implement against that spec. On this site the specs live in a separate repository and a local CI gate checks every change against them before it can be pushed.
- Is the finance content investment advice?
- No. The finance tools and essays are educational engineering: a public factor engine, its published methodology, and pre-registered forecasts scored against a benchmark. Nothing on the site is a recommendation to buy or sell anything.