Forem: PatrickBastosDeveloper

Working as a Dev with 100% AI: My Real Experience Inside a Bank 🤖💻

PatrickBastosDeveloper — Tue, 07 Apr 2026 20:02:26 +0000

🚀 Working as a Dev with 100% AI: My Real Experience Inside a Bank

If you had told me some time ago that I could work as a developer without actually developing, I would probably have laughed and moved on.

But today, not only is this possible, it’s already happening.

And I’m living this in practice.

🧩 The Context

I’m part of a squad in a bank here in Brazil that was chosen as a pilot to test a new way of working:

👉 Using AI as the main driver of development, not just an assistant.

No more using AI just to ask questions or generate a snippet here and there.

The idea was bold:

💡 What if AI did 100% of the technical work, and the developer became an orchestrator?

Spoiler: it works better than it sounds.

🤖 How I Used AI Before

My use of AI was pretty much what most devs do:

Ask something
Get an answer
Copy what makes sense
Adjust it manually

In other words:

AI was basically a boosted StackOverflow

Useful? A lot.

Transformational? Not really.

⚙️ The New Model: AI as the Executor

Everything changed when we started structuring how AI is used inside the development flow.

Two concepts made all the difference:

📄 AGENTS.md

Think of it as:

🧠 A behavior manual for the AI inside your repository

It defines:

Project structure
Coding standards
Conventions
Business rules
How to run, test, and validate

👉 Basically, the AI’s onboarding document

🧠 SKILLS

This is where the real power is.

Skills are capabilities that allow the AI to execute complete tasks, such as:

Creating endpoints
Fixing bugs
Refactoring code
Writing tests
Analyzing logs and identifying issues

The shift is simple, but powerful:

❌ “How do I do this?”

✅ “Solve this.”

🔄 My Role Completely Changed

Before, I used to code.

Now, I:

Define the problem
Provide context to the AI
Validate the results
Adjust direction when needed

I’ve become something between:

👨‍💻 Dev
🧠 Product thinker
🤖 AI orchestrator

And that changes everything.

📈 The Impact in Practice

🚀 Insane Speed

Things that used to take days now take hours.

No exaggeration.

AI can:

Understand the project context
Apply patterns correctly
Implement complete solutions

👉 And the best part: no repetitive manual work

🧹 Goodbye Manual Work

You know those tasks that aren’t really development?

Like:

Filling out detailed PBIs
Writing documentation manually
Creating boilerplate
Adjusting repetitive code

👉 AI just absorbed all of that.

And honestly, that was one of the biggest wins for me.

🐞 Smarter Debugging

With well-defined context (AGENTS.md + SKILLS), AI can:

Analyze errors
Suggest fixes
Apply fixes directly

It feels like:

Having a senior developer available all the time — just faster.

⚠️ It’s Not Perfect (Yet)

Of course, there are challenges:

AI needs well-written context, otherwise it gets lost
Sometimes it solves things, but not in the best way
You need to validate, you can’t blindly trust it

Which leads to an important shift:

You stop coding, but you need to understand the system much more deeply

💡 What Surprised Me the Most

It wasn’t just the speed.

It was realizing that:

🚨 The bottleneck is no longer writing code

Now the real bottleneck is:

Clarity of the problem
Quality of the context
Ability to guide the AI

And that completely changes the developer profile.

🔮 The Future (My Take)

After living this, I have a strong opinion:

Developers who only code will lose space
Developers who can think, structure, and guide AI will grow fast

👉 Code is no longer the end goal.

👉 It’s just the means.

🏁 Conclusion

This experience inside my squad was a turning point.

I went from someone who used AI as support to someone who:

💥 Works with AI as the main execution layer

And honestly?

I don’t see this going back.

👇 Final Thought

If you’re a developer, here’s my advice:

Stop asking:

“How do I do this?”

Start asking:

“Do this for me — here’s the context.”

Because the game has already changed.

🔥 Contract Testing: the bug that passes CI and breaks production

PatrickBastosDeveloper — Mon, 26 Jan 2026 12:39:47 +0000

You deploy with confidence.
Tests pass.
The build is green. ✅

Minutes later…

🔥 Production is broken because an API field changed.

If this has already happened to you (or will), this post is for you.

Recently, we’ve started adopting contract testing at the company where I work, integrating it into the set of validations that already run in our CI pipeline. The company has a strong testing culture and well-established quality standards, and the goal here was to complement what was already in place by adding more confidence to service-to-service communication. In this post, I want to share what we’ve learned so far and my practical impressions of using contract testing in day-to-day development, keeping things straightforward and free from unnecessary theory.

❌ The problem traditional tests don’t solve

In modern architectures, this is common:

Unit tests pass

Integration tests pass

Swagger is up to date

But… the API consumer breaks at runtime

Why?

Because traditional tests validate implementations, not agreements between systems.

And that’s where the real problem lives.

🤝 What Contract Tests are (no academic definition)

Contract Testing is basically this:

A formal agreement between API consumers and providers.

It ensures both sides agree on:

Payload structure

Field types

Status codes

Implicit rules (required fields, formats, etc.)

If someone breaks that agreement…
🚫 the build fails before reaching production.

💥 A simple (and painful) example

The consumer expects this:

{
  "id": 1,
  "name": "Patrick"
}

The provider decides to “improve” the API:

{
  "id": 1,
  "fullName": "Patrick Bastos"
}

✔️ Backend works
✔️ Swagger updated
✔️ Tests pass

❌ Frontend breaks
❌ App crashes
❌ The user finds out first

This bug is not about code — it’s about communication.

🛡️ Where Contract Tests come in

With Contract Testing, the flow changes:

Consumer defines expectations
↓
Contract is generated
↓
Provider validates the contract
↓
Deploy only happens if the contract is respected

In other words:

Whoever changes the API without warning… breaks their own pipeline.

And that’s beautiful ❤️

🧰 The most used tool in .NET: Pact

In the .NET ecosystem, the most mature and widely adopted tool is Pact, using PactNet.

Why Pact works so well

Consumer-Driven Contract Testing (CDC)

Tests written in C#

Versioned contracts

Automatic provider verification

Easy CI/CD integration

🧪 How this works in practice (very short version)
On the Consumer side

You write a test saying:

“When I call /customers/1…”

“I expect this response…”

That test generates a contract file.

On the Provider side

The backend runs a test validating:

“Does my API still respect this contract?”

If not:
❌ build fails
❌ deploy blocked

No production surprises.

⚠️ Contract Testing is NOT a silver bullet

Important to be clear:

❌ It doesn’t replace integration tests
❌ It doesn’t test business rules
❌ It doesn’t guarantee bug-free code

✅ It guarantees communication stability
✅ It prevents breaking changes
✅ It reduces silent incidents

🟢 When it’s REALLY worth it

Microservices

Multiple teams

Public APIs

Independent deployments

Frequently evolving endpoints

🟡 Maybe not worth it (for now)

Simple monoliths

Small teams

Joint deployments

Low complexity

✅ Quick checklist (real-world lessons)

❌ Don’t rely only on Swagger

✅ Version your contracts

✅ Let the consumer define the contract

❌ Don’t couple contracts to implementation

✅ Run contract tests in CI

✅ Fail fast

🎯 Conclusion

Contract Tests don’t prevent bugs.

They prevent surprises.

And in production, surprise usually means incident.

If your API changes without fear,
your consumer suffers without warning.

💬 Let’s talk

Have you ever broken production because of a contract?

Have you used Pact or another tool?

Are you still relying only on Swagger?

Drop a comment 👇
These pains are collective 😄

My First Experience as a Feature Lead in Technology✅

PatrickBastosDeveloper — Thu, 24 Jul 2025 21:41:53 +0000

Restructuring the Benefits Hub – A New Customer Experience

Taking the lead on this delivery was a turning point in my journey in the tech industry. The project involved a complete restructuring of a bank's benefits hub, not just a UI update, but a true transformation of the customer experience. It was a ToBe delivery, not just an AsIs. Here’s how the journey unfolded:

💥Week 1 – Business Alignment and Vision Understanding
We received the requirements from the business team. The goal was clear: transform the unified experience of three cards into a personalized journey for five cards, including two new products targeting high-net-worth clients with millionaire-level assets. Additionally, the business team wanted autonomy to configure the client experience dynamically through the backoffice, without relying on the tech team for customer-facing changes.

During refinement with the team, I was able to help the business understand that the delivery of this autonomy in the backoffice would need to be postponed to a second phase in order to meet the deadline for the main release. And that’s what we did. We had to hardcode many parts in the BFF to ensure that in the second phase, we would only need to adjust and integrate it with the backoffice.

💥Week 2 – Technical Refinement and Planning
This week was fully dedicated to technical refinement with the team, to deeply understand the expected solution, identify risks, and estimate timelines. We discussed architectural changes, potential challenges, and business impacts.

💥Week 3 – PBI Planning and Architecture Decisions
With everything aligned, we created the PBIs (Product Backlog Items) and designed the ERD (Entity-Relationship Diagram). One of the key decisions was to migrate the existing NoSQL database (MongoDB) to a SQL Server database, ensuring greater robustness and data integrity for the new business rules.

💥Week 4 – Service Development (V2)
We started development of the new version of the services (V2), keeping the current version running in parallel to avoid impacting existing customers. We also created a separate migration project, following the company's practice of decoupling migration processes from the main service.

💥Week 5 – BFF and APIM Development
We advanced with development in the BFF (Backend for Frontend) and APIM (API Management). The focus here was on ensuring performance, version control, and security for the new flows.

💥Week 6 – E2E Testing with the Mobile Team
Together with the mobile team, we ran end-to-end (E2E) tests in the staging (HML) environment. We validated the entire customer journey, service integrations, and data consistency.

💥Week 7 – Production Testing with Feature Flag
We rolled out the new experience using a feature flag for a small group of accounts in the production environment. This allowed the business team to conduct real-world testing, identify urgent fixes, and log enhancements for after the full rollout.

🚀Week 8 – Official Launch
On the first day of the eighth week, the new benefits hub was released to the public during a major event focused on the new high-net-worth credit cards. The launch was a success!

Final Thoughts

Although I’ve only been in the tech field for three years, my background in management and strategic thinking played a key role in driving this delivery. Working with a diverse team including junior, mid-level, and senior developers was incredibly enriching. Each person was essential, not only for their technical expertise but also for their commitment and shared drive to deliver.

This was a fantastic experience that confirmed something for me: I need to keep learning and going deeper into both technical and product domains, so I can contribute even more in future projects.

I was proud of myself!!😊

Code with purpose. Test with strategy. Deploy with confidence.

Beyond Code: Key Lessons I Learned from Chapter 2 - A Pragmatic Approach of The Pragmatic Programmer 📖🧭

PatrickBastosDeveloper — Wed, 16 Jul 2025 22:38:20 +0000

I recently dove into Chapter 2 of The Pragmatic Programmer and found some golden nuggets every developer should reflect on. Here’s a light recap of what stood out to me:

🔁 The Evils of Duplication
Repeating code is easy, but maintaining it becomes a nightmare. The classic DRY (Don’t Repeat Yourself) isn’t just style — it’s survival.

Each copy is a trap waiting to waste your future time.

🧲 Orthogonality
Components should be independent. If changing A breaks B, you're in trouble.

When parts of your system are too tightly coupled, every tweak becomes a bug party.

⏪ Reversibility
There's no perfect decision — but you can make them reversible. Use tools, patterns, and practices that allow you to change direction without burning everything down.

A good design gives you room to grow, not walls to crash into.

💥 Tracer Bullets
Test ideas quickly and cheaply. Fire “tracer bullets” to illuminate the path before fully committing.

Fail small. Learn fast.

🧪 Prototypes and Post-it Notes
Before coding the whole thing, simulate. It can be a sketch, sticky notes, or a quick mockup. The goal is to validate ideas early.

A bad idea killed early is better than great code thrown away.

💬 Domain Languages
Use language and abstractions that reflect the business domain. It bridges the gap between devs and non-devs.

Code that speaks the business's language is more valuable than one only the author understands.

📏 Estimating
Predicting the future is hard — but necessary. Estimating isn’t about being right, it’s about aligning expectations with your team and stakeholders.

A well-communicated guess is better than promising magic.

In the end...
Being pragmatic means thinking holistically, balancing clean code with clarity, and remembering that code is a tool — not the goal.

Code with purpose. Test with strategy. Deploy with confidence.

🚀My first tech promotion! 💻✨

PatrickBastosDeveloper — Sat, 05 Jul 2025 19:49:39 +0000

Two years ago, I was in that “Is this really for me?” phase.
Every line of code felt like a mix of fear and curiosity.
Every error in the terminal felt like the end of the world (and Stack Overflow became my best friend 😅).

But little by little, I realized it wasn’t just about coding.
It was about solving, creating, thinking, improving, growing.
And then, everything started to make sense.

I found myself in this infinite world of technology —
And the more I learn, the more I want to learn.

Today, after lots of coffee, nights of debugging, testing, commits, and restarts, I’m celebrating my first promotion! 🎉
A win that carries effort, growth, and the desire to do better every single day.

But this isn’t a period.
It’s a comma.
Because new challenges are already on the way, and I’m ready — both in code and mindset.

Let’s go.
Because those who love learning never stop evolving. 💙

Code with purpose. Test with strategy. Deploy with confidence.

When the Code Ends but the Screen Doesn't: The Hidden Cost of a Connected Life😮‍💨

PatrickBastosDeveloper — Sat, 21 Jun 2025 15:44:36 +0000

We live in the era of hyperconnectivity. As a developer, I spend at least 8 hours a day in front of a computer. At 39, having recently transitioned from an executive role to the tech field, I understand this is part of my job. The problem isn’t screen time at work — it’s what happens afterward.

In my free time, instead of disconnecting, I dive into mobile games, scroll Instagram almost on autopilot, and binge-watch YouTube videos. I have an 8-year-old son, and every time I see him imitating my habits, I feel a deep discomfort. Because in the end, it's not what we say — it's what we do that shapes who they become.

This routine, though common, is far from harmless.

🌟 The Reality: Data on Tech Dependency and Burnout

A Harvard Business Review study showed that 68% of developers have experienced burnout symptoms.

According to Common Sense Media, adults spend an average of 4.5 hours per day on social media outside of work.

The World Health Organization (WHO) has recognized burnout as an occupational condition since 2019, and excessive screen time directly contributes to symptoms like exhaustion, mental distancing from work, and feelings of ineffectiveness.

The Stanford University School of Medicine links prolonged screen exposure with sleep disorders, anxiety, and reduced social empathy.

💬 Reflection: What if We're Not Really Resting?

It's ironic that after a full day of digital connections, we seek "rest" on the very same screens that drain us. What should be leisure becomes escape. And this quiet escape steals our presence, our focus — and worse: our example.

I’m not writing this from a pedestal. I write as someone also seeking to rebalance.

📊 Practical tips I've been following to reduce screen time and regain presence

Use screen monitoring apps: I've been using Forest, but there are other tools like One Sec or Digital Wellbeing that help you monitor and limit your social media usage.

Create screen-free zones at home: Set moments like meals or bedtime as device-free.

Be intentional with leisure: Instead of impulsively opening your phone, plan offline activities — board games with your child, a short walk, or reading.

Remove social media from your home screen: This helps avoid mindless scrolling.

Be a visible role model: Tell your child what you're doing and why. Show them you're also challenging yourself.

Start digital detox routines gradually: Begin with 15 minutes less per day. Small wins create lasting habits.

--Conclusion--

Technology is amazing, but it can't be our only source of distraction, connection, and pleasure. If you also feel like you're living too much through screens, you're not alone. Change doesn't start with a revolution — it starts with a choice.

Today, I chose to look more at my son than at my phone. Tomorrow, maybe I’ll play less and talk more. Not out of guilt, but out of awareness.

And you? have you been able to disconnect? What small habit could you change today? Drop a comment and let’s support each other in this journey toward more presence and less distraction.

...Now close this tab, stretch a bit, and go live a moment offline — the internet will still be here when you get back. 😉

How to Study Programming Efficiently (Tips for Junior Devs 🚀)

PatrickBastosDeveloper — Wed, 11 Jun 2025 20:31:36 +0000

How to Study Programming Efficiently (Tips for Junior Devs 🚀)
I’ve been working as a developer for 3 years now. During this time, I didn’t have the luck of having a mentor... you know, someone who guides you, points you in the right direction, and helps you avoid getting lost along the way. Having someone like that makes things way easier! But since that’s not always the case, I’ve learned that you can manage with some strategies that work for any dev, especially if you’re just starting out.

If you’re on this journey too, check out these tips that helped me — and can help you study programming more efficiently and organized, without losing your mind:

Build your roadmap 🗺️
Forget about “learning everything at once.” Create a simple roadmap like: “Today I’ll understand JavaScript functions” or “I’ll build a small project using an API.” Small goals, big wins!
Organize your chaos (yes, even a napkin works) 📝
It doesn’t have to be fancy. It can be a checklist on paper, a sticky note, or apps like Trello, Notion, Google Keep. The important thing is to know what you’ve done and what’s next. Organization saves lives!
Embrace mistakes, they’re your best teachers 🤓
Bugs, errors, problems in code… don’t run away! They’re your most honest and persistent teachers. Every dev has been there and still is. Every mistake is a step forward... embrace it.
Code reviews are pure gold 💎
When someone reviews your code, don’t see it as criticism but as a chance to learn. See what can be improved, what worked, and even what you didn’t think about. Learning from others is top-notch.
Try the Pomodoro technique ⏲️
There are many ways to manage your time; Pomodoro is one of them. Study focused for 25 minutes, then rest 5. Repeat. It helps keep focus and avoid burnout. If you don’t like it, try another method, the key is to find what works for you.
Practice is king 👑
Reading or watching videos isn’t enough, get your hands dirty! Build projects, solve exercises, try challenges on sites like HackerRank or freeCodeCamp. The more you code, the better.
Review is a loyal friend 🔄
Go back to what you studied after a few days. It helps cement the knowledge and stops it from slipping away.
Organized environment, organized mind 🧘‍♂️
Choose a quiet place, tidy your spot, remove distractions. Focusing is way easier when your environment helps.
Connect with the community 👥
Join Discord servers, Telegram groups, forums. Asking questions, helping others, sharing experiences... all this makes you grow faster.

Quick checklist to save:

✅ Build a realistic roadmap
✅ Use any kind of organization (even a napkin works!)
✅ Love your mistakes — they teach a lot
✅ Make the most of code reviews
✅ Try time management techniques (Pomodoro or others)
✅ Code a lot
✅ Review what you learned
✅ Take care of your environment
✅ Connect with other devs

So, ready to code with focus and lightness? Drop your golden tip or questions in the comments 🚀let’s grow together!🚀

If you find this interesting, I’ll dive deeper into each topic in the future.

Code with purpose. Test with strategy. Deploy with confidence.

Beyond Code: What 📖The Pragmatic Programmer Taught Me in One Chapter

PatrickBastosDeveloper — Thu, 05 Jun 2025 19:16:10 +0000

Recently, I was invited to join a Tech Book Club founded and led by @andredarcie , a Senior Backend Software Engineer who has been gathering some of the best devs he’s encountered in nearly a decade of experience in the tech world.

📚 The book for this round was the renowned "The Pragmatic Programmer" by Andrew Hunt and David Thomas — a must-read for any developer.

We discussed the first chapter for over an hour, exchanged experiences, and had a relaxed yet super productive conversation.

💭 My understanding and first impression of the book?

🧭 What’s the book’s goal?
More than just teaching programming languages or frameworks, it aims to guide you toward becoming a more effective and efficient, responsible, and long-term-minded professional — someone who treats code like a true craft.

🧠 Chapter 1 – A Day in the Life
This opening chapter is a call for reflection: how do you conduct yourself as a developer on a daily basis?

Here are the key takeaways:

✅ 1. You are in charge of your own career
Don’t wait for your company to tell you what to learn. Stay up to date, explore new tools, and keep your radar on. A pragmatic programmer invests continuously in themselves.

✅ 2. Think before you act
It may sound simple, but many developers still code on autopilot. Question, analyze, and understand the why behind every technical decision.

✅ 3. Be proactive
Don’t wait for the system to break. Anticipate issues, propose solutions, automate processes, and document everything. Your attitude makes the difference.

✅ 4. Treat your code like craftsmanship
Your code is your legacy. Write clearly and simply, paying attention to detail. Quality matters — especially when no one is watching.

✅ 5. Don’t live with broken windows
This powerful metaphor from the book reminds us: small ignored mistakes create an atmosphere of negligence. Fix what’s wrong, even if it seems “minor.” Neglect spreads.

🚀 That’s just the beginning — and I'm already looking forward to the next chapters, which I'll certainly bring you a summary of so you can enjoy them with me!

Code with purpose. Test with strategy. Deploy with confidence.

Unit Tests... When and Where?🤔🧪

PatrickBastosDeveloper — Fri, 30 May 2025 18:40:15 +0000

Over the past few weeks, we've been restructuring our marketplace. We basically had to rebuild the project from scratch to support new business rules and migrate our database from NoSQL to SQL all without affecting the production environment experience.

Our CI/CD pipeline includes automated analysis with SonarQube to catch bugs, vulnerabilities, duplicated code, test coverage, and more.

Up to that point, everything’s great!

But then… the pipeline started failing a few times due to unit test coverage falling below the expected 70% threshold.

The problem? The uncovered areas included things like DbContext, repository classes, and even some domain entities areas that, according to best practices, shouldn't be the main focus of unit testing.

The danger of chasing high test coverage at all costs is that you end up testing things outside of your business logic like framework behavior, library internals, and implementation details that are likely to change.

✅ Focus on testing what matters: the behavior and rules of your business.
📉 High coverage doesn’t always mean high-quality tests.

Code with purpose. Test with strategy. Deploy with confidence.

👉 Here’s an article where Martin Fowler explains this much better:
https://martinfowler.com/bliki/TestCoverage.html

Kicking Off a Journey: Tech, Growth, and Everything In Between

PatrickBastosDeveloper — Sat, 12 Apr 2025 15:23:20 +0000

Hey everyone! 👋

I’ve decided to start sharing more about my journey in tech — not just the code, but everything that surrounds it.

Here you’ll find a mix of:

🧠 Hard skills — development tips, tools, and tech insights

💬 Soft skills — communication, leadership, and mindset

🔍 Curiosities — things that spark interest beyond the obvious

🚀 Professional growth — lessons learned, challenges faced, and the path ahead

Whether you're a developer, tech enthusiast, or just someone curious about how people grow in this space — welcome! Let’s learn and evolve together. 🌱

tech #softwaredevelopment #career #growth #devlife #softskills #hardskills