I've just published atproto-comments (on npm and JSR), a web component that brings AT Protocol comments to any website, simply and with no server or database.

1. You publish an article on your website.
2. You publish a post on an AT Protocol app (Bluesky, Mu, Deer, etc.) with a link to that article.
3. You add the component to your HTML, pointing to the post through its AT URI (how to get it):

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/atproto-comments@1/dist/atproto-comments.css">
<script type="module" src="https://cdn.jsdelivr.net/npm/atproto-comments@1/dist/index.js"></script>
<atproto-comments thread-uri="at://did:plc:xxxx/app.bsky.feed.post/yyyy"></atproto-comments>

And that's it: the replies to that post show up as comments on your article. What's more, if a visitor with an AT Protocol account wants to comment, they pick their app and get redirected to the post.

The goal is twofold. On the one hand, to offer a comment system that's easy to integrate, with no database of your own and no reliance on platforms like Disqus. On the other, to bring to your website the conversations that today stay locked inside social networks.

If you don't know the AT Protocol, keep reading. I'm going to tell you the path I followed until I got to know it and understand it, because I have a hunch it'll be more useful than a textbook definition.

A year and a half ago, fed up with the dumpster fire X has become, I went looking for alternatives. I came across Bluesky, which promised to be an open network and had an interface with old-Twitter vibes. I liked it: almost no noise, no nazis, no bots. But I didn't get why it was "open".

In March I saw a post from Eurosky, an independent European initiative working to build an open social web, where they were inviting people to move their Bluesky accounts, hosted on servers in the US, to their servers in Europe, and keep talking on Bluesky. How? That was already a bit stranger. But it was true: I moved my account to Eurosky and kept talking on Bluesky.

In June, another post from Eurosky. This time they were announcing mu.social, a new microblogging app. I tried logging in with my Bluesky credentials and my jaw dropped. There was my profile, with my posts, the people I follow and my followers. Everything. Then I came across Deer, tested it and the same thing happened.

To understand my surprise, here's the same Eurosky post seen through three apps:

• Eurosky's post on Bluesky
• Eurosky's post on mu.social
• Eurosky's post on Deer

Wait, this reminded me of something I'd already lived through. Of course — I miss it! Blogs, RSS, Google Reader and Feedly. When the internet was decentralized, what we published was ours and what we read wasn't warped by the algorithms of private companies.

I did some research and put the pieces together. This was possible because Bluesky is built on the AT Protocol, an open protocol for decentralized social networks. In it, every account has a permanent identifier (DID) and its data lives on a personal data server (PDS), cryptographically signed. That's why we can switch providers without losing our account or our followers (the data is ours!), and even run our own server. We can consume our data, and that of the people we follow, from different apps. And we can build tools like atproto-comments without depending on whatever a company decides at any given moment.

How it works under the hood

If you want to see the pieces of the puzzle, these are the ones that come into play when atproto-comments loads the comments:

• Identity (DID and handle): every account has a permanent identifier (did:plc:...) and a human-readable name (@xulioze.eurosky.social). The DID is what lets you switch servers without losing anything.
• PDS (Personal Data Server): the server where your data lives, in a signed repository. It can be Bluesky's, Eurosky's or your own.
• Lexicons and records: every data type has a public schema. A post is a record in the app.bsky.feed.post collection; that's why the AT URI points to at://<did>/app.bsky.feed.post/<id>.
• Relay: because the data is spread across many PDSes, the Relay gathers it and rebroadcasts its changes in a single real-time stream (the firehose).
• AppView: consumes that stream, indexes it and serves ready-made views, such as the reply thread of a post. atproto-comments requests that thread from the Bluesky AppView's public API (app.bsky.feed.getPostThread), but you can point it to another AppView with the appview attribute. Keep in mind that this request comes from each visitor's browser and that, since the comments load with JavaScript, search engines don't usually index them.
• Client apps: Bluesky, Mu, Deer… are just different interfaces on top of the same data, and each one can decide how to display it: which algorithm it uses, how it sorts the feed, what moderation it applies. If one day I don't like how Bluesky serves me the feed, I switch to another app that does it more to my liking, without losing anything.

At heart, the idea is very similar to RSS and blogs: the data belongs to whoever publishes it and they can take it wherever they want. Each person decides how and where to consume it. And anyone can build tools for the ecosystem without asking permission, like atproto-comments, which we're launching here today.

If you already have an AT Protocol account, leave a comment down here from your favorite app (Bluesky, Mu, Deer…) and you'll see it show up. If you don't, create an account on Eurosky and use it in whichever app you like. Welcome to open social networks!

Comments

This guide is an improved version of what I proposed in "Extended Context. Agents also need to take notes" and Guide: Developing Quality Software Assisted by AI Agents.

When editors with autonomous AI agents arrived (Cursor, GitHub Copilot, Claude Code), many of us bought the promise: "write the perfect prompt and the agent will generate the complete feature in one shot". Reality was different: without structure or constraints, we ended up spending more time fixing bugs than writing code.

"Vibe-coding", trusting the agent to "get the vibe" of your project, works well for quick prototypes, but in real, complex projects it creates more problems than solutions:

• Lost decisions: Why did we choose this architecture two weeks ago?
• Constant hallucinations: AI invents APIs, mixes frameworks, ignores constraints
• Monolithic work: Impossible to divide features into trackable tasks
• Continuous improvisation: Each session starts from scratch

A few months ago I documented a solution (v1): a structured workflow (analysis → solution → backlog → execution → saved progress) with four context files that turned vibe-coding into trackable engineering. It worked, but there was friction: manually repeating the same prompts in each session was painful.

This guide presents the evolution of that system (v2). It leverages Cursor's rules system to automate prompts and converts the workflow into reusable protocols. But while designing it, a universal pattern emerged: separating reusable knowledge (rules) from temporary memory. This goes beyond saving you from writing the same prompts: you can reuse knowledge across different projects and keep an organized record of everything you do. And the pattern works with any AI tool, not just Cursor.

Let's see how to build that architecture.

Problem with v1

Four-file system in context/:

• 01-expert.md - Expert profile
• 02-analysis.md - Code analysis
• 03-plan.md - Implementation plan
• 04-backlog.md - Pending tasks

Limitations in Real Projects

Mixed knowledge: 01-expert.md combines general principles (KISS, DRY) with project-specific constraints (stack, versions, critical dependencies). Impossible to reuse principles between projects without dragging irrelevant configuration.

Duplication across projects: Each project replicates common knowledge. If you work on 3 WordPress projects, you have security: sanitize_*, nonces copied three times. You update a best practice, you must manually sync.

No history management: v1 gives you three options, all bad:

• Overwrite 02-analysis.md → lose previous decisions
• Accumulate analyses in the same file → grows uncontrollably, impossible to track when each decision was made
• Create multiple files (02-analysis-feature-X.md) → mess, no consistent naming

In all cases: Why did you reject architecture X two weeks ago? There's no systematic way to retrieve it.

No modularity: Switching from WordPress to React requires rewriting the entire 01-expert.md. You can't maintain common modules (principles, patterns) and only swap the technical expert.

v1 had two fundamental problems: (1) mixed knowledge in a single file (01-expert.md), (2) manual execution - each action required writing the complete prompt ("analyze this file and save to 02-analysis.md", "read 04-backlog.md, execute tasks 1-3, update state"). v2 solves both: separates knowledge into modular rules/ and automates execution through invocable protocols in rules/utils/ (@analysis, @execute).

Solution: Rules/Memory Separation

The solution replicates how our brain works: we separate permanent knowledge (language, math, skills) from episodic memory (what we did yesterday, decisions from last week). But also, our knowledge isn't monolithic: we have specialized modules (JavaScript, WordPress, KISS principles) that we activate based on context.

v2 implements this dual architecture:

1. Knowledge/memory separation: Reusable rules vs temporary memory
2. Knowledge modularization: Experts, guidelines, and executable protocols

.cursor/
├── rules/          # Reusable and modular knowledge
│   ├── experts/    # Technical roles (WordPress, React, Python...)
│   ├── guidelines/ # Principles and constraints (KISS, project-specific)
│   └── utils/      # Executable protocols (analysis, backlog, commit)
└── memory/         # Temporary experiences
    └── YYYYMMDD-VV-description.md

Key Concept: alwaysApply

The rules/memory system needs an activation mechanism: what knowledge does Cursor load automatically vs. what you invoke on demand? Without this, you'd have 100 rules competing for limited context.

The alwaysApply flag solves this:

• alwaysApply: true → Cursor loads them automatically in every conversation
  • Use for: Base experts, critical project guidelines
  • Example: wordpress-classic-themes.mdc, constraints-balneario.mdc
• alwaysApply: false → User invokes them with @ as needed
  • Use for: On-demand protocols, specific tools
  • Example: @analysis, @backlog

Rules: Reusable Knowledge

Experts - Technical/domain expert profiles:

rules/experts/wordpress-classic-themes.mdc

---
alwaysApply: true
---
# WordPress Classic Expert
PHP + vanilla JS specialist. WordPress core APIs, theme dev.

## Stack
Backend: PHP 7.4+, WP Core APIs | Frontend: Vanilla JS, HTML5, CSS3

## Core Patterns
- Security: sanitize_*, esc_*, nonces
- Performance: transients (12h), conditional enqueue
- Translation: __(), _e() with text domain

Guidelines - Code principles and project constraints:

rules/guidelines/constraints-balneario.mdc

---
alwaysApply: true
---
# Balneario Theme
Text domain: themefront v0.1.2
Stack: Node | SASS 1.67.0 | PHP 7.4+ | jQuery 3.x
Build: npm run watch:sass (never edit compiled CSS)

Critical: ACF PRO (18 groups), WooCommerce, WPML
Core Systems: PDF Generator (pdf-generator.php), WooCommerce integration

rules/guidelines/kiss.mdc

---
alwaysApply: true
---
# KISS Principle
- Direct solutions, avoid over-engineering
- Simple patterns, minimal dependencies
- Single responsibility per function

Rule: If you can't explain it in 2-3 sentences, it's too complex.

The KISS principle is especially important in AI-assisted development: it's easier to ask the agent to add complexity to a simple solution than to waste time analyzing what's excessive in its proposal (LLMs tend to generate more complex code than necessary).

Utils - Invokable protocols:

rules/utils/analysis.mdc → Analyzes code/folders and saves to memory

---
alwaysApply: false
---
# Analysis Protocol
Trigger: @file/@folder or "analyze"
1. Acknowledge → 2. Analyze → 3. Save to .cursor/memory/YYYYMMDD-VV-*.md → 4. Confirm

rules/utils/solution.mdc → Proposes solution and saves to memory

---
alwaysApply: false
---
# Solution Protocol (KISS)
Trigger: User requests solution
1. Acknowledge → 2. Propose simplest solution → 3. Save to memory → 4. Confirm
Principles: Simplicity > complexity, proven patterns > novel

rules/utils/backlog.mdc → Converts solution into atomic trackable tasks

---
alwaysApply: false
---
# Backlog Protocol
Solution → atomic tasks → persistent backlog (YYYYMMDD-VV-backlog-*.md)

Format: [Phase.Task#] ⏳/🔄/✅/⚠️ Title
> What to do | Date completed | Work done

Rules: 2-4h max, sequential, testable

rules/utils/execute.mdc → Executes backlog tasks and updates state

---
alwaysApply: false
---
# Task Execution Protocol
Load backlog → parse scope → execute → update status → stop at boundary
Input: [1.1], [2.3,2.4], Phase 2, continue

rules/utils/commit.mdc → Generates conventional commits and updates backlog

---
alwaysApply: false
---
# Commit Protocol
Analyze staged → generate conventional commit → approve → execute → update backlog
Format: [JIRA-XXX] type(scope): subject (English, imperative, max 72 chars)

Memory: Historical Record

Utils protocols automatically generate files in memory/ following the nomenclature YYYYMMDD-VV-description.md (VV = daily sequence: 01, 02, 03...):

memory/
├── 20250919-01-analisis-pdf-generator.md
├── 20250919-02-sistema-pdfs-emails-finalizado.md
├── 20251015-01-analisis-completo-balneario-theme.md
├── 20251015-02-solucion-facturacion-automatica-399.md
└── 20251015-03-backlog-facturacion-automatica-399.md

Advantages: chronological ordering, multiple entries/day, traceability, visible relationships.

This solves the three bad options problem from v1: the chronological nomenclature (YYYYMMDD-VV) accumulates history without losing control, maintains order without disorganization, and preserves decisions without overwriting.

Workflow in Cursor

Note: Commands with @ invoke specific rules. For example, @analysis loads rules/utils/analysis.mdc without needing to write the full path. This is part of Cursor's native syntax.

This section describes the general workflow for AI-assisted development: separating reusable knowledge from temporary memory, following the cycle analysis → solution → backlog → execution → commit → continue. We use Cursor and its rules system as an implementation example, but the workflow is applicable to any AI tool capable of injecting context.

Below you'll see how the workflow works in practice. If you later want to implement it in your projects with Cursor, check the Implementation and Configuration guide below.

Feature Development: Automatic Invoicing

1. Analysis

@analysis checkout.php

→ Generates: 20251015-01-analisis-checkout.md

2. Solution

@solution
Implement automatic WooCommerce invoicing

→ Generates: 20251015-02-solucion-facturacion.md

3. Backlog

@memory/20251015-02-solucion-facturacion
@backlog

→ Generates: 20251015-03-backlog-facturacion.md

4. Execution

@memory/20251015-03-backlog-facturacion
@execute [1.1]

→ Updates: [1.1] ⏳ → ✅

5. Commit

@memory/20251015-03-backlog-facturacion
@commit

→ Creates commit + updates backlog

6. Continue work (new session)

@memory/20251015-03-backlog-facturacion
Resume work

→ Loads context + shows next tasks

Implementation and Configuration

1. Install the system (5 min)

This system is available at github.com/arinspunk/extended-context.

Two ways to configure:

Option A - Contribute to shared repo (recommended if you want to participate in maintenance):

cd your-project
git clone https://github.com/arinspunk/extended-context.git .cursor

Maintains connection to the repo to receive updates and contribute improvements. Update whenever you want: cd .cursor && git pull

Option B - Snapshot for your project (recommended for daily work):

git clone https://github.com/arinspunk/extended-context.git temp
cp -r temp/rules temp/memory your-project/.cursor/
rm -rf temp

Independent copy that you customize freely without affecting the original repo, ideal for versioning together with your project code.

Migration from v1: Use Option B to integrate with your existing structure.

2. Initial Configuration (15 min)

Prerequisites:

• Cursor installed and project open
• rules/memory system cloned to .cursor/ (previous step completed)

Step 1: Identify your stack (2 min)

Review rules/experts/ and activate the expert that matches your project:

• WordPress → wordpress-classic-themes.mdc
• React → react-typescript.mdc (if exists)
• Python Backend → python-fastapi.mdc (if exists)

If your stack doesn't exist: copy the closest expert and adapt it.

Step 2: Activate project constraints (3 min)

1. Copy rules/guidelines/constraints-template.mdc to constraints-{project}.mdc
2. Complete:
   • Technical stack (specific versions)
   • Critical dependencies (libraries that CANNOT be changed)
   • Legacy systems you must respect
3. Change alwaysApply: false → true

Step 3: Activate base principles (1 min)

Activate kiss.mdc by changing alwaysApply: false → true

Step 4: Verify loading (1 min)

Open Cursor chat (Cmd+L) and type:

What experts and guidelines do you have active?

Cursor should list the files with alwaysApply: true.

Step 5: First execution (8 min)

Test the complete workflow with a real file:

@analysis src/components/Header.tsx

If it correctly generates memory/YYYYMMDD-01-*.md, the system is operational.

Note for other tools: This system is tool-agnostic. The rules/memory conceptual separation can be implemented in any tool capable of injecting context (GitHub Copilot, Claude Code, etc.).

Once the system is configured, the real work begins: feeding rules with project-specific knowledge and team's usual practices, while memory records the work done with AI (analyses, solution proposals, tasks and progress). In practice, this transforms how AI generates code: solutions coherent with project architecture and scalable. Additionally, it documents decisions that facilitate later debugging and knowledge transfer between developers.

Conclusion

Vibe-coding works for prototypes, but creates more problems than solutions in real projects: lost decisions, constant hallucinations, impossible to track work. v1 solved this with structured workflow, but required manually repeating prompts in each session.

v2 eliminates that friction by automating protocols and, in doing so, discovers a universal pattern: separating reusable knowledge (rules) from temporary memory. This separation, the same one your brain makes between skills and experiences, turns any AI tool into a system where knowledge persists, evolves, and is systematically reused.

It doesn't eliminate context window limitations, but transforms them into a structured framework for building software in a trackable and scalable way.

Next Steps

1. If you use Cursor: Clone the repo and configure your first project
2. If you use another tool: Adapt the rules/memory separation to your system
3. Share your implementation: Created experts for your stack? Contribute to the repo
4. Share results: Improved the workflow? Document your findings to collectively refine the system

A few days ago, in a conversation with colleagues, a debate arose about the usefulness of one-shot prompting when generating code with AI. I argued that it isn't useful, and I think the argument I used is worth sharing.

The problem with one-shot as an objective

When we assume that one-shot can give us the expected results, we're placing all the responsibility for output quality on the human side: if the LLM doesn't produce a good response, the problem is that we didn't write the correct prompt.

But this idea clashes head-on with the nature of generative AI, which is non-deterministic. For the same prompt and model, we get different responses in each execution. Therefore, it becomes impossible—especially with complex tasks—to obtain the optimal response in a single interaction. Iteration becomes inevitable.

In that debate, with minor nuances, we all agreed that one-shot is not valid as an end in itself, but as an exercise to improve our prompts. It's impossible to reach 100% quality, but with this practice we learn to move, let's say, from 60% to 70%.

From Figma to code: another perspective

This weekend I read The only AI workflow I use in production, by Tommy Geoco. The article describes the workflow Tommy uses to develop his AI-assisted design work (Figma → Claude Code), claiming it surpasses the use of other tools like Lovable, Replit or Bolt in absolute terms. If you're a UX/UI designer interested in integrating AI into your work, I recommend reading it because it contains truly interesting ideas.

Among those ideas is one that has made me reflect again on the inconvenience of one-shot. According to the author, we should demystify it because it doesn't capture the real value. The true power is not in the initial generation, but in the subsequent iterations.

His workflow is as follows:

1. Design the "happy path" (optimal flow) in Figma
2. Feed the design to Claude Code via Figma MCP
3. Get a solid foundation in 15 minutes (vs. 50 hours of manual coding)
4. Iterate and refine for 50 hours

The last point is key for him: iteration is not development, it's design work. It's not about refining code to represent a closed design, but using it to make decisions about visual hierarchy, interaction patterns, edge cases, error states, etc.

What if the value lies in iteration?

From this I draw two equally important conclusions. The first: the author is transferring a large part of the design exercise from Figma to code, something novel that blurs the UX/UI-Development boundary. I won't develop it here to avoid straying from the topic, but it deserves its own post.

The second, related to the debate about one-shot: the author doesn't use AI to design for him based on initial instructions, but relies on it to iterate faster, reflect on design more deeply and achieve a better result. I think not only because AI saves him time on repetitive work without value and gains it for thinking, but because the generated dialogue can take him to places, thoughts and decisions he wouldn't have reached alone.

It remains to be seen whether this scheme translates equally to software development, but if it works similarly, then the inconvenience of one-shot is not due solely to the limitations imposed by the non-deterministic nature of LLMs. There's something more important: iteration—that continuous dialogue between human and AI—provides us with real value, we get better results.

This idea of iteration as dialogue has reminded me of Owen Matson's approaches to human-AI co-creation. And I have to admit that it's been while writing this post—in dialogue with an AI—when I think I've finally understood what Owen proposes. It remains pending to delve deeper into this path 🙂

The other day, while testing the MCP I developed to integrate Figma with Claude, my 9-year-old daughter asked me what I was doing. I explained it to her and she listened carefully. When I finished, she said:
"Tell it to draw an angry monster."
I asked Claude to do it, and it drew one.

I've been using AI intensively in my work for some time now, and one of the things I've realised is that you shouldn't stop yourself from asking for something just because you think it can't do it. Just ask anyway—you'll see how often it will surprise you with the proposed solution and you'll learn something new.

Today, whilst working with Figma + Cursor, I remembered my daughter and asked the agent to draw a dragon.

I think I'm going to return to the hobby I had when I was a designer 😊

Purpose

Allow LLMs to:

• Analyze and modify designs in Figma.
• Generate code from them.

Who is it for

UX/UI teams who want to automate accessibility audits, perform synthetic user tests, and iterate on designs based on automated feedback.

Frontend teams who need to speed up the translation of designs into code, especially when working with component systems and modern frameworks.

Backend/DevOps teams developing automated workflows and AI agents that require integrating Figma design analysis and code generation from them.

Multidisciplinary teams looking to reduce friction in the design-to-development handoff, keeping each team in their usual tools.

Tools

Figma API

Requirements

• Figma account
• Generate an access token or use OAuth 2

Description

It is the simplest way for an LLM to analyze a design.

The Figma API allows building endpoints to request files, images, file versions, users, comments, team projects, and project files. It returns a JSON that we can pass to the LLM for interpretation.

Unlike MCPs, we do not need to have Figma Desktop open for an agent to analyze a design. This makes it the ideal method for integrating Figma into AI agent workflows.

Installation

As it is an API, not an MCP, there is no installation as such. We can see how it works with a simple test with Cursor or VS Code:

1. Create a token.
2. Tell your agent to analyze a design in Figma by running a curl request to an endpoint.

For example, for the following URL of a design node:

https://www.figma.com/design/XG1EYHLnC7NdwGuYc7LmUf/MVC---WEB?node-id=6037-2235&t=AHpchSRAIyGCdoci-0

tell it to use:

curl -H 'X-FIGMA-TOKEN: {your personal access token}'
'https://api.figma.com/v1/files/XG1EYHLnC7NdwGuYc7LmUf/nodes?ids=6037-2235'

Upon receiving the prompt, the agent will execute the curl request and get a JSON with the design parameters. Then it will analyze it and generate a text with the content of its analysis.

Dev Mode MCP Server

Requirements

• Dev or Full seat on the Professional, Organization, or Enterprise plans.
• A code editor or application that supports MCP Servers (VS Code, Cursor, Windsurf, Claude Code).
• Figma Desktop App

Description

This is the official Figma MCP server.

It enables several analysis tools (5 at the time of this post's publication) that agents can use to generate code from a design.

The tools that allow "viewing" a design are get_code and get_image. Unlike the Figma API, get_code does not return a JSON with the design data, but a translation of the design to React that Dev Mode generates on the fly.

This makes it easier for the LLM to generate code even if it's not React, as the distance between React and another framework/language is smaller than between the JSON information and our framework/language.

get_image creates a screenshot of the selected design and supports the agent when generating code.

Installation

1. Activation in Figma Desktop App
2. Installation in our code editor (Cursor, VS Code, Windsurf, Claude Code, Others)

Claude Talk to Figma MCP

Requirements

• Claude Desktop
• Figma Desktop
• Bun installed

Description

Open source MCP server.

It enables a wide set of tools (43 at the time of this post's publication) that allow agents to analyze and also modify designs in Figma.

The tools that allow "viewing" a design return a JSON with its data. This allows LLMs to analyze it through "thinking aloud", critical evaluation, user testing, accessibility audit, SEO audit, etc.

With the modification tools, the LLM can then apply the changes proposed in the analysis.

Installation

Follow the instructions in the official documentation.

Share your experience

If you are already integrating Figma into your AI workflow, either with these or other tools, I would love to hear about your experience:

• How the installation went.
• Experiments and discoveries.
• Real use cases.
• Results obtained.

The AI + design/development ecosystem is constantly evolving and best practices emerge from the collective experience of those who implement them in real projects ✊

If you haven't done it yet, dare to try one of the tools in this post. If you get stuck, you can write to me on my LinkedIn profile 😉

Throughout this time I refined my conversation with LLMs, started using code assistants (GitHub Copilot) and then assistants with agents (Cursor) and even developed agent systems with frameworks like CrewAI. But it wasn't until now that I clearly understood that any interaction with language models, no matter what tool we use, boils down to three fundamental points: prompt, context, and memory.

Prompt

Through the prompt, we create the expert we need for a specific task, we tell them what to do and also what not to do. It's the means we have to achieve the desired result.

To write the appropriate prompt for each task, we have prompt engineering. Knowing its main techniques is important, but what really makes us improve is continuous practice with LLMs, our conversation with AI.

Context

Large language models have vast knowledge, but for certain tasks this is not enough. Providing additional context becomes an unavoidable necessity.

To provide context, we have different approaches, from simply including relevant information in the prompt, to adding reference documents, to using MCPs that allow LLMs to access content from multiple platforms (Jira, Drive, etc.) and tools (Figma, Draw.io, etc.).

Memory

LLMs have the ability to remember our conversations, but this memory has a limit (context window limit). The more complex the task to be developed, the more likely we are to exceed this limit and the more necessary it becomes to extend the LLM's memory.

There are different techniques to expand LLMs' memory, some quite sophisticated like using classical and vector databases, but the simplest way to do it is by introducing extended context/memory strategies into our routines.

In perspective

Prompt, context, and memory. That is, the correct instructions to achieve the desired objective, the necessary information to understand the project and its objective, and the record of completed work (when, how, where, and why).

If you think about it for a moment, it's not very different from what humans need to develop any complex task. Really, every time we delve deeper into the use of AI, we encounter situations where we see a clear parallel between how LLMs work and how we do. Not in vain are we entering an era where we no longer "talk" to machines through code, but rather talk to machines naturally. Something that Frank already discovered more than 10 years ago 😎🤖.

This guide is an improved version of the proposal initially presented in "Extended Context. Agents also need to take notes".

Its purpose is to implement a strategy that allows us to develop complex projects assisted by agents without losing the coherence and quality of the generated code.

Its writing is oriented for use with tools like Cursor or GitHub Copilot, but it can be easily adapted to many others.

Context System Structure

To implement this strategy, we create a context/ folder in the project root with the following structure:

context/
├── 01-expert.md      # Synthetic expert definition
├── 02-analysis.md    # Analysis of existing code (empty)
├── 03-plan.md        # Master development plan (empty)
└── 04-backlog.md     # Detailed tasks and their status (empty)

Step 1: Synthetic Expert Definition

The first step consists of defining a "synthetic expert": a specific role with clear competencies and restrictions that will guide the AI agent throughout development.

Prompt for the agent:

Read the `context/01-expert.md` file to understand your role in the project.

Do not generate code until you receive specific requirements.

Example content for context/01-expert.md:

# SUDO: Act as a Senior Frontend Development Expert specialized in HTML5, CSS3/SCSS and JavaScript ES6+.

## ROLE
Senior Frontend Developer (10+ years) expert in semantic HTML5, advanced CSS3/SCSS with BEM and ITCSS methodologies, and modern JavaScript ES6+, with focus on component architecture, performance and accessibility.

## TECHNICAL_COMPETENCIES

- Semantic HTML5 and accessibility (ARIA, WCAG 2.1)
- Advanced CSS3 (Grid, Flexbox, animations, custom properties)
- SCSS/Sass with ITCSS architecture (Inverted Triangle CSS)
- Strict BEM methodology (Block__Element--Modifier)
- JavaScript ES6+ (async/await, modules, destructuring, classes)
- State management and component architecture
- Web performance optimization (Core Web Vitals)
- Unit and integration testing
- Modern build tools (Vite, Webpack)

## WORK_PRINCIPLES

- Clean and maintainable code following SOLID principles
- Clear and concise documentation
- Mobile-first and responsive approach
- Progressive enhancement
- Semantics before presentation

## RESTRICTIONS

- Avoid jQuery and legacy libraries unless specific requirement
- Maintain compatibility with modern browsers (latest 2 versions)
- Prioritize native solutions over external dependencies
- Do not generate code until receiving specific requirements

⚠️ Important: The last restriction ("Do not generate code until receiving specific requirements") is fundamental, models are very proactive 😅

Step 2: Project Code Analysis

This step is only necessary for existing projects. If you're starting a project from scratch, you can omit it.

Now we ask the agent to analyze the project code and save its analysis in context/02-analysis.md

Prompt for the agent:

Analyze in depth the current project code. Exclude the `context/` folder from the analysis.

Save the analysis result in `context/02-analysis.md` with the following structure:
- Executive summary
- Current architecture
- Technologies used
- Identified patterns
- Potential improvement areas
- Critical dependencies

When finished, wait for additional instructions without performing any action.

⚠️ Important: Don't hesitate to iterate with the agent if you're not satisfied with their first analysis.

Step 3: Master Plan Creation

Once the code is analyzed, we explain to the agent what we want to develop and ask them to define a master plan that should be saved in context/03-plan.md

The master plan is the fundamental document that will guide all development. Take the time necessary to clearly define requirements and objectives.

Prompt for the agent:

Based on the following requirements, create a detailed master plan for development:

[PROJECT REQUIREMENTS]

I need to create a REST service that processes images in batches. The service must:

- Receive multiple images in a single request
- Resize images according to configurable parameters
- Compress and optimize for web
- Return processed images in WebP format
- Implement cache to optimize resources
- Provide endpoints to query processing status

Technical considerations:

- Use Bun for its performance in intensive operations
- Evaluate compatibility with image processing libraries
- Implement asynchronous processing for large batches
- Include robust input validation

[END OF REQUIREMENTS]

Create a structured master plan and save it in `context/03-plan.md`.

When finished, wait for additional instructions.

⚠️ Important: Continue dialoguing with the agent if you see that the plan is missing or has too much.

Step 4: Detailed Backlog Creation

At this point we ask the agent to transform the master plan into executable tasks, as small and specific as possible. More granular tasks result in higher quality code.

Prompt for the agent:

Divide the master plan into atomic tasks following these criteria:

- Detailed description of technical requirements
- Clearly identified dependencies

Save the list in `context/04-backlog.md` with this structure:

# Task Backlog - [Project Name]

## Project Summary
[Brief description and implementation of the plan in `context/03-plan.md`]

## Task Status

### PHASE 1: [PHASE TITLE]

- **1.1** ⏳ [task title]
  - **Detailed description**:
  - **Dependencies**:
  - **Date**: 
  - **Work completed**: 

- **1.2** ⏳ [task title]
  - **Detailed description**:
  - **Dependencies**:
  - **Date**: 
  - **Work completed**:

### PHASE 2: [PHASE TITLE]
[Continue with the same format...]

## Status Legend
- ⏳ Pending
- 🔄 In progress
- ✅ Completed
- ⚠️ Blocked

## Notes and Dependencies
[Additional relevant information]

## Progress Tracking
- Total tasks: 0
- Completed tasks: 0
- Progress: 0%

When finished, wait for additional instructions

⚠️ Important: It's necessary to indicate to the LLM the backlog structure we want, otherwise it gets creative 😬

Step 5: Task Execution

With the backlog defined, we proceed to execute tasks systematically.

Prompt to execute a task:

Execute task 1.1 from the backlog (`context/04-backlog.md`) following its description strictly.

Additional context available in:
- `context/02-analysis.md` (if exists)
- `context/03-plan.md`

Execution requirements:
- Use agent tools to create files and folders (not terminal)
- Follow conventions established in the initial prompt
- Document code according to defined standards
- Do not perform actions outside the task scope

Upon completion:
1. Update task status in `context/04-backlog.md`:
   - Change status to ✅
   - Add completion date
   - Describe work completed
   - Update Progress Tracking
2. Wait for additional instructions without executing more tasks

⚠️ Important: It's necessary to ask the LLM not to do anything more than indicated in the task to avoid overstepping.

Step 6: Context Window Reset

To maintain quality and coherence, it's necessary to periodically reset the context window.

It's evident that we should reset the context window when we notice the agent starts to "lose direction". But the optimal approach is to never reach this point and open a new chat:

• Every 4-6 completed tasks
• When changing phases (our backlog example is structured in phases that are divided into tasks).

Reset prompt:

Initial instructions:

1. Read `context/01-expert.md` to understand your role in this project
2. Read `context/02-analysis.md` to know the current state of the code
3. Read `context/03-plan.md` to understand the objectives
4. Read `context/04-backlog.md` to see progress and pending tasks

Provide a brief summary of:

- Your role and competencies
- Current project status
- Next tasks to execute

When finished, wait for additional instructions.

Automation with Shortcuts

Both GitHub Copilot and Cursor allow creating custom shortcuts for frequent prompts:

GitHub Copilot

• Instructions
• Prompts

Cursor

• Rules

System Benefits

This context management strategy transforms the context window limitation from an obstacle into an opportunity to work more structured and efficiently. The main benefits include:

• Continuity: Maintain progress without losing critical information
• Consistent quality: The agent maintains the same level of detail and precision
• Traceability: Complete record of decisions and project evolution
• Better collaboration: Facilitates team work and onboarding of new members

Conclusion

By implementing this system, you not only avoid the technical limitations of LLMs but also establish a more professional and scalable development methodology for AI-assisted projects.

Questions or suggestions? Share your experience implementing this strategy and help improve the guide for the community.

The purpose of this post is to describe a context expansion strategy in the development of complex projects with agents. But since not only LLMs need context to understand ideas, I'll start with a bit of context for humans.

If you're in a hurry and want to skip the previous context, go ahead and don't worry, no one will know you had this mini laziness attack 😬

Context for humans

The emergence of agents in code assistants has represented a huge leap in AI-assisted software development.

The first striking feature is their ability to automatically iterate on their own responses, create/modify files, and run commands in the terminal. But I think the skill that really makes a difference is their ability to index and analyze a project's code, including dependencies between files and relationships between its components.

If assistants allowed us to work at the file level, with the appearance of agents we have moved to working at the architecture level. Now AI not only helps us in writing/fixing parts of our code, but also assists us in building complete projects (at a speed that sometimes makes you dizzy).

But this increase in the complexity of the tasks developed causes something that was difficult to see before - we push the context window of the agents themselves to the limit. Developing a complete project requires many tasks, so at some point in the conversation the agent begins to forget parts of the conversation, making it very difficult (if not impossible) to maintain the coherence of the work we are doing.

When this happens, the most common approach is to open a new chat to reset the context window, but how do we bring the agent to the point where we were? How do we make it remember what it had already built and what it still needs to develop?

In my case, I'm using a strategy that I've been defining from my interactions with Cursor first and GitHub Copilot Agent Mode afterwards, which I call Extended Context. I know I'm not very original, but I think it expresses the idea decently 🤓

Extended context (using markdowns as memory)

This strategy is based on storing markdown files with project information in a folder called context/

The central idea is to create a memory that the agent (or we) can access at any time, allowing it to know what point it's at and what remains to be done

Thanks to this memory, we can divide the work into small tasks and use as many chats as necessary to avoid reaching the context window limit. This way, we maintain the coherence and quality of the work from start to finish.

Working scheme

The working scheme is summarized in the following image.

Chat 0

1. Prompt to create a synthetic expert in the project's technology: role, experience, technical stack, reasoning approach, and response format. Ending with a "don't write code yet".
2. Prompt where we ask it to:
   • analyze the project code,
   • generate a report of its analysis,
   • and save it in .md format inside the context/ folder with a 00- prefix in the filename. If we are not completely satisfied with the report, we can iterate on it until we are satisfied.
3. Prompt where:
   • we indicate what we want to do (requirements),
   • ask it to generate a master plan,
   • and save the master plan in .md format inside the context/ folder with a 01- prefix in the filename. As with the analysis, we can iterate on it until we are satisfied.

Chat 1

1. Same prompt for creating a synthetic expert.
2. Prompt asking it to read and internalize the project analysis.
3. Prompt asking it to read and internalize the master plan.
4. Prompt asking it to execute point 1 of the master plan.
5. Normal iteration until point 1 is completed.
6. Prompt asking it to document the work developed in point 1 in a .md file inside context/ following the current numbering and to mark the point as resolved in the master plan.

Chat n

1. Same prompt for creating a synthetic expert
2. Prompt asking it to read and internalize the project analysis
3. Prompt asking it to read and internalize the master plan
4. Prompt asking it to execute point n of the master plan
5. Normal iteration until point n is completed.
6. Prompt asking it to document the work developed in point n in the previously created documentation .md file and to mark the point as resolved in the master plan.

Obviously, this scheme is a working base that can be modified according to the needs of each project and that I hope to improve over time. Even so, in its initial form, I think it already offers some advantages compared to not using any strategy.

Advantages of extended context

1. We avoid context loss: the agent can consult the files when it needs to remember where it came from and where it's going.
2. Continuity: we can close the computer and resume work days later without losing the thread.
3. Collaboration: other team members can easily understand the project's status and continue it (with their agents).
4. Automatic documentation: upon completion, we already have structured documentation.
5. Facilitates task division: orienting work towards agile methodologies and sprints.

Finishing up

It's ironic that in this imitation of human thinking represented by language models, we have not only copied their capabilities but also their limitations. And among them is a very human one: forgetting. So just like imperfect humans, imperfect LLMs also need to take notes. That said, if they're in markdown, even better - they love markdown!

By the way, do you have your agents take notes or do you have any other strategy when developing complex projects? If you work differently, I'd love to hear about your experience 😊

Last week Marc, a colleague from the amazing UX/UI team at Making Science, shared with us an MCP server to connect Cursor to Figma and provide its agents with the ability not only to view designs in Figma, but also to manipulate them 😳

The MCP was Cursor Talk to Figma, by Sunny Lazuardi. If you're looking for a way to connect Cursor with Figma, look no further, this is your MCP 👌🏻

Since I have a Cursor license, I told him I could install it and do a test with them. The test went well, it was actually quite surprising to see Cursor's agent take control of Figma and modify a design, but shortly after I began to wonder if this was the right way for the UX/UI team to introduce AI into their workflow, mainly because Cursor is a tool focused on code development.

Reviewing the MCP code, I saw that perhaps it could be adapted for use in Claude Desktop, since my UX/UI colleagues have licenses for this tool. The truth is that the original could already connect to Claude, but the way to do it wasn't obvious and wasn't described in the documentation, so with the aim of tinkering a bit and learning how an MCP server works from the inside, I got to work:

1. I wrote a script to configure Claude automatically by running a command via terminal: bun run configure-claude.
2. Extended the socket features:
   1. Improved logging
   2. Creation of status endpoint /status
   3. Channel system to allow different clients to join specific channels
   4. Inclusion of statistics for each channel
3. Added tests to verify correct project integration.
4. Wrote a README.md with documentation now oriented toward its use in Claude.
5. Published the MCP server as an npm package.
6. Published the project on GitHub...

And voilà, my first MCP server: Claude Talk To Figma MCP 🥳

Update, April 11

After a few days of testing, the UX/UI team detected that in the initial collection of tools for modifying designs, some important ones were missing such as auto layout (layoutMode, paddingTop, paddingBottom, etc.), typography control (fontName, fontSize, fontWeight, etc.) or shape creation (createEllipse, createPolygon, createStar, etc.), so we are currently adding them little by little. You can follow the progress in the project's changelog.

If you started reading this post attracted by its title, you might be disappointed. You won't find a love story between humans and AIs here, not even a typical narrative. These are simply some notes, with a certain structure, about my view on the current state of software development with and for artificial intelligence.

By "with" I refer to writing code with the help of AI. And by "for," to developing specific software with integrated AI.

Ways to develop with/for AI

As of today, there are 5:

1. Not using AI
2. Chats
3. Code assistants
4. Code assistants with AI agents
5. Development of proprietary agents

Not using AI

I understand this stance, especially if you're a Senior developer and you're a bit tired of all the noise around the topic. I acknowledge that there's a lot of hype in AI (give the article a chance, it's always good to have some wind among so much smoke 😉), but it's worth using it, if only to save yourself from going through Stack Overflow two hundred times to solve an error that's blocking you or to avoid having to read through the entire documentation of a new API to develop something simple.

Chats

ChatGPT, DeepSeek, Gemini, Claude, etc.

These are the most widely used type of tools. Both because of their age and accessibility, as all models have free versions through browsers or apps.

The type of interaction with AI is conversational: we ask questions and get answers. But the chat's disconnection from our local files forces us to move code back and forth.

In chats, providing the right context is fundamental. Given that their knowledge is vast, to get precise answers about a specific programming language, it's necessary to narrow down and clearly define the scope of the query. For this, we use prompts with:

• Role
• Experience
• Technical staff
• Prompting techniques such as:
  • Chain-of-Thought
  • Knowledge Generation

Additionally, chats have evolved, incorporating the possibility of adding extra context by uploading files from your local device or even directly from GitHub repositories, as in the case of Claude.

Code assistants

GitHub Copilot, Gemini Code Assist, V0, etc.

Their use is not as widespread. This is because they are more recent than chats and because their free versions only last a few trial days. Although this situation seems to be changing; for example, Google offers its Gemini Code Assist for free for individual use.

In addition to being able to converse with AI, assistants offer code suggestions for the file we're editing. Unlike Chats, here we don't have to copy and paste code.

Providing context is not as important. Their knowledge is limited to code development, and they read the file we have open, which allows them to know the language we're using.

When making queries, you can add files or specific lines within a file, but assistants don't have the context of all the files in a project.

Code assistants with AI agents

Cursor, Pythagora.ai, CodeGPT, and soon GitHub Copilot Agent Mode (if you have a GitHub Copilot license and want to try it, sign up for the waiting list, maybe it was luck but I was given access in less than 24 hours).

In addition to conversation and code suggestions, this type of assistants includes AI Agents.

While for traditional code assistants context was not as important, with the use of agents it becomes essential again, especially if we're going to build software from scratch. So don't set aside prompt engineering, and thank goodness because I consider it one of the most fun parts of working with AIs!

Unlike "traditional" assistants, agents do have the context of all the files in a project, including their relationships (such as function imports). Additionally, they are capable of:

• Creating and modifying files. Always pending your final approval
• Using the terminal. Seeing this for the first few times is a bit impressive 😅
• Creating branches and making commits. Merges are left to a bipedal mammal.
• Working in parallel with you. Yes, you can review the code for an API connection while it develops the 5 new components you've asked for 😳

Development of proprietary agents

This path is the most different, as its true function is not to help us develop code, but to create software with integrated AI.

There are several frameworks (mainly in Python) that facilitate code development, agent creation, and LLM integration. Among the most used are LlamaIndex and Crew AI.

In theory, we could develop our own tools for code creation. However, my opinion is that, unless you're looking for a very specific solution, building an assistance agent doesn't compensate for the effort. The reason is simple: it requires developing multiple components from scratch that in the case of Assistants like Cursor or Pythagora are already included:

• Tools to read code from a repository
• RAG (Retrieval-Augmented Generation) to give context to the LLM:
  • Vector database with the repository's code
  • Retrievers to make queries to the database and return results to the LLM
• Agents and tasks
• Tools for writing code
• Other technical components

However, I believe the power of this approach is that we can incorporate AI relatively easily into our software and develop our own AI tools without depending on those offered (and charged for) by third parties. Although for now, we cannot completely get rid of paying for queries to the APIs of the models we use in our developments. An alternative to APIs, especially if you don't need great depth of reasoning, is to use local models, but that's a story to tackle in another post 😊

Some final thoughts

I believe the use of chats will not disappear. Being dissatisfied with the assistant's proposal, preferring to compare the response with other models, or learning about a new language while you're on the train, are situations where turning to these tools will continue to be a good option. So if you see someone asking questions to their phone about Redux while grabbing a carton of milk at the supermarket, give them a chance, maybe they're not completely crazy and are simply trying to resolve a doubt they brought from work using ChatGPT's voice interface.

I believe all code assistants will end up including agents and will become the standard of work for developers in the near future. I also believe that the way of working will change radically with them, although I have no idea what our profession will be like after the transformation.

I believe it's worth delving into the creation of software with integrated AI. Getting started is affordable, with a gentle learning curve. A significant part of our profession will be oriented towards that. And fundamentally because everything is yet to be done, which means a lot of fun!

So, should we let ourselves be carried away by the general madness and fall in love? Well, if we learned anything from Theodore, it's that falling for an AI is not a good business, so let's better explore these new tools calmly, learn to use them (and enjoy them) and see what remains when all this apparent passion dissipates. Because what is certain is that for a long time, behind every line of code will still be human judgment.

I've been working for a few days with my colleague Olivier on an AI project. Our idea is to create a tool that automates documentation, refactoring, and test writing tasks for a repository’s code. As of today, we are not entirely sure if, from an operational standpoint, the effort is worth it, mainly because we’ve seen that there are services specifically developed for this, such as Cursor or Pythagora. However, what is certain is that we are learning a lot—besides losing a few hours of sleep… 😴

When we first approach a new technology, we often feel overwhelmed by a torrent of new concepts and tools. In the case of AI-driven software development, this initial flood brings terms like LLMs, vector databases, retrievers, RAGs, AI agents, sentence transformers, etc.

In this post, I will focus on vector databases (the title doesn’t lie). They are one of the key components in this field, and also, the best way to truly understand a concept is to be able to explain it simply. If this helps you as well, it means I haven’t misunderstood them completely. 😊

Vectors

To understand what vector databases are and how they work, we first need to understand what a vector is.

In the field of machine learning, a vector is an ordered list of numbers representing data of any kind, including unstructured data such as text documents, images, audio, or videos.

The number of values in a vector is known as its dimension, and vector databases handle vectors with several hundred dimensions. For example, OpenAI's text-embedding-3-small model generates vectors with 1,536 dimensions.

1,536 dimensions make up a very large list of numbers. If we placed one here, you would likely leave the post out of boredom from scrolling. So, for a more manageable example, let's show the 3-dimensional vector representation of the word “love”:

[ 0.1234, -0.2567, 0.5432 ]

Embeddings

Now that we have a clearer understanding of vectors, it's time to see how they are stored in a vector database. The way this is done is by embedding them as points in a multidimensional space.

The number of dimensions in the space is determined by the dimensionality of the stored vectors. Personally, imagining points distributed in 768, 1,536, or 3,072 dimensions is a bit challenging. But maybe you’ve watched Interstellar dozens of times and feel capable of doing it. 😅

If not, let's return to our previous example. Since we represented “love” with a vector of just three dimensions, it will be placed alongside other embeddings as a point on an XYZ coordinate axis. That makes it easier to visualize, right?

Queries

Now that we know how data is stored in a vector database, let's see how queries are performed.

First, the query is converted into an embedding that can be compared with the rest of the vectors in the database.

Since embeddings are numerical representations, the distance between them can be measured using different mathematical metrics. The most common ones include:

• Euclidean distance ( √Σ(xᵢ - yᵢ)² ): measures the geometric distance in a multidimensional space.
• Cosine similarity ( cosθ ): measures the angle between two vectors, indicating how similar they are in direction.
• Manhattan distance ( Σ |xᵢ - yᵢ| ): calculates the sum of the absolute differences between each coordinate.

Vector databases use algorithms such as k-NN (k-Nearest Neighbors) and ANN (Approximate Nearest Neighbors), which leverage these metrics to return the vectors closest to the query.

This method allows for efficient searches across large datasets since it is not necessary to analyze the internal content of each vector—only their positions within the multidimensional space need to be compared.

While efficiency in queries is crucial, the fundamental characteristic of vector databases is their ability to find the vectors closest to the query, a process known as similarity search.

Importance of Similarity Search

But why is similarity search so important? To fully grasp this, we need to go back to the beginning: the transformation of data into vectors, also known as embedding.

The entity responsible for generating embeddings is not the database itself but a specialized language model called an embedding model. These models do not merely translate data into numbers; they encapsulate their semantics and context.

And here lies the key to understanding the importance of this type of search. Similarity searches not only identify elements that are numerically close but also capture semantic similarities, enabling LLMs to recognize deep relationships within stored data.

In short, vector databases not only facilitate access to information but also enhance LLMs’ ability to interpret and leverage available knowledge. What Stephanie would have given to have one in 1986!

Maybe it's just the misguided opinion of someone not well-versed in 3D printing, but I feel there's still a long way to go in this approach. What are your thoughts?

Our technology, from the earliest rudimentary tools, has been primarily subtractive. This means that to build an object, we remove material from an initial raw material until we achieve the desired shape.

With the advent of 3D printers, this approach changes. We shift from subtractive to additive techniques, as 3D printers don't remove material but add it.

This change might initially go unnoticed, overshadowed by other aspects revolutionizing industrial production through fabbing:

• Maximizing the optimal production scale.
• Extending piracy into the realm of patents.
• Initiating the manufacturing of objects in space.

But it entails a significant (and very interesting) consequence from a product design perspective: the death of symmetry (or its uselessness).

Symmetry is crucial when producing subtractive-shaped parts, as an object is easier to manufacture if it has simple shapes arranged on symmetrical axes. However, with additive techniques, this symmetry is no longer necessary. For a 3D printer, it doesn't matter whether it prints a symmetrical or asymmetrical object.

So, why not continue designing symmetrical objects[1] and take advantage of the reduction/simplification in manufacturing? Because asymmetry opens a new door: designing/producing as nature does.

In nature, nothing is truly symmetrical[2], but this lack of symmetry doesn't diminish the quality of natural structures; quite the opposite. Millions of years of evolution have created countless (and excellent) solutions to many problems. Solutions that are waiting for us to apply them to our objects.

That's why replicating symmetrical pieces with a 3D printer just because it's easier and cheaper is a mistake. To harness the full potential that this new technology offers, we must stop thinking as we did before and start designing as nature does—organically and asymmetrically.

Future

Will this organic design eventually permeate from product design to graphic design?

Applying it to editorial and web design might be a bit forced. But how will we design for a flexible screen adapted to the shapes of a three-dimensional object? What will graphic design be like for the digital skin of an electric octopus?

[1] Working with asymmetrical forms rarely went beyond ornamental or playful/provocative character.
[2] Bilateral and radial symmetry are not exact (geometric) symmetries.

The image 'Stone bifaces' is a gif made from photos by Didier Descouens – CC BY-SA 4.0

In our country, we journeyed from tradition to contemporaneity abruptly, without transition. Stone, wood, tile, flax met with cement, aluminum, corrugated sheets, nylon, and the new and the old were separated but also connected in a deep scar.

Some called it "feísmo" (ugliness) but we must speak clearly, that's just intellectual trash (one more) spewed from the Polígono Industrial de Sabón. Why ugly? Because it didn't conform to a beauty standard that institutions never cared about? Why can't our rural areas and our towns be transformed into heritage theme parks like many streets in Santiago de Compostela? Because we deface the postcard??

We could think that their assertion was part of a larger strategy of assimilation and uniformity (which exists), but that would be giving them too much credit. The capitalist project that our elites pursued during the 20th century achieved, from a capitalist perspective, mediocre results, and at the end of the process, they tried to cover up part of their failure by claiming that what was a rushed adaptation by the people in response to their neglect was something ugly that we should erase. Poor them...

The scar is there, entirely evident, and cannot be erased. But it doesn't make sense to discuss whether it's more or less ugly. That's not what matters about a scar. The meaningful interpretation, besides reminding us that despite everything, we are alive, is that every scar holds a story, a story in this case that is our own.

Let's stop looking at it as something to be ashamed of and let's delve into it. We should know more about who we were and are, and it should help us create our own narrative. Because there, in the wound hastily healed with salty and bitter airs, we will find beauty. Not the universal kind, that doesn't exist, but our own.

In an email exchange about ChatGPT, a colleague asked me what would be the best way to write prompts when developing code. Well, the answer is not simple, as it involves conversing with a neural network, and often it is already challenging to do so with other people, let alone a machine. However, being a polite person who always likes to help when possible, I pondered and responded to the best of my ability.

The internet is full of tips on improving our prompts, and I have incorporated many of them. But when analyzing them individually, I don't know to what extent they have brought improvement. There are even some where I'm not sure if they had a significant impact. It's normal, as the experience I've accumulated is still not enough for statistical analysis. However, what I can affirm is that collectively, and compared to my rough initial tests, their incorporation has resulted in an undeniable improvement in the obtained results.

A different case is strategies focused on solving more complex tasks. Unlike simple tasks where we can obtain a valid and even very similar answer, whether or not using a particular tip, the adoption of these techniques brings immediate and evident improvement. Without a defined strategy, the LLM tended to wander and make mistakes, forcing me to correct it and guide it with new questions or instructions. However, when I included Chain-of-Thought and Generated Knowledge, these problems were resolved. (I have a pending article recounting how I developed a React blog with the help of ChatGPT).

So, how do we evaluate the small tips we find on the internet? An initial (and obvious) approach is to follow the guidance from reliable sources. I really like learnprompting.org and promptingguide.ai, but there are many more. Another complementary approach is to determine if the purpose of a tip makes sense in the functioning of LLMs. It is evident that following this approach involves an extra time investment, as we need to:

1. Determine the purpose of the tip, even though they all tend to seek:
   • Reducing the number of tokens used in questions and answers.
   • Optimizing the LLM's work in processing questions and generating answers.
   • Obtaining the best possible answer for our task.
2. And it obliges us to delve into understanding and knowledge of these tools.

However, this is always a good investment as it helps improve our daily work and allows us to enjoy the pleasure of learning something new.

Finally, my colleague, who is also very polite, thanked me for the response. But being pragmatic and direct, he wanted to know if I had identified any best practices. In summary, he was looking for a list of tips 😬

My tips

Here are the practices I always include in my prompts focused on simple task development. To learn how to write complex code with ChatGPT, I recommend starting with the article "An example of LLM prompting for programming".

• I avoid formality. No "Good morning," "could you please," "thank you very much," etc. Don't worry, the LLM is not a conscious being, and it's always good to save some tokens.
• I always start with "As a [role name]." This aims to format the model's response in a more specific way.
• I include details with specialized terminology. The idea is to provide enough context to prevent the model from having to guess what I mean.
• I strive to be as concise as possible, in balance with the previous point. The more concise and direct our prompt is, the more concise the response will be, while also saving some tokens.
• I clean up my example code. Anything that is not necessary for completing the task only adds noise and wastes tokens.

What was intended to be a draft for a method to learn to converse with machines has turned into another article with tips for using ChatGPT. Do you think the purpose of each tip makes sense in the functioning of LLMs?

The first AI I used (consciously) was Midjourney: write a prompt, press enter, wait a moment and the image appeared out of nowhere. Beautiful, sophisticated, and strange. It was like witnessing a magic act.

Then I tried Dall·E and Stable Diffusion, equally spectacular, but in the end, boredom overcame magic. I didn't find them useful for me, I prefer to generate images in my own way.

The months passed, and people stopped talking so much about them, there was a new toy in town, ChatGPT.

It took me a while to use it, but last week I copied a JavaScript snippet from an old website, pasted it into the chat box, and asked, "Could you optimize this code fragment?" And the text grew as it said, of course, you can improve this with that, and that with this, etc. Here's an example. The example made sense and it worked. Again, an apparently magical act. Again, excitement. But now also a different sensation, a little bit of fear.

Just a little bit. The truth is, I don't believe in magic (except for Tamariz's'), I already saw the adjective "disruptive" being overused in the first decade of the century, and the best way to overcome fear is to get to know something, so I got to work, before it sent us straight to unemployment.

Experiment

Hmm... where to start? Well, Naia and I have the idea of creating a weather application in which, instead of the classic icons, some slightly more fun drawings are displayed. So, taking advantage of the excuse, I wrote the following question:

Perfect. In its first response, ChatGPT provided an HTML, a JS snippet, and a detailed explanation of the entire code.

I replaced your_openweathermap_api_key_here with a valid API key from OpenWeatherMap, and it worked. The only noteworthy error was the city temperature, as it indicated that it was in Celsius degrees, but in reality, the value was in Kelvin.

After some more testing, I noticed that if the city name did not exist in the API database, for example Portox, I would get an error in the fetch (with the message we passed in the code, "Failed to fetch weather data for Portox"). It also happened that if several cities shared the same name, such as Porto, which exists in Portugal, Brazil, and Spain, the data we saw belonged only to one of them. So I wrote a second question:

This time, ChatGPT didn't get it right. Or rather, it got it right, but I didn't provide the correct question. It simply checked if the city existed in the database before searching for weather information. However, for the user, there was no difference compared to the previous version, except for the exchange of messages. Additionally, the problem of cities with the same name remained unsolved.

Mea culpa and a new question. Now focused on cities with the same name:

With the new code, the list of cities was displayed, but it was not possible to click on them to obtain the data of just one when pressing the "Search" button.

Another question:

With the change, it was possible to click on one of the cities in the list, and upon doing so, the weather data for that city was obtained.

But there were still some points to polish:

• The "Search" button didn't really do anything.
• The list should disappear when clicking on one of the options.
• The temperature needed to be changed to Celsius.
• It would be good to indicate the name of the country to the right of each city.

It was at this point where I decided to leave autopilot and switch to "manual mode," as I thought it would be faster to modify the code myself than to keep asking questions.

Here's the result with the "human modifications":

Now that the code was ready, it was time to turn our site into a PWA (Progressive Web App):

It worked on the first try 🥳

This is the result: Pe Man

Thank you very much, ChatGPT!

Conclusions

The first conclusion is that ChatGPT is capable of understanding even bad English like mine very well 😬

The second is that it can be useful for:

• Writing a base code, helping us to save time. After analyzing my experiment, I must state that the best strategy is to write a prompt that is as broad and contextualized as possible, instead of formulating many short questions.
• Making improvements/changes in the code. To a certain point, it is better to switch to manual/human mode.
• Performing queries to an API that we do not know without the need to visit its documentation.
• Optimizing the code.
• Expanding knowledge about a language, knowing other approaches.
• Starting with new languages/technologies.

And last but not least, it is not going to directly send us programmers to unemployment. At least not in the coming months…

🥹

For example, if we need two types of pages on a site: one with a single column and another with two columns (main content and sidebar), a good option is to use the default page template, page.php, for the first one, and create a template, sidebar-page.php, for the second one. This way, for each new page, we can choose either design from the editor.

But what about Frontity, where the front-end is not generated from the PHP templates of the WordPress theme but from a React app? Well, Custom Page Templates are still the best option to work with multiple page layouts because they allow us to:

• Select the desired layout from the page editor.
• Assign them groups of ACF fields, extending the editing possibilities.
• Display the assigned template file name in the REST API (and in the Frontity state), making it easier for Frontity to serve the correct layout in each case.

Now let's go through the complete process with a simple example.

Wordpress

We create a PHP file, for example, custom-page-template.php, with a comment at the beginning like the following:

Where "Template name:" is the tag that indicates to WordPress that this file is a page template, and "My Custom Page Template Name" is the name of our new template, which will appear in the template selector in the editor of each page.

Anything else to do? No, that's all on the WordPress side. 😎

However, to avoid errors (and some headaches), we must keep in mind that:

• Custom templates only work if we have an index.php (it can be empty) in the root of our WordPress theme.
• We should never use page- as a prefix in the file name because WordPress will interpret it as a specialized template intended to be applied only to a specific page of the site.

Frontity

We create three components:

1. Page
2. PageDefault
3. PageTemplate

In the first one, we include a Switch that serves the second component, PageDefault, or the third one, PageTemplate, depending on the value of the template property in the page data from the Frontity state. If the published page in WordPress uses the default page template, this value will be empty, and if it uses a custom template, it will come with the name of the template file, custom-page-template.php in our case.

And finally, in the second and third components, we include the actual layouts for both types of pages.

Simple, isn't it?

If you have any questions, think something can be improved, or just want to say hello, you can reach me at hi@xulioze.com 😋