The industry is selling you a massive lie about AI coding assistants.
They want you to believe that typing code faster automatically equals shipping products faster.
But local speed rarely translates to global throughput… unless you have a lot of money and the right framework.
Are you seeing your developers crank out code at record speeds while your actual release cycle remains stuck in the mud?
If you are a Tech Lead and you are looking to scale AI-generated code without sacrificing architectural integrity, then this email is for you.
We are stripping the magic away from these tools in The A-Side. I will show you how the SPDD framework turns disposable chats into first-class, version-controlled artifacts.
We need to stop treating prompts like used tissues.
And the rest of the stack is just as loaded:
The Read-Only Memory: Tim Berners-Lee and the radical 1993 decision to release the World Wide Web entirely for free.
The Open Thread Club: A reader desperately needs help taming an exploding AI token budget.
The Rendezvous: Upcoming developer summits in Bengaluru, Amsterdam, and Barcelona.
Before continuing, if you like my work and you want to support it, I would appreciate it if you could share this newsletter with your peers via:
💚 On WhatsApp | 💙 On LinkedIn | 🩵 Bluesky
Or just forward this email. Thanks in advance!
The Read-Only Memory
Today I bring you Tim Berners-Lee and his momentum when the World Wide Web was in place, and so a question came:
how to spread this thing
When the Web began to demonstrate its potential, he and his collaborator Robert Cailliau seriously considered the possibility of starting a company and charging for its use.
They even discussed various business models, but faced a problem: the experience with Gopher had shown that charging royalties could hinder the adoption of a technology still trying to take off, and that turning the Web into a commercial product could lead to the emergence of incompatible, fragmented versions.
Ultimately, they reached a conclusion unusual for creators of something with such immense economic potential: they were more interested in building something useful than in getting rich.
CERN finally opted to release the technology royalty-free on April 30, 1993, allowing anyone to use and develop it. Refs [1], [2]
I want to reinforce this sentence:
[…] They were more interested in building something useful than in getting rich. […]
Can you imagine that nowadays? I read you in the comments or replying this email.
In this section, we will focus on biographies of computer pioneers, forgotten historical white papers that remain entirely relevant, and independent blog posts that question the status quo of our industry.
Would you like to suggest some? I hear you! 👇🏻
The Open Thread Club
The following topic arrived quite soon in my inbox (as expected):
My company wanted me and my team mates to waste money in AI as much as possible, so we did. Now, that the cost is higher than they expected, they want us to reduce the cost. I want to reduce the cost but not the usage
— Anonymous cost reducer
This is a hot topic in my opinion. Reading on Bluesky, I find many people struggling with this. Do you feel identified with this? I do. Would you have a take on this for our Anonymous cost reducer reader? Share it in the comments!.
📖 My take: The first thing I did was install rtk tool to save tokens. It actually works for me.
Second, I use Haiku by default (I’m using Claude Code), and I just switch to Sonnet when I want the plan and iterate over it. Opus is just for really complicated plans. Fable when I’m ending the month… and I still have budget :).
Just with that, I managed to keep my money burning under control.
Any other tip you may have? Share it by replying to this email!
In this space, we will address real dilemmas about architecture, technical friction, or leadership situations sent anonymously by you.
Instead of giving theoretical or dogmatic answers, I will respond with honesty, sharing my own past mistakes in similar situations and the lessons I took away when trying to solve them.
You can start participating RIGHT NOW! Click the button below and tell me your story so I can answer in the next issue 👇🏻
The Rendezvous
This week I bring you conferences in India, Europe, and the US.
For you, reading from Bengaluru (India), Open Source India 2026, happening on October 7th and 8th.
In Amsterdam (Netherlands), the World Summit AI 2026 is coming on October 9th and 10th.
And for those RUST lovers, the EuroRust 2026 will happen in Barcelona (Spain) and online from October 14th to 17th,
A radar of events about software engineering and technical leadership.
The priority here is not to be exclusively massive conferences, but to give visibility to smaller, local encounters or emerging initiatives. If you are organizing a conference or know of an event worth sharing, the channel is open for you to send it to me and share it with the community.
Do you own an event or summit? Drop me an email! 👇🏻
The A-Side
Are you seeing your developers crank out code at record speeds while your actual release cycle remains stuck in the mud?
Maybe that question is too drastic; I know. My point there is:
How can we make our work with prompts more effective?
PDD wants to ensure that as we scale AI-generated code, we don’t sacrifice quality or architectural integrity.
☝🏼 Disclaimer: I have not tried this methodology yet. This is a summary of the framework, so you can get up to speed on this trend and give it a try.
Let’s go.
🎯 The Problem
Individual coding speed is rarely the true bottleneck in the software delivery lifecycle. When teams adopt AI assistants without a framework, they often hit four friction points that kill throughput:
Ambiguous Requirements: Misunderstandings are turned into code faster, scaling the impact of every error.
Review Fatigue: Pull requests become massive and frequent, making architectural inconsistencies harder to spot. For me, today, this is a huge impact.
Integration Issues: Generated code does not automatically mean aligned code, leading to frequent testing failures.
Production Risk: Reasoning about the risk of a change becomes nearly impossible as the volume of unmapped code rises.
It’s like buying a Ferrari and driving it on muddy roads: the engine is powerful, but road conditions and traffic determine your arrival time.
Here is where this SPDD framework comes.
👩🏽💻 What is SPDD? Prompts as First-Class Artifacts
SPDD is an engineering method that treats prompts as version-controlled, reviewed, and reused assets.
Nice definition, right? Let’s dive in a bit
👉🏼 Instead of relying on disposable chats, teams use structured prompts to capture requirements, domain language, and design intent.
The backbone of this method is the REASONS Canvas, which guides the AI from high-level intent to concrete execution.
Abstract parts (intent & design)
R — Requirements: What problem are we solving, and what is DoD?
E — Entities: Domain entities and relationships.
A — Approach: The strategy of how we’ll meet the requirements.
S — Structure: Where the change fits in the system; components and dependencies.
Specific parts (execution)
O — Operations: Break the abstract strategy into concrete, testable implementation steps.
Common standards parts (governance)
N — Norms: Cross-cutting engineering norms (naming, observability, defensive coding, etc.).
S — Safeguards: Non-negotiable boundaries (invariants, performance limits, security rules, etc.).
SPDD enforces a “closed-loop” rule: when reality diverges or requirements change, you must fix the prompt first. This ensures the prompt remains the source of truth for the system’s logic.
☝🏼 Warning: Prompts are not tissues; don’t toss them after one use.
This is it for today’s issue. Next week, you will receive in your inbox the second part that completes this series: The SPDD Workflow: From Story to Code.
Be safe,
Marcos.