AI is the future of development, but not as I imagined.

For developers like me, the narrative around AI is often problematic. Since the launch of ChatGPT, AI is frequently framed in a way that polarizes professionals into two extremes: on one side, there are those who fully embrace the trend, delegating as much as possible to AI; on the other, those who want nothing to do with it.

A divisive topic

Developers tend to be practical people who want to experiment and try things firsthand. The frantic rush to announce new, groundbreaking AI milestones tends to make us view LLMs (Large Language Models) with some skepticism: isn’t it all just marketing? Even within the studio where I work, Moze, opinions differ: some are more open to experimentation, while others remain uninterested, preferring the craft of coding by hand.

Until a few months ago, I found myself somewhere in the middle. My adoption was, I’d say, curious but cautious. I used Copilot X (GitHub’s generative AI coding tool) for smaller, refinement tasks: code review and documentation. In other words, a concrete and limited use case—as a co-pilot. I hadn’t gone beyond that.

Two things changed my perspective: a work project entirely focused on AI and a project born from a personal need. Let me tell you more.

The right opportunity

The first opportunity arose from a project at Moze, where a client asked us to develop an advanced chatbot.

After an initial round of research, we chose the approach that seemed the most suitable: we used OpenAI’s Assistant API, which allows integration of an AI capable of understanding and responding to natural language inputs, alongside the quick-start project for Next.js—a React-based framework in which we specialize—to build the application. We set a precise context and crafted effective prompts, meaning targeted phrases or questions that guide the Assistant in its responses, providing it with the necessary dataset for optimal performance. Done.

The chatbot worked, but with a major limitation: it was extremely inefficient. Each session demanded excessive computational power, reflected in token consumption—the units of text that the AI processes to generate a response. The higher the token count, the greater the computational and monetary costs. In this case, the costs were disproportionate to the benefits.

We asked ourselves: how could we optimize usage? And who better than an AI?

We then created a system of four agents—autonomous programs that perform specific tasks independently, working in succession:

1. The first agent optimizes and reduces instructions, trimming token use from the outset.
2. The second re-organizes the data sources on which the model operates.
3. The third prepares that dataset in the best possible way for processing.
4. The fourth checks that the work of the other agents aligns with our objectives.

Through this optimization, we significantly reduced token consumption. I won’t go further into detail on this point, both for confidentiality reasons with an ongoing project and because this isn’t an article on token optimization.

What I want to emphasize, however, is how we managed to solve the problem in a way we hadn’t initially considered, thanks to AI itself.

AI also makes clients more efficient

Many discussions on artificial intelligence focus on how much time and resources it saves (and consequently, how many professions might become redundant in the coming years).

But we didn’t just save time; we created something new with tools that didn’t previously exist or weren’t so readily accessible.

A few years ago, developing a project like this would have been far more complicated—and likely beyond our reach. Emerging tools are opening up an entirely new market, allowing more and more developers to create applications they previously couldn’t have achieved.

This is the turning point worth reflecting on.

How AI changed my work

My own work has changed. It’s as if I unlocked a new level of professional abstraction: instead of just executing tasks, I could view the project in all its complexity, taking a strategic approach and using AI to bridge the gaps.

Instead of acting like a builder, I thought like an architect. And I realized a shift in perspective: yes, AI frees me from tedious tasks and speeds up my work, but what am I going to do with this extra time?

AI offers the chance to transcend the boundaries of one’s role, enabling a developer to solve problems and close the gap between different functions. This marks the rise of the Product Engineer, as defined by Intercom and explored by Luca Rossi in his article on Refactoring, “How to Become a Product Engineer.”

The Product Engineer takes full responsibility for client issues, meaning they design solutions and manage the entire stack.

This approach works well in teams where the distance between the client and IC (Individual Contributor) is minimized. For instance, at Moze, we don’t have project managers—just designers and developers. We work closely with clients, fully immersed in the project. There are big advantages here, with only one risk: sometimes, you might lose the bigger picture.

But it’s worth asking: how can AI help me? For instance, it can allow me to test different approaches I have in mind, evaluating their benefits and drawbacks even before development begins. In other words, I’ve gained not only power but also mental time and space, which translates to higher-quality projects.

AI as a skills amplifier

As I mentioned earlier, a developer loves to experiment, to get hands-on. In this sense, even a home automation issue can become a training ground for new skills.

In my case, I needed to solve issues with a floor heating system that had poor cloud management. I couldn’t control it through Home Assistant, the core of my home automation network. I found a way to access the system using a Python program that exposes REST APIs via a WaveShare.

Now, I’m a developer, but I don’t know Python. So I gave the entire codebase to an LLM and asked it to explain the parts I didn’t understand. It did so step by step, with examples in languages I’m familiar with.

I programmed and solved the issue: I now control the temperature in full automation. I approached it with a seasoned developer’s mindset, but applied to languages I don’t know. I didn’t relinquish my role by passively delegating to AI. I remained a developer, managing the solutions proposed by AI with ingenuity and critical thinking—even in a field that isn’t my own.

With a bit more fine-tuning, I could take on challenges I previously considered out of reach, thinking I lacked the necessary skills. This experience leads me to believe that, in the future, some of the divide between front-end and back-end developers may also shrink, enabling each to better understand the other’s work when needed.

Conclusion

I understand that some innovations can be intimidating, or that excessive marketing might lead us to believe there’s little substance behind the hype. Nonetheless, my advice is to dive into AI decisively, as I’ve done in my recent projects.

I feel that if you’re a developer and don’t feel excited about what’s happening in AI today, you’re missing out on something significant. It’s a bit like not being enthusiastic about the first Macintosh computers in the ’80s. New technologies won’t threaten your job—as long as you embrace this new era from the start.

Remember, there was a time when even JavaScript, now commonly used by all professionals, was considered a language for amateurs, fit only for animating web pages. Back then, Douglas Crockford defended it with a book that made history: “JavaScript – The Good Parts.”

So, without sensationalism but with clarity, I believe AI also has its “good parts.” We have a responsibility to put them to the test.