, I wrote a mid-year reflection on AI developments, during which I mentioned the reported impact of AI on the unemployment rate for recent graduates, referencing a New York Times (NYT) article. And, since I’ve read the article, regardless of the point well taken, there was one sentence in it that stuck with me:
“Does the code work or not?”
To avoid taking the sentence out of context, let me share the background on how the author arrived at it.
The timely NYT story begins by discussing AI displacing the need for entry-level professionals, where the author notes that automating white-collar work has been a long-held ambition for many executives. However, the technology itself wasn’t sufficiently mature to manage the more complex and technical aspects of many jobs. At least, not until recent AI advancements, which prompted him to write:
That is starting to change, especially in fields such as software engineering, where there are clear markers of success and failure. (Such as: Does the code work or not?)
In the reporter’s defence, there are probably writing guidelines and principles that we don’t understand, resulting in a restriction and “limited space” to explain the “code work/not work” part better. That said, no hard feelings on my callout here. Nonetheless, for all the non-tech people out there, I feel a need to elaborate on a common misconception: not everything we (tech people) produce is measurable in ‘1s’ or ‘0s’. 🙂
Before I deepen my explanation, let me share a story that’s been on my mind a lot lately.
More than 14 years ago, I was doing an internship on a High-Voltage Laboratory construction project at a transformer company. Being a part of the so-called Steerco, i.e., steering committee, my tasks were to push the project forward by resolving legal and budget-related hiccups. As is often the case on construction projects, budgetary and legal problems are not so unusual when you have different professions coming together — architects, civil engineers, electrical and mechanical engineers — to build a specialised manufacturing plant with a Faraday cage.
So, five months into the project, and a mere seven months out of Uni, the project sponsors (CEOs), who were engineers by profession, noticed that the actual cost for the facade was above the estimated budget. The cost of materials listed in the preliminary budget, which significantly impacted the overall project cost, was diverging by (if I recall correctly) 40%.
Because of this, the CEOs instructed my colleague and me to inform the architect, who had over 20 years of experience, that the costs were unacceptable and that a change in materials was expected to fit the project budget.
You can imagine what happened next: I was shot down in a second.
I will never forget her saying:
We are not at a bazaar here; there is a reason why specific materials were picked for the facade. Just because everyone today has built their own storage unit at home, it doesn’t mean they are an architect who knows how to design a specialised building according to the relevant standards.
Then she added “…isolation, something, building physics, something, sub-surface, something, preliminary vs. main design, something, something…”
Of course, I returned this message, with “something, something”, to the CEOs, and what happened further was that I was shot down twice in a day with the counterstatement:
True, we are not at a bazaar, but we don’t need to pay the price for someone else’s mistake. The responsible party should take accountability and find a solution that fits our budget.
[So much about “don’t kill the messenger”, ha? ;)]
You see where I am going with this story. In the generative AI era, everyone has managed to experience what it means to be a “coder”. However, not everyone is a software engineer, nor willing to pay the salary of one if life is just as good with a “sub-optimal DIY storage unit that only you and your family members will use.” 😉
Returning to the NYT article, you can now understand why the sentence, “Does the code work or not?” stuck with me. In my head, this sentence sounded as if the coding task could be mostly simplified to: “If it (among other straightforward, binary outcomes) compiles, you can ship it.”
Again, while this was only an example (and not a false one), at least a dozen more questions should be asked to get a fuller picture and arrive at a true “working state” for any code change or implementation, such as:
…Is the current (data) architecture supporting this change?
…Is the change approved by the legal and security team?
…Is the code implemented according to development practices?
…Is the change performant?
…Is it end-to-end tested?
…Is the CI/CD process in place?
…Is the change affecting other features?
…Is the affected business team informed of the changes?
…Is the change causing higher costs?
…Is the change bringing value?
If we provide answers to all the above questions, there are still more queries to consider before we can conclude “the code works.” For example:
- Did the project budget get approved for this development?
- Who will act as a SPOC for this development?
- What’s the optimal balance between feature completeness and time to market?
- How does this impact on-call responsibilities?
- How challenging will it be to retire this development?
- To what extent does this solution scale (with growing data or users)?
- What’s the rollback strategy if issues arise?
- What documentation and knowledge transfer is needed?
- …and many more…
This is why you’ll often see tech folks passionately posting or re-sharing statements like “Coding was never the problem.” It really never was, and the real problems never have binary answers.
In other words, the challenges I’ve seen and faced involved inheriting 10–20 years of accumulated technical debt, which resulted in dedicating months, sometimes years, of human resources to maintaining fragile legacy systems, all while attempting to modernise business processes that relied on outdated technology deeply rooted in organisational decision-making.
Pivoting back to architects, I have one more story to share at the end, and it concerns a recent conversation I had with my Uni roommate, who is — you guessed it — an architect.
The two of us were talking about her experience with generative AI, where she explained how she uploaded parcel plans and prompted an LLM to deliver an initial housing project with the “famous” budget. Her observation was that while the AI output looked “beautiful,” it was completely flawed on the technical side, and it only served to generate a couple of design ideas. Then she mentioned something interesting:
You see, this was useful for me, but if my investor took the same AI tool and ran the same plan through it with the same prompt, he would never be able to deliver a standing building.
I smiled at her statement because it’s exactly what I think for now about AI delivering complete software. You can and will get the code that “works,” but without an experienced and/or knowledgeable data/AI/software engineer’s oversight and expert fixes, you’re heavily risking accumulating future technical debt.
The principles of scalability, security, and maintainability, or the “building physics” of software, are not (yet) manageable by leveraging (only) AI, and this is where the role of technical experts lies.
There’s no question that Generative AI is a powerful way to get code to a “working” state, and we should all be using it. But that isn’t where the real value lies in the development process. The real value is in the process of making sure that “working” code is doing what is supposed to do, and has existing processes around it for avoiding problems in the dedicated (data) platforms.
With this in mind, I can only conclude that a “yes, but” will usually provide an answer to “work/not work” alike questions (in any domain).👇🏼
Thank You for Reading!
If you found this post valuable, feel free to share it with your network. 👏
Stay connected for more stories on Medium ✍️ and LinkedIn 🖇️.
If you are interested in learning more about how a data science or analytics development process goes, read my post on:
