Roger Mattos

- Entrepreneur, Indie Hacker and AI
- 1 Exit
- Building

[Roger Mattos @_rogermattos]

@mikefutia REELS

[Roger Mattos @_rogermattos]

@hasan28d HK

[Roger Mattos @_rogermattos]

Google's AI Revolution in Software Engineering

37% of Google engineers' code completions are now powered by AI.

Here's what this means for the future of software development:

Just 5 years ago, most software engineers couldn't imagine how AI would transform their daily work.

Today, Google's internal data reveals a remarkable shift in how code is written.

What's working at Google:

✅ Code completion with 37% acceptance rate
✅ AI resolving 8% of code review comments automatically
✅ Smart paste adapting code to context (~2% of all IDE code)
✅ Natural language code editing in IDEs
✅ Automated build failure predictions and fixes

The key insight?

Engineers are becoming reviewers, not just writers.

The role is evolving from "how do I write this?" to "is this AI-generated code correct?"

What made these tools successful:

- Seamless integration into existing workflows
- One-click/tab acceptance, no complex triggers
- Continuous learning from real usage data
- Focus on high-impact and technically feasible features
first

The next wave isn't just about code generation.
Google sees AI expanding into:

→ Test automation
→ Code understanding and maintenance
→ End-to-end workflow automation (from bug detection to fix deployment)
→ Natural language as the primary interface for development tasks

The conclusion:

We're moving from AI that helps write code to AI that helps think through entire engineering problems.

The transformation is happening faster than anyone predicted.

The question isn't whether AI will change software development, it's how quickly teams can adapt to this new reality.

What's your experience with AI coding tools?

Are you seeing similar adoption patterns in your organization?

#SoftwareEngineering #ArtificialIntelligence #DeveloperTools #CodeCompletion #TechInnovation #GoogleResearch #FutureOfWork

[Roger Mattos @_rogermattos]

🎯Your product team might be building in a vacuum without even knowing it.

I just read about Boddle Learning a company that created educational games that kids literally BEG their parents to buy. Their secret?

They threw out the traditional playbook.

What most teams do wrong:

- Engineers execute tickets
- PMs manage roadmaps
- Designers refine flows
- But nobody actually listens to users

What Boddle did differently:

They got ruthlessly close to their users. CEO Clarence Tan and his team didn't just send surveys they sat in classrooms, watched kids play, and studied real reactions.

When COVID hit, they offered their games free to schools.

Result?

50,000 users overnight. Their servers crashed, but the product worked because it was built with genuine empathy.

The brutal truth:

It doesn't matter how good your technology is if nobody wants to use it.

Ask yourself:

- Can your engineers describe users without reading a persona document?

- When did your designers last sit with real user feedback?

- Is your roadmap shaped by internal goals or real user pain?

Speed without understanding isn't innovation. It's waste.

Proximity to users beats assumptions every time.

What's your experience with user-centered product development?

Share your thoughts below 👇

[Roger Mattos @_rogermattos]

@JViertelBTG It's hard to say, but with the fast growing of LLMs capacity and AI code tools like Claude CLI and Gemini CLI, it will occur soon a near future.

But i think it won't replace totally (at least now) a Sr. Engineer that will spend more time orchestrating the tools than coding.

[Roger Mattos @_rogermattos]

The Future of Coding is Here (And It's Not What You Think)

Build a full SaaS app in 10 days. Here's how "vibe coding" is changing everything for senior engineers.

Forget everything you think you know about AI coding.

This isn't about junior developers copy-pasting from ChatGPT.

"Vibe coding" with models like Claude Sonnet 4 is a superpower for experienced engineers who know what they're doing.

The game has changed:

What took weeks now takes hours

A full-featured app? 10 days instead of months

Code is no longer expensive, your judgment is!

But here's the catch:

You need experience to wield this power effectively.

The 6 essentials I've discovered:

1️⃣ Great Scaffold – AI needs rich examples to learn from. Start with a solid monorepo setup.

2️⃣ Strong Rules – Use .cursor/rules to codify your conventions. Make AI behave like a clean, accountable junior engineer.

3️⃣ Perfect Context – AI has amnesia. Open every relevant file, especially TypeScript definitions. Don't be stingy with context.

4️⃣ Smart Editor – Cursor beats CLI tools. You need fast linting and the ability to redirect mid-generation.

5️⃣ Top Models Only – Claude Opus 4, Sonnet 4, Gemini 2.5 Pro. Your time is worth more than token costs.

6️⃣ Audio Prompts – Sometimes rambling into voice-to-text works better than perfectly formatted requests.

The secret sauce?

Prompting like you're managing a talented but overeager junior:

→ Always demand a plan before coding
→ Be ridiculously specific about outputs
→ Use constraints liberally
→ Keep scope tight (AI loves to wander)

What AI still can't do:

❌ Automatic context management
❌ Proper TypeScript types (defaults to any too often)
❌ Architectural taste and design patterns

Your role as senior engineer:

Architecture, taste, and keeping the AI on track.

This might be our "last hurrah" where human engineers still matter for guidance.

The tooling is magical, the velocity is intoxicating, and we're still essential.

Time to embrace the magic while we can.

What's your experience with AI-assisted coding?

Are you seeing similar productivity gains?

#SoftwareDevelopment #AI #Coding #ProductivityHacks #SeniorEngineer #Claude #TechTrends

[Roger Mattos @_rogermattos]

The AI browser automation framework

https://t.co/ABDoAOibgH

[Roger Mattos @_rogermattos]

PyIceberg is a Python library for programmatic access to Iceberg table metadata as well as to table data in Iceberg format. #Python #PyIceberg #dataengineering

https://t.co/2aYaj0DWwg

[Roger Mattos @_rogermattos]

The Reality of Product-Led Growth

Unpopular opinion: Your product doesn't need MORE features. It needs SHARPER focus.

Lessons from John Rush, an entrepreneur who built 25 startups without raising a single penny of capital.

His secret?

"I only build products 100% aligned with my way of thinking."

This statement is impactful because most of us are doing product-led growth completely wrong.

We think product-led means:
✅ Apps packed with features
✅ Frictionless free trials
✅ Viral loops in everything

But it actually means:
🎯 Building for problems YOU experienced
🎯 Solving ONE thing incredibly well
🎯 Making your product feel inevitable to users

Here's the reality:
→ You don't need 10 features to get 1 user
→ You can get 100 users with 1 perfect feature
→ Growth comes from fluency, not features

Winning founders don't ask: "What does the market want?"

They ask: "What did my past self desperately need?"

When you build from that place, you:
- Know the problem intimately
- Use your product daily
- Identify friction before anyone reports it
- Create something that feels "obvious" to your users

Bottom line:

Stop over-building. Start over-solving.

Your product doesn't need to be brilliant, it needs to be sharp.

What's the ONE feature your users can't live without?
Share below! 👇

#ProductLed #StartupLife #ProductManagement #Bootstrapping #Entrepreneurship

[Roger Mattos @_rogermattos]

Every IKEA engineer works retail shifts. Here are lessons on managing at scale from their EM.

Most engineers think: legacy = bad code. At IKEA, legacy = billions in revenue working perfectly for decades.

Nikolay, Engineering Manager at IKEA's Group Digital, shared counterintuitive insights about managing engineers in "real" businesses vs. startups:

- The "Anti-Corruption"

Practice Every engineer spends one day annually putting pillows on shelves and helping customers. This keeps them connected to who they're really building for.

- The Humility Reality Check

New engineers often think: "This tech looks old, I'll fix everything!" Reality: A business this successful didn't grow by accident. What seems inefficient is often accumulated wisdom from solving real problems over time.

- From Push to Pull Leadership Nikolay's biggest EM lesson:

Stop pushing your ideas through logic and start pulling insights from your team through guiding questions. "Arguments don't work when there's no trust. I was silencing quieter engineers who might have had better ideas."

- The 60-70% Specification Rule

They don't wait for perfect requirements. Engineers step in as problem solvers when specs are incomplete, working with POs to clarify and seek access to underlying problems.

The Lesson: Managing engineers in established companies requires different skills than startups:

- Respect for existing systems
- Deep business knowledge
- Patience with "boring" but critical infrastructure
- Focus on sustainable pace instead of hero culture

What's your experience with legacy systems?

Are they always the enemy, or sometimes the foundation that keeps everything running?

#EngineeringManagement #TechLeadership #IKEA #LegacySystems #TeamBuilding

[Roger Mattos @_rogermattos]

Pydoll is a library for automating chromium-based browsers without a WebDriver, offering realistic interactions.

https://t.co/T31kTo6Qnx

[Roger Mattos @_rogermattos]

https://t.co/UOlIuoNF78

[Roger Mattos @_rogermattos]

APIs for the AI World

Did you know that your APIs might be costing a fortune for AI systems?

Every word your API sends costs money to process.

Yes, literally every word.

We’re living in a new era of software development.

First, we created interfaces for humans. Then, we created APIs for other software.

Now? We’re creating APIs for AI.

And here’s the problem: AI doesn’t behave like traditional software.

5 things that have changed forever:

Every byte costs money
- 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝗔𝗰𝗰𝗼𝘂𝗻𝘁𝗜𝗱𝗲𝗻𝘁𝗶𝗳𝗶𝗲𝗿 vs 𝗰𝘂𝘀𝘁𝗜𝗱 = 4 tokens vs 2 tokens
- Multiply that by thousands of calls per day
- Result: a hefty bill at the end of the month

AI is 100x slower
- Traditional software: milliseconds
- AI: seconds
- A simple conversation can turn into a 10-second wait

AI tries to fix itself
- When something goes wrong, AI tries again
- Automatically changes parameters
- Looks for other ways to solve the issue

AI is unpredictable
- It can “forget” what it was doing
- Calls APIs in a different order
- Interprets the same response in different ways

Your documentation has become code
- AI reads your examples and follows them exactly
- If you show “try 3 times,” AI will try 3 times
- Error in documentation = error in production

What does this mean for you?

If you develop APIs, you need to think differently now.

It’s no longer just about making it work.

It’s about making it work intelligently.

Some companies are already doing this:
- PayPal has a “verbosity” parameter
- Stripe created a toolkit specifically for AI
- Google is creating an “agent-to-agent” protocol

The future arrived faster than we thought.

In a few years, “dumb” APIs might not even exist anymore. The future is intelligent systems talking to other intelligent systems.

The question isn’t IF this will happen. It’s WHEN.

And you? Have you thought about how your APIs work with AI?

I created an infographic with 5 Design Principles for AI-First APIs!

Share your experience in the comments! 👇

#AI #APIs #SoftwareDevelopment #Technology #Innovation

[Roger Mattos @_rogermattos]

Infographic - https://t.co/UOlIuoNF78

[Roger Mattos @_rogermattos]

APIs for the AI World

Did you know that your APIs might be costing a fortune for AI systems?

Every word your API sends costs money to process.

Yes, literally every word.

We’re living in a new era of software development.

First, we created interfaces for humans. Then, we created APIs for other software.

Now? We’re creating APIs for AI.

And here’s the problem: AI doesn’t behave like traditional software.

5 things that have changed forever:

Every byte costs money
- 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝗔𝗰𝗰𝗼𝘂𝗻𝘁𝗜𝗱𝗲𝗻𝘁𝗶𝗳𝗶𝗲𝗿 vs 𝗰𝘂𝘀𝘁𝗜𝗱 = 4 tokens vs 2 tokens
- Multiply that by thousands of calls per day
- Result: a hefty bill at the end of the month

AI is 100x slower
- Traditional software: milliseconds
- AI: seconds
- A simple conversation can turn into a 10-second wait

AI tries to fix itself
- When something goes wrong, AI tries again
- Automatically changes parameters
- Looks for other ways to solve the issue

AI is unpredictable
- It can “forget” what it was doing
- Calls APIs in a different order
- Interprets the same response in different ways

Your documentation has become code
- AI reads your examples and follows them exactly
- If you show “try 3 times,” AI will try 3 times
- Error in documentation = error in production

What does this mean for you?

If you develop APIs, you need to think differently now.

It’s no longer just about making it work.

It’s about making it work intelligently.

Some companies are already doing this:
- PayPal has a “verbosity” parameter
- Stripe created a toolkit specifically for AI
- Google is creating an “agent-to-agent” protocol

The future arrived faster than we thought.

In a few years, “dumb” APIs might not even exist anymore. The future is intelligent systems talking to other intelligent systems.

The question isn’t IF this will happen. It’s WHEN.

And you? Have you thought about how your APIs work with AI?

I created an infographic with 5 Design Principles for AI-First APIs!

Share your experience in the comments! 👇

#AI #APIs #SoftwareDevelopment #Technology #Innovation

[Roger Mattos @_rogermattos]

Framework Tip:
https://t.co/NtBXyrCiJ8
#AWSS3 #S3 #OSS

[Roger Mattos @_rogermattos]

For those who want to see the Infographic in a dynamic way, here's the link to the online artifact - https://t.co/WupC0NVZ6Z

[Roger Mattos @_rogermattos]

How Cursor Built a $500M Company in Just 2 Years

This programming tool went from $0 to $500M in revenue in just 24 months. Here's how they did it.

Most companies take over 10 years to reach $500M. Cursor did it in 2.

The secret? They didn't try to build everything from scratch.

Here's their smart approach:

✅ They copied what worked. Instead of building a new code editor, they took VS Code and made it better. This saved years of work.

✅ They chose the right tools

- TypeScript for most of the programming (easy to use)
- Rust for the super-fast parts (impressive speed)
- Smart mix of both languages

✅ They solved the privacy problem. Your code never leaves your computer. Their AI helps you program without seeing your secrets.

✅ They made everything extremely fast. Code suggestions appear in less than 1 second. That's faster than blinking twice.

The numbers are impressive:
→ 50 engineers total
→ 1 million requests per second
→ Used by half of Fortune 500 companies
→ Over 100 million lines of code written daily

3 main lessons for any startup:

1️⃣ Don't reinvent the wheel - Build on what already works

2️⃣ Speed matters more than perfection - Aim for quick results first

3️⃣ Privacy builds trust - Keep user data secure

The best part?

They did this with just 50 people.

Sometimes, the fastest path forward is to start with something that already works and make it 10x better.

I created an AI Infographic showing the Architecture, Stack Analysis and Strategies of the #Cursor team! 👇

#Startup #Engineering #AI #SaaS #TechStrategy #Innovation #Cursor

[Roger Mattos @_rogermattos]

The Hero Manager Problem!

"Don't worry, the manager will handle it!"

Many engineering managers love hearing this. It makes them feel important and needed.

But here's the hard truth:

Being the "hero manager" actually hurts your team.

Here are 3 hero patterns that happen everywhere:

1️⃣ The Fixer Manager

What it looks like: They jump in to solve every difficult problem. They become the person everyone looks for when things break.

Why it's bad: The team never learns to solve difficult problems on their own. The manager steals their best chances to grow.

Better way: Managers should step back on small problems first. Teach the team HOW to solve things. Wait 15-20 minutes before jumping in to help. Let them lead, then follow.

2️⃣ The Shield Manager

What it looks like: They hide all the company drama from the team. No bad news, no chaos, just "everything's fine."

Why it's bad: When reality hits (and it always does), the team isn't ready. They get shocked and confused.

Better way: Managers should be honest about what's happening. Share the real picture. Help the team deal with problems, don't hide problems from them.

3️⃣ The Fighter Manager

What it looks like: They fight every battle for the team - raises, time off, tools - even when the team doesn't ask.

Why it's bad: Team members never learn to speak up for themselves. The manager treats them like children who can't handle their own problems.

Better way: Managers should coach their team to fight their own battles. Sit with them, support them, but let THEM do the talking.

The truth?

These patterns make managers feel good because they get to be the hero. But they're actually making their teams weaker.

Great managers don't make people think "Wow, my manager is incredible."

They make people think "Wow, I'M incredible."

Which hero pattern do you see in your workplace? 👇

#EngineeringManagement #Leadership #TeamGrowth #Management

[Roger Mattos @_rogermattos]

Your Best Engineers Are Quietly Giving Up (And You Might Not Even Know It)

They don't send a "I'm leaving" message. They don't complain in meetings. But something changes.

The spark in their eyes disappears. They stop asking tough questions. They stop challenging bad ideas. They still do the work, but the fire isn't there anymore.

And when you notice? It's already too late.

The Silent Warning Signs

Your best professionals don't quit loudly. They leave gradually, piece by piece.

One day they're your go-to person. The next, they're just... doing the work. Nothing more.

This isn't about money or working too many hours. It's about losing the three things that keep great engineers excited:

Growth • Freedom • Purpose

When these things disappear, people don't complain. They simply disconnect.

What Really Keeps Engineers Engaged

1. Growth: "Am I improving here?"

The best engineers want to learn and grow. They don't want easy work, they want work that challenges them.

When growth stops, engagement stops too.

You don't need expensive training programs. You need to:

- Show the bigger picture
- Let them lead projects, not just follow orders
- Build learning into their daily work

2. Freedom: "Can I actually make decisions?"

Engineers don't burn out from heavy work. They burn out from meaningless work.

From waiting for someone to make all the decisions. From never having a voice in what gets built. From fixing the same problems over and over.

Good engineers want to own the results, not just write code.

Give them a real voice in what you're building and why.

3. Purpose: "Does this really matter?"

Even the most technical person wants their work to have meaning. They want to know:

- Who uses what I build?
- What problem am I solving?
- Am I improving someone's life?

When purpose disappears, even perfect code feels empty.

Bring it back by sharing user stories, connecting engineers with customers, and celebrating real impact, not just completed tasks.

The Solution Isn't a One-Time Thing

You can't solve this with a company meeting and a motivational speech.

You build engagement through small, consistent actions. Through daily choices that show your team that their growth, freedom, and purpose matter.

The best leaders don't wait until people disconnect. They protect what keeps people excited from day one.

The question:

Can you honestly say your best engineers feel they're growing, have real freedom, and see purpose in their work?

If not, they might already be quietly looking for the exit.

What keeps your best professionals engaged? What warning signs have you seen? 👇

#LeadershipTips #TechManager #TeamLead #EngineeringManager #PeopleFirst