DEV Community: Cristian Bonomo

Building a Harness From Zero

Cristian Bonomo — Mon, 14 Sep 2026 13:08:21 +0000

We're going to build a harness from zero, explaining step by step how to do it and why.

What Is a Harness

A harness is the set of files, conventions, and rules that give an AI agent everything it needs to operate in a repository without depending on someone feeding it context in a chat. It defines how the agent starts, what it can and can't do, how it knows a task is done, and how it leaves a record of what it did so the next session (another agent, or you) can continue without rebuilding everything from scratch.

The underlying idea is simple: if the criterion for "done" only lives in your head, or in a chat message that's going to disappear, any agent (or any person) who continues the work is going to make different decisions than you would. A harness takes those decisions out of the chat and puts them in the repository, as the single source of truth.

Building the Sandbox App

We're going to build a minimal sandbox project, since it's not the important part here — what matters is what we build around it.

https://github.com/crisbonomodev/ledger-cli

The project is a simple ledger that lets you record credit and debit operations, search by date, and get an account's balance, built on top of a LinkedList and a Map.

We'll also need a verification mechanism: check and test scripts the harness can run to validate its own changes.

Once we have the base of our ledger, let's set up the initial structure of our harness.

Initial Structure

We need an entry point for our harness — an AGENTS.md file (or CLAUDE.md, in Claude Code's case). We'll use /init in Claude to generate an initial CLAUDE.md, and then modify it.

Reference commit with the generated base file: https://github.com/crisbonomodev/ledger-cli/commit/e0cb08c81b1d92d3c7fc831bdc05f931b683908f#diff-6ebdb617a8104a7756d0cf36578ab01103dc9f07e4dc6feb751296b9c402faf7

Editing CLAUDE.md

CLAUDE.md should contain only the instructions the harness needs to operate, plus references to other files the agent can reach if it needs them. It shouldn't go over 100 lines.

Sections

Initial description: briefly tells the agent the purpose of the file.
Operating Loop: the sequence of steps every agent must follow.
Rules: the set of constraints the agent must respect while working in this repository, following the operating loop.
Required files: files the harness needs to function.
Completion gate: the explicit rule by which the agent knows it has completed the task.
Before you stop: the final steps for handing off the task.

Our CLAUDE.md had architecture details in it — let's move those to a new ARCHITECTURE.md file.

You can see the state after that refactor in this commit:

https://github.com/crisbonomodev/ledger-cli/commit/7ef78c14c334748a29a7b22e1aaf67d77a993e54

The Startup Script

Now we need to add our startup script, which takes care of initializing everything related to the project: installing dependencies, running verification scripts, and the start command, all in a single step — so the Operating Loop has something real to run.

You can see it in this commit:

https://github.com/crisbonomodev/ledger-cli/commit/bed716002edb4678412f85a4544e17fbc912018e

Feature List

Once this script is validated, we can move on to structuring feature_list.json. But first, we need to define what our ledger-cli's features will be. For this example, they'll be:

history(account) — a chronological listing with a running balance per account.
Correction/reversal (void) — a past transaction is never deleted or edited; instead, an entry is added that reverses it.
Transfer between accounts — move money from one account to another as a single atomic operation (debit on the source + credit on the destination).

Now let's define the structure of our feature_list.json. Each feature needs:

id: unique identifier
priority: an integer — the lower it is, the higher the priority
area: which part of the app it touches
title: a short description of the task
user_visible_behavior: what the user should see once the feature is complete
status: the task's state, one of:
- not_started: not yet started
- in_progress: feature currently being worked on. Only one at a time
- blocked: feature blocked by a known issue or unmet precondition
- passing: verification has passed and evidence has been saved
verification: step-by-step instructions to confirm it works
evidence: proof that verification passed, filled in by the agent
notes: extra content

You can see the feature_list.json in this commit:

https://github.com/crisbonomodev/ledger-cli/commit/50fdc573689144e858cba83226cdeeca059d2f3b

Progress

Now we need a file where we can log every session and task we work through. For this, we use claude-progress.md (or just PROGRESS.md).

You can see it here: https://github.com/crisbonomodev/ledger-cli/commit/19cf16927c6fcfa83511010a61fc37945182021e

Running Our Harness for the First Time

With this, we now have the base of our harness. Let's run our first feature. The history feature needs to:

filter by a single account
sort that account's transactions by date
walk that sorted list accumulating the balance, storing the running balance at every step, not just at the end

For now, we'll just leave it the information it has in feature_list.json and see what it does. We open Claude in a terminal and give it the following prompt:

Follow the operating loop from CLAUDE.md and work on the top priority feature pending on @harness/feature_list.json

Commit with the result of that run:

https://github.com/crisbonomodev/ledger-cli/commit/9e7fbe53907d0a0227de1ec54084b01b2cbb6632

Looking at the result, we can see the harness completed the task, but took quite a few liberties with how the code was written. For example:

history(account: string): { transaction: Transaction, balance: number }[] {
    const transactions = this.load().toArray()
        .filter((tx) => tx.account === account)
        .sort((a, b) => a.date.localeCompare(b.date))

    let balance = 0
    return transactions.map((transaction) => {
        balance += transaction.type === TransactionType.CREDIT ? transaction.amount : -transaction.amount
        return { transaction, balance }
    })
}

Notice it used an anonymous type, when by convention it would've been better to declare a new AccountHistoryEntry { transaction: Transaction; runningBalance: number } interface in src/types.ts, following the convention we'd been building toward. But we never wrote that convention down anywhere, and since the repository is the single source of truth, it implemented it however it saw fit.

To improve this, we have a few options:

Separate the implementing agent from the evaluator: there's a documented bias (self-evaluation bias) where, when an agent is asked to evaluate its own work, it systematically gives more positive evaluations than an independent observer would. The fix is to use a separate agent to review the implementer's work, against a rubric that spells out exactly what conditions must be met before marking a task as passing.
Sprint contract: we need a contract defined before implementation that spells out what to change, what not to change, and the verification standards.
New conventions file: we'll add a new CONVENTIONS.md file listing the code conventions we want to respect and maintain. In this project it ended up with simple, concrete rules: complex return types belong in src/types/types.ts (not inline), a saved transaction is never mutated, every new Ledger method needs a happy-path test and an edge-case test, no CLI framework. Nothing exotic — but exactly the kind of thing an agent with no memory of the previous session has no way of guessing.

You can see the files in this commit: https://github.com/crisbonomodev/ledger-cli/commit/261dd0fb7a3c2dc596fcd06693770ef525d9173d

Now let's implement the next task and see the result.

Implementing the Second Task

Before dispatching the implementer, we wrote this task's sprint contract (void). What's interesting isn't just the Scope section, but the Exclusions one:

Exclusions (explicitly out of scope for this sprint)

Behavior when id does not exist — undefined, not required, not tested.

Preventing or detecting double-voiding the same transaction — undefined, not required, not tested.

Explicitly saying what not to solve is just as important as saying what to solve — without this, an agent might "improve" the task by adding error handling nobody asked for, or worse, leave it half-done.

Using our Claude terminal in the project, we run /clear and then:

use the implementer subagent for ledger-002

Commit with the implementation: https://github.com/crisbonomodev/ledger-cli/commit/d8d3d187a0f93a8944886ead3ae2802b0e37f04c

And then, to have it evaluated:

use the evaluator subagent for ledger-002

The evaluator doesn't give a free-form verdict — it fills out evaluator-rubric.md, which scores 6 dimensions from 0 to 2: correctness (does it do what feature_list.json asks for?), contract fidelity (did it respect the names and locations from the sprint contract, not just "does it work"?), verification (did it re-run the checks itself, or trust the implementer's notes?), scope discipline (did it stay within what the contract allowed?), reliability (does it survive a rm -rf dist && ./init.sh from clean?), and handoff readiness (was progress properly recorded?). Only if everything scores 2 (or there's a documented exception) is the verdict Accept.

Now we can see that different agents were used, conventions were respected, the sprint contract was implemented, and the rubric was completed. But the progress file didn't record the commits, and we still aren't really validating that the app stays in a consistent state and runs correctly, beyond the tests.

To fix that, we need to add a file listing the checks the evaluator agent has to run as part of the passing requirement.

Clean State Checklist

The underlying problem is that "tests pass" isn't the same as "the repository is left in a consistent state." An agent can leave the build broken, progress badly recorded, or stray work files behind, and the tests for that specific feature will still pass just fine. The clean state checklist is a short list of non-negotiable conditions (build compiles, tests pass, recorded progress matches what actually happened, no leftover temporary artifacts) that the evaluator has to confirm one by one before considering the session closed — it's not enough for just the feature at hand to work.

One detail worth calling out: the check that recorded progress is accurate has to happen after committing, not before — the commit hash depends on the entire tree, including the progress file itself, so you can't verify a reference that doesn't exist yet.

We implemented the clean-state-checklist.md file in the harness. And while we're at it, remember we'd blocked the evaluator agent from committing — that has to change, because if the evaluator is the one running the final checklist, it also has to be the one closing the session with the commit.

https://github.com/crisbonomodev/ledger-cli/commit/bdf3b8a1122dd843109dbd1db78b9e8db55348bf

Implementing the Third Task

With these changes in place, we can now implement the third task (ledger-003, transfers). Since we already wrote the sprint contract before dispatching it, the prompt is straightforward after a /clear:

implement the next task by priority

https://github.com/crisbonomodev/ledger-cli/commit/51fa2cbadc51773ec72d167d83fb58347b6a6d7b

This time the whole cycle (contract → implementer → evaluator → checklist) held up without any manual adjustment on my part. The difference from the first task isn't that the agent got better — it's that this time the design decisions were already in the repository before it started writing code, instead of living in my head.

Implementing the Handoff Between Agents

We now have our three features implemented, but our agents left loose fixes and validations scattered along the way. We're going to tackle error handling and validation across the flows. But to do that, we need to split the implementation into subtasks — and that's where we need a safe mechanism for agents to record what they did, so each agent can pick up exactly where the last one left off.

We add a new session-handoff file to handle this, update our CLAUDE.md and agent definitions, add the task to the feature list, and write our sprint contract.

https://github.com/crisbonomodev/ledger-cli/commit/555b93016eec16974985ee0d1b16cfdd6e9a8e0e

Now we can start implementing our task. Session A builds the shared mechanism (the error hierarchy) and proves it out on a single flow:

You are the implementer. Work on ledger-004 following harness/sprint-contracts/ledger-004-validation-errors.md —
but ONLY the "Session A" part of the Delivery Plan: create a complete src/errors.ts (the 4-exception hierarchy)
and implement/test only record()'s guard. Don't touch transfer() or void(). When you're done, write
harness/session-handoff.md instead of harness/claude-progress.md, and leave the feature in_progress.

https://github.com/crisbonomodev/ledger-cli/commit/e854260551a37c401e9121154bc89550c3211b40

Now we move on to Session B. This is the key point of the whole experiment: it starts with a /clear, with nothing from Session A's chat, and the only context it receives is session-handoff.md:

You are the implementer. Start by reading harness/session-handoff.md — don't assume anything else about what the
previous session did beyond what that file says. Follow the rest of CLAUDE.md's Operating Loop and finish
ledger-004 according to the "Session B" part of harness/sprint-contracts/ledger-004-validation-errors.md: transfer(),
void(), and the CLI's try/catch. Write harness/claude-progress.md as usual.

https://github.com/crisbonomodev/ledger-cli/commit/002dc66c80146165f5a20aafff97886789a7167f#diff-d5b7d5fb05719d146f8dc4f0106425539454fdfeea858de48916db3dc34f3142

(Note: between Session A, Session B, and the evaluator, the intermediate commits were made by me, by hand, in the terminal, orchestrating each dispatch. The implementer is explicitly forbidden from committing — so if you spot a commit "mid-task" anywhere, that's the human operating the harness, not the agent breaking its own rule.)

Finally, we run the evaluator, which is the one that actually closes out the task with a single commit:

You are the evaluator. Evaluate ledger-004 against harness/sprint-contracts/ledger-004-validation-errors.md and
harness/evaluator-rubric.md, reviewing both sessions' work together (A and B) — including whether Session B's code
is genuinely consistent with the classes Session A defined, without redefining them or drifting from them.

https://github.com/crisbonomodev/ledger-cli/commit/35ffd50101e43dc736be0bd7869e1436c0f9a6a3

What This Proved

What matters here isn't that Session B finished the work — it's that it did so without having seen a single line of the chat where Session A was designed. Everything it needed — which error classes already existed, where they lived, what they were called — was in session-handoff.md. And I'm not taking the evaluator's word for it: I checked the code myself afterward — zero redefinitions, zero naming drift. Session B used exactly the classes Session A left behind.

That's the point of the whole exercise: a harness isn't a tidy set of files, it's the answer to a concrete question — what does the next session need to know so it doesn't repeat or contradict what's already been decided? When that answer lives in the repo instead of in your memory or in a chat that's about to close, the work becomes pickable-up by anyone: another agent, another session of yours, or someone else on the team. And that habit of not trusting an agent's declared state without checking the evidence yourself is, to me, the one that holds up all the rest.

Seeing It Run

All this talk of contracts, roles, and checklists can sound abstract if you never see the result actually working. After building (npm run build), here's a real terminal session using the four features we built:

$ node dist/index.js record checking 1 500 "Paycheck"
$ node dist/index.js record checking debit 120 "Groceries"
$ node dist/index.js balance checking
balance of checking: 380

$ node dist/index.js history checking
2026-09-13 #1 1 500 - Paycheck | balance: 500
2026-09-13 #2 0 120 - Groceries | balance: 380

$ node dist/index.js void 2
#3 voids #2 - checking 1 120

$ node dist/index.js transfer checking savings 100
#4 checking -> #5 savings - 100 (transferId 4)

$ node dist/index.js balance checking
balance of checking: 400
$ node dist/index.js balance savings
balance of savings: 100

(Side note: 1 as the second argument to record means CREDIT — a known, never-fixed bug means comparing it against the string "credit" doesn't actually work; anything else falls back to DEBIT by default. It's exactly the kind of minor technical debt a sprint contract deliberately leaves out of scope, and that stays documented instead of quietly fixed by nobody's request.)

The numbers check out: 500 − 120 + 120 (reversed) − 100 (transferred) = 400 in checking, 100 in savings. That's the result of all four features, built across separate agent sessions, working together without friction.

ledger-cli is a toy project on purpose — the idea was to see the problem and the solution in a full cycle in a couple of hours, not to build something production-grade. Depending on the complexity of the project it's applied to, these files will need to be more or less detailed — and in fact, building and maintaining a harness turns out to be an iterative, ongoing process.

The full code — CLAUDE.md, sprint contracts, the implementer/evaluator split, all of it — is on GitHub: ledger-cli.

Curious how others handle this: when two agent sessions can't share chat context, what do you pin outside the conversation so the second one doesn't quietly redefine what the first one built?

No todo es console.log()

Cristian Bonomo — Fri, 24 Dec 2021 17:13:31 +0000

Cuando empezamos a programar en JavaScript, una de las primeras cosas que aprendemos a hacer es imprimir por consola.
Para esto, nos enseñan el console.log(), el cual nos permite mostrar el mensaje que queramos al ejecutar nuestro código, sea en el navegador o en la terminal que utilicemos.

Sin embargo, la clase console no está limitada a este único comando, ya que posee varias alternativas y funcionalidades que nos pueden resultar útiles a la hora de debuggear nuestra aplicación.

Este artículo pretende ser una pequeña guía sobre estos métodos, para tener a mano en caso de que necesitemos algo un poco mas específico que simplemente mostrar algo por pantalla.

Si tienen ganas de estudiar más a fondo la clase console, y que ocurre por detrás, pueden ver la Console API, la especificación sobre console a la cual los motores de JavaScript se han adaptado para proveer funcionalidades similares.

assert()

Con este método, especificaremos una condición, la cual en caso de ser falsa, mostrará un mensaje por consola.

let isActive = false;
let isActiveAgain = true;
console.assert(isActive,'Usuario deshabilitado');
console.assert(isActiveAgain,'Usuario deshabilitado!!!');

-----------------------------------------------------
cbonomo@usuario-ThinkPad-X1-Carbon-Gen-8:~/Javascript/01-fundamentos$ node console.js 
Assertion failed: Usuario deshabilitado

clear()

Este método simplemente limpíará la consola en caso de que podamos hacerlo, es otro de los comandos que aprendemos al comienzo.

count()

Este método logueará la cantidad de veces que realicemos una llamada a count(), util en caso de que necesitemos establecer un contador para evaluar cuantas veces utilizamos una función.

let user = "";

function saludar() {
    console.count(user);
    return "hola " + user;
}

user = "Cristian";
saludar();
user = "Sol";
saludar();
saludar();

------------------------------
cbonomo@usuario-ThinkPad-X1-Carbon-Gen-8:~/Javascript/01-fundamentos$ node console.js 
Cristian: 1
Sol: 1
Sol: 2

countReset()

con countReset() podemos resetear la cuenta de count()

let user = "";

function saludar() {
    console.count(user);
    return "hola " + user;
}

user = "Cristian";
saludar();
user = "Sol";
saludar();
saludar();
console.countReset(user); //resetea a 0 el indice Sol
saludar();

------------------------------------------------------
cbonomo@usuario-ThinkPad-X1-Carbon-Gen-8:~/Cursos/Javascript/01-fundamentos$ node console.js 
Cristian: 1
Sol: 1
Sol: 2
Sol: 1

debug()

imprime un mensaje en la consola a nivel de debug, el cual sera solo mostrado si la consola esta configurada para mostrar esta salida. En la consola de Google Chrome, por ejemplo, solo se vera si activamos la opcion Verbose en los Default Levels, en Node se muestra por defecto.

console.debug('Error printing data');

dir()

Mediante dir(), podemos mostrar una lista interactiva de métodos de un objeto JavaScript. Es un método bastante útil para poder ver los métodos de un objeto.

console.dir(console);

--------------------------
Object [console] {
  log: [Function: log],
  warn: [Function: warn],
  dir: [Function: dir],
  time: [Function: time],
  timeEnd: [Function: timeEnd],
  timeLog: [Function: timeLog],
  trace: [Function: trace],
  assert: [Function: assert],
  clear: [Function: clear],
  count: [Function: count],
  countReset: [Function: countReset],
  group: [Function: group],
  groupEnd: [Function: groupEnd],
  table: [Function: table],
  debug: [Function: debug],
  info: [Function: info],
  dirxml: [Function: dirxml],
  error: [Function: error],
  groupCollapsed: [Function: groupCollapsed],
  Console: [Function: Console],
  profile: [Function: profile],
  profileEnd: [Function: profileEnd],
  timeStamp: [Function: timeStamp],
  context: [Function: context]
}

dirxml()

Muestra la misma información que dir, pero en formato XML.

error()

Este método nos permite mostrar un mensaje de error en la consola. A simple vista, puede parecernos igual a console.log(), pero la diferencia es que mientras console.log() escribe mediante stdout, console.error() escribe a stderr, lo que nos permite utilizarlos de manera diferente. Les recomiendo correr este código en Node y en la consola de Chrome para ver la diferencia de manejo.

console.error('Error reading data');

group() y groupEnd()

este método nos permite crear indentaciones en nuestros logs, mediante agrupaciones. Utilizaremos group() para abrir un nivel y groupEnd() para cerrarlo.

console.log('Nivel base');
console.group();
console.log('Nivel 1');
console.group();
console.log('Nivel 2');
console.group();
console.log('Nivel 3');
console.groupEnd();
console.log('Nivel 2');
console.groupEnd();
console.log('Nivel 1');
console.groupEnd();

---------------------------
Nivel base
  Nivel 1
    Nivel 2
      Nivel 3
    Nivel 2
  Nivel 1

groupCollapsed()

Este método nos permite crear un grupo desplegable, el cual al imprimirse por consola nos permitirá abrirlo y cerrarlo. Recomiendo probar esta funcionalidad en la consola del navegador.

console.log('Nivel base');
console.groupCollapsed('Ver más');
console.log('Nivel 1');
console.group();
console.log('Nivel 2');
console.group();
console.log('Nivel 3');
console.groupEnd();
console.log('Nivel 2');
console.groupEnd();
console.log('Nivel 1');
console.groupEnd();

-----------------------------
Nivel base
VM64:2 Ver más
VM64:3 Nivel 1
VM64:4 console.group
VM64:5 Nivel 2
VM64:6 console.group
VM64:7 Nivel 3
VM64:9 Nivel 2
VM64:11 Nivel 1

info()

Este método muestra como salida un mensaje de información a la consola. Normalmente, aparece un icono con una 'i' para indicar esto.

console.info('Este es un mensaje informativo');
VM154:1 Este es un mensaje informativo

log()

Como hablamos al comienzo, uno de los primeros métodos que aprendemos. Veamos algunas funciones extra que tiene.

Podemos utilizar sustituciones dentro del string, para imprimir determinados tipos de valores.

let celular = {
    codArea: 54,
    prefijo: 11,
    numero: 12345687
};

let duracion = 5.6;

for (let i = 0; i < 5; i++) {

    console.log("Hola, %s, este es el mensaje número %d al teléfono %o, con una duración de %f segundos", "Cristian",i+1, celular, duracion);

}
--------------------------------------
Hola, Cristian, este es el mensaje número 1 al teléfono { codArea: 54, prefijo: 11, numero: 12345687 }, con una duración de 5.6 segundos
Hola, Cristian, este es el mensaje número 2 al teléfono { codArea: 54, prefijo: 11, numero: 12345687 }, con una duración de 5.6 segundos
Hola, Cristian, este es el mensaje número 3 al teléfono { codArea: 54, prefijo: 11, numero: 12345687 }, con una duración de 5.6 segundos
Hola, Cristian, este es el mensaje número 4 al teléfono { codArea: 54, prefijo: 11, numero: 12345687 }, con una duración de 5.6 segundos
Hola, Cristian, este es el mensaje número 5 al teléfono { codArea: 54, prefijo: 11, numero: 12345687 }, con una duración de 5.6 segundos

Otra funcionalidad interesante es dar estilos a nuestros mensajes. Podemos aplicar estilos a nuestra salida de consola para que sea mas atractiva, o según lo que deseemos resaltar.
Tenemos dos formas de realizar esto según donde mostraremos nuestro mensaje.

//navegador
console.log("%cError detectado","color: yellow; font-style: italic; background-color: black");

//node
console.log('\x1b[31m%s\x1b[0m', 'Error detectado');

Nota: en el caso de Node, existen paquetes como colors para simplificarnos la tarea.

table()

este método nos permite imprimir una tabla con valores por consola. Debemos pasarle por argumento un array o un objeto

const persona = {
    nombre: 'Cristian',
    apellido: 'Bonomo'
};

console.table(persona);

const lenguajes = ['Javascript','PHP','Java','Python'];

console.table(lenguajes);

----------------------------------
┌──────────┬────────────┐
│ (index)  │   Values   │
├──────────┼────────────┤
│  nombre  │ 'Cristian' │
│ apellido │  'Bonomo'  │
└──────────┴────────────┘
┌─────────┬──────────────┐
│ (index) │    Values    │
├─────────┼──────────────┤
│    0    │ 'Javascript' │
│    1    │    'PHP'     │
│    2    │    'Java'    │
│    3    │   'Python'   │
└─────────┴──────────────┘

time()

Este método nos permite registrar cuanto tiempo puede tomar una operación en específico. Vamos a utilizarlo en conjunto con timeLog(), el cual nos permite ver el valor actual de un timer previamente inicializado, y timeEnd(), el cual frena el timer.
Para este caso, voy a simular una función init(), que solo realizara un conteo, pero también podría ser una métrica de cuanto tiempo toma el sistema para inicializar, o responder a una petición.

function init() {
    let count = 0;
    for (let i = 0; i < 100; i++) {
        count++;
    }
}

console.time('init');
init();
console.timeLog('init');
init();
console.timeEnd('init');

--------------------------------------
init: 0.092ms
init: 0.276ms

trace()

Este método nos permite realizar un trace sobre las funciones llamadas hasta el punto en que llamamos a trace()

function funcionUno() {
    function funcionDos() {
        console.trace();
    }
    funcionDos();
}

funcionUno();

Trace
    at funcionDos (/home/cbonomo/Javascript/01-fundamentos/console.js:133:17)
    at funcionUno (/home/cbonomo/Javascript/01-fundamentos/console.js:135:5)
    at Object.<anonymous> (/home/cbonomo/Cursos/Javascript/01-fundamentos/console.js:138:1)
    at Module._compile (node:internal/modules/cjs/loader:1095:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1147:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47

warn()

Este método nos permite mostrar un mensaje de alerta en la consola web. En esta consola, nos mostrará el mensaje junto con el símbolo amarillo de warning.

console.warn('Este es un mensaje de alerta');

Así, llegamos al final de este repaso por los métodos que nos ofrece la clase console(), espero les sea de utilidad a la hora de programar, para mostrar mejores mensajes por consola y poder implementar mas fácilmente las soluciones que necesiten en su desarrollo.

Hasta la próxima!