2019 to 2024 · Sunnyvale, California

John Deere

Senior Software Engineer, Data and Computer Vision Platform

Blue River Technology is John Deere's AI division. For five years I built the platform underneath its computer vision teams: the path a camera frame takes from a tractor in a field to a trained model, and back again when that model gets something wrong.

field to model loop

From field-camera datato trained models

At Blue River Technology, I built the path from machine cameras to model updates: labeling workflows, Databricks datasets, AWS validation, live tests, and production feedback.

1field data

2labeling workflows

3Databricks tables

4AWS training workflows

5live validation

6production feedback

Platform work

Platform layers behind production computer vision.

Field to model

Petabyte-scale computer vision data from test fields and production tractors

Storing the images was never the hard part. Making them searchable was. Test rigs and production spray tractors produced streams that model development had to reach into every day, and trace backwards through whenever a model called a crop a weed.

Data

Petabytes

Sources

Fields and tractors

Ingest, organize, enrich, and query field imagery alongside the machine events around it.
Debugging loops that traced a model failure back to the frame, the label, the metadata, and the field it came from.
Access patterns spanning lake queries, staged datasets, APIs, and machine-learning-ready feature views.

◇field → model lifecycle

petabyte-scale

sources · streamingimagery + machine events

test fieldscamera rigs

spray tractorsfleet · live

ingest · continuous frame capture

data lake · organized + searchableenrich → query

raw frame

geolocationmachine eventcrop + weed labelsfield context

access patterns

lake

queries

staged

datasets

image

interfaces

feature

views

machine-learning-ready feature views

model developmenttrain · evaluate · ship

training

evaluation

ship

model failureresolves back to frames · labels · metadata · field context

debug loop · failures feed re-enrichment

ingest→enrich→query→train→debug→re-enrich

Labeling operations

In-house labeling tool and job manager

Raw field imagery arrives unusable. I built the annotation platform that turned it into training data: the product surface, the backend services, job dispatch, review states, schema changes, and the handoff into computer vision datasets.

Annotation APIs, review queues, assignment logic, and worker-backed job processing.
Quality-control loops so labels could be reviewed and corrected instead of re-cut from scratch.
Dataset handoff paths that made labeled frames findable at training and debugging time.

+annotation canvas

human in the loop

classes

crop

weed

soil

crop · 0.98weed · 0.87polygon

frame 0488 · 3 of 5 labeledtool · bounding box

job managerreview queue · 24

Raw frames

queued1,420 in

Label job

in progress6 workers

Quality review

in review2 reviewers

Dataset handoff

doneto computer vision

review rejects loop back to relabel · enrich · correct · reuse

Machine learning operations

The first shared training cluster

Every team ran its own training machinery. I stood up the first shared community cluster on AWS and wired orchestration, continuous integration, artifacts, releases, and data access into one path teams could repeat.

Kubeflow and Argo-style orchestration for repeatable training and evaluation runs.
Continuous integration, artifact management, and deployment paths around fast-moving model code.
One route from a research notebook to a scheduled job to a production pipeline.

Machine learning operations

Shared operating layer

Cloud

AWS

Scope

Shared cluster

Before · scattered

Perception

own machinery

Mapping

own machinery

Agronomy

own machinery

After · community cluster

One shared AWS cluster

first of its kind

AWS shared cluster

Repeatable training / evaluation pipeline

Commit

code

Build

test

Run

Argo

Train

job

Evaluate

metrics

models

Deploy

serving

evaluation feeds the next run

Continuous integration

fast-moving code

Artifact registry

models + data

Data access

lake + tables

Deployment

serving paths

Platform services wired into every run

Databricks lakehouse

Change data capture into model-ready tables

Databricks is where operational data became something a model could train on. I built the lakehouse side: change data capture off production systems, the transforms on top, and the notebooks teams debugged incidents from.

Change streams from operational systems, landed as analytical tables.
Transforms that kept field and production events current for computer vision workflows.

streaming lakehouse pipeline

near real time

sources

operational systems

operational database

row changes

field metadata

machine context

machine + model outputs

inference events

change data capture

stream

+insert

~update

−delete

transform · medallion

ascending quality

01raw

landed change events

02refined

cleaned + deduplicated

03enriched

joined + feature-ready

Delta

enriched Delta tables → model-ready signal

consumers

computer vision workflows

fresh field + production events

notebooks + jobs

explore · enrich · validate · debug

operational change→captured→transformed→model-ready signal

Developer experience

Internal developer kits and live testing

I shipped the reusable kits and test harnesses engineers used daily: querying the lake, staging examples, exercising APIs, inspecting images, and running live tests against real data paths.

Clients for lake queries, service connectors, image APIs, and database access.
Live testing that validated field-facing behavior without waiting on a release.

dev kit session

query · stage · predict · live test

users

engineers

surface

APIs + notebooks

devkit · console

›kit.lake.query("field_run_id = 4821")

↳1,284 frames

›kit.images.stage(sample_set)

↳staged · 64

›kit.client.api.predict(frame)

↳1 box · 0.94

›kit.live_test.compare(prediction, label)

↳matchpass

image inspectorframe 0188

prediction 0.94label · crop

prediction vs label: match

query result4 rows · overlap 0.91

frame_01880.94✓

frame_01890.91✓

frame_01900.88✓

lake client

query

image API

predict

notebook

investigate

test harness

validate