Category Archives: Tech Lead

3 Common Mistakes When Working with LLM Projects

As LLMs and AI agents become mainstream tools in enterprise environments, more organizations are rushing to integrate these technologies into their operational pipelines. However, teams discover too late that implementing LLM solutions requires more than just purchasing an API key and making a few calls. Here are three critical mistakes to avoid:

1. Not Having Clear Scope

Teams often approach LLM implementations with vague objectives like “improve customer service” or “enhance document processing and querying”. This lack of specificity leads to vague objectives, wasted resources, and ultimately, disappointing outcomes.

What happens: Without clear scope boundaries, teams chase endless possibilities rather than focusing on concrete deliverables. The project expands beyond initial timelines and budgets as stakeholders continuously discover new use cases.

Better approach: Define specific, measurable objectives from the start. Establish clear success criteria, identify exactly which business processes will be affected, and determine precise and expected inputs and outputs for your LLM solution.

2. Underestimating Prompting Effort

Many teams assume that interacting with LLMs is as simple as asking questions in plain English. They drastically underestimate the expertise, time, and iteration required to develop effective prompts that produce reliable, high-quality outputs.

What happens: Initial prompts produce inconsistent or low-quality results. Teams discover they need specialized skills to develop robust prompt engineering systems, and what seemed like a quick implementation turns into months of refinement.

Better approach: Budget time and resources specifically for prompt engineering. Consider it a critical component of your project that requires dedicated expertise. Plan for multiple iterations and continuous improvement of your prompting strategy.

3. Expecting No Data Preparation Needed

Perhaps the most pervasive misconception is that LLMs eliminate the need for data preparation. Project leaders often assume these models can seamlessly process raw, unstructured data with no preprocessing.

What happens: The LLM produces poor results when fed disorganized inputs. Teams discover too late that they still need data cleaning pipelines, formatting standards, and quality control mechanisms. Combined with a lack of clear scope, this leads to endless experimentation cycles where teams chase better results without addressing the fundamental data issues.

Better approach: Invest in proper data preparation workflows. Standardize your input formats, implement data cleaning processes, and create validation steps to ensure the LLM receives high-quality inputs consistently.

Conclusion

Successful LLM implementations aren’t about having the most powerful models or the latest technology—they’re about the fundamentals: clear scope definition, thoughtful prompt engineering, and diligent data preparation. These three elements can make the difference between a transformative AI solution and a costly disappointment.

These lessons came directly from my experience working on multiple real-world projects integrating LLMs into existing workflows. In each case, I observed how addressing these common mistakes earlier would have saved countless hours of frustration and significantly improved our return on AI investment.

What has your experience been with LLM implementations? Have you encountered different challenges when building solutions in real-world settings? The landscape of AI application is constantly evolving, and sharing our collective experiences can help everyone build better solutions. I’d love to hear your stories and insights in the comments below!

The Future of AI for Developers: Rethinking Productivity and Competition



Recently, I had the honor to be invited and discuss the future of AI for developers in the Red Hat DevNation SP event. Being surrounded by brilliant minds shaped my perspective on this topic, which has been widely debated since the launch of ChatGPT and the subsequent boom in generative AI.

The Productivity Fallacy

Global leaders and consultants are captivated by the promise that AI can maintain or even boost productivity while reducing workforce size, immediately connecting with cost reduction and business profit margin improvement.

While this potential exists, it overlooks a critical reality: AI capabilities are equally accessible to all competitors.

The Flaw in Static Mindset

The current AI boom mirrors the digital revolution: its disruptive potential extends across industries, with widespread accessibility and adoption becoming the norm.

Assuming competitors will remain passive in adopting AI is a strategic blind spot. In this rapidly evolving landscape, traditional performance benchmarks quickly become obsolete.

Embracing Growth in the AI Era

To stay competitive, business owners must shift their focus from maintaining current productivity levels to pursuing growth with AI—both vertically and horizontally.

Vertical growth involves enhancing existing operations by:

  • Equipping teams with AI assistants
  • Training staff in effective AI prompting
  • Selecting appropriate AI solutions for specific challenges

Meanwhile, horizontal growth focus on expanding business opportunities by:

  • Generating new content and insights
  • Revieweing and automating workflows
  • Processing natural language data

Those who embrace a growth-oriented mindset are better equipped to navigate emerging market dynamics and seize new opportunities with the potential of AI.

Conclusion

In conclusion, the integration of AI into business processes isn’t just about maintaining the status quo with fewer resources. It’s an opportunity to redefine productivity, explore new avenues for growth, and stay ahead in an increasingly dynamic and competitive market.

Making Tough Architectural Decisions

What experienced Software Architects do to make Tough Architectural Decisions in their projects?

During a meeting with experienced Architects friends, I’ve shared a difficult challenge I was facing at my work!

That driven our discussion to think about approaches we do follow to help us decide things that can have big impact and costly consequences in our projects.

Here are the four best tips and practices highlighted from our discussion:

Focus on real problem

Discussing architectures for complex problem is stressful and can become extensive. During the design process is very common to get hyped with many solutions and lose focus on the real problem.

Invest time to state the real problems you need to solve in a clear and visible way for you and your team, and revisit it frequently to stay close to your goals.

Create Proof of Concepts

Architectural patterns are solution blueprint and should be used as a reference only. There are no silver bullets, and a great way to get rid of hidden challenges is to create small Proof of Concepts to validate ideas.

Don’t be shy and create as many disposable samples as you can just to stress out potential solutions. You’ll be surprised, in a good way, how many things you haven’t covered before going through a practical exercise.

Tradeoff with involved parts

Not every tradeoff is about technology aspects. In a project, many other roles needs to contribute to have balanced weights when deciding the directions to follow.

The Managers, Product Owners, End Users, Stakeholders and also Developers, each of them can contribute with their perspectives and concerns to better drive your solution architecture.

Make sure to write documents such as Architecture Decision Records, to capture important architectural decisions made along with its context and consequences.

Think together

It’s good to have time alone and go deep on analysis during tough tradeoffs, but having someone else to discuss a solution is as valuable practice to keep focused and don’t get biased by yourself.

All these awesome tips only raised because I had to share my challenge with other Architects. Our discussion helped me to think in the problem with different perspectives 🙂

How about you? What you do when you have to make tough decisions in your project? Share with us!

Do I need to stay up to date with new technologies?

Have you asked this question to yourself before?

The chance is high.

If you are a Web Developer and try to learn every single framework or library available in the market, you’ll realize soon how INSANE task it is!

Because… it REALLY IS!

So, what can we do?

Well… I had to change the approach

Instead of looking for everything, first I had to start defining my career focus.

Ok! Wasn’t easy nor instant thing… but once I had my focus, the most effective practice to keep me updated with new and interesting technologies was to CONNECT with people that are connected with my focus!

  1. Connect with experts to learn their path and discover better ways to achieve your goals!
  2. Connect with peers to have discussions and overcome challenges together!
  3. Connect with beginners and start doing more to help them grow!

That was a game changer to clarify what is IMPORTANT for ME to learn and keep up to date.

How about you? How do you keep updated with new technologies?

Share with us! I’ll be happy to listen different ideas =)

I want to stay relevant on my Team!

While trying to become a better architect and start leading my team, I’ve asked myself many times how to stay relevant and keep growing in my career…

Did you feel the same?

It’s a common question also asked by my fellows and mentees.

And I see no easy answer since it’s subjective and our industry changes all the time!

I’ve separated three great tips that I’ve learned from my day to day to help me keep up with the team:

  1. Find your focus to become a consistent and reliable professional
  2. Understand your team’s goal to create good tradeoffs and make better decisions
  3. Help building collaborative environment to go further and achieve more with your team

How about you? Have you developed other ways to keep up with your team and career? Share with us! I’ll be happy to listen different ideas =)

To help find your focus and gain consistency, I strongly suggest reading these great titles:

How to become a good technical leader?

Some days ago, a friend of mine asked “How to become a good technical LEADER?”

The transition from developer to a technical leader position is a challenging moment…

I remember how much I struggled when I went through it.

During the process I’ve learned three precious actions that helped to improve myself and become a better leader for my team.

  • Focus on the real problem to make better tradeoffs
  • Understand my team strengths to boost their potential
  • Experience our application end-user routine to gather valuable insights

Keeping these actions in mind helped me to become a better leader for my team and focus on what matters.

How about you? Have you learned other ways to become a better technical leader?

Share with us! I’ll be happy to listen different ideas =)

Food for thoughts

If you like this content, I strongly recommend also watching this video from Simon Sinek about being a Leader:

Most Leaders Don’t Even Know the Game They’re In | Simon Sinek

4 actions to help Web Developers make good technical decisions

At some point in our development career, we collect enough experience and start leading technical decisions for our teams.

Some of them can be exciting, but others are very challenging if you don’t do the right trade-offs.

There are many approaches and plenty of content on the web. Here are my 4 essential actions to help you make good technical decisions:

Understand the business real problem

The business is the real problem and should be the root of every technical decision you do.

Rather than implement a Microservice or Monolithic architecture, use React or Angular, you can only make good choices when you understand the business real problem and put it in the center of your trade-offs.

No matter how great you craft something if no one needs it, right?

Make sure to have a clear and well-defined problem. Be present in business discussions. Connect every decision you make with the business problem it solves.

Once I thought since I’m a tech guy, I can focus exclusively on technologies and architectures, and let the business decisions to the business guys.
In the end, I see myself wasting time concerned with things with no real value and trying to fix issues no one cares about.

Evaluate your team skills

Teams are very unique. Each member has their own background and skills at different levels.

Evaluating your team skills is important to get the right tools and frameworks that enhance team productivity as a whole. Since software development is a group task, relying on a highly effective team is better and safer than on a single highly effective developer.

Involve the team members to figure out the best decisions for the whole team’s productivity. Make the entire process transparent for everyone to collect honest feedback.

Once I was responsible to decide the technology stack for a new project. I’ve made a lot of research and comparisons between the best options available at that time all by myself. When I finally came up with my “best stack”, it might have worked to build the solution but isn’t the right one for the team very late.

Experience the end-user’s routine

Experiencing the end-user’s routines is about getting closer to the real problem domain experts and developing empathy. They are who define the success of your product because they feel the pain you are trying to solve.

If you are really concerned to deliver value and make an impact on your end-users, sit on their side, and hear what they have to say. Work with them. Rich insights come from this action and can be a game-changer to success.

Once we have the opportunity to stay weeks validating the very first prototype together with the end-users, on their site. Amazing weeks! It was not easy, but every piece of feedback collected was so valuable to understand their real needs and building the right solution.

Avoid the hype complexities

All those ultimate, shiny, killer frameworks or architectures on the hype are tempting to use for any tech lovers.

Hypes tend to make us look only after the solution and forget about the real problem. When making hype-biased trade-offs, there is a high risk to adopt the wrong tool and bring unnecessary complexity to your business.

Technologies and architecture are created to help us solve a problem, not to bring more problems. Stay focused on the real problem to make non-biased and relevant trade-offs. Keep things as simple as you can.

Conclusion

In our development career, when we start leading technical decisions, we need to have a process, so we can make GOOD decisions.

Practicing the 4 essential actions in this article helped me not only make good technical decisions but also be consistently making good decisions.

How about you? Do you lead technical teams? Do you have to make technical decisions for others? I told you mine, but what is YOUR approach to making GOOD decisions consistently? Share with us!