A few days ago I bought two cheap little touchscreen displays from Amazon to show me some arbitrary UI while my main display stays available for the main work. And these display actual came with touch features so I could actually use them with a Virtual StreamDeck controller and make things even more powerful.
They use the same touch controller as the Corsair Xeneon Edge, although obviously I did not know that when I bought them. I just wanted two small touchscreens connected to my Mac, each doing its own thing. I plugged them in but the touch features didn't work. And I do not mean it was slightly inaccurate or needed calibration. They behaved more like some kind of weird external trackpad than actual touchscreens. You would touch one place and macOS would interpret it in a completely different context.
At that point I had no idea what was wrong. I did not know if this was a macOS problem, a USB problem, a hardware problem, a driver problem, or some combination of all of them. More importantly, I did not really know how I would go about finding out.
This is where AI tooling has completely changed how I approach these things. Instead of deciding that this was probably not worth the rabbit hole, I asked OpenAI Codex 5.6 Sol to help me figure out what was actually happening.
We started digging. Eventually we figured out that the displays use the same touch controller as the Corsair Xeneon Edge, and that this particular controller is known to be problematic on macOS. PERFECT.
I hear you thinking "How is finding out that the thing you bought is not compatible with the thing you want to use it with"? Knowing what's wrong is way better than not knowing at all. Even if the answer is "these thing is not supported AT ALL!"
Now we had something. So I asked the obvious next question: has somebody already solved this? Or perhaps a workaround? Codex found an existing open-source project called MacXeneonEdgeTouchDriver. So we installed it and things started working. Not properly but a little bit.
And that "a little bit" was actually the breakthrough. Before that, the problem was just some black box where touching the screen produced nonsense. Now we had working code talking to the hardware. We had an entry point.
So now the questions changed. Where before we were going after "Can we make this work at all?", now we were going into the direction of "Why does it still behave incorrectly?", "Can we map each physical touch controller to the correct display?", "Can we make that survive reconnects and rearranging displays? Or a reboot?" and we eventually ended up with "Can we make taps, scrolling, dragging and double clicks behave like you would actually expect from a touchscreen?"
After a few rounds of investigating it started to feel like this was no longer a stupidly ambitious side quest. It actually looked doable. I started having Codex look into official Apple documentation for the libraries we were planning to use and had it verify that our approach was supported by Apple's coding guidelines and if that approach is valid in line with what other Mac OS utils did... After a few minutes of back and forth, it looked like we were in a good position. So I let Codex do the implementation work.
The first version came back and worked. Okay, mostly but after a few more iterations, we were there. I had both displays behaving properly in the setup I actually wanted to use. At that point, we were long beyond the "I really want this to work" and well into the "this would be nice to have too!". But before calling it "good enough", I decided that I wanted one more tweak because "why not". A total "this is dope! I love it" level of feature that I needed. That worked too.
And then I realised that I now had a fairly substantial improvement sitting on top of somebody else's open-source project.So I figured I might as well give it back.I cleaned it up, made sure the tests passed, and opened a pull request for the original author. Maybe they merge it. Maybe they won't. Maybe they look at it and decide that half of it is terrible but one idea is useful. I genuinely do not mind.
The interesting part to me is that the cost of contributing it was almost nothing. I already needed the solution for myself. Turning it into something somebody else could inspect, use or merge was just one more small step. And if it never gets merged, somebody else with the same weird setup can still find my fork and use that instead.
That is the part of AI-assisted development that I think is much more interesting than "AI can write code now." A few years ago I would not have done this. Not necessarily because I was incapable of learning it. I could have learned the APIs. I could have figured out the macOS internals. I could have worked my way through the driver code. But would I have spent days doing that for two cheap touchscreens? Absolutely not. It would never have survived the priority list. And even in the alternate universe where I did decide to spend the time on it, I probably would have built the ugliest possible fix for my exact setup, got it working, and immediately moved on.
That is what AI changed here. It made finding the problem cheap enough to bother. It made understanding somebody else's codebase cheap enough to continue. It made experimenting cheap enough to try a better solution instead of stopping at the first hack that worked. And then it made turning the result back into an open-source contribution cheap enough that there was almost no reason not to.
Maybe that produces more merged pull requests. Maybe it produces more forks. Maybe somebody takes my implementation and cleans it up. Maybe somebody tells me exactly why it is wrong and comes up with something much better. Perfect. That is the beauty of open source anyway. The work does not have to stop with the person who originally needed the fix. AI just lowered the barrier for more people to participate in that process.
For anyone curious, this is the PR: https://github.com/ajvwhite/MacXeneonEdgeTouchDriver/pull/3