DEV Community: Paulo Victor Leite Lima Gomes

Claude code and 512000 Becoming Public

Paulo Victor Leite Lima Gomes — Wed, 01 Apr 2026 11:00:24 +0000

The Moment Every Engineer Knows

You publish a package.

Everything seems fine.

Then someone on the internet discovers something you absolutely did not intend to ship.

And suddenly half a million lines of your internal code are circulating on GitHub.

That’s essentially what just happened with Claude Code, Anthropic’s command-line developer tool.

What Actually Happened

Anthropic released version 2.1.88 of the claude-code npm package.

Inside the package there was a source map file.

For people outside the frontend / JS ecosystem, a quick explanation:

A source map is normally used to map compiled JavaScript back to the original TypeScript source files for debugging.

But if the source map accidentally includes references to the original sources and the sources are embedded or accessible, anyone can reconstruct the entire codebase.

And that’s exactly what happened.

The result:

~ 2,000 TypeScript files
~ 512,000 lines of code
internal architecture exposed
instantly mirrored and forked across GitHub

Within hours, developers were already exploring the internals.

Important: The Models Were NOT Leaked

Let’s be clear about something.

The leak did not expose the Claude models.

No weights.

No training data.

No internal datasets.

What leaked is the CLI developer experience layer.

Think of it as the operating system around the AI, not the AI itself.

Still, that layer is extremely valuable.

Why This Matters

Many people underestimate developer tooling.

But tools like Claude Code, Copilot CLI, Cursor, etc. are not simple wrappers.

They are complex systems with:

tool execution frameworks
memory management
query orchestration
prompt pipelines
plugin systems
guardrails
verification loops

According to early analysis of the leaked code:

~ 40k lines for the plugin/tool system
~ 46k lines for the query engine
complex memory rewriting pipelines
multi-step memory validation
background context refinement

Which confirms something many engineers already suspected:

These tools are production-grade software systems, not thin wrappers around LLM APIs.

Why Competitors Will Study This Carefully

This leak gives a rare look at how a modern AI developer tool is built.

Competitors can now analyze:

architecture decisions
orchestration patterns
prompt pipeline design
tool execution safety models
memory persistence strategies

Even if companies don't copy code directly (which would be legally risky), they can learn a lot from the design choices.

It's basically a blueprint of a modern AI coding assistant.

The Security Angle

There's also a darker side.

Whenever internal architecture becomes public, attackers can:

analyze guardrail logic
probe validation layers
search for weaknesses in tool execution
discover bypass patterns

Security through obscurity is never a real defense, but suddenly giving attackers a full architectural map does raise the stakes.

The Irony

Claude Code itself exists to help engineers ship code faster.

And the leak happened because of a release packaging mistake.

Not a hack.

Not a breach.

Just a build artifact that shouldn't have been published.

Every engineer reading this knows the feeling.

My Take

From an engineering perspective, two things stand out.

1. The sophistication is real

People often say:

"These AI tools are just wrappers around an API."

That’s clearly not true anymore.

Half a million lines of orchestration code tells a different story.

2. This will accelerate the ecosystem

Ironically, leaks like this often speed up innovation.

Now thousands of developers can study:

memory strategies
prompt pipelines
tool orchestration
AI developer UX design

And build their own versions faster.

That’s how software ecosystems evolve.

The Bigger Picture

AI development tools are becoming something closer to operating systems for programming.

They orchestrate:

context
tools
models
memory
safety

Claude Code is just one example of this emerging layer.

Seeing its internals confirms something many of us suspected:

We are not just building AI models anymore.

We are building AI runtime environments for developers.

Final Thought

Some engineers are probably embarrassed about this release.

But if we’re honest…

Every developer has shipped something accidentally.

Most of the time it's harmless.

Sometimes it's half a million lines of proprietary code.

OpenClaw is infrastructure, not intelligence

Paulo Victor Leite Lima Gomes — Mon, 09 Feb 2026 10:14:34 +0000

There is a new hype going around called OpenClaw, and Yes, it is a hype. Early AGI? no.

OpenClaw is an agent orchestration framework. A good one. Clean. Opinionated. Well documented.
But conceptually, it is not new.

What OpenClaw actually is? Based on their own docs and code:

OpenClaw lets you define agents
Each agent can run tools, call LLMs, keep state, and execute steps
You can run it locally on your own machine
You control the infrastructure and the data flow

that’s it

This is not intelligence. This is software plumbing for LLM-powered workflows 😒

We have seen this before

Nothing here is magic or unprecedented.
You can do the same thing today with n8n more scalable and way more guardrails
You can do the same thing with LangChain-style agent loops
You can do the same thing with custom workers + queues + LLM APIs

Lets be honest, the difference is not capability, is ergonomics.

OpenClaw gives you a cleaner mental model and less glue code. I see this as a more “developer-first” way to define agents, and as we say in polish 🇵🇱 oczywiście, which means, offcourse That is valuable, not AGI.

“But it runs locally, that’s new”

Not really.

OpenAI themselves shipped local / semi-local execution environments in the past:

Tool calling
Code execution sandboxes
Agent-like runtimes that could call external systems

Those experiments came and went. Some were removed.
The idea stayed.

OpenClaw is simply doing this outside OpenAI, in an open-source, self-hosted way.

Their difference? Router and messaging apps, WhatsApp, iMessage, Telegram... you named it.

But again:
You can already do this with n8n, webhooks, and LLM APIs.

The real difference is cost and control:

With OpenClaw, you might run everything on a custom local computer
With n8n or cloud setups, you usually pay more over time
This is a deployment choice, not a breakthrough.

So what is the right framing?

OpenClaw is:

Not AGI
Not consciousness
Not reasoning in the human sense

OpenClaw is:

An elegant agent framework
A solid abstraction over LLM workflows
A good tool if you want local-first, controlled execution

That is already enough.
It does not need AGI branding to be useful.

My conclusion

Calling OpenClaw “AGI” is marketing-driven confusion. Calling it a clean, modern way to build agents is accurate. And accuracy matters more than hype. I see this is game changing for some cool things, you have now some agent working eventually 24 hours a day, but this one still needs tons of triggers and guidelines as well as will halucinate as we already see in a common openai chat. You can use it, you can deliver awesome job with it, bit it will not replace a human. yet.

References

Docs: https://docs.openclaw.ai/start/getting-started
GitHub: https://github.com/openclaw/openclaw
n8n: https://n8n.io/

VS Code now has agents: what changed

Paulo Victor Leite Lima Gomes — Sun, 08 Feb 2026 15:24:13 +0000

Keeping up with AI coding tools is exhausting

First we had simple chat assistants.
Then multiple modes like ask, edit, plan, agent.
Then different models.
And now… VS Code added something new: agent execution environments like: Local, Background, Cloud, Claude

If you feel lost, good.
Me too.
So let’s simplify what is actually happening.

From chat assistants to real agents

At the beginning, which was like two years ago😅, AI in coding was basically:

"Here’s some code. Fix it."

That was the Ask era

Then tools started editing files directly, that became the Edit era.

After that, AI began planning multi-step changes.
Welcome to Plan.

And now we are here where AI can run tasks, monitor progress, and execute workflows.
That is the Agent era

This is the real shift 💩 and is part of the thausand options we have with AI, also with all companies chasing attention in AI initiatives

Why VS Code suddenly has more options on the side panel

Before, the decision was:

Which mode?
Which model?

Now there is a third dimension:

Where the agent runs ?

This is more like from "AI that answers and are our copilot" to be more like "AI that does the work"

This is off course not something new, this was the idea before, and now the biggest trend, and yes its getting harder to follow. Reasons why we are here, to organize it mentally.

How to think about the new VS Code Agents (simple mental model)

first, forget the complexity

Just remember:

Modes = what the AI should do: ask, edit, plan, agent
Model = how smart it is more or less
Execution environment = where it runs: local, background, cloud, claude

That’s it

Now its it more than a autocomplete, or copilot or an step-by-step doing work, its more really delegating the work using your IDE.

For the full official explanation from Microsoft, read here

Java in 2026: still boring, still powerful, still printing money

Paulo Victor Leite Lima Gomes — Sat, 07 Feb 2026 14:16:00 +0000

Let’s be honest.

Java is not sexy.
Nobody wakes up excited thinking “wow, I hope today I can write some beautiful enterprise Java code.”

And yet…

Banks, fintechs, payment processors, credit engines, risk platforms, and trading systems are still massively powered by Java in 2026.
And they’re not moving away anytime soon. With AI taking up to 70% of written code? Not a problem.

I have worked as a software engineer for more than 17 years, and since I've started, people talking about java becoming legacy was just part of my day.

we are in 2026, american debt is skyrocketing, BTC is melting and dollar losing value... while Java? Well, looks like this guy is a tough dinosaur

Quick Java timeline (why this dinosaur refuses to die)

1995 → Java is born. “Write once, run anywhere.”
2006 → Open-sourced. Enterprise adoption explodes.
2014 → Java 8. Lambdas. Streams. Real modern Java begins.
2018–2021 → 6-month release cycle. JVM performance goes crazy.
2021 → Java 17 LTS becomes enterprise default.
2023 → Java 21 LTS ships with virtual threads (Project Loom). Massive scalability shift.
2026 → Java 25 era. Cloud-native, AI-assisted dev, still dominating finance production systems.

So yeah…
Not dead. Not even close.

Why finance still trusts Java more than anything else

financial systems do not care about hype.

They care about, predictability, latency stability, memory safety, tooling maturity and last but not least a huge hiring pool

JVM stability is unmatched if you run:

loan engines
payment authorization
anti-fraud scoring
card transaction routing

JVM gives:

battle-tested GC (even with its problems)
insane observability
deterministic performance tuning
backwards compatibility across decades

Concurrency changed the game (virtual threads)

Before Java 21:

threads were expensive and async code was ugly, now:

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 1_000_000).forEach(i ->
        executor.submit(() -> processTransaction(i))
    );
}

This is millions of concurrent operations with simple blocking code and no reactive nightmare.
For fintech backends, this is huge.

Spring ecosystem still dominates enterprise

Yes, people complain about Spring Boot, but look at reality:

80%+ of fintech APIs run on Spring
security + observability + config = solved problems
onboarding engineers is easy
production support is predictable

Example minimal API:

@RestController
@RequestMapping("/loans")
public class LoanController {

    @GetMapping("/{id}")
    public Loan getLoan(@PathVariable String id) {
        return new Loan(id, BigDecimal.valueOf(1000));
    }
}

Boring?
Yes, but every engineer can get it easily, even in an eventual case of some AI-code-creationg halucination.
Finance chooses boring.

Performance is no longer an excuse

Modern JVM gives ZGC/Shenandoah which is ultra-low latency GC, JIT + profiling that optimizes the runtime, theres also a GraalVM native images for faster startup on any cloud provider

The real shift in 2026: AI-augmented Java developers

This is where things get interesting, guess what? java is a big winner here, if I can't check everything is being created, how about I rely on a very deterministic well shapped programming language?

A simple example on putting claude code/github copilot to work for you

Example: generate a Spring service instantly

Prompt in editor:
create a service that calculates compound interest with validation and unit tests

Result in seconds:

@Service
public class InterestService {

    public BigDecimal compound(
        BigDecimal principal,
        BigDecimal rate,
        int periods
    ) {
        if (principal.signum() <= 0 || rate.signum() < 0 || periods < 0) {
            throw new IllegalArgumentException("Invalid input");
        }

        return principal.multiply(
            BigDecimal.ONE.add(rate).pow(periods)
        );
    }
}

tests look like a charming...

@Test
void compound_shouldGrow() {
    var service = new InterestService();
    var result = service.compound(
        BigDecimal.valueOf(1000),
        BigDecimal.valueOf(0.1),
        2
    );

    assertEquals(new BigDecimal("1210.00"), result.setScale(2));
}

Time saved with control.

How about using claude for refactoring and architecture?

Some things that were a nightmare before, now are just a task in jira like:

migrating legacy Java 8 → Java 21
converting blocking code → virtual threads
generating integration tests
explaining weird enterprise codebases

Real workflow:

inline or chat with the legacy class

modernize for Java 21 + clean architecture

tadah: get production-ready refactor

This is insane leverage.

Lets talk about career now, this moment a lot of software engineers are actually loosing their jobs, one more reason why java careers are still strong...

Everyone wants to learn:

Rust
Go
A new AI-agent-ish of work
shiny new things

But banks still run on Java, and guess what?

So supply ↓
Demand ↑

Opportunity.

Lets finish here...

Java in 2026 is like:
a boring Swiss bank account that quietly keeps getting richer
Not hype.
Not trendy.
But extremely powerful where it matters.

And in finance…, and somehow, even this boring guy is leveraging himself on AI to get fun a nice

I'm not saying sitck with java, java is more than a programming language, it is a technology, we have for example Clojure that is a lisp way of coding that runs on JVM, how about Kotlin? My point is to be aware and awake, Java still rocks.

posted here

Why LLM predictions are dangerous for Finance?

Paulo Victor Leite Lima Gomes — Thu, 21 Aug 2025 12:40:00 +0000

Thats right, prediction are not the same as calculations, and LLMs don't calculate, they predict the next word.

Stanford's HELM report shows GPT-4 hits 90%+ accuracy on math tasks. But 90% accuracy in financial calculations means 1 in 10 transactions could be wrong. Would you ship that to production?

Why FinTech Can't Ignore This

If you're building payment systems, trading algorithms, or accounting software, AI math errors aren't just bugs—they're customer and compliance nightmares:

Regulatory scrutiny: Wrong calculations in financial reports = SEC problems
Customer trust: One miscalculated portfolio balance destroys credibility, FOR EVER. Who will trust in a financial company that doesn't calculate right?
Audit trails: How do you explain "the AI got confused" to auditors?
Compound errors: Small mistakes in interest calculations become massive losses, I mean, if you know the power of interest bearing you might get me

I can say to you, I tested the most famous AI assistants and vibe-code tools in the market: VScode with Github copilot, Cursor, Claude code, Replit, you named it... All of them do a really good job to kick-off, they work also very well for some classical CRUD features and some next level coding as well, like improving the scalability of some parts of the code. But, when you let they go, just doing calculations and validating by them-selves, the problem start to get serious...

Real Code, Real Problems

Let's see how AI math failures could break financial systems:

Problem 1: Interest Calculation Gone Wrong (Clojure by Claude Opus 4.1)

(defn compound-interest [principal rate time]
  ;; AI confidently writes this...
  (* principal (Math/pow (+ 1 rate) time)))

;; Looks right, but what about edge cases?
(compound-interest 100000 0.05 10) ;; => 162889.46

;; But AI might miss precision issues:
(compound-interest 100000.01 0.05 10) ;; Floating point errors
(compound-interest 100000 -0.05 10)   ;; Negative rates break everything
(compound-interest 100000 0.05 0)     ;; Edge case: time = 0

The Problem: AI generates plausible code but misses edge cases that financial systems must handle. Negative interest rates, floating-point precision, and boundary conditions aren't just theoretical—they're regulatory requirements.

And this is still very surface of the problem, we are still not mixing the problems, like a customer with a Credit Card bill that gets late, he pays a minimum and buys a new think of other interest rate that needs to consider the tax of the country. This is a perfect place for AI halucinations.

Problem 2: Portfolio Rebalancing Logic (Rust by DeepSeek-R1)

rust// AI-suggested portfolio rebalancing
fn rebalance_portfolio(assets: &mut Vec<Asset>, target_weights: &[f64]) {
    let total_value: f64 = assets.iter().map(|a| a.value).sum();

    // AI logic seems reasonable...
    for (i, asset) in assets.iter_mut().enumerate() {
        let target_value = total_value * target_weights[i];
        asset.value = target_value; // Wait... this isn't how rebalancing works!
    }
}

struct Asset {
    symbol: String,
    value: f64,
    shares: f64,
    price: f64,
}

The Problem: AI confidently generates code that looks mathematically sound but completely misunderstands the business logic. Real rebalancing involves buying/selling shares at market prices, not magically changing asset values.

The AI pattern-matched "rebalancing" with "adjusting proportions" but missed the crucial financial mechanics.

What's Missing in AI Math

Real mathematical reasoning needs:

Symbolic reasoning: Apply rules systematically, not guess patterns
Persistent memory: Remember that principal = 100000 throughout the calculation
Domain knowledge: Understand that negative interest rates are possible in modern finance, also all possible caveats and laws
Formal verification: Prove that functions handle all valid inputs correctly
Meta-cognition: Know when it's uncertain about financial regulations

But ok, and what...?
Should we avoid AI in all financial systems? Of course not, also I'll never be this person saying that AI is useless, also not being this person saying AI is already replacing everything it sees. The fact is that this AI revolution, as everything in life lives in the middle term, I mean, neither black, neither white, besides we as a humans like to see polarization, the world doesn't work like that. That said, I suggest you, full usage of AI on financial world, but keep your aware and cautions ON, kind of creating your own guidelines, you can start from mine ones:

AI usage guidelines for Finance:

Double-check all AI-generated financial calculations
Use math-optimized models (GPT-4, Claude Opus) but never trust them blindly
Implement comprehensive validation layers
Never let AI directly touch critical financial paths without supervision
Maintain audit trails for all AI-assisted calculations
Identify errors fast, rollback and learn from it

The Future

Mathematics is the foundation of financial systems. An AI that truly understands math—not just mimics it—could revolutionize risk management, fraud detection, and algorithmic trading.

But we're not there yet. Current LLMs can bluff convincingly, but financial markets don't accept "close enough."

The future belongs to AI that knows the difference between prediction and calculation. Until then, trust but verify—especially with other people's money.

References

The Limitations of Language Models - Academic deep dive

Stanford HELM Report - Comprehensive AI model evaluations
SEC Guidance on AI in Finance - systemic risk on capital markets - Regulatory perspective
Apple paper the Illusion of Thinking - Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity
Formal Verification in Financial Systems - Why math matters in finance
Mathematical Reasoning in AI - Current capabilities and limitations

Why I’m Betting on UTCP as a Serious Alternative to MCP

Paulo Victor Leite Lima Gomes — Fri, 01 Aug 2025 13:37:03 +0000

Over the past few years, I’ve worked on large-scale distributed systems where messaging, streaming, observability, and backpressure weren’t just technical details. They were daily blockers. Every protocol decision mattered, especially as teams scaled and complexity grew.

That’s why when MCP (Model Context Protocol) was introduced in late 2024, I was genuinely excited. It brought a structured way to manage AI model contexts, enabling execution orchestration, consistent context propagation, and model-aware communication. In many ways, MCP filled a much-needed gap in the AI stack.

But like any new protocol, it still has room to evolve.

Recently, I spent some time reviewing a new proposal called UTCP (Unified Transport Control Protocol). After reading the RFC and supporting documentation, I believe it deserves serious consideration. Not because MCP is broken, but because UTCP addresses a different set of system-level needs that will likely become more relevant over time.

If you’re working with MCP today or planning to adopt it, I think it’s worth understanding what UTCP is offering. Here’s why.

🧠 A Simple Code Comparison: MCP vs UTCP in Clojure

Before jumping to recommendations, here’s a simplified Clojure example that helps explain the difference in scope and philosophy between MCP and UTCP.

This code is conceptual. It’s not connected to real-world libraries. The goal is to visualize the design mindset of each protocol.

MCP – Wrapping Context Around Model Execution

(defn run-inference \[model input context\]  
  (let \[merged-context (merge {:trace-id (java.util.UUID/randomUUID)} context)\]  
    {:model model  
     :input input  
     :context merged-context  
     :result (str "Inference result for input: " input)}))

;; Example usage  
(run-inference "gpt-4" "Summarize this article" {:user-id "abc123"})

Explanation:

MCP helps structure model requests by embedding metadata such as trace IDs, user roles, or request origin. The focus is on organizing context per call.

UTCP – Streaming-Aware Transport with Flow Control

(defn send-stream \[stream metadata\]  
  (let \[session-id (java.util.UUID/randomUUID)\]  
    (doseq \[chunk stream\]  
      (if (\< (rand) 0.95) ;; simulate backpressure  
        (println "Transmitting chunk:" chunk "with session:" session-id)  
        (println "Backpressure triggered, delaying chunk:" chunk)))  
    {:status :ok  
     :session session-id  
     :trace (str "Trace ID: " (:trace-id metadata))}))

;; Example usage  
(send-stream \["Hello" "world" "this" "is" "UTCP"\] {:trace-id "xyz789"})

Explanation:

UTCP focuses on message flow, backpressure handling, and streaming behavior. It’s meant for transporting data in motion across services.

Quick Comparison

Feature	MCP	UTCP
Purpose	Contextual model execution	Streaming-aware transport and control
Handles Streams?	No	Yes
Observability	Context passed manually	Tracing built-in
Backpressure	Not handled	Handled natively
Usage Style	Wrap model calls	Transmit and control stream behavior

Why I Think UTCP Is Worth Watching

Designed for Streaming from the Start

UTCP handles continuous data flows as a first-class concern. It fits naturally into systems where data is not just requested but streamed, processed, and forwarded in near real-time.

Observability Is Built Into the Protocol

UTCP includes native support for:

Tracing identifiers
Telemetry at each node
A simple message recorder to track flow paths

You don’t need extra tooling or manual hooks to understand how your system behaves.

Clear Separation of Layers

UTCP introduces a modular protocol structure:

Transport Layer for message delivery and retries
Control Layer for routing and QoS
Extension Layer for optional features like compression, authentication, or domain-specific plugins

This makes it easier to evolve and maintain in production environments.

Built-In Backpressure Handling

Consumers can signal capacity to upstream producers directly within the protocol. That avoids the need for application-level workarounds and keeps message flow stable even under load.

Multiple Reliability Modes

UTCP allows you to choose what level of message delivery makes sense:

At-most-once
At-least-once
Exactly-once (through optional extensions)

This kind of flexibility helps you avoid overengineering while still covering critical paths.

Attention to Security and Governance

The protocol includes:

Support for tagging and metadata for policy enforcement
Hooks for authentication and authorization
Audit-friendly structure out of the box

This is essential for teams operating in regulated industries or complex internal environments.

My Recommendation

Am I saying you should drop MCP and move to UTCP, even though MCP just launched?

Not really.

I understand it’s an overwhelming amount of information, and we’re still learning how to extract more value from MCP. It’s early days, and MCP still has a lot of potential to fulfill.

So my point is this: keep your eye on UTCP. It’s being built by people solving the right problems. If more people contribute to it, test it, and share feedback, we might end up with something that grows through the community. And who knows — maybe one day it becomes more powerful than anything released by the big tech players.

If you’re someone who cares about protocol design, system behavior, and software that lasts, I think UTCP is worth your time.

References

UTCP

UTCP RFC: utcp-RFC.md
UTCP Full Specification: https://github.com/utcp/specification

MCP (Model Context Protocol)

MCP Launch Announcement: OpenAI Dev Day 2024
MCP Reference Docs: platform.openai.com/docs/guides/gpt/mcp
MCP Overview Article: Introducing the Model Context Protocol (MCP)

Now the layoffs … later software engineers will clean the vibecoding mess

Paulo Victor Leite Lima Gomes — Fri, 01 Aug 2025 10:40:55 +0000

Let’s get straight to the point: AI is taking Software Engineers place, its faster to setup and bugless in the beginning… How about later? How about after some changes and some adjustments in the core of the applications because of business decisions and world changes? What will happen? Get ready and lets analyze it together.

A shift that’s already underway

AI is already changing the way software is built. It’s not a matter of if, but how fast you’re willing to accept, understand, and adapt to it. Many predict that by the end of this decade, AI will be responsible for producing up to 90% of all code. From powerfull code assistants like cursor to vibecoding nocode like Replit…

However, in the next two to three years, that number is unlikely to exceed 30%.

Why the gap? While AI is excellent at producing results quickly, it struggles with the kind of complexity that emerges in large systems. Especially those tied to the messy logic of human behavior and business priorities.

“Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.”

― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

Let’s be clear: AI doesn’t struggle with logic. It struggles with us. With people. Our decisions are influenced by emotion, intuition, and experience, not just data, even the most rational CEO’s and leaders. Think about when your partner says “I’m fine,” but you know they’re not. Or when a CEO kills a profitable project simply because they don’t trust the person behind it. AI can’t make sense of those things. And yet, the software it writes often needs to reflect and support decisions driven by them.

In these situations, the issue isn’t just AI’s limitations, it’s the loop of translation: a human expresses intent in a prompt, an AI writes the code, and then another human needs to adapt and evolve that code within a real system. That back-and-forth creates cracks, especially when the system grows.

The Rush for Speed

Tools like GitHub Copilot and ChatGPT already help developers get more done, faster. Tasks that used to take days now take minutes. One developer using AI can produce what once took a team. This kind of acceleration will continue to attract businesses chasing quick results.

Founders with limited technical knowledge, junior engineers, and even experienced developers are using AI to release features in record time. The benefits, faster launches, reduced costs, and smaller teams , are impossible to ignore.

The Hidden Cost

But speed comes at a price. And that price is complexity, particularly when it’s invisible until too late.

AI-generated code often lacks cohesion when integrated into bigger platforms. It might work in isolation, but struggles to scale or adapt when things change. As systems grow, AI can’t keep up with the ripple effects of design choices, performance bottlenecks, or architecture decisions that require long-term thinking.

Many people using AI tools lack the background to recognize these challenges. They’re deploying code that solves today’s needs, but unintentionally creating massive maintenance costs down the line.

AI doesn’t (yet) have a strong grasp of:

* How to structure systems for adaptability
* When to prioritize performance over simplicity
* How one change can introduce cascading issues across multiple components
* Design patterns that keep software stable and understandable

Without this knowledge, teams relying too heavily on AI will face rising error rates, longer recovery times, and growing frustration as systems break under pressure.

Hitting the Wall

Yes, we’re heading toward a future where AI writes most of the code. But before that, many companies will face a harsh reality. Over the next few years, teams will hit a wall. Projects rushed with AI will become harder to maintain. Bugs will increase. Flexibility will vanish. The result? A growing demand for experienced engineers who can step in and make sense of the mess.

This is why AI-generated code will likely plateau around 30% in the short term. Not because the technology isn’t powerful, but because building reliable systems takes more than outputting lines of code.. it takes real understanding.

What’s Coming

Eventually, AI tools will improve. They’ll learn to include context, track intent, and help design better systems, not just generate functions. Teams will also become more thoughtful in how they use AI, blending its speed with human insight.

But for now, we need to stay cautious. The coming years will divide those who use AI to strengthen their codebase from those who use it to patch together short-term results.

Software complexity won’t disappear just because AI can write quickly. And writing fast is not the same as writing well.

A Case in Point

Here’s a simple example from a study I’m currently finishing:

A trading startup created a platform for currency exchange. Their five-year plan aimed to capture a large share of the global market. Instead of hiring 20 engineers, they used AI to build the entire platform with just two developers and a small team of product managers and analysts steering the process.

The results were impressive, at first. They reduced bugs by over 40% compared to traditional teams, and their output was 70% higher.

But then the market shifted. A new U.S. president introduced tariffs that made currency trading unprofitable. The company pivoted to focus on energy and oil trading instead.

And this is where the problems began.

Rebuilding the platform for the new strategy wasn’t just difficult, it was nearly impossible. What should have taken weeks would now take months. Why? Because the code was built by AI to solve specific problems with no clear documentation, no architectural foresight, and no long-term planning. The AI-generated scripts weren’t designed to adapt. And the people operating the system didn’t fully understand how it worked under the surface.

Without experienced engineers, the company faced massive delays and rework. They had saved time upfront, but at the cost of flexibility when it mattered most.

Final Thoughts

This is why software engineers will matter more than ever in the years to come. Especially those with mid to senior-level experience. They won’t just write code, they’ll be the ones called in to fix what was built too fast, too recklessly, and with too little thought.

AI might lead the charge, but humans will still be needed to make sense of the chaos that follows.

Memory vs. Context in AI: Why ChatGPT Is Ahead , and Why That Matters

Paulo Victor Leite Lima Gomes — Fri, 01 Aug 2025 10:36:54 +0000

In the current AI arms race, everyone’s talking about models, benchmarks, multimodal capabilities, and token context windows. But very few talk about the most important differentiator for real-world usefulness: persistent memory.

If you care about long-term productivity, personal assistants, or AI that actually understands you, this is the piece you need.

🤯 First: Memory ≠ Context

This is where most misunderstandings begin. People assume that because an AI like Claude or Gemini “remembers” what they said 2 minutes ago, it has memory.

Wrong.

Here’s the real difference:

Concept	What it really means	Example
Context	Temporary chat history , only visible in the current conversation	Ask something, get a reply, it “remembers” it… until you close the tab.
Memory	Long-term, persistent knowledge across sessions	Tell it your project goals today, it brings them up automatically next week.

Context is like short-term RAM. Memory is like a persistent database.

🧠 Why Memory Is Game-Changing

If you’re building anything that takes more than one session , like:

An investment strategy
A health or fitness tracking system
A language-learning roadmap
A long-term coding or business project

…then memory turns ChatGPT into something more than a chatbot.

It becomes a personal AI operating system.

You can say:

“Remember this as part of my Poland tax planning.”

Or:

“This fitness routine is temporary , don’t store it long-term.”

Then weeks later:

“What was my Polish safe plan again?”

→ ✅ Instant recall.

🏆 Why ChatGPT Is Ahead of Claude, Gemini, DeepSeek, and Mistral

Let’s be direct:

Model	Memory Support?	Notes
ChatGPT	✅ Yes	Full persistent memory. You can view, edit, delete memory.
Claude	❌ No	Great summarizer. No memory between chats.
Gemini	❌ No (yet)	Only has session-based context. Memory is experimental.
DeepSeek	❌ No	Great at coding. No long-term memory.
Mistral	❌ No	Open-weight model. Memory must be built externally.

ChatGPT is currently the only mainstream model with memory you can interact with, control, and build on.

🧠 But Here’s the Trap: More Data ≠ More Intelligence

Let’s kill a myth:

“If I upload all my Google Drive, I’ll have the smartest AI assistant ever!”

🚨 False.

Dumping massive data without structure = chaos.

Why?

LLMs aren’t designed to handle unfiltered, redundant, outdated, or low-signal content.
Memory slots are limited (about 100–300 facts/pieces of context).
Without prioritization, your AI assistant becomes a hallucination machine.

Instead of sharp answers, you get:

“Based on that 2019 PDF and one random bullet in a meeting note, I recommend…”

Nope. Not useful. Not smart.

🧱 The Right Way: Build a Personal AI OS

If you want to build an actual assistant that works, here's the high-level approach:

Organize your knowledge

Group your files and info into areas: Finance, Health, Projects, Legal, etc.
Curate, don’t dump

Feed in only the relevant conclusions, not raw documents. You want distilled insights, not clutter.
Assign Relevance

Tag info as: Core, Important, Reference, or Temporary.
Use Memory Intentionally

Tell ChatGPT:

“Remember this as part of my Finance path.”

Or:

“Forget this ankle injury stuff from July , not important anymore.”
Avoid Data Hoarding

More memory ≠ better output. High-quality context > massive memory dumps.

🧠 Final Thought: Memory Is the Real AI Breakthrough

Everyone’s talking about longer context windows and flashy benchmarks, but they’re missing the point:

The future isn’t just smart AI , it’s AI that knows you.

ChatGPT is leading that future right now.

So instead of asking, “Which model is smartest?” start asking:

“Which model knows me?”
“Which one improves over time with my goals?”
“Which one helps me build a system, not just answer a prompt?”

Memory is not a feature , it’s the foundation of a real relationship with your AI.

Want help designing your personal memory architecture?

DM me, or just start with this:

“ChatGPT, remember this as part of my personal operating system.”

Let’s build something smarter than a search bar.

staging and QA will not save your systems

Paulo Victor Leite Lima Gomes — Fri, 20 Dec 2024 16:20:32 +0000

In the now named "traditional" software development workflows, staging environments and QA testing have been treated as essential steps to ensure software quality, right? However, in our current fast-crazy-ia-uncertain environments, these practices often fall short. Let’s explore why this approach is flawed and how a more clear/problem-solving approach addresses these shortcomings.

The Limitations of Staging Environments

A staging environment is intended to replicate production as closely as possible, or at least this is the goal. However, this replication is never perfect, leading to some problems like:

Environmental Drift: Staging environments rarely mirror production completely. Differences in configurations, data, and scale mean issues encountered in production might not surface in staging, even having a perfect infra as code you have and having perfect isolated containers configurations.
Maintenance Overhead: Keeping a staging environment in sync with production requires constant effort, adding operational complexity.
False Security: A successful test in staging does not guarantee that the software will work flawlessly in production. Relying on staging can create a false sense of confidence.
Cost: Staging environments consume resources and increase costs without necessarily providing commensurate value.

Why QA Cannot Fully Represent Customer Behavior

QA engineers focus at identifying edge cases, as funny illustrated in the classic meme:

A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders a lizard. Orders -1 beers. Orders a alijskjficcckk.

First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.

This rigorous testing is essential to ensure the system handles unexpected inputs gracefully. However, QA processes often miss real-world scenarios that customers encounter. For instance:

Unpredictable User Behavior: Customers interact with software in ways that no QA process can fully anticipate. For example, a QA engineer might focus on functional correctness, while a customer might inadvertently trigger a critical bug by navigating an uncommon path.
Environment Differences: Real customers operate in diverse environments with varying network speeds, devices, and configurations that QA tests might not cover.

In the joke’s conclusion, the real customer asks, “Where’s the bathroom?”—an ordinary scenario—and the entire system fails. This underscores the gap between QA testing and real-world usage.

A Better Validation Flow for Modern Companies

To mitigate these challenges, modern software development practices emphasize a validation flow designed to identify and address issues in production quickly and efficiently:

Unit Tests: These form the foundation by validating individual components in isolation, ensuring basic correctness.
Integration Tests: These ensure that components work together as expected, catching issues that unit tests might miss.
Canary Deployments: Instead of using a staging environment, deploy changes to a small subset of production users. This allows teams to observe real-world behavior with minimal risk.
Feature Flags: Feature flags enable teams to release features to specific user groups, providing granular control over the rollout process.
Rollout Approach: Gradually increase the user base for new features, monitoring for issues at each step. This minimizes the impact of potential problems.

Advantages of the real problem-solving approach

Real-World Validation: By testing directly in production, teams gain insight into actual customer behavior.
Faster Feedback Loops: Canary deployments and feature flags enable rapid iteration, reducing time to resolution for issues.
Cost Efficiency: Eliminating staging environments reduces operational overhead.
Improved Customer Experience: A gradual rollout with real-time monitoring ensures issues are addressed before they impact a large user base.

Recommended Libraries and Tools

To implement this approach effectively, consider these tools:

Unit Testing: JUnit, Mocha, PyTest
Integration Testing: Cypress, Postman
Canary Deployments: Argo Rollouts, LaunchDarkly
Feature Flags: Unleash, Flagsmith
Monitoring: Datadog, New Relic, Grafana

Conclusion

Staging environments and QA testing have their place but are insufficient to ensure software quality in modern, customer-centric organizations. By leveraging a combination of unit tests, integration tests, canary deployments, feature flags, and gradual rollouts, teams can validate software in real-world conditions, reducing risk and delivering a superior user experience. This approach not only aligns with modern practices but also ensures that systems are truly ready for customer use.

Understanding Conways Law and Its Impact on Software Engineering teams

Paulo Victor Leite Lima Gomes — Fri, 20 Dec 2024 16:17:18 +0000

Understanding Conway's Law and Its Impact on Software Engineering Teams

Conway's Law, introduced by computer scientist Melvin Conway in 1968, states:

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

This observation implies that the architecture of a software system will inherently reflect the communication patterns of the teams that develop it. While Conway's Law provides insight into the relationship between organizational structure and system design, it can have significant negative effects on software engineering if not managed properly.

How Conway's Law Can Negatively Impact Software Engineering Teams

Fragmented Systems Reflect Team Silos When teams are structured around specific functions (e.g., frontend, backend, QA), their communication boundaries often create systems with poor integration. This can lead to overly complex architectures, such as tightly coupled components that are hard to scale or maintain.

Example: A team responsible for APIs may build services optimized for their goals, while the frontend team struggles to use those APIs effectively due to mismatched requirements.

Reduced Collaboration and Innovation

Communication gaps between teams often result in misaligned goals. This leads to technical debt, duplicated efforts, and missed opportunities for innovation, as teams focus on isolated objectives rather than holistic outcomes.
Difficulty Scaling

As organizations grow, rigid team structures often exacerbate the challenges of scaling software. Misaligned teams may create software components that work well independently but fail under the stress of integration.
Suboptimal User Experience

When teams are organized based on internal considerations rather than user needs, the resulting product often fails to deliver a seamless user experience. For instance, a customer-facing app might feel disjointed because the teams responsible for different features don't communicate effectively.

Why Define the Software Platform First

Instead of organizing teams first and letting Conway's Law dictate system design, a better approach is to define the software platform and architecture first. Then, structure teams to align with the system's goals and user needs.

Benefits of This Approach

User-Centric Design

By prioritizing the platform's architecture, organizations ensure the system meets user needs. Teams can then be aligned around specific user journeys or services, leading to cohesive and optimized user experiences.
Improved Modularity

A platform-first approach encourages a modular architecture (e.g., microservices), which is easier to scale and maintain. Teams can then be structured to own distinct modules, reducing dependencies and promoting autonomy.
Cross-Functional Collaboration

Defining the software system first often highlights the need for cross-functional teams, where members with diverse skills collaborate to own end-to-end delivery. This minimizes communication bottlenecks and fosters innovation.
Flexibility and Scalability

Teams organized around a well-defined system architecture are better equipped to adapt as the platform evolves. This agility is critical in dynamic industries where software requirements change frequently.

Examples and References

Spotify Model

Spotify structures its teams into "squads" that own specific user-facing or system-level functionalities. This organizational approach supports their modular platform architecture, enabling faster feature development and scaling.

Industry Case Study

The failure of monolithic systems like the healthcare.gov rollout in the U.S. highlights how mismatched team structures can hinder project success. Conversely, companies like Amazon organize teams around their microservices platform, ensuring high autonomy and efficiency.

Conclusion

Conway's Law reveals the inherent connection between organizational structure and software architecture. To mitigate its negative effects, companies should prioritize designing their software platform before defining their team structure. This ensures the system reflects user needs rather than internal silos, fostering innovation, scalability, and better collaboration.

References:

Melvin Conway's original paper on the topic: How Do Committees Invent?
"Team Topologies" by Matthew Skelton and Manuel Pais: A practical guide on aligning team structures with software architecture.
Spotify Engineering Culture, Part 1: Insights into their team-first, system-driven approach to scaling.

We Need to Talk About Cloud Repatriation

Paulo Victor Leite Lima Gomes — Wed, 07 Aug 2024 17:34:52 +0000

The tech world, like almost everything in this world, is cyclical, right? In this new cycle, a new wave is coming, and it’s within the infrastructure world. After a boom in cloud computing and then code as a service, the new trend is the opposite: cloud repatriation. It's a term that has been popping up more frequently in tech circles, but what exactly does it mean? The bigger question is, why?

Understanding Cloud Repatriation

Cloud repatriation describes a shift away from the cloud and back to on-premises infrastructure. Cloud repatriators move their data, applications, or workloads from a public cloud environment back to an on-premises or local data center. "While the cloud certainly has its merits, it's not a one-size-fits-all solution." This sentiment encapsulates the core reason behind the repatriation trend. Companies are recognizing that although cloud computing offers significant advantages, it also presents challenges that can make on-premises solutions more appealing in certain contexts. And now that we have more tools that make it easier to set up a full infrastructure with Infrastructure as Code (IaC), like Terraform, Ansible, Pulumi, and OpenTofu, why not do it on our own servers?

The Motivations Behind Cloud Repatriation

After years of being told that migrating to the cloud would save money and provide flexibility, many businesses are rethinking their strategy. Several factors have driven the rise of cloud repatriation. But make no mistake, cost is the big one. While a move to the cloud could theoretically save you money, the promise often falls short.

Cost

Many companies hit hardest by cloud costs made their move to the cloud with a "lift-and-shift" strategy, where existing applications are moved to the cloud without any modifications to leverage the cloud's scalable and elastic infrastructure. While this method seems straightforward, these applications, by their nature, are not inherently optimized for the cloud environment. Consequently, they can consume more resources and become more expensive to operate than anticipated.

Control

With on-premises infrastructure, companies have full control over their data and applications, something not always possible with cloud services. This control allows for customization and fine-tuning to suit specific business needs, which can be a big factor for many businesses.

Internal Policies and Compliance

Certain industries, particularly those dealing with sensitive data, internal policies, and compliance requirements, may necessitate moving away from the cloud. In such cases, having direct control over data can help meet stringent security standards.

Storage

With the explosion of data, some organizations need vast and growing amounts of it, which can get expensive on the cloud. Repatriating this data can be a cost-effective solution for managing large-scale storage needs.

The Downsides of Cloud Repatriation

Of course, like any major shift, cloud repatriation has its challenges. Infrastructure needs, such as the requirement for physical space and hardware, can pose hurdles. There's also the need to have in-house expertise to manage and maintain this equipment, which can be costly.

The Upsides of On-Premises Infrastructure

Despite the potential drawbacks, returning to on-premises infrastructure has its benefits. Apart from cost savings and better control, businesses may find that performance is improved when data and applications are stored locally. This can lead to quicker response times and better service for customers.

Navigating the Shift Back to On-Premises

If your business is considering cloud repatriation, careful planning is crucial. Begin by evaluating your needs and resources. Identify which applications and data would benefit most from being brought in-house. Also, consider seeking advice from IT professionals with cloud repatriation experience to help guide your transition.

How About a Hybrid Approach?

As with many IT business decisions, the answer may lie somewhere in between. A hybrid approach to IT infrastructure is an effective strategy for businesses seeking to balance the benefits of cloud services and on-premises solutions. With this model, you can leverage the scalability and flexibility of the cloud while maintaining critical data and applications in your own infrastructure for enhanced control and security. By adopting a hybrid approach, you can tailor your IT landscape to fit your unique needs, optimizing for cost, performance, and compliance.

A hybrid environment can also be a stepping stone if you're wary of full cloud adoption or reconsidering your cloud-first strategies. It offers a middle ground, permitting a more gradual transition that can be adjusted over time. Finally, you can keep sensitive workloads in-house while still enjoying the innovation and modernization opportunities that cloud computing brings. This flexibility can prove invaluable as technology and business requirements continue to evolve at a rapid pace.

My Thoughts

Sure, no crazy CTO or director will turn the wheal without thinking, and sure the cloud certainly has its merits, it's not a one-size-fits-all solution. As more businesses explore cloud repatriation, it's clear that a balanced approach that combines the strengths of both on-premises and cloud-based solutions might be the best strategy moving forward.

References

"Cloud Computing: Concepts, Technology & Architecture" by Thomas Erl, Ricardo Puttini, and Zaigham Mahmood - This book provides a comprehensive understanding of cloud computing, including various strategies and architectures.
"Architecting the Cloud: Design Decisions for Cloud Computing Service Models (SaaS, PaaS, and IaaS)" by Michael J. Kavis - This book offers insights into making informed decisions about cloud service models and architectures.
"The Cloud Adoption Playbook: Proven Strategies for Transforming Your Organization with the Cloud" by Moe Abdula, Ingo Averdunk, Roland Barcia, Kyle Brown, Ndu Emuchay, and Glen G. Mella - This book discusses strategies for cloud adoption and how to effectively manage cloud and on-premises environments.

Why are working agreements crucial in engineering teams?

Paulo Victor Leite Lima Gomes — Thu, 18 Jul 2024 15:05:07 +0000

Humans are inherently social, hardwired for connection and collaboration. From ancient times, our ancestors formed tribes and communities for survival, nowadays it happens to everyone for different reasons like evolution, well-being and winning a championship or business growth.

We need to socialize

As mention in the netflix documentary about How to Live to 100, Wherever You Are in the World one of crucial point about longevity is "Connect with others as often as possible"

Working in groups lets us use different skills and views, leading to new solutions and better decisions. When people work together, they bring their unique talents and ideas, which can combine to create something greater than they could alone. Teamwork boosts creativity as members build on each other’s ideas, creating new thoughts and discoveries. For engineering teams this is pretty much the same, even if you work with a small team, establishing some rules are important to avoid misalignment during the daily work. For that, it is good to sit together and create what we call "Working Agreements".

Working agreements

Working agreements or team agreements exist to establish a common understanding of how the team will work together, define expectations, and create a foundation for effective collaboration.

Here's a breakdown of why working agreements are important and examples of important projects that use them.

Importance of Working Agreements

Clarity and Expectations:
- Working agreements clearly define roles, responsibilities, and processes within the team. This ensures that all members know what is expected of them and what they can expect from others.
Conflict Resolution:
- By setting ground rules for communication and collaboration, working agreements help in resolving conflicts by providing a framework for addressing disagreements.
Efficiency and Productivity:
- Teams with well-defined working agreements can work more efficiently as they spend less time dealing with misunderstandings and more time focusing on their work.
Accountability:
- Working agreements hold team members accountable for their contributions and adherence to the agreed-upon processes.
Cohesion and Culture:
- They help build a positive team culture by fostering mutual respect and understanding among team members.

Who Uses Working Agreements?

Working agreements are used by various types of teams, including:

Software Development Teams: Both in-house and remote development teams use working agreements to coordinate efforts and ensure consistent practices. For distributed teams are highly recommended given the fact that people might not be able even to talk on synchronous way.
Agile Teams: Agile methodologies like Scrum and Kanban often emphasize the use of working agreements to support iterative and collaborative work.
Open Source Projects: Many open source projects adopt working agreements, or similar practices, to manage contributions from a diverse and geographically distributed group of developers.

How to apply it?

It’s not a big deal or rocket science. I recommend organizing a meeting with your team to start writing down basic guidelines for working together. These guidelines can include anything that will make daily work easier and ensure everyone is on the same page. For example, decide which tool to use for communication: Slack, Discord, WhatsApp? How will you interact there—via channels or direct messages (DMs)? Will you have a plan for your team? Are you going to follow a project management methodology? Which one—Scrum, for instance?

After reaching an agreement, make sure to write it down somewhere accessible to the entire team, such as GitHub, Google Docs, or Confluence. Also, review it regularly and use it as onboarding material for new members. Below, I've listed some famous guidelines from open-source projects that use the same contribution ideas. They have a broader approach, but the rules and guidelines generally follow the same principles.

Examples guidelines and agreements

1. Linux Kernel:

The Linux kernel project has a well-defined contribution process documented in its Code of Conduct and Contributor Covenant. These documents outline how contributors should interact, resolve conflicts, and participate in the project. While not a "working agreement" in the traditional sense, they serve a similar purpose by setting expectations for behavior and contribution.

2. GNU Project:

The GNU Project, which oversees the development of the GNU operating system and various software, follows the GNU Kind Communication Guidelines. These guidelines emphasize respectful communication and cooperation, serving as a working agreement to foster a collaborative environment.

3. Apache Software Foundation (ASF):

The Apache Software Foundation hosts numerous open source projects, each with its own set of governance and contribution guidelines. For example, the Apache Software Foundation Code of Conduct applies to all ASF projects, outlining expected behaviors and processes for collaboration.

4. Mozilla:

Mozilla, the organization behind the Firefox browser and other open source projects, has a Community Participation Guidelines document. This serves as a working agreement by defining how contributors should engage with one another and the broader community.

Conclusion

Working agreements are a vital component of successful engineering teams, whether in traditional settings or open source projects. They provide structure, clarity, and a framework for collaboration that helps teams work more effectively and harmoniously. Projects like the Linux kernel, GNU, Apache, and Mozilla illustrate how such agreements can be implemented in open source environments to manage diverse contributions and maintain a positive community atmosphere and in the end, deliver one of the most important legacies for the world.

If you as a software engineer, an engineering manager or a person outside of the IT industry feels that your team takes too much time in solving simple problems, I suggest you try it.