Why I started BostonFSD

I started BostonFSD because I am fascinated by Tesla and wanted to share what I was experiencing firsthand. The channel has a small audience. It has not taken off on social media, and although I wanted to test whether it could become financially meaningful, the results in this review do not make a compelling case for the time involved. My interest in the technology has held up much better than the business case.

What keeps my attention is the whole experience. Scheduling service, buying accessories, navigating to a charger, paying for charging. Everything feels connected, and the steps are usually as simple as I would want them to be. The closest comparison I can make is an iPhone, but a car. It is one of the most thoughtfully integrated products I have used.

Then there is Full Self-Driving (Supervised). Watching it handle roads I know around Greater Boston has changed how I think about AI. I do not think many people appreciate how capable this technology has become in the physical world. Experiencing it regularly makes that progress tangible in a way that a headline or demonstration cannot.

It has also made me more deliberate about driving. I pay attention to what the car is doing, keep my phone away, and notice more of what is happening around me. Impatience, distraction, sudden lane changes. You start to appreciate how much everyone on the road depends on everyone else paying attention. I am still responsible for the car, and that responsibility extends to the people around me. Tesla requires active driver supervision; the software does not make my Model Y autonomous.

In July 2026, I started posting drives on YouTube and X under the name BostonFSD. Tunnels, work zones, highway merges, narrow streets. I wanted a record of what the car actually did, including the hesitation and the moments that needed my involvement. The standard was straightforward: support the claims with the footage, label what comes from another source, and show or disclose takeovers. When the screen cannot be read, say so. As this project taught me, setting that standard and consistently meeting it are different problems.

Filming was the easy part. A raw recording has to be searched for moments worth showing. Speeds have to be read off a screen. Faces, license plates, and private information on the display need attention. Location metadata and cabin audio have to be removed. Then the video has to be edited, described for two platforms, packaged, uploaded, scheduled, and tracked. Repeating that process turned a video project into an operations problem.

My degree is in finance, and I spent about four years underwriting digital asset risk. That work taught me to make decisions with incomplete evidence and to distinguish what I know from what I am assuming. I brought the same habit to this experiment, including the question of whether the channel deserved the time I was putting into it.

Claude, Anthropic's AI model, wrote most of the code and ran much of the production workflow. I set the standards, made the editorial and privacy decisions, and published the videos myself. The system grew through that back-and-forth: notice a problem, explain it, build a fix, and check whether the fix actually worked.

The outputs take several forms. A Telemetry Cut is my long-form format: a whole drive, sped up when nothing happens and played in real time when something does, with a data overlay and a closing scorecard. A Short is a vertical video under a minute. Each drive or clip also produces a separate cut for X, a thumbnail, and a posting package, which is a folder holding the files to upload and the text to paste.

Two inputs, two production lanes

The footage arrives in two forms, and they need different work. The first is a native export from the Tesla app: a clip of about 30 seconds saved from the car's own cameras. The exports used in this project carry a telemetry bar along the bottom of the picture showing the gear, the turn signals, the speed, and whether the car reports that it is self-driving. The second is a cabin recording: a phone mounted behind the front seats filming an entire drive of 25 to 60 minutes. It shows the road, the steering wheel and the car's center display, and as shot it also shows the people in the car.

Those differences decide the design. An app export already carries its own evidence in the bar, so the clip lane is short: read the bar, find the event, remove the file's metadata, and build a vertical Short around the untouched picture. A cabin recording requires an extra step to read the display inside the frame, and the frame also contains private material. The long-form lane therefore starts with a privacy pass, then a screen read, and only then an edit.

The clip lane runs no tracked blur pass, produces no separate telemetry file, and ends with no scorecard. Those are differences in the implemented workflow, not a guarantee that a short road clip contains nothing identifiable. The plate miss discussed below exposed that distinction. What the two lanes share is the last stretch. Finished files are checked, a package is built, I publish, and the records are reconciled against what the platforms actually show.

One drive through the workflow

To make the long-form lane concrete, I will follow one drive from recording to publication. On 2026-09-25, at the evening rush, I recorded a drive from a parking space at Wellington Circle Plaza in Medford to Winthrop. I chose it for this article because its package is complete on disk, because it was the first drive built end to end in the current package shape, and because it was a hard case. The low sun washed out the car's screen for most of the drive, which makes it a better test of the method than a clean one would be.

The source is a single 4K phone recording a little under 25 minutes long. Everything after that is a chain of files, each built from the one before it, and none of them is edited by hand in a video editor. The edit is a script. A recipe file says which seconds of the source play at which speed, and a command-line tool called ffmpeg renders the result.

video      3840x2160 HEVC, 29.97 fps
duration   1499.6 s
audio      present (stripped downstream)
GPS tag    present (value withheld here)
caption    2026-09-25. Chipotle at Wellington Circle Plaza to
           Winthrop during rush hour. Software 2026.27.10.
           FSD v14.3.10.

display media pane          whole drive
route list and map          first 9 s
map pane                    from 1200 s to the end
passenger, right edge       every window a head shows
driver, left corner         every window a head shows
rearview mirror             tracked, whole drive
faces outside the car       every detector hit, held 0.5 s either side
license plates              every plate text recognition can read

"src_start": 3.0,  "src_end": 1325.0,
"zones": [
  [3, 20, 3],  [20, 36, 4],  [36, 70, 12],
  [70, 90, 1],            // out of the lot, real time
  [196, 214, 1],          // the I-93 merge, real time
  [214, 400, 16],         // highway
  ...  28 zones in all
],
"events": [
  {"t": 204, "dur": 6, "label": "MERGES ONTO I-93"},
  {"t": 1318, "dur": 5, "label": "THE CUT ENDS HERE · ONE
    TAKEOVER NEAR HOME, AFTER THE CUT"}
]

0:00 Cold open: it pulls itself out of the space
0:13 Out of a parking space at Wellington Circle
0:26 Out of the lot toward Boston
0:57 Onto I-93 South
1:28 The Zakim Bridge at rush hour
1:44 Two tunnels to East Boston
2:04 East Boston signals
2:35 Under the overpass, a stop sign, a red
3:26 East Boston streets
3:55 Into Winthrop and the scorecard

long-form YouTube  1.0x: frames 510  hits 22
long-form YouTube  1.5x: frames 510  hits 30
long-form X        1.0x: frames 225  hits 10
long-form X        1.5x: frames 225  hits 13
Short 01           1.0x: frames 40   hits 3
Short 02           1.0x: frames 72   hits 1
Short 03           1.0x: frames 90   hits 2
(every hit looked at on the hit sheets)

BOSTONFSD | YOUTUBE | 2026-09-25_wellington-winthrop_v14.3.10
Upload:    2026-09-25_wellington-winthrop_v14.3.10_YT.mp4
Thumbnail: 2026-09-25_wellington-winthrop_v14.3.10_YT-thumb.jpg
Schedule:  2026-10-08 17:00 ET (proposed ...); E slots

BEFORE POSTING
- Replace placeholder(s) before posting: [LONG-FORM URL]

TITLE
Tesla FSD from a parking space to Winthrop at rush hour:
I-93, the Zakim, two tunnels | v14.3.10

YouTube   public, 4:15, checked on the channel page
folder    under posted/
text file still proposes 2026-10-08, placeholder unresolved
X post    not verified for this article

Two details of this drive show why the chain matters. The first is the ending. The cut stops on a main road before my turn, and the last 174 seconds of the recording appear in no version. That stretch includes my one takeover of the drive, near home. Leaving it out is a privacy decision, but leaving it out silently would have turned a privacy decision into a misleading claim. So the video says it on screen at the cut point and again in the description: no takeover in the cut, one near home after it.

The second is that the YouTube and X versions are the same drive rendered from the same privacy master with two different recipes. The YouTube cut runs 4:15. The X cut runs 1:53, with everything at 40 times speed except four moments in real time. Neither required anyone to re-blur a face or re-read a number, because those steps happened once, upstream.

Privacy is part of production

A cabin recording leaks in more ways than I expected. My face shows in the rearview mirror and at the edge of the frame when I lean toward the screen. A passenger sits at the other edge. License plates fill the windshield in traffic. The car's display can show messages with contact names, a route list that exposes where a drive ends, and a card labeled Home. The file itself carries a GPS tag and my caption, and the audio track carries whatever was said in the car.

The first rule came from a draft I rejected. An early version cropped the picture to remove me from it. That worked, and it also removed the steering wheel and half the cabin. Keeping the wheel and cabin visible preserves context, so I asked for blur instead of crop, with the blur covering what is identifiable. The wheel alone cannot establish that a driver is attentive. An oversized blur reads as censorship, which works against a channel whose entire pitch is that it shows you everything it can.

Blur boxes cannot be placed by eye and trusted. The working rules record a day, 2026-09-01, when four hand-placed boxes missed in a single pass. The phone mount also moves, between drives and within them, so a box that covers the mirror in minute one can be covering the dashboard by minute twenty. The pipeline handles this with tracking, which means locating the same object, such as the mirror or the display, frame after frame so the blur follows it. Faces are found by a detection model, plates by text recognition on the band of the picture where the road is, and the leaky panes of the display are blurred inside its bezel while the speed and the driving state stay visible.

Every file that leaves the pipeline is written with its metadata stripped and without the cabin audio track. Then comes the step I consider the most important one in the whole system. Detection is run again, on the finished output, and every hit is put on a contact sheet and looked at. Most hits are not faces.

Enlarge

What this supports

That detector hits are reviewed and that most are false positives. It does not show that the video contains no identifiable person.

A clean detector report is therefore not proof that a video contains nothing identifiable. It is one control. The look at the output is another. Neither is a guarantee, and I would rather say that plainly than imply the pipeline is airtight.

A screen read is not a vehicle data feed

The overlay on a Telemetry Cut shows a speed, a driving state, and a small trace of acceleration and braking. It would be easy to assume those come from the car's computers. They do not. Telemetry here means data about the car over time, and mine is produced by optical character recognition, or OCR, which is software that reads text out of an image. The pipeline crops the car's display out of the phone recording and reads the digits, four times a second on this drive. It is a reading of a picture of a screen.

Enlarge

What this supports

That the overlay presents a screen read and labels its derived trace. It is a presentation example, not independent validation of each displayed value.

That distinction changes how each value should be trusted, and I ended up sorting what the overlay shows into five kinds of evidence. Underwriting taught me to keep an observed fact, an attribution, and a calculation in separate columns, and this is the same discipline applied to a dashboard.

The washed-out screen on this drive is why the numbers are what they are. Across the whole recording, 1,852 of 5,996 samples produced a speed, which is 31 percent. Through a short gap the overlay holds the last value it read. Once a gap runs past eight seconds, it shows a dash and the words NO SCREEN READ. I would have preferred a complete trace. I prefer an honest gap to an invented one.

The rule for any number that reaches a title, a description, a thumbnail or the overlay is two independent confirmations from the footage, or one source from outside it, such as the Tesla app's trip history. The word independent is doing real work in that sentence. On this drive, two reading passes agreed within 2 mph on 81 of the 87 seconds they shared. That is useful, and it is weaker than it sounds, because both passes read the same pixels of the same recording. Agreement between them shows the readers are consistent. It does not show the number is true.

Enlarge

What this supports

That a missing speed is left missing. It does not by itself establish the driving state.

An open disagreement between my own records

• The frame: the state label reads SELF-DRIVING, in a tunnel.
• The telemetry file: the row for that second records the state as read from the path tint, not held.
• The package notes: state reads are described as covering moving samples outside the tunnels.
• The published description: it says the state label shows NO READ in the tunnels.

These do not agree for this frame. I have not gone back to the source frames to settle which record is wrong, so I am leaving the screenshot exactly as rendered and listing this as unresolved.

The same care applies to the scorecard that closes every long-form video. It scores five things from 1 to 5, in the same order each time, and each score carries a sentence stating its basis. It is my editorial judgment of one drive, in one car, with one driver.

Enlarge

What this supports

That the scorecard is an editorial assessment with stated reasons. It is not a safety rating, a controlled benchmark or a representative measure of FSD performance.

It is not a safety rating, a benchmark, or evidence about how the system performs in general. The interventions line counts the times I took over within the cut. It does not record why, and a takeover by itself establishes nothing about what the car would have done next.

Every failure became a rule

The project has a rulebook, and nearly every rule in it has a date and a failure behind it. I think that is the most transferable thing I built. A principle such as only report what the screen shows did not prevent a bad number from reaching publish-ready copy. A control that names a mechanism, such as two independent confirmations, could be checked, and so it could fail visibly. In underwriting terms, the first is an intention and the second is something you can test.

These are incidents from one small project, not benchmark results. A written rule is a control to keep testing, and several of the limits listed above are still open.

Build the handoff around the human

I upload and schedule every video myself. A scheduling service was considered early and declined, and that choice has a consequence. If a person is the last step, the system's final output should be shaped around that person's hands. By 2026-09-19 the packages had grown several folders deep, and I said that batch uploads were impractical when reaching each file took that much navigation. The current shape, settled on 2026-09-28, is flat. One folder per post. The top level holds only what I upload or paste, and everything else sits one level down.

All of the text in a package comes from one file. Titles, descriptions, tags, playlists, the pinned comment and the X post are written once, and a builder script generates a text file per platform with the fields in the order each upload form asks for them. The same script has a check mode that regenerates everything and compares it against what is on disk. It also asserts the house rules, including a YouTube title of at most 100 characters, an X post of at most 280, the supervision wording appearing exactly once, and the subscribe line being present. A placeholder link left in the text is raised as a blocker at the top of the file. The check verifies form. It cannot verify that a description is true, which is why the reading rules in the previous section exist.

The most useful distinction I learned to make is between five states that sound alike: prepared, checked, uploaded, scheduled, and public. The first two are facts about files on my computer. The last three are facts about a platform, and only the platform can report them. For YouTube that means YouTube Studio, the creator dashboard. My tracker and my folder names are records, and records drift. A reconciliation on 2026-09-09 found six videos on the channel with no tracker entry at all and five public videos whose folders still sat under scheduled.

The Wellington package showed the same gap in the October 2 review. The video is public. Its folder sits under posted. And its generated text file still proposes a 2026-10-08 slot and still lists a placeholder link to replace. Nothing is wrong with the video. The record simply trails the platform, which is the normal condition and the reason the reconciliation step exists.

On 2026-10-01 I asked for a further round of changes to cut clicks: related videos referenced by their actual title, the follow-up post on X dropped, tags and hashtags removed if they are not earning their place, long-form videos moved to Mondays, and the schedule structured and automated in the tracker. None of that was implemented in the October 2 project snapshot. The builder still requires tags and still emits the follow-up post. I mention it because a request is not a feature until the code and a test say so.

The financial experiment

I wanted to know whether the channel could become financially meaningful. The initial target was two subscribers per 1,000 views. The October refresh adds another month of evidence, but it still does not measure revenue, costs or hours worked.

The next useful test is whether I can maintain a manageable publishing schedule and whether viewers return or subscribe. Reach alone does not answer whether the work is worth its time. The refreshed evidence gives me a clearer question to test, rather than a business result to claim.

What I learned and what remains

The division of labor was clear by the end, and it is worth setting down exactly, because articles about building with AI tend to blur it in one direction or the other.

What the project demonstrates, I think, is a set of specific capabilities and not a general claim about AI. It shows a workflow that checks privacy processing on the finished output, with documented misses that still need attention. It shows screen-read data with source labels that make it possible to inspect how a value was obtained, including values that should not have survived the merge. It shows scripted editing, one-source packaging with a build-time check, reconciliation of records against a platform, recovery from a real loss of files, and analytics read against thresholds set in advance. The thread through all of it comes from my working background more than from the tools: decide what counts as evidence before you need it, keep observation apart from inference, and write the control down where it can fail.

If you want to see the output, the channel is at youtube.com/@BostonFSD and x.com/BostonFSD. I wrote about a similar arc in a hockey highlight project that turned into a system, and about choosing tools in why the best AI model depends on your workflow.

I started out wanting to post some driving videos. What I have at the end is a folder structure, a rulebook with dates in it, and a set of scripts that will not call a package finished while a check is failing. The videos are the visible part. The part I would build again is underneath them.

Considering a Tesla? You can use my Tesla referral link (code: erik750483). I may receive a referral reward if you make an eligible purchase or complete a qualifying demo drive through it. Check Tesla's current referral terms for eligibility and any available benefits.