We are at the end of a cycle, and the beginning of a new one, which always brings me back to the musings of CalTech’s Carver Mead.
Mead, best known for pioneering the automation, methodology and teaching of the integrated circuit design used in microprocessors and memories, famously implored would-be innovators to, “Listen to the technology; find out what it’s ‘telling’ you.”
Case in point, if you are building software and services as we do (at Datex Property Solutions), AI not only influences how you think about the capabilities you are baking into your offerings, but how you are actually developing them as well.
Let me take a step back. One of the core values of our company is that we “eat our own dog food,” which is to say that we embrace the same strategies in our business that we advocate clients embrace in their businesses.
Be data driven? We built SURF, our User & Usage profiling system, so we could better understand, quantify & benchmark how users actually work in Datex.
We built Tenant Track so we could surface merchant health trends and correlate them with retail occupancy and leasing activity.
Which brings me to a quandary we recently faced.
Our Internal Ticketing System & the Birds-Eye View
For 10 years, Datex has used Jira by Atlassian as our internal ticketing system. As a ticketing system, it is great. It is customizable, has a nice workflow, and surfaces all the information needed to allow our Software Engineers and Client Service Managers to know what needs to be done for that ticket.
However, Jira does not have a great way for the Director of Engineering to be able to get a birds-eye view of ALL Tickets, or be able to see what are due in a Sprint, for a Client or a Developer’s work load.
Yes, they have Filters, but honestly, it is not very useful.
About 3 years ago, we began using Monday.comas the tool to help visualize all the work that was going on at Datex (at times, we have hundreds of tickets in the pipeline).
We were able to create views based on Clients, Project Managers, Components, Developers, Sprints and Major Projects.
We ran our business on these various views.
This was all possible because Monday.com was able to pull data directly from Jira. We were probably using 20% of the capabilities of Monday.com, but what we used, made us infinitely more productive.
Flash forward to last June, and Monday.comdecided to deprecate the connection we had to Jira and wanted us to switch over to a new and “improved” API.
The problem was this new API didn’t have all the functionality of the old API, and thus our import would not work.
After many hours and emails, Monday.com told us that they would put on their road map adding the needed functionality to their new API, but while they were building it, we could continue to use the old API, albeit with limited support, which was fair.
From Broken Connections to an AI-Driven Rebirth
Then, one day the old API stopped working.
After many more emails with Monday.com, they apologized profusely, but said no more old API, and pretty much left us at a crossroads, with options that were both inferior and doubly expensive.
But, the moral of the story is NOT that we were wronged by Monday.com, but rather how what would have been a bad outcome was turned into a “get out of jail free” card thanks to Codex, an AI software engineering agent by OpenAI that functions as an intelligent coding partner.
The win was reclaiming 95% of the functionality that we had with Monday.com using Codex, including building out of the back end database, the middle tier code and the user interface.
The cost? ~18 hours of development time on a project that would have otherwise taken 150+ hours to build.
So, What Could Go Wrong?
The new solution is LIVE, and in regular use with the team.
Moreover, I have not seen or heard any red flags, so far.
That noted, the most basic type of red flag I’m watching for is the “death by a thousand cuts” risk, where getting to the “good enough” stage continues to nibble at always-scarce developer resources.
We will do a post mortem on learnings and course corrections, including stretch goals, but it does raise all sorts of open questions regarding how AI will drive developer/development process moving forward, including:
- Supportability of AI generated code
- The efficacy of having the AI generate its own documentation
- Sandboxing implications in general
- How best to backtest data and functionality validation, and general QA
- How product management scales when AI code generation scales 2-10X what you can build
- Tech stack implications
In parallel, we are scheduling a team review to better gauge how developers are using AI today in their personal projects and professionally (at Datex), so as to establish group learnings and best practices.
For example, one clear area of “low hanging fruit” with AI is prototyping, proof of concept and functional mockup builds, where efforts can sit on spectrum of: 1) POC but throw-away code; 2) Functional mockup that yields an “80/20” build, where 80% is AI and 20% is developer; and C) Where it just works.
That’s a pretty broad spectrum, making exercising discriminating awareness essential. By the same token, that shouldn’t be an excuse for letting perfect become the enemy of better.
Having been fortunate that my love of tech coincided with the birth of the PC (my first computer was a TRS-80), and that my tech career has traversed the rise of the internet and web, mobile, social, broadband and the cloud/SaaS, that won’t happen here.
The lessons of the past have taught us that AI will dwarf everything that came before it. Embracing AI is an AND not an or, and so we’re diving into the deep end of the pool.
A bit frightened of the unknown, but also really excited about the endless possibilities.
–Mark Sigal, CEO, Datex Property Solutions