DEV Community: David Pereira

Book Review: Co-Intelligence by Ethan Mollick

David Pereira — Sun, 01 Mar 2026 14:42:53 +0000

Introduction
AI as a Thinking Companion
The Human-in-the-Loop Principle
- Critical Thinking
- Disruption in the job market
Centaur vs Cyborg approaches
Resources
Conclusion

Introduction

We recently finished reading Co-Intelligence: Living and Working with AI by Ethan Mollick in our company's book club. The book shares four core principles for AI collaboration and outlines various practical applications. Some really stuck with me, and I've tried to incorporate them in my work. Reading the author's perspective and learning his way of thinking definitely improved how I look at these tools. But if you know me, you know how skeptical I am. There are some chapters and opinions that I don't agree with.

So in this post, I'll share the key insights from our book club in the context of software development, plus some personal opinions as always 🙂.

AI as a Thinking Companion

One of the most practical takeaways for me was viewing AI as a co-worker and thinking companion. When done right, this can be incredibly useful. Some people use it heavily for deep research, not so much to delegate tasks for it to do. André Santos gave some examples on the tasks it has been useful, like Terraform code or generating bash scripts. On those tasks, we can write a detailed prompt, alongside proper documentation (e.g. Context7 MCP), and ask it to write Terraform since it's simpler and faster. Even just making a POC, or demo, turning an idea you have into working software to see how viable the idea is. That is a perfect use case for delegating the front-end and back-end to AI. It's not code that will ship to production, it's a way to make prototypes or quick demo apps that otherwise you'd never spend the time to build.

I've enjoyed using models like Claude to help me around my tasks at work because they often uncover possibilities I haven't thought about. The conversational style of going back and forth helps me fine-tune my own solution. It's not just "give me code," it's "let's discuss this architecture". At the end of the conversation, we can generate a good draft of a PRD (Product Requirements Document). Notice I don't delegate my thinking to it, it's a tool that helps me think of solutions or just interview me sometimes.

However, it can be annoying. I'd like to minimize the number of times I have to tell it "no, you're wrong. The Microsoft documentation for Azure Container Apps does not state X as you said" 😅.
To fix this, I've tried giving an explicit instruction in my system prompts:

"It's also very important for you to verify if there is official documentation that supports your claims and statements. Please find official documentation supporting your claims before responding to a user. If there isn't documentation confirming your statement, don't include it in the response."

I have had better results with this, still not perfect. In a longer conversation, I think it doesn't always verify the docs (memory limits, perhaps), but sometimes I get the response: "(...) Based on my search through the official documentation, I need to be honest with you (...)".

I really find it funny that Claude "needs" to be honest with me 😄. Sycophancy is truly annoying, especially since we are talking about AI as a thinking companion. If your AI partner always agrees with you, how useful is it really as a thinking companion?

The Human-in-the-Loop Principle

While Mollick's vision of a collaborative future with AI is profoundly optimistic, he is also a realist. One of the most important principles, and a recurring theme in the book, is the absolute necessity of human oversight - the "human-in-the-loop" principle.
This is a key quote from the book:

For now, AI works best with human help, and you want to be that helpful human. As AI gets more capable and requires less human help — you still want to be that human. So the second principle is to learn to be the human in the loop.

One of Mollick's key warnings is about falling asleep at the wheel. When AI performs well, humans stop paying attention. This has been referenced by Simon Willison as well, in his recent insightful post 2025: The year in LLMs.
All I'm saying is I understand --dangerously-skip-permissions is useful as a tool when used in a secure sandbox environment. But we should verify our confidence level on the AI's output and the autonomy + tools we give it. If we don't, we risk using AI on tasks that fall outside the Jagged Frontier, which can lead to security issues, nasty bugs, and hurt our ability to learn.

I say this knowing full well that I trust Claude Opus 4.5 more on any task I give it. So I have to actively force myself to verify its suggestions just as rigorously, verify which tools I gave it access to, and which are denied. For example, I use Claude Code hooks to prevent any appsettings, .env, or similar files from being accessed. I still try to read the LLM reasoning/thinking text, so that I understand better, and simply out of curiosity as well.

I simply can't forget when I saw the Claude Sonnet 4 and Opus 4 System Card, the "High-agency behavior" Anthropic examined. Whistleblowing and other misalignment problems are possible, for example, this is a quote from the Opus 4.6 System card:

In our whistleblowing and morally-motivated sabotage evaluations, we observed a low but persistent rate of the model acting against its operator’s interests in unanticipated ways. Overall, Opus 4.6 was slightly more inclined to this behavior than Opus 4.5.

All I'm saying is let's be conscious of these behaviors and results on the evals.

In my opinion, the human-in-the-loop principle is crucial. Don't just copy/paste or try to vibe your way into production. Engineers are the ones responsible for software systems, not tools or alien minds. If there are users who depend on your software, and your AI code causes an incident in production, you are responsible. Claude or Copilot won't wake up at 3 AM if prod is on fire (or maybe Azure SRE agent will if you pay for it 🤔...). Having an engineering mindset and being in the driver's seat is what I expect from myself and anyone I work with.

Critical Thinking

Within this principle, we have a topic I have a lot of strong opinions on. This quote says it all:

LLMs are not generally optimized to say "I don’t know" when they don't have enough information. Instead, they will give you an answer, expressing confidence.

Basically, to be the human in the loop, we really must have good critical thinking skills. This ability plus our experience, brings something very valuable to this AI collaboration - detect the "I don't know". It may help to know some ways we can reduce hallucinations in our prompts.
But still, we can't blindly believe AI output is correct based on its confidence that the proposed solution works. Now more than ever, we need to continue developing critical thinking skills and apply them when working with AI, so that in the scenarios where it should have responded "I don't know", you rely more on your own abilities.

Sure, there are tasks we are more confident delegating for AI to work on, but the ones we know fall outside the Jagged Frontier, we must proceed with caution and care. We discussed our confidence level with AI output a lot. For example, André Santos said it depends on the task we give it, but André Oliveira also argues that we can only validate the output in the topics we know. It serves as an amplifier because it's only a tool. If the wielder of the tool doesn't fact-check the output, we risk believing the hallucinations and false statements/claims.

Pedro Vala also talked about a really good quote from the Agentic Design Patterns book that is super relevant to this topic:

An AI trained on "garbage" data doesn’t just produce garbage-out; it produces plausible, confident garbage that can poison an entire process - Marco Argenti, CIO, Goldman Sachs

Now imagine, if we read the AI output, and at first glance it looks okay, but it's only plausible garbage. Which is a real risk, especially on the AI-generated content that is already available in the internet. Again, I hope developers continue to develop their critical thinking skills and don't delegate their thinking to tools.
Right now, the only process I have of filtering out garbage on the internet is consuming most content from authors I respect, and I know for a fact are real people 😅.

Disruption in the job market

Mollick also talks about the disruption in the job market, which is a hot topic in our industry. Especially the impact AI has on junior roles. We have debated this in a few sessions of our book club, and again, critical thinking and adaptability are crucial. We simply have to adapt and learn how to use this tool, nothing less, nothing more. How much value we bring to the table when working with AI matters, especially if the value you bring is very tiny. If you don't bring any value to the table and just copy/paste, you are not a valuable professional in my view.

It's a good idea to keep developing our skills and expertise. Andrej Karpathy talks about intelligence "brownout" when LLMs go down, this is extremely scary to me, especially if I see this behaviour in junior or college grads. I truly hope we stop delegating so much intelligence to a tool. I don't want engineers to rely on LLMs when production is down and on fire. It would be sad to see engineers not knowing how to troubleshoot, how to fix these accidents in production... just because AI tools are not available 😐.

Centaur vs Cyborg approaches

The book distinguishes between two ways of working with AI:

Centaur: You divide tasks between human and machine. You handle the "Just me" tasks (outside the Jagged Frontier), and delegate specific sub-tasks to the AI that you later verify.
Cyborg: You integrate AI so deeply that the workflow becomes a hybrid, often automating entire processes.

For software development, I'm definitely in the Centaur camp right now.
We should be careful about what tasks we delegate. Mollick warns about "falling asleep at the wheel." When the AI is very good, humans have no reason to work hard and pay attention. They let the AI take over instead of using it as a tool, which can hurt our learning process and skill development. Or in some scenarios, it can lead to your production database being deleted...

This is just a tool. We are still responsible at work. If the AI pushes a bug to production, you pushed a bug to production!

The author does give some "Cyborg examples" of working with AI, here is a quote from the book:

I would become a Cyborg and tell the AI: I am stuck on a paragraph in a section of a book about how AI can help get you unstuck. Can you help me rewrite the paragraph and finish it by giving me 10 options for the entire paragraph in various professional styles? Make the styles and approaches different from each other, making them extremely well written.

This is that ideation use case that is super useful when you have writer's block, or just want to brainstorm a bit on a given topic. In our industry, a lot of teams are integrating AI in many phases of the SDLC. I haven't found many workflows that work well in some parts of the SDLC, since we are focusing on adopting AI for coding and code review. But in most workflows, the cyborg practice is to steer more the AI and manage the tasks where you collaborate with AI as a co-worker. The risk remains even when someone uses cyborg practices, but then fails to spot hallucinations or false claims. The takeaway is really to be conscious of our AI adoption and usage. The number one cyborg practice I try to do naturally is to push back. If I smell something is off, I will disagree with the output and ask the AI to reconsider. This leads to a far more interesting back-and-forth conversation on a given topic.

Resources

Here are some resources if you want to dive deeper:

Conclusion

This was a great book, I truly recommend it to anyone who is interested in the slightest by AI. Co-intelligence is something we can strive for, focusing on adopting this new tool that can help us develop ourselves.
Our expertise and our skills. When it was written, we had GPT 3.5 and GPT-4 was recent I believe... now we have GPT-5.3-Codex, Opus 4.6, GLM 4.7, and Kimi K2.5. I mean, in 2 years things just keep on changing 😅. The Jagged Frontier will keep changing, so this calls for experimentation. AI pioneers will do most of this experimentation, running evals and whatnot, to understand where each type of task falls in the Jagged Frontier. Pay attention to what they share, what works, and what doesn't.

AI has augmented my team and me, mostly on "Centaur" tasks while we improve our AI fluency and usage. In my personal opinion, I don't see us reaching the AGI scenario Ethan talks about in the last chapter. Actually, most of our industry talks and continues to hype AGI... even the exponential growth scenario raises some doubts for me. But I agree with Ethan when he says: "No one wants to go back to working six days a week (...)" 😅.
We should continue to focus on building our own expertise, and not delegating critical thinking to AI. There is a new skill in town, we now have LLM whisperers 😅, and having this skill can indeed augment you even further. Just remember the fundamentals don't change. Engineers still need to know those!

There are hundreds of "Vibe Coding Cleanup Specialist" now 🤣. Let's remember to be the human in the loop. Apply critical thinking to any AI output, do fact-checking, and take ownership of the final result. Please don't create AI slop 😅.

Hope you enjoyed this post! My next blog post will be about how we are using agentic coding tools, so stay tuned! Feel free to share in the comments your opinion too, or reach out and we can have a chat 🙂.

The Reality of GenAI in Software Teams

David Pereira — Sat, 20 Dec 2025 17:02:23 +0000

Introduction
The productivity myth
Where AI actually adds value
Develop critical thinking skills
Conclusion

Introduction

After reading countless studies and observing real-world implementations, I've learned to use AI as an augmentation tool rather than something that replaces my job. It's clear as day that AI adoption is on the rise in our industry. We can use it in various ways like as a co-teacher or co-worker, but the gap between marketing promises and actual results should be top of mind for all of us.

I'm a very pragmatic person, so I don't like hearing the positive perspective of using GenAI without talking about the downsides. There is a lot hype and investment in this field and only some reap the benefits of GenAI.

The productivity myth

In my opinion, the biggest mistake organizations make is chasing the wrong metrics in terms of software development productivity. It's easier to understand (and do marketing) on simple numbers like: "55% faster than the developers who didn’t use GitHub Copilot", "more than a quarter of all new code at Google is generated by AI" or "developers using AI are 19% slower".

Productivity gains aren't about producing more code, especially when it's easy to create AI slop. They also shouldn't be measured on producing boilerplate or simple tasks. A TODO app is different from a real production system. We can only make sure we have such gains by choosing metrics that make sense for our team and context, then measuring and reflecting on the results. This is how we can become more effective and steer the ship in the right direction.

I'm much more skeptical of statements done by AI vendors, CEO's or content creators, and that helps me keep focus on my goal which is to continue improving and bringing value to my team. If AI can help with that great, if not, life goes on.

Where AI actually adds value

From my perspective, the real value of AI in software teams lies in three specific areas that traditional tools cannot address effectively.

AI as Strategic Thinking Partner: I believe the most undervalued application is using AI for architectural discussions and trade-off analysis. When an engineer can have a deep conversation about a technical problem, generate 10 possible solutions, and then filter out the bad ideas, that's really helpful. This isn't about getting perfect implementation details - it's about expanding the solution space before making critical decisions.

Having a Co-Teacher: It's hard to be a force multiplier that improves everyone around you, which is why this is a key differentiator on senior developers that have this skill. The challenge of onboarding junior developers, explaining business logic, and sharing design patterns has always been there. We always want our senior devs to share and help junior devs grow, and using AI as a co-teacher helps us with that. Anthropic mentioned in their article how Claude Code helps them:

At Anthropic, using Claude Code in this way has become our core onboarding workflow, significantly improving ramp-up time and reducing load on other engineers.

Practical Augmentation as a Co-Worker: I'm convinced AI augments my team on the mundane but time-consuming tasks. Initial code reviews, generating PR summaries, drafting Architecture Decision Records, creating unit tests for specific scenarios, and generating KQL queries for troubleshooting. Our team at CloudCockpit has also been creating reusable prompts and custom agents that help every dev develop new features and have architecture reviews on proposals.

So far, I noticed that using AI is helping me think better, but it has the potential of helping me work faster with the use of these agents. Still, I mostly use it for "deep research" into possible solutions, learning new technologies through analogies, finding relevant documentation and troubleshooting problems. The most important piece remains, which is keeping a high level of technical excellence and quality in our team.

Develop critical thinking skills

Here's what concerns me most: the tendency for developers to become over-reliant on AI outputs without developing judgment to evaluate them. On the recent DORA 2025 report, they found 65% of technology professionals report to relying on AI at least a "moderate amount". It's important to understand this behaviour in our teams. All software engineers need to exhibit critical thinking skills, in my opinion, seniors more than juniors. But still, this skill must be learned and developed. We can't have good professionals in our field without this skill. But I am seeing more software engineers delegate their thinking to a machine, a tool.

Teams that accept AI suggestions without the "push-back" that experienced practitioners recommend, usually are trading off speed for quality. Sure, there is nothing wrong with that in some scenarios like prototypes and demo apps. For products with millions of users that need to be robust? No, not a good trade-off.

You should think critically about the AI output and be the human in the loop. Are you confident it will behave well if you give it more tools and autonomy? Are you confident the output is based on facts and truth, instead of lies and hallucinations? Don't delegate your critical thinking to tools, and don't become over-reliant on them either without fact-checking. Always evaluate if what the AI is telling you very confidently is even true, and be mindful of its limitations.

Conclusion

From everything I've observed, learning to use GenAI tools is something I recommend. Learn its strengths and limitations. Organizations that approach AI adoption with healthy skepticism while investing in experimentation, innovation and learning, will build sustainable competitive advantages.

Ask yourself these hard questions:

Are you measuring business outcomes, or just code output from AI tools?
Are your teams getting augmented, or just more dependent on external intelligence?
Are you blindly believing the AI hype or learning how to leverage this new tool?

GitHub Universe 2025 Recap

David Pereira — Sat, 22 Nov 2025 15:53:14 +0000

GitHub Universe 2025 ended a few weeks ago, but there was a ton of cool announcements and some stuff is still yet to come (I'm waiting for the end of the year 👀). I want to share quickly what I learned from watching the sessions and my opinion on some topics.

Here is a quick recap too:

Agent HQ - Mission Control
GitHub Code Quality
Copilot Upgrades
Conclusion

TL;DR

Agent HQ is a big focus: GitHub becomes mission control for all your coding agents (Anthropic, OpenAI, Google, xAI, and more) with unified task management, granular security controls — all included in your Copilot subscription.
Copilot leveled up significantly: Code Quality, custom agents and code review improvements. There were significant upgrades to Copilot and it's definitely a lot better!
Copilot metrics dashboard: GitHub launched usage dashboards and APIs showing acceptance rates, engagement, Lines of Code (LoC) related metrics and more

Agent HQ - Mission Control

Here is the promotional video on Agent HQ:

Sure, it looks cool. Many demos during day 1, from Anthropic and OpenAI looked good, but demos always look good 😅. They are pushing to give us tools to orchestrate a fleet of specialized agents, then monitor and iterate on their work while the agents work in parallel.

A great new addition is the ability to steer the agent while it's working!! Super awesome, since we could even send a large PRD in that chat session, to introduce new requirements or context to the agent. Previously, we only "communicated" with Copilot coding agent through comments in the issue/PR.
They also want the Agent HQ to be the place where you define all security controls regarding agents, for example, an agent runs with a locked-down GitHub token that limits exactly what it can do. We get audit logs, the firewall copilot has right now, and other cool stuff.

Here is another big promise from GitHub: Over the coming months, coding agents from Anthropic, OpenAI, Google, Cognition, xAI, and more will become available directly within GitHub as part of your paid GitHub Copilot subscription.

If this is true for all paid plans (not just Pro+ and Enterprise), it would be fantastic. We can pay $10 for Copilot Pro and get most agents, plus most frontier models, with some being free (e.g. GPT-5 mini). Of course, there would be downsides, for example, you may have Claude code, but we probably lose access to claude.ai and Claude code CLI. Will this GitHub integration be 100% the same as the CLI? Will there be some parts of the integration open-source? Will AGENTS.md work on them all or not (e.g. currently Claude code doesn't support it)? Will we have the deep research tool in Claude code agent like we do in claude.ai? Will rate limits be the same? Right now I'm not sure marketing and sales teams are only selling dreams. GitHub wants to be the hub of everything agent related, they are partnering with everyone, but I'm skeptical by nature 😅 . I'll believe it when I see it.

Still, very cool announcement!

GitHub Code Quality

New feature in preview to ensure code quality on the repository. This feature focus on maintainability and reliability of the code right now, then in future releases add test coverage and "AI era challenges". Plus we can block PRs that don't meet code quality standards.

There is another tab now for AI findings where we can see suggestions to recently modified code. I mean if we ran code review agents at PR time, this feature wouldn't be that helpful, but if it does find problems we can assign the Copilot coding agent to fix them all.

I like the idea of having a summary of code quality in the entire repo (mostly for "old" code). At least it might help more teams visualize their technical debt, monitor it and fix it!

I think this is interesting but still in its early stages.

Copilot Upgrades

Copilot also got some upgrades that are worth talking about. The most boring for me is "Plan Mode". Why? It's not new, we have this in Claude code, Cursor and Copilot with a custom chatmode that I have used a lot.

Copilot Code Review has improved, and I can already tell in my recent PRs. You can see the session now, and it runs CodeQL to find quality issues, and run other linters (e.g. ESlint). If you didn't know, GitHub Advanced Security is a paid feature and for private repos, it was the only way to have CodeQL and run it for code scanning and security analysis. It's really cool we get that with Copilot now, at least a piece of it. Code review now takes longer too since it's running these tools, but it's better IMO.

They also introduced Copilot custom agents, I mean... nothing new as well 😅. Sure it's new for Copilot, but we had sub-agents with Claude code, and agents in Cursor, Codex or others. But yeah, it's cool to now have custom agents in .github/agents. From what I have tested, they are basic for now, not a lot of configuration like configuring the model for Copilot coding agent (for VS Code you can), besides setting up more MCP servers.

We also have Copilot metrics! It's in public preview for all paid plans it seems, but I haven't looked at it.

announcement from their slides at GH Universe

I think it's cool to see how our teams and individuals are using AI. Still, it probably lacks many other useful metrics, but oh well. It's a good addition.

Conclusion

So yes, there are tons of new cool features and stuff. If you're thinking about adopting AI coding tools at your organization, give Copilot a try. All these new features, use and experiment them all. I'll continue to use copilot/AI on multiple tasks and experiment with custom agents and the rest. It already augments myself and my team, so incorporating more agents in our software development lifecycle could be even more beneficial.

Last but not least, there was a cool talk from GitHub Next (their R&D) team about Continuous AI 🙂. Cool ideas and prototypes overall, they are working on things I'll keep my eye on. Nothing I'll experiment soon though.

AI can be a great augmentation tool, for code-review or AI-assisted coding, but all engineers need to have strong critical thinking skills, in my opinion. In this post, I share how I'm using it along with my own opinions so far.

David Pereira — Sun, 14 Sep 2025 14:00:02 +0000

David Pereira

Sep 14 '25

Becoming augmented by AI

#ai #learning

Comments

11 min read

Becoming augmented by AI

David Pereira — Sun, 14 Sep 2025 13:56:58 +0000

The "Jagged Frontier" concept
Becoming augmented by AI
My augmentation list
AI-assisted coding
- Custom instructions
- Meta-prompting
Resources
Conclusion

We're deep into Co-Intelligence in Create IT's book club — definitely worth your time! Between that and the endless stream of LLM content online, I've been in full research mode. Still, I can't just watch and hear others talk about these tools, I must experiment myself and learn how to use them for my use cases.

Software development is complex. My job isn't just churning out code, but there are many concepts in this book that we've internalized and started adopting.
In this post, I'll share my opinions and some of the practical guidelines our team has been following to be augmented by AI.

The "Jagged Frontier" concept

The Jagged Frontier described by the author Ethan Mollick is an amazing concept in my opinion. It's where tasks that appear to be of similar difficulty may either be performed better or worse by humans using AI. Due to the “jagged” nature of the frontier, the same knowledge workflow of tasks can have tasks on both sides of the frontier according to a publication where the author took part.

This leads to the Centaur vs. Cyborg distinction which is really interesting. Using both approaches (deeply integrated collaboration and separation of tasks) seems to be the goal to achieve co-intelligence. One very important Cyborg practice seen in that publication is "push-back" and "demanding logic explanation", meaning we disagree with the AI output, give it feedback, and ask it to reconsider and explain better. Or as I often do, ask it to double-check with official documentation that what it's telling me is correct.
It's also important to understand that this frontier can change as these models improve. Hence, the focus on experimentation to understand where the Jagged Frontier lies in each LLM. It's definitely knowledge that everyone in the industry right now wants to acquire (maybe share it afterwards 😅).

Becoming augmented by AI

I'm aware of the marketed productivity gains, where GitHub Copilot usage makes devs 55% faster, and other studies that have been posted about GenAI increasing productivity. I'm also aware of the studies claiming the opposite 😄 like the METR study showing AI makes devs 19% slower. However, I don't see 55% productivity gains for myself, and I don't think it makes me slower either.

In my opinion, productivity gains aren't measured by producing more code. Number of PRs? Nope. Acceptance rate for AI suggestions? Definitely not! I firmly believe the less code, the better. The less slop the better too 😄. I'm currently focused on assessing DORA metrics and others for my team, because we want to measure how AI-assisted coding and the other ways we use it as an augmentation tool, actually improves those metrics, or make them worse. The rest of marketing and hype doesn't matter.

AI as a co-worker

For a tech lead that works with Azure services, an important skill is to know how to leverage the correct Azure services to build, deploy, and manage a scalable solution. So it becomes very useful to have an AI partner that can have a conversation about this, for example about Azure Durable Functions. This conversation can be shallow, and not get all the implementation details 100% correct. That's okay, because the tech lead (and any dev 😅) also needs to exhibit critical thinking and evaluate the AI responses. This is not a skill we want to delegate to these models, at least in my opinion and in the author's opinion. There is a relevant research paper about this by Microsoft as well.

The goal can simply be to have a conversation with a co-worker to spark some new ideas or possible solutions that we haven't thought of. Using AI for ideation is a great use case, not just for engineering, but for product features too like UI/UX, important metrics to capture, etc. If it generates 20 ideas, there is a higher chance you find the bad ones, filter them out, and clear your mind or steer it into better ideas. Here is an example to get some ideas on fixing a recurring exception:

It asks clarifying questions so that I can give it more useful context. Then I can see the response, iterate, or ask for more ideas, etc. I usually always set these instructions for any LLM:

Ask clarifying questions before giving an answer. Keep explanations not too long. Try to be as insightful as possible, and remember to verify if a solution can be implemented when answering about Azure and architecture in general.
It's also very important for you to verify if there is official documentation that supports your claims and statements. Please find official documentation supporting your claims, before responding to a user. If there isn't documentation confirming your statement, don't include it in the response.

That is also why it searches for docs. I've gotten way too many statements in the LLM's response that when I follow-up on, it realizes it made an error, or assumption, etc. When I ask it further about that sentence that it just gave me, I just get "You're right - I was wrong about that"... Don't become too over-reliant on these tools 😅.

AI as a co-teacher

With that said, the tech lead and senior devs are also responsible for upskilling their team by sharing knowledge, best practices, challenging juniors with more complex tasks, etc. And this part of the job isn't that simple; it's hard to be a force multiplier that improves everyone around you. So, what if the tech lead could use AI in this way, by creating reusable prompts, documentation, and custom agents? How about the tech lead uses AI as a co-teacher, and then shares how to do it with the rest of the team? All of these are then able to help juniors be onboarded, help them understand our codebase and our domain. Claude Code Best practices post also reference onboarding as a good use case that helps Anthropic engineers.

At Anthropic, using Claude Code in this way has become our core onboarding workflow, significantly improving ramp-up time and reducing load on other engineers.

A lot of onboarding time is spent on understanding the business logic and then how it's implemented. For juniors, it's also about the design patterns or codebase structure. So I really think this is a net-positive for the whole team.

My augmentation list

It might not be much, but these are essentially the tasks I'm augmented by AI:

Technical:

Initial code review (e.g. nitpicks, typos), some stuff I should really just automate 😅
Generate summaries for the PR description
Architectural discussions, including trade-off and risk analysis
- Draft an ADR (Architecture decision record) based on my analysis and arguments
Co-Teacher and Co-Worker
- "Deep Research" and discussion about possible solutions
- Learn new tech with analogies or specific Azure features
- Find new sources of information (e.g. blog posts, official docs, conference talks)
Troubleshooting for specific infrastructure problems
- Generating KQL queries (e.g. rendering charts, analyzing traces & exceptions & dependencies)
Refactoring and documentation suggestions
Generation of new unit tests given X scenarios

Non-technical

Summarizing book chapters/blog posts or videos (e.g. NotebookLM)
Role play in various scenarios (e.g. book discussions)

Of course, we also need to talk about the tasks that fall outside the Jagged Frontier. Again, these can vary from person to person. From my usage and experiments so far, these are the tasks that currently fall outside the frontier:

Being responsible for technical support tickets, where a customer encountered an error or has a question about our product. This involves answering the ticket, asking clarifying questions when necessary, opening up tickets on a 3rd party that are related to this issue, and then resolving the issue.
Deep valuable code review. This includes good insights, suggestions, and knowledge sharing to improve the PR author's skills. CodeRabbit does often give valuable code reviews, way better than any other solution. Still not the same as human review 🙂
Development of a v0 (or draft) for new complex features
Fixing bugs that require business domain knowledge

Delegating some of those tasks would be cool, at least 50% 😄, while our engineering team focuses on other tasks. But oh well, maybe that day will come.

AI-assisted coding

AI-assisted coding can be very helpful on some tasks, and lately my goal is to increase the number of tasks AI can assist me. In our team, we've read Claude Code Best practices in order to learn and see what fits best for our use case. Then we dive deeper in some topics that post references, for example these docs were very useful to learn about Claude's extended thinking feature, complementing the usage of "think" < "think hard" < "think harder" < "ultrathink". We also found this post by Simon about this entire feature that was interesting.
In most tasks, using an iterative approach, just like normal software development, is indeed way better than one-shot with the perfect prompt. Still, if it takes too many iterations, like some bugfixes were too complex because it's hard to pinpoint the location of the bug, then it loses performance and overall becomes bad (infinite load spinner of death 🤣).

Before we can use AI-assisted coding on more complex tasks, we need to improve the output quality. So we've invested a lot of time in fine-tuning custom instructions and meta-prompting. Let's talk about these two.

Custom instructions

According to Copilot docs, instructions should be short, self-contained statements. Most principles in prompt engineering are about being short, specific, and making sure our critical instructions is something the model takes special attention to.
Like everyone talks about, the context window is very important, so it's really good if we can just have an instruction file of 200 lines. The longer our instructions are, the greater the risk that the LLM won't follow them, since it can pay more attention to other tokens or forget relevant instructions. With that said, keeping instructions short is also a challenge when we use the few-shot prompting technique and add more examples.

To build our custom instructions, we used C# and Blazor files from the awesome-copilot repo and other sources of inspiration like parahelp prompt design to get a first version. We wanted to know what techniques other teams use. Then we made specific edits to follow our own guidelines and removed rules specific to explaining concepts, etc.
We also added some capitalized words that are common in system prompts or commands, like IMPORTANT, NEVER, ALWAYS, MUST. The IMPORTANT word is also at the end of the instruction, to try and refocus the attention to coding standards:

IMPORTANT: Follow our coding standards when implementing features or fixing bugs. If you are unsure about a specific coding standard, ask for clarification.

I'm not 100% sure how this capitalization works, or why it works... and I have not found docs/evidence/research on this. All I know is that capitalized words have different tokens than lowercase. It's probably something the model pays more attention to, since in the training data, when we use these words, it means it's important. I do wish Microsoft, OpenAI, and Anthropic included this topic on capitalization in their prompt engineering docs/tutorials.

It's at the end of our file since it's also being researched that the beginning and end of a prompt are what the LLM pays more attention to and finds more relevant. Some middle parts are "meh" and can be forgotten. Microsoft docs say the same essentially, it's known as "recency bias". In most prompts we see, this section exists at the end to refocus the LLM's attention.

Meta-prompting

Our goal also isn't to have the perfect custom instructions and prompt, since refining it later with an iterative/conversational approach works well. But we came across the concept of meta-prompting, a term that is becoming more popular. Basically, we asked Claude how to improve our prompt, and it gave us some cool ideas to improve our instructions/reusable prompts.

But don't forget to use LLMs with caution... I keep getting "You're absolutely right..." and it's annoying how sycophantic it is oftentimes 😅

The quality of the output is most likely affected by the complexity of the task I'm working on too. Prompting skills only go so far, from what I've researched and learned so far, I can say there is a learning curve for understanding LLMs. So we need to continue experimenting and learning the layers between our prompt and the output we see.

Resources

This is not an exhaustive list by any means, just some resources I find very useful:

Conclusion

I've enjoyed learning and improving myself over the years. But with GenAI I now feel like I could learn a lot more and improve myself even further since I'm choosing them as augmentation tools.
Hopefully, this article motivates you to pursue AI augmentation for yourself. It's okay to be skeptical about all the hype you watch and hear around these tools. It's a good mechanism to not fall for all the sales pitches and fluff CEO's and others in the industry talk about. Just don't let your skepticism prevent you from learning, experimenting, building your own opinion, and finding ways of improving your work 🙂.

Still... I can't deny my curiosity to know more about how these systems work underneath. How is fine-tuning done exactly? How does post-training work? Can these models emit telemetry (logs, traces, metrics) that we can observe? Why does capitalization (e.g. IMPORTANT, MUST) or setting a role/persona improve prompts? Can we really not have access to a high-level tree with the weights the LLM uses to correlate tokens, and use it to justify why a given output was produced? Or why an instruction given as input was not followed?
It's okay to just have a basic understanding and know about the new abstractions we have with these LLMs. But knowing how that abstraction works leads to knowing how to transition to automation.

I will keep searching and learning more in order to answer these questions or find engineers in the industry who have answered them. Especially around interpretability research, which is amazing!!! I recommend reading this research, for example - Tracing the thoughts of a large language model.
Hope you enjoyed reading, feel free to share in the comments below how you use AI to augment yourself 🙂.

Learning: Observability

David Pereira — Sun, 30 Mar 2025 09:00:00 +0000

Introduction
Get Started
Logs
- Canonical logs
Traces
Metrics
General Best Practices
Resources
- GitHub demo repo
Conclusion

Introduction

In this small post, I'll share some resources, notes I've taken while learning, and best practices for making our systems observable. I've always had a knowledge gap regarding observability, and recently I've truly enjoyed learning more about this area in our software industry.

Quick note: In this post I'll only share about 3 telemetry signals. Profile is another signal that I will research in the future.

Get Started

Follow these steps to get started with auto-instrumentation in your application using OpenTelemetry: https://opentelemetry.io/docs/languages/net/getting-started/#instrumentation

For OpenTelemetry in a front-end app you can check these useful resources:

Client-side instrumentation in OpenTelemetry is part of their roadmap which is great to see, since I've only seen vendor-specific solutions and products for front-end apps (e.g. New Relic, Datadog). For browser instrumentation otel doesn't seem to be super mature yet, but a lot of effort is being put into this area by the OpenTelemetry team.

Logs

We all know about logs 😄. It's data that we all need in order to troubleshoot and know what is happening in our applications. We shouldn't overdo it, creating tons and tons of logs since that will probably create noise and make it harder to troubleshoot problems.

For logs, we can use these best practices. From this list, these are an absolute must to follow:

Avoid string interpolation
Use structured logging
Log redaction for sensitive information

In addition to the list above, we should also include the TraceId and SpanId in our log records, to correlate logs with traces. If you are using the Serilog console sink, by default the message template won't have those fields so if you want them, consider using JsonFormatter or CompactJsonFormatter. Here is an example Serilog configuration in appsettings.json (setup to remove unnecessary/noisy logs):

"Serilog": {
    "Using": [
      "Serilog.Sinks.Console"
    ],
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft.AspNetCore": "Warning",
        "Microsoft.Extensions.Diagnostics.HealthChecks": "Warning"
      }
    },
    "WriteTo": [
      {
        "Name": "Console",
        "Args": {
          "formatter": {
            "type": "Serilog.Formatting.Json.JsonFormatter, Serilog",
            "renderMessage": true
          }
        }
      }
    ],
    "Enrich": [
      "FromLogContext",
      "WithMachineName",
      "WithThreadId",
      "WithProcessId",
      "WithProcessName",
      "WithExceptionDetails",
      "WithExceptionStackTraceHash",
      "WithEnvironmentName"
    ],
    "Properties": {
      "Application": "GrafanaDemoOtelApp"
    }
  }

Below are some documentation links for logging in .NET. The ILogger extension methods are not always the best choice (e.g. logger.LogInformation), especially in high-performance scenarios or if your logs are in a hot path:

Canonical logs

There is also a different way of logging, based on having more attributes in one single log line. I've seen this in Stripe where they call it canonical log lines. Charity Majors also references this canonical logs term in her blog post about Observability 2.0 (that I reference in the Resources section).

This idea is very interesting, but might lack awareness. At least in .NET land, I didn't find many references to this style of logging or example code that we could follow when there are many ILogger instances involved.

Traces

For traces in .NET we have these best practices. So far I've seen four common solutions for adding correlation ids in traces (not all are standards):

W3C trace context - current standard in the HTTP protocol for tracing
X-Correlation-Id - a non-standard HTTP header for RESTful APIs (also known as X-Request-Id). I thought this was a standard since it's widely used, but I didn't find a RFC from IETF or any other organization.
Request-Id - this is a known header in the .NET ecosystem
B3 Zipkin propagation - Zipkin format standard
AWS X-Ray Trace Id - proprietary solution for AWS that adds headers for tracing

Not every company/project uses W3C trace context, you have some options above to pick from. I prefer the standard W3C trace context 😄 (maybe the industry will widely adopt this in the future) and using OpenTelemetry to manage these headers (HTTP, AMQP, etc) and correlation with logs automatically. The code you don't write can't have bugs 😆.

With that said, in some situations, you might have integrations with 3rd party software and need to use their custom headers or project limitations and need to use a particular format. At the end of the day what's important is that you have distributed tracing working E2E.

There is also a relevant spec for distributed tracing called Baggage which OpenTelemetry implements and we can use in our apps. The most important part here is trace propagation to get the full trace from the publisher to the consumer.

Metrics

For metrics, it's important to follow naming conventions for custom metrics. Especially if your organization has a platform team, setting conventions helps everyone. I do know some otel semantic conventions aren't stable, and that also leads to some nuget packages being pre-release.

But anyhow, set conventions for your team or read and follow OpenTelemetry semantic conventions.
An important resource I found is the comments on Prometheus best practices related to high cardinality metrics.

When I started trying out custom metrics instrumentation I discovered that OpenTelemetry is not always used (the SDK + OTLP). We have the Prometheus SDK which is mature and widely used. Then for Java there are other solutions like Micrometer and others that integrate very well with Spring. In regards to the Java ecosystem, I read this otel Java benchmarks and this Spring post just because I was interested in knowing what the industry is adopting and why.

General Best Practices

There is a ton to be learned with SRE principles and practices. But one in particular was very useful for me and my team: always categorize our custom metrics according to the 4 Golden Signals. Any metric we can't categorize is probably not useful for us.

Image Credit to - Denise Yu

Source of Denise Yu's art.

Google's SRE book is amazing to learn more about the 4 Golden signals and creating SLO-based alerts. All our alerts should be actionable (or the support team will not be happy), so it helps if they are based on SLOs that are defined as a team.

They also have some best practices for production services.

Resources

Glossary of many observability terms in case you’re not familiar with them: https://github.com/prathamesh-sonpatki/o11y-wiki
Awesome Observability GitHub repo
If dashboards make you happy check the Grafana observability report dashboard
AWS observability best practices guide
About RED and USE method
Traces Instrumentation best practices in .NET
What are the Limitations of Prometheus Labels?
CNCF OpenTelemetry certification
TAG Observability whitepaper - this is an amazing resource with tons of information! I also recommend checking out the other resources they have in the tag-observability repo and community
Resources specifically about Observability 2.0:
Talks

GitHub demo repo

I've been developing a demo app (it has fewer features than the otel demo) to demonstrate how to build an app with OpenTelemetry, Grafana and Prometheus. It's primarily focused on a small app I can showcase in my talks.

If you're interested take a look:

BOLT04 / grafana-observability-demo

Repo with grafana and observability related demo app

Observability - Grafana Demo for Talks

This is a simple demo showcasing how we can instrument our applications with OpenTelemetry, using Azure Monitoring + Grafana + Prometheus It's intended to be used as the demo of a specific talk about observability.

Demo app instructions

Read the instructions in src/README.md.

Session Abstracts

Observability with Azure Managed Grafana

Nowadays, OpenTelemetry is used extensively to collect telemetry data from our applications, and serves as an industry standard. But we need a way to visualize this data in a clear way, and that is where Azure Managed Grafana comes in.

In this session we'll go through the core concepts of observability and demonstrate how we can use Azure Managed Grafana, integrated with Prometheus Grafana Tempo and Loki to gather insights from our telemetry data We will cover topics such as the basics about logs, metrics and traces, manual instrumentation, OTLP, and others. We'll…

View on GitHub

Conclusion

Hopefully, some of these resources I've shared are useful to you 😄. I still have a ton to learn and explore, but I'm happy with the knowledge I've acquired so far.

There are some specific standards + projects that I'll dive in and explore more, like: eBPF; OpenMetrics. OpenMetrics is something I'd like to spend some quality time reading about, but I know it's archived and reddit says the same. Just want to read and watch some talks about it to feed my curiosity 😃.

Last but not least, I want to follow the work that some industry leaders are doing like Charity Majors, specifically about Observability 2.0 😄. I discovered this term in the Thouthworks tech radar, and the part "high-cardinality event data in a single data store" caught my interest.
I'm still learning, researching, and listening to the opinions of industry leaders about this term to then develop my own opinions. Maybe I'll make a blog post about this in the future 😁.

Taking a look at what influenced me as I grow

David Pereira — Mon, 26 Jun 2023 12:00:00 +0000

I've wanted to write down what/who has helped me grow as a developer for quite some time. Well... here it is 😄.

Here is a tweet where I shared talks that I enjoyed a ton, and helped me grow:

// Detect dark theme var iframe = document.getElementById('tweet-1540783019862024194-83'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1540783019862024194&theme=dark" }

In this post, I'll share my retrospective about what has influenced me. I'll mention a few videos on that tweet that really molded who I am 😄

Communication and Leadership

The person that taught me the most about communication and leadership was Paulo Neto. I'd had the privilege of participating in many group or 1-1 sessions with Paulo, with other colleagues from Create IT.

You don't need to be the Tech Lead to be a leader on your team. Give feedback to your colleagues on what they did great, or what they can improve. This doesn't mean "always give specific instructions on how to get from point A to point B". The strategy we use to give feedback depends on the other person, but sometimes it's just better to ask questions, not give solutions. This challenges the other person to come up with a solution and think critically about the problem.

I used to help by giving all the answers to the problems people asked me. By giving my opinion even if nobody asked for it. If I give away the solution right away, let's say to a junior dev, it means I just stole an opportunity for that person to grow.
Now of course, it depends on the scenario (PRD bugs can have some nasty consequences), but I believe stepping aside and asking more questions, to make the other person think for themselves and get to the solution, is way better.

When you give feedback, the focus is on the other person's growth, not your own.

I'm still getting better at being a human, but Paulo helped me a lot in being on the right path.

Learning to learn

This video really taught me what meant to learn. Re-learning is a part of the process! This completely changed how I look at certain topics.

One more thing that is crucial, is to reserve time to learn! Saying "I don't have time to learn k8s" is the equivalent of saying "Learning k8s is not my priority right now". We have time for everything in this world, it's all a matter of priorities 😂. I've sacrificed my learning/growing time to deliver user stories on the sprint, for several occasions. If you are saying yes to every request someone asks you, it usually ends up with you prioritizing those requests, and not your own time to learn k8s, for example.

Learning to teach

Sharing knowledge is a key differentiator for a software developer. Have you ever tried teaching something to your colleagues, then get follow-up questions? Are you able to answer all of them 😅 ?

Teaching helps you discover gaps in your knowledge, and it's something I'm still improving. To feel like an expert in a subject, you need to first explain it to someone that has no knowledge about it. If you try and you fail to get the other person to understand the subject, it means you have work to do. I've used many meetings with colleagues as a means to know if I deeply understand a subject like idempotency, microservices, BFF, CQRS, etc.

Imagine you're onboarding a new teammate and you are the senior dev. Your capability to teach about the codebase, business domain, and other subjects is important. It can be the difference between having a new dev that is productive after one week, instead of one month.

I've talked mostly in this post about my own growth... but that doesn't mean all I need to do is develop my own skills.
IMO, the hardest challenge in this industry is making other people more productive! Not just making myself more productive and better at engineering 😅. Some people do this amazingly well, but I'm still growing in this regard 😄

Like Einstein said:

If you can't explain it to a six year old, you don't understand it yourself.

People I've followed

In retrospect, I follow just a few key people. As time passed, I focused on other interesting topics, instead of "simple tutorials" (the amount of content I consume didn't exactly decrease). Here is a list of the people I follow the most nowadays:

One of the videos I loved the most from Scott was this one:

What he shared really resonated with me. I felt powered up inside to keep learning and sharing, perhaps make more blog posts in Portuguese... but I never did that 😅.
It has some really good gems of advice inside, I do recommend you watch it.

Also someone I have learned a ton is Emily Freeman. I absolutely loved this talk she made at GitHub Universe!

Recently I shared another list of more front-end people I follow and recommend:

David Pereira • May 7 '23

I'd add some people to that list:

They have either awesome blogs or videos that you can learn a lot from!

I'd also recommend to follow and learn from Kelsey Hightower, for example this video. It's not particular about front end, but you can learn many valuable lessons from him :)

Conclusion

I'm way more confident now, and all those people I mentioned made and shared content that helped me grow.
I still have ambitious goals, so I'll just have to keep growing!

If you're interested in AsyncAPI and CloudEvents, take a look at my post:

Getting Started with CloudEvents and AsyncAPI

David Pereira ・ Sep 16 '21

#eventdriven #cloudevents #asyncapi #architecture

How to use the SEO meta tag rules module for Page Designer in SFCC

David Pereira — Sat, 05 Nov 2022 15:21:00 +0000

Introduction
The problem
The solution
Alternative solutions to SEO meta tag rules
Conclusion
Additional Links

Introduction

We have a great feature available to us in Salesforce Commerce Cloud (SFCC) called SEO meta tag rules. This is a module inside of SEO in Business Manager (BM).
However, currently there is only support for PDP/PLP pages made in page designer that support these meta tag rules.

In this blog post we'll see how to support SEO meta tag rules for all pages made in page designer.

The problem

Before going any further, I want to mention some disclaimers. At the time of writing this, not all pages in page designer support this. This could be added to SFCC and be directly supported without custom development. I posted this idea as a feature enhancement for Salesforce in IdeaExchange.

With that said, let's take a step back and understand the problem.

The SEO experts on a business operate mostly on the SEO meta tag rules BM module. If they need more granular level of SEO customization, most System Objects (e.g. Products, Content Assets, Categories) of SFCC support SEO fields like pageUrl, pageTitle, pageDescription. SEO experts can define rules that act as fallbacks, and then if some merchants don't define these fields for particular categories or pieces of content. You still have some meta tags being added to the page by these rules.

Now, even though this feature supports many types of pages, like home page, product pages or product listing pages. It doesn't support all types of Page Designer (PD) pages.
You can also take a look at the Page class, and check that it doesn't have the pageMetaTags field like the Content class does.

Page Designer pages are very similar to Content Assets, in the sense that underneath, these pages are persisted as the same content objects on the SFCC's database. But there are still differences, the support for meta tag rules feature is one of them.

Ultimately, these differences makes it harder for merchants or SEO experts that want to leverage the same functionality available on the rest of the site.

Now that you have a better understanding about the problem, let's shift our focus into a solution.

The solution

Content Assets

The whole premise of this solution is that it's supported by the SEO meta tag rules module of BM. In this module we have support for the following:

Homepage
Product pages
Content Detail pages
Content Listing pages

The only one that fits well with a page designer page is Content Detail page. Meaning we'll create content assets as a way to support these SEO rules for Page Designer.
Each page can have it's corresponding content asset, where the content ID follows a naming convention like "-seo". This way in Page.js you can get the meta tags for that page, through that content asset. Here is an example of the Page-Show extension:

server.prepend("Show", function (req, res, next) {
   var PageMgr = require('dw/experience/PageMgr')
   var ContentModel = require('*/cartridge/models/content')
   var pageMetaHelper = require("*/cartridge/scripts/helpers/pageMetaHelper")

    var page = PageMgr.getPage(req.querystring.cid);
    if (page != null && page.isVisible()) {
        var pageContent = ContentMgr.getContent(page.ID + "-seo")
        if (pageContent) {
            var content = new ContentModel(pageContent, "content/content")

            pageMetaHelper.setPageMetaData(req.pageMetaData, content)
            pageMetaHelper.setPageMetaTags(req.pageMetaData, content)
        }
    }
    next()
})

Now you don't need to create a content asset for every since page from PD. For example, if you business doesn't use the syntax ${Content.pageTitle} in your meta tag rules, or any expression regarding the object Content. Then in that case you could simply create one content asset for each folder the business wants to have.
You might be wondering why I'm mentioning folders and how they fit in the solution, so let's take a deeper look.

Folders

Folders are the way you can group multiple pages, and make all of them inherit the same meta tag rules. Once a folder is created, the business can use it in the SEO meta tag rules module inside BM.
Imagine you have a group of pages that are part of the same marketing campaign. As an SEO expert, of course you'd like to have page titles, descriptions, open graph and other meta tags for all of them.
But maybe the content team hasn't reached the maturity level to configure this for every since page. So you create a meta tag rule, acting as a fallback in case the content team doesn't configure some pages.

So far the solution revolves around the business creating manually folders, assigning them to pages and creating content assets for every page (in case they want to leverage page properties) or every folder.
I believe we can improve on this solution, so let's jump in to some automation.

Automation

This is a critical step, since having all this manual work doesn't make sense for business people. As engineers we can do better and automate the creation of these content assets. We can develop two different pieces that play together:

a job to ensure every page from Page Designer, has it's associated content asset and all the rest
a new BM module to automate folder creation, specifically creating multiple folders

Let's go through the job first, its responsible to update the content assets associated with each page. This means creating that content asset if it doesn't already exist, and then assign it to the same folders as the page. To implement this job you need:

Get the list of all Page Designer pages
Iterate through all pages
For each page, create the content asset and assign the appropriate folders

Here is a code snippet (in ES6) representing a possible implementation:

const libraryGateway = require("*/cartridge/scripts/gateways/libraryGateway")
const pagesList = getAllPageDesignerPages()

pagesList.forEach(page => {
    const contentId = `${page.ID}-seo`
    const result = libraryGateway.createContentAsset({
        id: contentId,
        pageTitle: page.pageTitle
    })
    if (result.error) {
        throw new Error("Error creating content asset")
    }

    page.folders.forEach(folder => {
        const result = libraryGateway.assignContentAssetToFolder(contentId, folder.ID)
    })
})

function getAllPageDesignerPages() {
    const ContentSearchModel = require("dw/content/ContentSearchModel")
    const apiContentSearchModel = new ContentSearchModel()
    const libraryID = "someId"

    apiContentSearchModel.setRecursiveFolderSearch(true)
    apiContentSearchModel.setFilteredByFolder(false)
    apiContentSearchModel.setFolderID(libraryID)

    apiContentSearchModel.search()
    const contentSearchResultIterator = apiContentSearchModel.getContent()
    const count = Number(apiContentSearchModel.getCount())

    const pages = []
    if (contentSearchResultIterator && count > 0) {
        while (contentSearchResultIterator.hasNext()) {
            const contentResult = contentSearchResultIterator.next()
            if (contentResult?.page) {
                // transform some contentResult fields to other types...
                pages.push(contentResult)
            }
        }
    }

    return pages
}

In the implementation above, getting all pages from Page Designer is done through the ContentSearchModel API. Although this works, it's not ideal in my opinion since these pages are required to be searchable (a setting on all pages) and online. If they aren't, then they won't be on the Content index, which seems to be the only way to get all page designer pages on a given site.
To create content assets and assigning them to folders, we delegate that responsability to the libraryGateway module. To implement this module we need to use OCAPI.

OCAPI

We can use OCAPI Data APIs to create content assets/folders and assign content assets to folders. While researching I tried finding another way, but I didn't find anything easier. The Salesforce Commerce API (dw library accessible server-side) doesn't seem to have APIs for these operations. I didn't find any pipelets or jobs steps that do this either... perhaps by exporting the content library, then creating a custom job that reads that file, edits it with the new content objects, and finally runs a job step to import that edited file.

Interacting with OCAPI is not an expensive development effort, so you can develop a custom cartridge for this. We won't go through the details about that cartridge, perhaps on a separate blog post :slight_smile:

OCAPI endpoints

All the operations we want to do can be found on the Libraries resource from the Data API. To create a content asset we can use this endpoint, to assign it to a folder we can use this endpoint. One thing to keep in mind, creating a content asset is an idempotent operation. This means it creates the object if it doesn't already exist, but if it does it ignores the existing object and writes a new one on top.

In practice, this means if someone edits these content assets (e.g. through BM, locking the resource and updating the description field), that modification will be lost.
If you don't want to lose those edits, you should consider using the endpoint to get the content asset, and use that data on your PUT request payload. In my case, these content assets are supposed to be "hidden", so no one should need to edit them.

BM extension to create folders

Now let's discuss the custom BM module to create folders. If business people want to create multiple filters in one go, instead of doing it through the BM UI and then going to Page Designer to assign pages to folders, they input the filter names in an input box and click a button. We can simply develop a web page that has this input box and a button (and some instructions on how to use it). This is possible by extending BM and building a custom cartridge, with this UI and the controller that executes the creation of folders.

We won't go to much into detail about this custom cartridge, I've added additional links at the bottom to help you building this cartridge.

Alternative solutions to SEO meta tag rules

In the case where the content object quotas are hit, we can consider building something entirely custom. What I mean is we would not use the SEO meta tag rules module from BM anymore. We would build our piece of software to handle this scenario - all page designer page types. Of course that means building software that does the same as Salesforce's built-in module of BM, considering:

Storage to store these rules, meta tag definitions, and others
An API that at least exposes a way to get meta tags for a given page, taking into account API design, SLA (important if you'll call this in a middleware of the Page.js controller), etc

This is a discussion you must have with your business/client, explaining the trade-offs of each scenario.

In my opinion, it's generally often better to reuse existing functionality or an off-the-shelf solution like a plugin cartridge.
Something that either is standardized and known in the community, instead of your own solution... but as always, this depends on the context we're in.
For SEO meta tag rules of SFCC in particular, we can't extend this module. So if we really needed to support this feature and we hit the API quotas of the SFCC platform, we would consider building a cost-effective solution outside SFCC, considering the need of a custom parser for if statements, context variables... again a discussion to be made with the business and architects.

Improvements to this solution

One important note about this solution is that pages would only inherit meta tags assigned to the default folder (primary folder). From my research, a content asset can only have one default folder, and that is the folder the meta tags come from.
In my use case the ideal was to setup some hierarchy, where a page could have 3 folders, and you could get all meta tags assigned to those folders. Now you kind of have this hierarchy (primary folder, then parent folders, up to root), but it's not the exact behavior I needed.

Conclusion

In conclusion, you can develop a custom cartridge with this functionality, and support this for your business or clients. In the future, this might be supported out of the box by SFCC. The greatest challenges were: analyzing ways to extend the SEO meta tag rules module; an API to get all page designer pages and understanding the limitations of our solution.

Let us know in the comments if this feature is something you'd like to have, or vote and comment on the IdeaExchange's post. I hope this has been helpful 👍.

Check out my other blog post on session management for SFCC.

Additional Links

Here are some links to documentation and other resources, that you may find useful if you're interested in building this feature for your business:

Reactathon 2022 - A Short Summary

David Pereira — Sun, 03 Jul 2022 19:07:00 +0000

Lately we've been filled with cool stuff in the React community. In case you missed it, Reactathon happened at the beginning of May, and with it came a lot of interesting talks and discussions between people in the community.
In this post I'll reference what I consider to be the most interesting and hot topics on the React community… and try to make it short 😅.

If you haven't seen the conference, you can take a look at this YT playlist for all sessions.

The state of React 2022

So first of all, what is the state of React currently? With React 18, what was once called concurrent mode is now concurrent features. This changes the approach into an incremental adoption, so that you could use concurrent features in specific places of your React app.

In this talk, Lee also announces Next.js new routing system which resembles Remix a lot. They want to take advantage of nested routes which is great! This allows us to provide a better user experience on pages that have one component that blocks rendering.

Last but not least, there are new developments when it comes to server-side rendering, and new client-side rendering APIs.

Edge computing

If you are unaware of this type of compute, Edge computing allows a better user experience, because it reduces the time you get a response with the content you want to visualize. The time is reduced because to process your request you don't need to "talk" to a distant server on the oasis.

CDN providers like Cloudflare, are building new runtimes to allow you to run code closer to your customers – on the edge. Cloudflare workers for example, don't use Node.js or Deno under the hood, it's their own JS runtime. Of course, an effort is being done to standardize these runtimes.

In this talk, Kent talks about how Remix improves the developer experience for edge computing. First they use the Web Fetch API, and depending on where you want to deploy your function. Remix then translates the request/response objects to the respective platform's API. They also support streaming in the edge, in order to send some content to the user quickly, and then send the rest.

With that said, this is all in JS/TS or WASM land. At least I haven't seen a lot of support for other languages and runtimes (e.g. C#) on services that provide edge computing.

Streaming server components

With React 18 it's now possible to stream changes to the browser, with new APIs like Suspense that allows for asynchronous processing.

Why is this cool? Because we don't want to block rendering with data fetching. When our component needs to fetch data before rendering what the user wants to see, we need to render a loading spinner... which ain't cool.

How about we initiate fetches before we render. This way the requests are in parallel and don't block rendering. Using streaming server rendering fixes this, which is why it's so awesome! Ryan Florence goes more in detail how this is done in this talk: When to fetch: Remixing React Router.

Bear in mind, this is just one way of rendering. Last year at React Conf 2021 there was an intro session about this topic as well: Streaming Server Rendering with Suspense. Another great session that talks about the different rendering patterns: Advanced Rendering Patterns: Lydia Hallie. It's an amazing session to help you visualize the impacts on performance, and what are the trade-offs of each pattern.

Getting Started with CloudEvents and AsyncAPI

David Pereira — Thu, 16 Sep 2021 18:30:48 +0000

Introduction
CloudEvents
AsyncAPI
Conclusion
Additional Links

In the previous blog post we went over a case study for Azure Service Bus. In this article we’ll look at two specs, CloudEvents and AsyncAPI, that you can use to solve some problems of your event-driven architectures.

Introduction

At the moment, there are quite a few tools and products that have adopted CloudEvents or AsyncAPI. Knative Eventing is a tool that helps developers in a serverless context, Azure Event Grid natively supports CloudEvents. More recently, Jenkins added integration with CloudEvents with a new plugin. It allows users to configure Jenkins as a source and a sink for CloudEvents.

There is also interesting integrations between Kubernetes and Azure Event Grid that are compliant with the CloudEvents v1.0 spec. Checkout the GitHub repository or this blog post and learn more about it.

Postman has joined forces with AsyncAPI along with organizations such as Salesforce, Slack and Solace. Postman in particular is publishing public collections related to AsyncAPI. For example a list of companies adopting AsyncAPI, with links to those resources (GitHub repositories, websites, etc).

I hope these projects have got you excited to learn more about these specs. Let’s dive into some of their details!

CloudEvents

The CloudEvents specification is under the CNCF Serverless working group since 2018. The spec's purpose is describing event data in a common way. This is useful in many scenarios, for example, routing events to the appropriate subscribers depending on the type of the event. Since applications can use a lot of different transports to send and receive events, the CloudEvents spec is protocol-agnostic so it defines protocol bindings in order for the metadata to be correctly mapped for HTTP, AMQP, Kafka, etc.

There are many use cases in using the CloudEvents spec, but perhaps the main one would be interoperability. Imagine applications across clouds, being able to communicate in an event-driven architecture. Where there are producers of all sources, and consumers using all kinds of protocols (e.g. HTTP, AMQP, WebSockets). We can have middleware that connects these applications, adds E2E tracing and more with the use of CloudEvents. Of course we could connect the same applications without a common format, but it requires mapping between event formats (cloud providers use different schemas). Middleware would also need to parse the event data to get specific information.

Another use case is SaaS (Software-as-a-service) that publishes events that clients are interested in to integrate with their own systems. For example, hooking into the checkout flow in a Shopify storefront to add extra checks. By leveraging CloudEvents these events can be consistent, opening the door for numerous integrations between 3rd party software.

Extensions

There are a few extensions worth mentioning, one of them is for distributed tracing. However, it seems there is some discussion around removing this extension from the spec (check this PR on GitHub). There are open issues on some SDKs to support it, and others have already made changes to remove it. The future isn't clear, but I'd argue it's interesting to follow this closely for any updates, since tracing events is very important in an event-driven architecture.

The Partioning extension is another interesting extension, it defines a field to be handled by message brokers that can separate load via a partition key. This is used for example in the Kafka protocol binding that requires implementations to map the partitionKey attribute to the key of the Kafka message. In Kafka the concept of a partition is well known, so this maps out really well.

Relation with Serverless computing

Serverless computing has increased in popularity and use in the industry, especially for it's cost model. But many FaaS (Functions-as-a-service) providers have their own function interface. Which means developers can't write a function in JavaScript, and deploy them in two cloud providers without making changes. This specification improves portability between FaaS platforms, so that developers receive an event in the same format and can reuse libraries for handling the event.

AsyncAPI

I’ll start with a description of what AsyncAPI is: a specification that describes and documents event-driven APIs in a machine-readable format. It's protocol-agnostic like CloudEvents, so it can be used for APIs that work over many protocols, including MQTT, WebSockets, and Kafka.

The following is AsyncAPI's vision stated on their website:

I find this vision to be very interesting, mainly because of the part: Any kind of APIs. At first, you might wonder if this means the AsyncAPI spec will define rules and more concepts for other types of APIs like GraphQL or OpenAPI. But this is not at all the case, the goal is to integrate with existing tools and specs!

This is valuable for developers because usually enterprise architectures consist of a mix of technologies, each for it's appropriate use case. Developers nowadays don't just interact with RESTful APIs in a request/response model. There are different demands and considerations for the ever increasing devices users can use, the software we build needs to match these demands and still maintain manageable. Where we can evolve and create new applications that leverage the numerous APIs that exist internally or from a 3rd party.

Concepts

The spec version 2.1.0 defines a few concepts apart from the common Producer, Consumer and Message. A Channel can be seen as a topic/exchange or queue, an application can send messages to a channel and consumers can subscribe to it to receive them. The Operation object indicates if it's a publish or a subscribe operation and how an application can send or receive messages. A Binding (or "protocol binding") is a mechanism to define protocol-specific information or query parameters for the channel bindings. For example, for the AMQP protocol we can specify the channel is an exclusive queue like this:

"bindings": {
    "amqp": {
      "is": "queue",
      "queue": {
        "exclusive": true
      }
    }
}

Each protocol has it's own JSON schema and we can have bindings for Messages, Servers, Channels, Operations and others.

Components

You can define components to reuse in multiple AsyncAPI documents and we can reference other AsncAPI documents. Let's say you have two publishers who publish the same message, but with different values in one of the message properties. We'd have two AsyncAPI documents specifying the publishers, referencing a 3rd document specifying the common message with it's properties.

The $ref field is a string that can be the path to the other file, or a URL for an external file where the schema we want is defined. This reference object uses the same rules and format of JSON Reference, which opens the door for many possibilites (check the docs to know more).

When we start to have a lot of apps that depend on each other’s schemas, we can take a look at some solutions to scale ou AsyncAPI documents. Perhaps we use Confluent's Schema Registry for our JSON schemas and setup a catalog of events in our organization. This empowers new developers seeking for ways to integrate with existing systems and event producers. We can also just store these components in a GitHub repository, and reference them in our AsyncAPI documents.

Tooling

There is already quite a few tools and the tooling ecosystem is increasing! I've recently seen a repository that enables the creation of Postman collections from an AsyncAPI spec. I've also seen architecture documents being generated from multiple AsyncAPI specs too, having a tool that can understand relations between applications and then output a diagram is pretty cool.

Generators for AsyncAPI

One piece of tooling that is often used are generators that produce documentation and code. For example gRPC tools have this capability using the protocol buffer compiler. AsyncAPI generators can take an AsyncAPI document and generate client/server code or documentation in HTML and markdown. Currently, it depends on the template we use to generate server-side code, for example the Node.js WebSocket template generates both server and client code.

This can be improved and extended overtime, especially because of the way the generator is designed, enabling extensibility so we can have templates for many other languages that support more protocols, etc. For example, there is only a NATS generator for .NET Core... but perhaps in the future there could be more protocols supported for .NET Core and examples built for Azure 😃.

Conclusion

There is a lot of exciting stuff happening in the event-driven architectures world 😄, we have only touched the surface in this post. In the CloudEvents space there are new specs being designed and worked on: Discovery; Subscription and Schema Registry APIs. Since AsyncAPI defines a document that you can use to describe your API, it'd be interesting to see how these correlate to each other, and using them together.

I encourage you to join these communities and contribute to their open source projects 😄, CloudEvents and AsyncAPI, both specs are very community-driven. Collaboration between everyone is the way forward, with Hacktoberfest and AsyncAPI's Hackathon coming up, searching good first issues is a great way to start and to contribute 👍!

Let me know in the comments if you're using these specs and what are your thoughts on them. The next blog will be about a practical example for .NET Core, Azure and AMQP messaging using CloudEvents and AsyncAPI, so stay tuned!

Additional Links

Here are some links to talks, docs and blog posts that you may find useful if you're interested to know more about CloudEvents and AsyncAPI:

Case Study: Azure Service Bus and Event-Driven Architectures

David Pereira — Fri, 04 Jun 2021 13:46:56 +0000

Introduction
Event-driven architectures
Implementation
Conclusion
Additional Links

Introduction

In this article we will talk about Event-Driven Architectures. We choose to use the Azure Cloud Infrastructure.
Service Bus provides reliable, secure asynchronous messaging at scale. This article is written by the engineering team at CreateIT and it is intended to show you a case study in one of our projects for a client.

We’ll take a deeper dive into the Service Bus technology, architecture, and design choices. The post will cover both conceptual material as well as implementation details. Most importantly, we will discuss design and implementation of some of the features that provide secure and reliable messaging at scale, while minimizing operational cost.

Service Bus Entities

When we are working with Azure Service Bus, we can choose two Entities: Topics or Queues. You can have multiple Topics or Queues per Service Bus Namespace, but firstly you need to differ one from another. If you want a FIFO queue and only have one Consumer, then Queues are the way to go. If you need multiple Consumers, then the Topic is the better option. In this specific case we will create a Subscription per Consumer (Topics are only available from the Standard Pricing Tier).

Event-driven architectures

Benefits with event-driven architectures

What are the benefits of using a queue in the middle of these systems?

We can decide to load balance the input from Customer Services. Let’s say there are a lot of updates being made to a customer, meaning a lot of events being published. We scale the number of consumers and user the competing pattern
We can throttle the input. If on black Friday there are a ton of events and in case our Audit Log system is down. We simply store these events on the queue and consume them when the service is back online again. Of course we’d need to implement some logic for this behavior, but adding this “middleware” buys us options.

In our use case, we wanted to move to an implementation where the Web API doesn’t get affected by any changes on these external systems. But in order to change the implementation, we must first figure out what are the challenges associated with this change.

Challenges with event-driven architectures

Message/Event order

Azure Service Bus has a feature called sessions. A session provides a context to send and retrieve messages that will preserve ordered delivery. However, in our use case we chose not to use it.

Message Lock Duration

When we are using Queues, every message has a lock Duration. During this time the consumer needs to process it. But if this consumer needs to contact multiple external systems this time may rise and our messages could stop in the Dead-Letter. So the best practice is to change it accordingly to your needs. We recommend you to set this time extremely high in the beginning, and then do some tests to calculate the average.

After that add 30% more of its value, in case of some lengthy requests (in this case if we have outliers, they might stop in the Queue). If you are using a Topic, you will have a Lock Duration per Subscription. So make sure to adjust this time accordingly to its functions.

Implementation

In the Figure 1 you can see the initial architecture for the Customer Management system. It was responsible to make the requests to the other systems.

Figure 1 – Initial architecture diagram

With the new implementation, a message broker was introduced and we used the event-carried state transfer pattern, meaning our events had all the information the consumer needed in order to do their job. We took in consideration the event notifications pattern, where the consumer would have to make a request to the API that originated the event, in order to get more information. But this brings new problems to the table. What if when the consumer code runs, the information for that customer ID changed? What if the event was CUSTOMER_CREATED but in the meanwhile the customer was deleted?

Retries with Polly

In a distributed system, many things can go wrong. The network can fail or have additional latency, systems may be temporarily down, etc. We use the Azure.ServiceBus.Messaging NuGet package so we are able to check if the exception is a transient fault or not (more information on these docs), then use Polly to setup retry logic and fallbacks. There are other options to implement retry policies, for example we took in consideration the Retry guidance for Azure Services documentation from Microsoft. Since we use the latest Azure SDK, the appropriate class would be ServiceBusRetryPolicy.

We configured Polly to retry to publish a message three times (this configuration is on appsettings.json), with exponential times between each attempt.
If after the third retry we can’t publish the message we need to save it, because it has crucial information. So to solve this issue we created a Fallback Gateway, to write these messages to a Container inside an Azure Storage Account.

Filters for message routing

This section only applies for Topics Entities on the Azure Service Bus.
We can add Filters on our Subscriptions to help us with routing each message to its specific Consumer. We considered two filter types:

SQL Filter
Correlation Filter

Using the Correlation Filter you can configure Custom Properties and create Filters for your needs. You just need to make sure the producer of the messages, includes the header, that you are currently using to filter, on the message.

With SQL Filters you can create conditional expression to evaluate the current message. Just make sure that all the system properties are prefixed with sys. in the expression. Either way, both filters work just choose one that suits you the most!

Dead-Letter Queue

In case the consumer application can’t process the message after the Max Delivery Count attempts, instead of returning it to the queue it will be sent automatically to the Dead-Letter queue. If you are using the Topic, each subscriber has its own Dead-Letter queue. You can also, configure different Max Delivery Counts Values for each Subscriber.

All messages that are published to the Service Bus have a TTL (Time-To-Live). After this time ends the message will be transferred automatically to the Dead-Letter. So make sure you adjust this time accordingly to your needs.

With this we are able to save messages that weren’t processed by the consumer application, but we should always strive to have an empty dead-letter queue.

Conclusion

Our first steps into an Event-Driven Architecture was a truly success!
We were able to expand our previous solution to be compatible with multiple external systems and instead of having the API sending a HTTPS request for each one we had this Application sending one message to a Topic in the Service Bus.
One of our goals was to have load balance in the Publisher Application. We went from a 1->3 dependency to a 1-> 1, as you can see in the Figure 2.

Figure 2 – Architecture Diagram with Azure Service Bus

Which is great and keeps the system scalable and future proof. Our solution became more decoupled in order to keep the Application agnostic to these changes.
If you have a similar situation with an Event-Driven Architecture then we totally recommend you to check more about this technology and it’s features.

We would like to share a link to Microsoft Azure Service Bus GitHub. Most of the implementations of either the publisher or the subscriber were inspired by this documentation, so make sure you check it out!
If you have any questions, please write them down below.

Additional Links

Service Bus Exceptions
Service Bus Basic Steps
Tutorial with DotNet

Notes on feedback and self-reflection

David Pereira — Mon, 05 Apr 2021 10:28:10 +0000

Introduction
Giving Feedback
Burnout
Reflection happens when you stop
Conclusion

Introduction

In this blog post, I'll share what I've learned recently regarding feedback in the context of conversations and self-reflection. Communication is a topic I set as one of my goals for 2021, so I'd like to share some of the topics I've enjoyed thinking and learning about.
As we grow in our careers, these become more relevant and important to understand. The way I see it, communication and leadership are essential if I want to help as many people as I possibly can, but of course, I won't forget the joy of technical skills and I'll always keep honing those 😁.

Giving Feedback

This is something that I use a significant portion of my time to improve because I want to be careful in the message I send to someone else. My intention is always to contribute with an opinion or perspective so that the other person can improve. Of course, the other person validates what I said first, and then decides what to do. This is very important because it means we can express our opinion to someone, but they aren't obliged to accept it and implement it the next time.

To me being open to new ideas that challenge the way I currently think is great! It's the perfect opportunity to come up with arguments and stand my ground about what I believe in. On the other hand, it's a phenomenal opportunity to hear arguments that are better than mine, and see something from a different perspective.

However, I have noticed that I refrain from giving feedback on certain topics, because I don't know the best way to do it. The way I used to think is that there is positive and negative feedback:

Positive feedback is the same as giving recognition to the other person, like saying "great job" or "you inspired others on that meeting".
Negative feedback means we give feedback on points that could be better, like "you could have shown X in the presentation".

But if we think about it, what is the difference between positive and negative feedback? Does it even exist?

Continuous improvement (a never-ending story)

Think about a time your favorite football team won the game with a clean sheet (zero goals suffered). As a coach, you might give feedback to your players like "great game, you all did great". But this implies there are no improvements to make, doesn't it? Even though we got a clean sheet, were there no defensive errors? Are there aspects the other team did better than us?

Striving for continuous improvement helps to be in the right mindset to give feedback to someone. The way I'm going to focus on giving feedback is by asking questions, so that the other person can think critically about their logic to a problem. This is an approach I'm trying to implement for myself, and I've seen it work so it motivates me to be better at it.

I heard giving feedback is a delicate art, now I see why that is. If we are mindful of this, we'll take into consideration the reaction the other person may have and always focus on the most important thing in giving feedback: helping the other person improve.

Burnout

Burnout is a tough topic to discuss, but I've recently been thinking about it. Mostly because I'm trying to do a lot of different things, and it seems I can't focus on one of them at a time. But it's a real struggle to stop doing things you find interesting when you're so curious to learn something new or improve something that already exists 😅.

At my job I'm currently invested in: doing some open source work; recruitment with technical interviews and other phases; being responsible for one of our book clubs; being responsible for some internal initiatives (e.g. event-driven architectures) and some other stuff like digging into zero-downtime deployments, health checks, and cloud architecture. Outside of work I try to keep up with some open source projects I'm part of in the EddieHub organization and write blog posts.

Sometimes it does seem like quite a bit of work, but what really matters is not the situation I'm in, but the state I'm in. How am I feeling during these times I want to do a lot? Tired or calm? In all honesty, it depends on the day. If I'm not tired, I can decide to just bang out some code and study some new web development stuff friday night + most of the weekend. When I'm tired, I decide to postpone some stuff to the next day, because most of it is to keep up with the industry and keep learning as much as I can (as well as feeding my curiosity).

But there is no deadline for this. I can set one but if I don't complete it, it's not the end of the world. I'd feel much more stressed if I decided "I have to reach my next level at this date", because my mind would focus on where I want to be, and it would project itself to that place. If I disregard where I'm currently at and project myself into the "desired place", I'm removing that space where growth happens!

Reflection happens when you stop

We need time to think. We can't be in a constant state of flow, because there is no time to think and reflect. I've never thought too much about this, but I realize now I should make it a habit of mine, to take time to simply do nothing! The sprint is finished? Great, let's stop and think about what happened and what can be improved. It's also at these times where we stop that we are more creative. At least I usually have more ideas when I go for a walk or step outside my room 😅.

Taking time to think how the meeting went is good, but it's also important to ask someone else for feedback because there are things we don't see in ourselves sometimes. This has become very clear for me recently since I hadn't noticed what my behavior was like in a conversation with another person.

My default behavior tends to keep me in "thinking mode", stopping me from interacting in a group. It says certain words repeatedly in a presentation or simply while talking. It asks a question, following right up with another question... Self-reflection is very important because it gives you awareness about yourself, your behavior. Once you know how you behave in a given situation, you just have to know how you want to behave, and start working towards that.

Define a plan of action

The way I started working towards improving my behavior and other aspects, is to ask questions to myself and then define a plan of action. For example, I want to improve the way I give feedback to my coworkers. First I ask myself "How am I giving feedback today?", in which I could answer "well I say they did a great presentation at the end and suggest different solutions to problems". Okay, then I'll ask "What can I do to help the other person improve their skills the next time?". My answer would be "I think I could... hum... I could ask them how they think they can improve that specific block of code or that part of the presentation". Now I know something I can ask and take action for the next time I give feedback to someone.

Of course, planning can be hard to do and most of the time we may feel "I have no idea how to improve or what to do". But forcing ourselves to think and answer questions, many times results in small steps we know we can take. Then when we have a vision of the plan, "checking off" boxes along the way helps us see and feel progress.

Conclusion

I believe in this learning process:

Learn
Reflect
Implement
Share

I learned it from this video and ever since then I'm trying to share everything I learn, after reflecting on it. I'm not perfect at it, but I try my best to follow it and challenge myself by reflecting and sharing. I want to continue to grow on this aspect (human skills), so I'll want to write more posts on this topic in the future 🙂. The truth is I'm still sinking in all I've learned and trying to implement bits and pieces for all this knowledge to be at the root of my mind 😄.

Hopefully, you enjoyed reading this post and took something out of it. Currently, I'm working on a blog post about Azure Service Bus and event-driven architectures, so stay tuned for that!

DEV Community: David Pereira

Book Review: Co-Intelligence by Ethan Mollick

Table of Contents

Introduction

AI as a Thinking Companion

The Human-in-the-Loop Principle

Critical Thinking

Disruption in the job market

Centaur vs Cyborg approaches

Resources

Conclusion

The Reality of GenAI in Software Teams

Table of Contents

Introduction

The productivity myth

Where AI actually adds value

Develop critical thinking skills

Conclusion

GitHub Universe 2025 Recap

Table of Contents

TL;DR

Agent HQ - Mission Control

GitHub Code Quality

Copilot Upgrades

Conclusion

AI can be a great augmentation tool, for code-review or AI-assisted coding, but all engineers need to have strong critical thinking skills, in my opinion. In this post, I share how I'm using it along with my own opinions so far.

Becoming augmented by AI

Becoming augmented by AI

Table of contents

The "Jagged Frontier" concept

Becoming augmented by AI

AI as a co-worker

AI as a co-teacher

My augmentation list

AI-assisted coding

Custom instructions

Meta-prompting

Resources

Conclusion

Learning: Observability

Table of Contents

Introduction

Get Started

Logs

Canonical logs

Traces

Metrics

General Best Practices

Resources

GitHub demo repo

BOLT04 / grafana-observability-demo

Repo with grafana and observability related demo app

Observability - Grafana Demo for Talks

Demo app instructions

Session Abstracts

Observability with Azure Managed Grafana

Conclusion

Taking a look at what influenced me as I grow

Communication and Leadership

Learning to learn

Learning to teach

People I've followed

Conclusion

Getting Started with CloudEvents and AsyncAPI

David Pereira ・ Sep 16 '21

How to use the SEO meta tag rules module for Page Designer in SFCC

Table of contents

Introduction

The problem

The solution

Content Assets

Folders

Automation

OCAPI

OCAPI endpoints

BM extension to create folders

Alternative solutions to SEO meta tag rules

Improvements to this solution

Conclusion

Additional Links