Building ChefCollect: The side project that AI helped me actually finish
ChefCollect started as a Christmas break experiment with extracting recipes from cookbook …
I was on a train to London on Tuesday morning. Seatfrog upgrade, first class, table, space, coffee. The kind of setup where you expect to get a decent amount done.
Except normally, you do not.
Train WiFi is still terrible, and mobile signal drops in and out. A few years ago that would have meant one thing: no real development work. Maybe emails, maybe some local tinkering, but nothing particularly meaningful.
That morning started a bit differently.
I was stood on the platform before 7am, having just been working on a personal side project. One of my coding agents had outlined a full set of manual test plans across the platform. I did not want to leave my personal laptop running for the next couple of days while I was away, so I had Copilot generate a set of GitHub Issues to break the work down and then shut everything down before heading to the station.

While I was standing there, it occurred to me that even though my laptop was off, Copilot was not.
So, using the GitHub app on my phone, I tagged one of the parent issues and watched as Copilot picked it up and started working on it server side.
By the time I was on the train, settled in, and working through 200 unread emails from the day before on my work laptop, my phone pinged. Copilot had finished and opened a pull request with the test suite.
That should not have worked as smoothly as it did, so I pushed it a bit further. I had Copilot review its own work, which checked out, then bulk assigned the remaining tickets and let it carry on. At that point I was not “coding” in the traditional sense at all. I was setting direction and letting the work continue.
What should have gone wrong there is obvious. No connectivity, dropped sessions, failed API calls, lost context. Modern engineering workflows assume stable, fast internet, and on a train you simply do not have that.
But because the work had been handed off to cloud-based agents, none of that really mattered. The processes just carried on. I could get through emails, drink my coffee, and check in when I had signal. The work did not stop just because my connection did.
The slightly strange part was how normal it started to feel. I had set the direction, given guidance, and then left it to run. Coming back to it later, everything was still there, context intact and progress made.
At one point I was back in a better signal area, just past the same stretch of countryside you always notice on that route, and I picked things up again while continuing with my actual day job. Building out scaffolding for a new platform, reviewing PRs, the usual flow. At that point I effectively had two independent streams of work happening: my side project progressing on its own, and my actual work continuing as normal.
I was not multitasking or context switching. One of those streams just did not require me to be constantly present.
The other interesting part is how this all happened across different surfaces. Laptop at home, phone on the platform, work machine on the train. CLI, GitHub mobile, email. No IDE in sight.
It did not even feel like a “session” anymore. It felt more like directing a distributed team, even if that team was technically just me and a set of agents. A couple of years ago, the only way this would have been possible was carrying multiple machines and trying to juggle them. Beyond being impractical, it also would not have been appropriate. I was travelling for work, using that time to get through emails and manage a few projects, not to be switching between my job and a personal side project. Trying to run both laptops side by side would have been a form of job switching that I have always avoided. This approach meant the work could continue without me needing to do that.
Now it just works.
This is not really about convenience, it is about where the work lives.
Not long ago, engineering was tied to a machine. Your IDE, your environment, your local state. Now it is something else. The repos are the same, the pull requests are the same, the CI/CD gates and controls are all still there, but the execution model has shifted. The work is not happening on the device in front of you anymore.
The IDE is no longer where the work happens. It is just one of the ways you access it.
We are moving towards what I would call location-independent engineering. Not tied to a desk, not tied to a laptop, and not even tied to a single continuous session.
There are some obvious implications. Work does not stop when your connection drops, devices become interchangeable, and you can deal with everything else in your day without blocking progress. More interestingly, you are no longer required to be constantly present for work to continue.
Engineering used to be tied to a place and a device. Increasingly, it is tied to neither, and that probably changes more about the job than we realise.

Which raises a different set of questions. If work becomes persistent and distributed like this, what happens to code review, ownership, discipline, and the way we structure our time and ceremonies?
That might be the next thing to explore.
Thank you to Winston Tjia and Bruce Mars on Unsplash for the photos used in this post (other than the header, which I took myself!)
