DEV Community: Pablo Felipe

Context engineering is engineering work — not prompt-writing

Pablo Felipe — Thu, 25 Jun 2026 21:37:40 +0000

TL;DR — When the spec is good, implementation needs less model. I started using a top-tier model to write the spec and a cheaper, faster one to implement it — still using the strong model, just spending it on the spec instead of the implementation. The gain isn't some magic prompt phrasing; it's the context: explicit business rules, audited project constraints, a defined output contract. That's systems engineering — the discipline of anyone who's kept real software alive, whatever their stack.

Every backend dev knows the scene: the Swagger is out of date, the last hotfix shipped without a unit test, and the README.md documents a command nobody's used in six months. The code works. The docs lie. And the gap between the two is exactly where AI — and we — start to go wrong.

I've spent the last few months developing with AI for real inside production projects, not tutorial greenfield. My takeaway was less about which model to use and more about a shift that already has a name: the move from prompt engineering to context engineering.

The difference isn't semantic. Prompt engineering treats the problem as writing — finding the magic phrase. Context engineering treats it as what it always was: a systems engineering problem. And it's where my backend background applied most directly — though anyone who's kept a real system alive has the same instinct.

The experiment that convinced me

Let me start with the evidence, because that's what made me take this seriously.

My reflex, for a long time, was to reach for the strongest model for everything — more expensive, smarter, fewer errors. Makes sense on paper.

In practice, I saw something else. When the task's specification is well done — explicit business rules, audited project constraints, a defined output format — the model capability needed for implementation drops sharply. Enough to split the work by stage: I started using a top-tier model (currently Opus) to write the spec, and a cheaper, faster model (Sonnet) to implement from it. I didn't drop the strong model — I moved it: off the implementation, onto the spec.

The comparison that actually matters isn't cheap implementer vs. expensive implementer. It's strong model implementing with no structured spec vs. strong model writing the spec, cheaper model implementing from it — and the second is both cheaper and more accurate. The accuracy isn't coming from the cheap model — it's that the spec carries the precision. With unlimited budget you could run the strong model on both stages, and that's the ceiling; the useful finding is narrower: good context makes a cheaper implementer beat the strong model left to implement without it — while saving on the highest-volume stage.

Be precise about what that does and doesn't show, though. Sonnet isn't a weak model — it's a notch below Opus, not a tiny one. So this isn't evidence that some minimal model can implement anything; it's that a good spec lowers the capability ceiling a task demands, and in my case that ceiling dropped below top-tier. How far it drops depends on the task.

I want to be honest about the scope of this claim, because it easily turns into misleading clickbait. It's not a universal recipe. The exact split depends on task complexity, codebase maturity, and how good your patterns already are. Apply this to a messy project with no specs and the cheap model will hallucinate, and you'll conclude I was wrong — when what was missing is exactly the half that makes the claim true.

What is generalizable is the principle behind it:

Context quality lowers the model capability a task requires.

The Opus→Sonnet split is just concrete evidence that the principle works. And it explains, as a bonus, why the hype migrated so fast from "prompt engineering" to "context engineering": the marginal gain from investing in context is bigger than from investing in the phrasing.

What counts as "good context"

Here's a trap I also fell into: thinking more context is better context. It isn't. Dumping the whole repo into the window doesn't help the model infer better — it just inflates cost and dilutes signal. Good context isn't volume, it's precision. In practice, what moves the needle:

What the project does — one sentence. Sounds obvious; it's almost never written down.
The stack, the architecture, and the patterns — because LLMs are excellent at replicating. That's their core strength. A project with consistent, documented patterns gives the model a mold to copy, and that's where hallucination drops.
Clear commands in the README.md — silly but real example: I had a test breaking, asked the agent to fix it, and it ran the test command itself to see the error before touching anything. It only managed that because the command was documented.
The output contract — defining the input and output format of functions and methods up front gives the model a target instead of a guess. One caution before calling this "TDD as executable spec," though: in my flow the same model writes both the test and the implementation, so the test isn't an independent oracle — it's the model checking its own reading of the task against itself. What actually anchors things is the contract in the spec I review by hand; the test only operationalizes it, and its assertions still have to survive Check 2 of the verifier below.

Notice none of this is "prompt technique." It's engineering hygiene. AI just made the cost of skipping that hygiene visible and immediate.

The system: a pipeline of skills

A thesis without a method is a motivational talk. So here's the how.

I treat every repeatable step of my flow as a skill: a structured prompt with three fixed parts — Instructions, Constraints, and Output Format. They live versioned in .md files, reachable from both the editor and the agent. When I catch myself asking the model for the same thing a third time across different projects, I formalize it into a skill.

The flow of a task in an existing project looks like this:

extract task description
   → spec-writer        (generates the spec from the informal ticket)
   → [review the spec]  (human in the loop — the step I don't delegate)
   → implement
   → ai-output-verifier (red-team what the AI generated)
   → code-reviewer      (senior-level critical review)
   → commit-message     (Conventional Commits from the diff)
   → pr-description     (description in the team's format)
   → push
   → review by another model on the PR

Three of these skills do the heavy lifting. Let me open all three.

1. The one that generates context: `spec-writer`

The heart of the pipeline. It turns an informal ticket (natural language, bullets, a Slack thread) into an implementation-ready spec. The detail that makes the difference isn't the template — it's the Constraints Audit: before describing what the code should do, the skill forces an inspection of what the project already has configured that could invalidate the model's output.

# Skill: Spec Writer

Turns an informal ticket description into an implementation-ready SDD spec.

## Instructions
1. Read the provided description.
2. Identify ambiguities BEFORE writing the spec. If there's at least 1
   critical doubt, STOP and ask.
3. Project Constraints Audit (mandatory). Before describing what the code
   should do, audit what the project ALREADY HAS configured that could
   invalidate the output. Run concrete inspection — don't assume:
   - Schema (DB writes): inspect the table. NOT NULL, defaults,
     UNIQUE/FK, encoding. Sample existing data to see the expected
     format of special fields.
   - Transpile/syntax (JS/TS): Babel rules may differ across
     .js, .jsx, .ts, .tsx. Confirm modern syntax (?., ??) IN THE SAME
     file type that will be modified.
   - TypeScript config: target, strict, noImplicitAny.
   - Lint config: rules that could reject the output.
   - Dependencies in use: suggest libs ALREADY present, don't add
     new ones without justification.
   - Existing patterns: grep for a similar implementation and follow the style.
4. Suggest at least 3 non-obvious edge cases from the original ticket.

## Constraints
- DON'T invent business rules. If info is missing, mark it as TODO.
- DON'T assume default stack/config. Use what the Constraints Audit
  found. If transpile doesn't support ?. in .jsx, the spec says
  "use traditional conditionals in .jsx".
- Keep the spec short: one screen max.

Why this matters: most of the hallucinations I've seen weren't the model "inventing" from nothing. They were the model assuming a reasonable default that the specific project didn't follow — ?. in a file that project's Babel doesn't transpile, an insert that violates a NOT NULL nobody mentioned. The Constraints Audit kills that entire class of error before the first line of code.

2. The one that fights sycophancy: `ai-output-verifier`

Sycophancy is the tendency of LLMs to agree with, flatter, and validate the user at the expense of accuracy — the model tells you what you want to hear instead of acting as a neutral truth-seeker. In a flow where AI generates a lot of code, this is the hidden tax: the code looks right, passed the tests (which the same AI wrote), and nobody checked whether the tests test anything.

This skill formalizes distrust into a checklist. I run the checks in order and stop at the first red flag:

# Skill: AI Output Verifier

Red-team of AI-generated output. Fights sycophancy, fabrication, and the
"code that looks right but isn't" pattern.

### Check 1: Fabricated references
Did the AI cite file:line, a function, or an API? Open each one and confirm
it exists AND does what it claimed. Red flag: a plausibly-named but
nonexistent function, a lib version different from the installed one.

### Check 2: Tests that don't test
Does each expect validate BEHAVIOR, or just that it "ran without throwing"?
Would the test fail if you commented out the implementation? Red flag:
expect(result).toBeDefined(), mocks that return the expected result
instead of simulating real behavior.

### Check 3: Happy path syndrome
Does it work with empty input (null, undefined, "")? Under concurrency?
With the external integration down? Red flag: no try/catch on I/O, no
input validation.

### Check 4: Adjectives without evidence
Did the AI use "robust", "performant", "secure", "production-ready"? Is
there a benchmark or technical argument to back it? Red flag: "more
performant" with no comparison.

### Check 5: Sycophancy detection
Did you push the AI in a direction and it changed its mind too fast,
without a new technical argument? If so, ask explicitly: "what's the
evidence for this new position?"

### Check 6: Plan vs delivery
Did the AI reference files/specs/paths as if they exist — in summaries,
conclusions, or next steps? For each path, run `ls` or open the file: does
it exist? Watch verb tense — "X becomes the destination in Y/Z/" is a plan
dressed as delivery. In the final summary, separate "I created" (verified
by `ls`) from "I suggest creating" (just a plan).

### Check 7: Confidence on inferences
Did the AI make claims it couldn't have verified directly? It must not give
the same affirmative authority to what it SAW in the code and what it
INFERRED from folder structure. Demand a level: High (directly observed) /
Medium (inferred from structure) / Low (speculative).

## Constraints
- DON'T mark "verified" if any check landed on "maybe". Go back to the code.
- DON'T rely on the AI's tests alone. They came from the same source that
  might have the bug.
- DON'T skip a check because "it's a small change". Sycophancy scales —
  small changes are where AI cheats most.

The metric that started to matter to me isn't "how much code per day." It's how much bad code I kept from reaching production. This skill is the instrument for that.

3. The one that gives the verdict: `code-reviewer`

Short and direct. Critical review at a senior backend Node/TS level, focused on correctness and security — not style, which Prettier handles.

# Skill: Code Reviewer

Critical code review at a senior backend Node/TS level. Focus on
correctness, security, maintainability — not style.

## Instructions
1. Read the provided diff.
2. Classify each issue as Blocker, Major, or Minor.
3. For each Blocker/Major, give a concrete example of the bug (input that
   breaks it, race condition scenario).
4. Suggest a refactor ONLY when it reduces real complexity. Not for aesthetics.
5. End with a Verdict: Ship / Fix and ship / Block.

## Constraints
- Assume Node 20+, TypeScript strict, ESLint configured.
- Don't comment on formatting.
- Consider concurrency, DB transactions, idempotency, promise leaks,
  silent error handling.
- If it's an HTTP endpoint: input validation, authz, rate limit, PII logging.

Notice the pattern across all three: Instructions + Constraints + Output Format, always. The Constraints are the part that matters most, because that's where you encode the "do NOT" — and the "do NOT" is what keeps the AI on the rails.

Where this points

The Achilles' heel of all this is documentation aging. A spec is a snapshot of the past; the code keeps changing. The direction that feels right to me is living documentation — generated and maintained on every change, not in a heroic quarterly effort. Tools are already aiming exactly at this, and while they mature, you can approximate it: take a snapshot of the project and ask the model to generate a context file from the code + README.md.

How I see this evolving inside a repo: alongside the README.md, a _Skills/ folder with the team's structured prompts and anchor files (CLAUDE.md, CODEX.md) that list the available skills and point to the project's CONTEXT.md. The model enters the repo and already knows what to read, in what order.

And there's a layer beyond this one. Context engineering is about what you put into a model call; the moment you wrap those calls in a system — quality gates, retries, an independent reviewer, persistent memory — you've crossed into what the field now calls harness engineering: the discipline of everything that isn't the model. The skill pipeline above is already a harness in miniature. That's where I go next.

None of this is exotic. It's the old engineering discipline — document decisions, keep patterns, write tests that test — with a new, impossible-to-ignore incentive: now the cost of skipping those steps shows up immediately, in the form of an agent that hallucinates. AI didn't change what good development is. It just stopped letting us pretend that shortcuts are free.

This is the flow I run today. The skills evolve every week as I catch the AI failing in new ways — if you run something similar and hit different walls, I'd want to know which.

Difference Between Two Arrays in JavaScript

Pablo Felipe — Thu, 17 Mar 2022 07:54:07 +0000

Introducing the .includes Array entity method that is used to determine if an element belongs to an array, we will make use of it to determine which elements of the first array, is included too in the second array.

With this, we will use it inside the condition() function within the .filter method. This callback function can be either an arrow function or a common function as a callback function. The .filter can be used literally to filter array elements based on a condition, and the callback function will dictate what elements the .filter will add or not to the returned array.

Difference Between Two Arrays in JavaScript

The .include is a method of the Array entity. It returns true if the element passed as parameter is included in the array that the method is called, or false if the element is not included. As a simple example:

// Input
let array = ['a', 'b', 'c', 'd'];
console.log(array.includes('a'))

Output:

// Output
true

And if the element doesn't belongs to the array, we have:

// Input
let array = ['a', 'b', 'c', 'd'];
console.log(array.includes('z'))

Output:

// Output
false

This method can only receive two parameters. If you pass more than one, it can return a wrong value to the set of elements that was passed as parameter. The first parameter is the element, as seen above; the second is the index or the fromIndex, that is optional.

The fromIndex is the index that the .includes will start "searching" for the element. Let's see the example below:

// Input
let array = [1, 2, 3, 4, 5];
console.log(array.includes(3, 3))

As the 3 value is on the index array[2], it is false that the array have an element equals to 3 starting from the index array[3] to the end:

// Output
false

Now for the .filter method, it is also a method of the Array entity and this method returns a new array filtered by a condition, that is provided by the condition() function within it. Returning a new array, means that the original array which the method is called will stand immutable.

Also, this condition() function is a callback function. A callback function is a function passed as parameter to another function or method which is called "outer function". The callback function will be called by the outer function to do something; in the case of the .filter method, it will call the condition callback function to filter the array based on this condition.

The .filter method will call the callback function for each element in the array. So the .filter will have array.length iterations and will finally return a new array with a number of elements equal to the number of iterations that the callback function return a value equivalent to true.

For example, if we want all elements that have their size equal to 3, we can use the .filter as below:

// Input
let array = ['one', 'two', 'three', 'four', 'five']
array = array.filter(element => element.length == 3)
console.log(array)

In this case, it receives an element as parameter, and if this element have its size equal to 3, it returns true and if not, returns false. So, the .filter method add any of the element that the condition results in true.

// Output
[ 'one', 'two' ]

As expected, the .filter method returned an array based on the element.length == 3 condition. Each value of the array that have its size equals to 3, was added to the returned array.

But we want to get the difference between two arrays, and this will be possible putting all together.

Will use the .filter method on the array that we want to get the difference, and inside it, we will use the .include as the condition, verifying if the element on the array that the .filter is called is included in the second element. Let's see this example:

// Input
let array1 = ['a', 'b', 'c', 'd', 'e'];
let array2 = ['a', 'b', 'c'];
console.log(array1.filter(element => array2.includes(element)))

Output:

// Output
[ 'a', 'b', 'c' ]

Well, see that the output is not the difference between the two array, but their intersection. Not that the condition array2.includes(element) is comparing if the element is included in the second array, and if it is true, the .filter will add this element to the resultant array.

But if we put a logical "not" or ! in the condition? This way, the .filter will add only elements that are not included in the second array. Check the example:

// Input
let array1 = ['a', 'b', 'c', 'd', 'e'];
let array2 = ['a', 'b', 'c'];
console.log(array1.filter(element => !array2.includes(element)))

Output:

// Output
[ 'd', 'e' ]

Finally, we have the difference between the two arrays.

As a plus, if we want to get all elements that are not in the intersection, we can just do the following:

// Input
let array1 = ['a', 'b', 'c', 'd', 'e', 'f'];
let array2 = ['a', 'b', 'c', 'x', 'y', 'z'];
let array3 = array1.filter(element => !array2.includes(element)).
    concat(array2.filter(element => !array1.includes(element)))
console.log(array3)

In this example, we want all elements that are not 'a', 'b' or 'c', so the output is:

// Output
[ 'd', 'e', 'f', 'x', 'y', 'z' ]

And finally, as the last thing we can add our solution to the difference between two arrays in a prototype method of the Array entity. The .prototype is a property of the Array entity that allow us to add custom properties and methods to an entity.

To make a .difference method to the Array entity, we can use the following structure:

// Input
// Declaring the prototype .difference method
Array.prototype.difference = function(array2){
    return this.filter(element => !array2.includes(element))
}
let array1 = ['a', 'b', 'c', 'd', 'e'];
console.log(array1.difference(['a', 'b', 'c']))

Output:

// Output
[ 'd', 'e' ]

This way, we can use .difference each time that is necessary to, instead to rewriting the logic every time.

Sort an Array of Integers in JavaScript

Pablo Felipe — Thu, 17 Mar 2022 07:50:44 +0000

Introducing the .sort method that can be used to sort an array by a specific order, this tutorial has the purpose of explaining why this method needs a comparison function if you want to sort an array of integer numbers correctly.

This comparison function will dictate the sorting order. Also, we will explain how to use it to make a descending order sorting, plus a shorter way to use it all together, by utilizing the comparison function as an Arrow Function within the .sort method.

Sort an Array of Integers in JavaScript using the `.sort` Method

The .sort method is a method of the Array entity that returns an ordered array from the array that this method was originally called. For example:

// Input
let array = [10, 10000, 1000, 100, 1]
console.log(array.sort())

Output:

// Output
[ 1, 10, 100, 1000, 10000 ]

Sure, this is expected as the .sort method orders the array. But, if we have the below input:

// Input
let array = [12900, 877, 12, 992, 10000]
console.log(array.sort())

We have a wrong ordering like this:

// Output
[ 10000, 12, 12900, 877, 992 ]

It happens because .sort default ordering is based on the UTF-16 or 16-bit Unit Transformation Format, which is an encoding of the Unicode pattern. The method converts the array values into the string type and then orders their Unicode values.

With this explained, the .sort method can also be used to order other data types, not only numbers.

But how can the .sort method be used to order an array correctly? It is simple: by using a Compare Function.

Passing a Compare Function as Parameter

As the .sort method can be used without any parameter, a Compare Function is optional. Basically, this function defines the .sort method ordering, and this function receives two parameters: the first element to be compared and the second element to be compared.

The .sort method will:

Put first after second if the compareFunction return a value greater than 0;
Put first before second if the compareFunction return a value less than 0;
Do nothing if the compareFunction return a value equals to 0.

So, with the compareFunction(first, second), we can dictate the order of the sort by passing an operation among the first and second parameters. To ascending ordering,

// Ascending ordering
function compareFunction(first, second){
    if(first > second) return 1 // 1 is greater than 0, so .sort will put first after second.
    if(first < second) return -1 // -1 is less than 0, so .sort will put first before second.
    return 0
}

And for descending order, we can invert the operators.

// Descending ordering
function compareFunction(first, second){
    if(first < second) return 1 // 1 is greater than 0, so .sort will put first after second.
    if(first > second) return -1 // -1 is less than 0, so .sort will put first before second.
    return 0
}

Now, putting compareFunction for ascending ordering together with the .sort method, finally, we have:

// Input:
let array = [12900, 877, 12, 992, 10000]
// Ascending
array.sort(function compareFunction(first, second){
    if(first > second) return 1 // 1 is greater than 0, so .sort will put first before second.
    if(first < second) return -1 // -1 is less than 0, so .sort will put first after second.
    return 0
})
console.log(array)

Output:

// Output:
[ 12, 877, 992, 10000, 12900 ]

Sort an Array of Integers in JavaScript using with the Arrow Function

We can also reduce all the code block to a minimum syntax, utilizing Arrow functions.

An Arrow function is another way to use a function with shorter syntax. Arrow Functions are anonymous functions, and this means that they are not named (are stored in variables or passed as function parameters) and can't be used in all situations.

With the structure of an Arrow Function, the traditional functions can be transformed into a shorter block, as the example:

// Common anonymous function
function (x){
    return x + 1;
}

// Arrow function
(x) => x + 1

Besides that, the structure of an Arrow Function can return automatically the expression value without the reserved word return:

// Arrow function
let arrowFunction = (x) => x + 1
console.log(arrowFunction(1))

Output:

//Output
2

The console.log() prints the value of 1 + 1, that is 2 even though the arrowFunction does not utilize the return statement. This will help us in the next step.

As said, the .sort method can have a Compare Function within it, and this function can be an Arrow Function. Converting the previously Compare Function structure, we can transform all that block of code to a shorter block as below:

// Input:
let array = [10000, 10, 100, 1000, 1]
array.sort((first, second) => {
    if(first > second) return 1
    return -1
})
// Ascending: If first > second == true, then change one by the other.
console.log(array)

We can drop the condition to first < second and instead, return a -1 value as default, if the primary condition is not the case; given that the 0 value to the .sort method is to equal values and this way, they can have their positions changed without interfering in the final result. This way, we can reduce even more, as the example below:

// Input:
let array = [10000, 10, 100, 1000, 1]
array.sort((first, second) => first > second ? 1 : -1)
// Ascending: If first > second == true, then change one by the other.
console.log(array)

Look that the previous > comparison and default return was changed to only one comparison: first > second ? 1 : -1. This means that, if the comparison is true, then returns 1, if not, then returns -1.

We need the ? ternary operator because the first > second comparison, result in only in true or false. But as said, the .sort method expects 1, -1 or 0.

Output:

// Output:
[ 1, 10, 100, 1000, 10000 ]

And for descending ordering:

// Input:
let array = [10000, 10, 100, 1000, 1]
array.sort((first, second) => first < second ? 1 : -1)
// Descending: If first < second == true, then change one by the other.
console.log(array)

Output:

// Output:
[ 10000, 1000, 100, 10, 1 ]

Another way to do the same is using the - ternary operator for subtraction. When we use array.sort((first, second) => first > second ? 1 : -1), if first - second result in a value greater than 0, then will be an index changing among each other. If first - second result in a value less than 0, nothing will happen and for equal values, the comparison will return 0.

Example:

// Input:
let array = [10000, 10, 100, 1000, 1]
console.log(array.sort((first, second) => first - second))

Output:

// Output:
[ 1, 10, 100, 1000, 10000 ]

What can we do in descending order? No, it is not changing the - ternary operator to + because each positive number plus another positive number result in a value greater than 0. But we have a simple solution to this: invert the first - second to second - first.

This way, if second - first results in a value greater than 0, then the .sort method will change their positions with each other.

Example:

// Input:
let array = [10000, 10, 100, 1000, 1]
console.log(array.sort((first, second) => second - first))

Output:

// Output:
[ 10000, 1000, 100, 10, 1 ]

Count Certain Elements of an Array in JavaScript

Pablo Felipe — Thu, 17 Mar 2022 07:45:29 +0000

Introducing the .filter method that can be used literally to filter array elements based on a condition, we can use it in addition to the .length property to count certain elements of an array. The condition of the .filter method is provided by a function, passed as parameter. Also, we will introduce the .reduce method that executes a function for each element in the array and return a single value.

The function passed as parameter can be either an arrow function or a common function as a callback function, and it will dictate what elements the .filter will add or not to the returned array or what exactly the .reduce method will do for each elements in the array.

Count Certain Elements of an Array in JavaScript using the `.filter` Method

The .filter is a method of the Array entity that returns a new array filtered by the provided condition. Returning a new array, means that the original array which the method is called will stand immutable. For example, if we want all elements that is equal to the value 'one' in an array, we can use the .filter as below:

// Input
let array = ['one', 'two', 'three', 'four', 'five']
array = array.filter(element => element == 'one')
console.log(array)

Output:

// Output
[ 'one' ]

As expected, the .filter method returned an array based on the element == 'one' condition. So if the actual element of the array is equal to 'one', then the filter will add this element to the returned array.

But what is happening inside the .filter method? We can see better by using a common function structure to the condition() function:

// Input
let array = ['one', 'two', 'three', 'four', 'five']
array = array.filter(function condition(element) {
    if (element == 'one') return true
    return false
})
console.log(array)

With this, we have the same first example output:

// Output
[ 'one' ]

The condition() function receives an element as parameter, and if this element is equals to a certain value, in this case 'one', it returns true and if not, returns false. So, the .filter method add any of the element that the condition results in true; as the original array has only the first element as one, the .filter return only one element.

Note that the condition() function is declared inside the .filter method. If you declare it outside and call it inside the .filter, it will not work, because the element is part of the callback scope.

Basically, a callback function is a function passed as parameter to another function which is called "outer function". The callback function will be called by the outer function to do something; in the case of the .filter method, it will call the condition() callback function to filter the array based on its condition.

Back to our objective, the .filter will finally return a new array that have array.length elements, which each one is an element that the callback function returned a value equivalent to true. As we want to count these filtered elements, we can easily do this with the .length property.

The .length is as property of the Array entity that returns the number of elements in an array. This number is always greater than the highest index in that array, because the first element is always on the index equals to 0.

// Input
let array = [1, 2, 3, 4, 5]
console.log(array.length)

Output:

// Output
5

The number of elements in the array is 5. 5 is a number greater than the index of the value 5, that is 4.

Putting all together, as an example we can use the following: How to get the number of all test notes of an school, that are greater than seven? The array of the test notes is in the example.

// Input
let notes = [7.0, 6.7, 7.3, 9.8, 5.6, 7.1, 7.8, 6.2, 8.0, 9.0, 4.5, 6.9, 7.5, 8.5, 6.4]
greaterThanSeven = notes.filter(value => value > 7)
console.log(greaterThanSeven.length)

Output:

// Output (The array returned by the .filter is: [7.3, 9.8, 7.1, 7.8, 8, 9, 7.5, 8.5])
8

So, 8 is the number of notes that are greater than 7 of all 15 notes in the original notes array.

Now, as another option we can use the .reduce Array entity method. This method is used to execute a callback function (as well as the .filter) on each element of the array, but it will finally return a single value.

A simple example to the .reduce working, is the sum of all element in an array:

// Input
let array = [1, 2, 3, 4, 5].reduce((previous, current) => previous + current)
console.log(array)

Output:

// Output
15

But this method can be used in other way, that is by passing the initial value. In the previous example, we can see that the previous begin with the first index element in the array, being the callback function, this way:

/*
previous + current = result
1 + 2 = 3
3 + 3 = 6
6 + 4 = 10
10 + 5 = 15 -> final result
*/

This sum is working correctly because if we don't pass a second parameter (as the callback function is the first parameter) to the .reduce method, it will consider previous as the first element of the array in the first iteration.

But if we want to count certain elements in the array? We cannot use the first element as the previous, because it could result in a wrong value. The example below is about counting how many 2 numbers are in the array:

// Input
let array = [1, 2, 3, 4, 5].reduce((sum, value) => (value == 2 ? sum + 1 : sum))
console.log(array)

Output:

// Output
2

As we can see, the result is 2, but the correct answer is 1. This happened because the sum is being initialized with the first element 1, as we don't passed any other parameter beyond the callback function. To do the correction, we can just pass a 0 as the second .reduce parameter:

// Input
let array = [1, 2, 3, 4, 5].reduce((sum, value) => (value == 2 ? sum + 1 : sum), 0)
console.log(array)

Output:

// Output
1

This way, the .reduce is making sum + 1 every time that the current element is equal to 2, with the sum being initialized with 0.

Extra

As a plus, instead of using all theses logics every time that we need to count certain elements in an array, we can use the .prototype Array entity property to write custom methods or properties to this entity.

To make a .countCertainElements method to the Array entity, we can use the following structure:

// Input
// Declaring the prototype .countCertainElements method
Array.prototype.countCertainElements = function(value){
    return this.filter(arrayElement => arrayElement == value).length
}
let array1 = [1, 2, 2, 2, 3, 4, 5]
console.log(array1.countCertainElements(2))

Output:

// Output
3

And the same can be done for the .reduce:

// Input
// Declaring the prototype .countCertainElements method
Array.prototype.countCertainElements = function(value){
    return this.reduce((sum, element) => (element == value ? sum + 1 : sum), 0)
}
let array1 = [1, 2, 2, 2, 3, 4, 5]
console.log(array1.countCertainElements(2))

Output:

// Output
3

DEV Community: Pablo Felipe

Context engineering is engineering work — not prompt-writing

The experiment that convinced me

What counts as "good context"

The system: a pipeline of skills

1. The one that generates context: spec-writer

2. The one that fights sycophancy: ai-output-verifier

3. The one that gives the verdict: code-reviewer

Where this points

Difference Between Two Arrays in JavaScript

Difference Between Two Arrays in JavaScript

Sort an Array of Integers in JavaScript

Sort an Array of Integers in JavaScript using the .sort Method

Passing a Compare Function as Parameter

Sort an Array of Integers in JavaScript using with the Arrow Function

Count Certain Elements of an Array in JavaScript

Count Certain Elements of an Array in JavaScript using the .filter Method

Extra

1. The one that generates context: `spec-writer`

2. The one that fights sycophancy: `ai-output-verifier`

3. The one that gives the verdict: `code-reviewer`

Sort an Array of Integers in JavaScript using the `.sort` Method

Count Certain Elements of an Array in JavaScript using the `.filter` Method