Interacting with people, not just LLMs

When ChatGPT first came out, I was in absolute awe. It was a mind-blowing tool that, for me, appeared out of nowhere to quickly become a pinned tab in my browser. After using it for some months, however, that awe and feeling of wonder started to turn into a sense of dread. In a way, it was way too useful. Suddenly, when facing a new problem or task, what usually took me hours of research and trial and error to archive some kind of progress, now took me a few minutes, if not seconds.

Now, almost three years later, I don’t feel that dread anymore. AI is here to stay, and it will keep improving. Sure, it has some limitations, and if you learn how it actually works, you can see that it is not as smart (or magical) as it looks. But even with the “it will hit a plateau” argument, the reality is that the most powerful technological companies in the world are all in on AI, pouring billions of dollars into making it better every day. And while I don’t believe that this iteration of AI will replace us, I do think that if you don’t take full advantage of it, you will be replaced by someone who does. But how does one take full advantage of AI? By not being just an interface between the problem and the LLM. Anyone can ask it questions, and the more experienced users can ask it really good questions. Sure, there are practical problems that you can solve with just asking a simple, two-sentence prompt (“Got error X, how do I fix it?”). But for this post, I want to focus on how to go beyond that, taking a broader view of the situation at hand instead of just focusing on the technical aspects of what needs to be done. To exemplify this, I present you with a real-life problem that I faced some years ago, before the arrival of LLMs. This problem was simple in technical terms, but profoundly complex in its implications.

The problem

I was working as a Product Owner in a small company that didn’t do software development, but rather provided operational and customer support services to other companies. The people working there knew my technical background, and from time to time they would ask for my help with small, specific issues. One day, the commercial manager came to me with a problem that, at first, seemed simple enough: “Hey Enzo! Do you have an app or something that can download a bunch of PDFs?” You see, the commercial team had some kind of “ceremony” that would happen every week, where they would all drop everything they were doing and start downloading PDFs from a list of URLs that were sent to them by email. There were several of these PDFs, and on special occasions, the number would reach the hundreds. During this ceremony, their job was to download these files and then send them to the associated customers’ email address. The structure of the data in the list was simple: each line contained a URL, followed by the customer’s name, and the period of time for which the order was placed.

https://example.com/5568c64312c06ad3ef138bb31c8e86e9|Enzo Biggio|Orders 1 Jan 7 Jan

Why did they need to do this? Because these PDFs were generated by a third-party system belonging to a company that sold gift cards in one of our virtual stores. That company, instead of sending the gift cards directly to the customers, would send this list of URLs to the commercial team for the orders that had been placed in the previous week. The PDFs contained the gift card codes that the customers needed to redeem them in associated stores, which could be physical or virtual. So, after being taken aback by the sheer amount of manual work that was being done, I started thinking about how to automate this process, which was rather easy and could be done in a few hours with a simple Python script.

The solution

Behold the mighty batch script that I ended up writing:

@echo off
for /f "tokens=1,2,3 delims=|" %%a in (giftcards.txt) do (
  if not exist "pdfs/%%c\" mkdir "pdfs/%%c"
  wget %%a -O "pdfs/%%c/%%b.pdf"
)

Yes, your eyes don’t deceive you. It’s not a Python script, but rather a Windows batch script that uses wget to download the files. It took me more time that I would like to admit to put it together from Stack Overflow threads (remember, this was before LLMs), but it worked nevertheless, making it a huge improvement over the previous manual operation. The commercial team was thrilled and I was hauled as a hero for reducing a process that took hours to just a few minutes. “Thank god we have Enzo!”, “This is just like magic!”, “Was that thing even possible?” The comments were all in good fun, but I could see that they were genuinely impressed.

Now, in 2025, the commercial manager could just upload the file with the PDF list to ChatGPT, ask it how one could download the files, and the LLM will provide in seconds a script that does exactly that. And if he doesn’t know or want to learn how to run it, he can approach it in an agentic way, asking the LLM to run and download the files for him. So how can one go beyond that? Suppose that the commercial manager comes to you with the exact same problem. How can you shine in this situation, where everyone can get the same solution in seconds?

The first step is not coding

It is easy to get caught up in the technical aspects of the problem and start thinking about how to automate it as soon as possible. After all, for many of us, that’s the most exciting and fun part of the job: to write code that moves or transforms data to help people do their jobs better. But before writing a single line of code, you should take a step back and think about what you are actually automating: the pieces that compose the process, what kind of data is being handled, and how it is being used. If you refer to my example, one could easily say “You just needed to get those PDFs, so what’s the big deal?” But what if you start thinking about the data that is being handled? What if you ask yourself “What is in these PDFs?” and “How are they used by the customers?” Are you supposed to have access to the data in these PDFs? Are you allowed to store them in your own systems? (GDPR?, HIPAA?, NDA?) Is the commercial team even allowed to have these files in the first place? I asked these questions to the commercial manager, which told me that the PDFs included sensitive information about the customers, such as their names, personal identification numbers and the gift card codes. And while the PDF files had the customers’ names on them, the gift card codes could be redeemed online without any additional verification. In practice, this meant that anyone with access to the codes could use them without the customers’ consent, essentially stealing money from both the customers and the company. These files where radioactive: holding them was a risk even if you didn’t do anything with them, since several people already had access to the PDFs (the commercial team, the third-party system, and who knows who else). So, while the technical solution was simple and effective, it had serious implications for everyone involved. What if, after proposing the solution, you were tasked with performing the operation every day? What if you were asked to store the files in a shared folder, or even worse, in a public cloud storage service? That’s not very ISO 27001 if you ask me.

Before automating a process, you should try to understand the context in which it is being done. And for that, what better way than to ask the people involved?

• What are the risks involved in handling the data?
• Who should have access to this?
• Am I allowed to even see the data?

Be clear about the implications of your solution. Notify the people involved about the risks and the potential consequences of handling the data, and stand your ground. More often than not, you will notice that people don’t know or are dismissive of these risks (“We have always done it this way”, “It’s not a big deal”, “We trust our employees”). But you should always raise these concerns, even if it means that in the end you won’t be able to write a single line of code.

Step back and zoom out

Here is where experience and knowledge come into play. If you are familiar with this kind of situations (“we need to get files from A to B automatically”), you usually start thinking about the bigger picture. “How are these files generated and stored in the first place?” That was my first question when I was asked to solve this problem. In my case, I learned that the PDFs were generated by a third-party system not under our control. It had no API or FPT access, so we had no simple way of getting the files other than downloading them by HTTP. But what if the system had an API? What if we could set up a webhook that would notify us when a new PDF was generated, and then we could download it automatically? Before even starting your favorite IDE, think about the process as a whole to identify potential improvements and not just automation opportunities. You can ask the LLM how to download these files, and he will tell you how to do it, either programmatically or with manual instructions. But you should ask yourself why it is done this way, and how it could be improved from the assumed beginning.

• Ask the person having the problem about the process at hand, and try to understand where they are coming from.
• Ask him about the systems involved in the process. He most likely won’t know much, so ask him about the person in charge of that system.
• Then, ask that other person if he can put you in contact with someone who is familiar with those systems at a technical level, so you can discuss ways to integrate it with your own platforms.

All these steps are people-oriented. And while they could end up being dead ends (which was my case), they will help you understand the problem better and get to know the key people involved (specially useful when things fail).

Understanding the consequences of your solution

Now that you have a better understanding of the problem, you can start thinking about the solution. But, just like the maxim of software architecture, “everything is a trade-off”, you should also consider the consequences of your approach before implementing it. Is not about what’s “better” or “worse”, but rather about the implications in the context of the company and the people involved. For example, in my case, I could have written a Python script that would download the files and then send them to the customers’ email addresses. But that would have meant that:

• The person in charge of the process would have to be familiar with Python and how to run scripts.
• The machine running the script would have to have access to the internet and the necessary libraries installed.
• Access to an email server to send the files to the customers.

Going the Python route would have mean that I would have needed to request admin privileges on the machine to install the necessary libraries, which would have triggered a whole process of approvals and security checks. I could have used a cloud service to run the script. However, that would have meant that I would have to expose the data to a third-party service, which was not an option due to the sensitive nature of the information (so no Zapier, no n8n, etc.). Instead, I went with the batch script, which was simple enough to run on any Windows machine without any additional dependencies. We also opted to have the script on a single, isolated machine, with an account only used for this purpose. That account that was handled by only two people: the commercial manager and me. And when the moment came to run the script, we both were there to supervise the process: the commercial manager would provide the file with the URLs, and I would run the script and check that everything was working as expected. After the script finished, I would copy the files to a personal USB drive, which was then handed to the commercial manager. After that point, the responsibility of protecting the data was exclusively his. This ritual was in no way ideal, and most people found it funny. But on a good week, especially after a big sale, the number of orders was such that the little USB drive at times held more that thousands of dollars in gift cards codes. So the less people involved in the whole ordeal, the better.

Use the LLM as your personal consultant

Once you have a working solution, you can start thinking about how to improve it. If you go back to the batch script, you will notice that it is not very robust. What if a person orders more than one gift card on the same week? The script would overwrite existing files, leaving only the last one. Also, no email is sent automatically, so the commercial team still has to do that manually. These issues, while important, were not part of what was initially requested. However, they were on my radar, and I knew that I could push for a more robust solution once I had concrete results. So after running the script for a few weeks, with the commercial team happy, I went to my manager with a proposal to improve the process, which was rapidly accepted. If you find yourself in a similar situation, you now have an incredible advantage: you can ask the LLM to help you improve the solution before even starting to implement it. Don’t just ask it to write code that does what you want, but rather:

• Ask it about the justification for its proposal (“Why do you do it this way?”).
• Ask it about alternatives to its solution.
• Ask it about potential risks and how to mitigate them.
• Give him more context about the problem (without revealing sensitive information) and ask it about blind spots that you might have missed.

Don’t become just an interface for AI

If you just ask a LLM to write a script, it will do so. And it will probably do it so well, what you will be tempted to use it as is. But that will be you just using your fingers to feed the LLM and then typing out what it returns. Instead, try to think about the people involved. Talk to them, ask them questions, put yourself in their shoes, follow them around, and listen to what they have to say. I would even go as far as to say that if you’re not annoying them a bit, you’re not doing enough. Interacting with people and understanding their concerns will always be key to be an effective problem solver, even in the age of AI. Software is still a people problem, after all.