Reshare — content by Jérémy Surget
I spent the weekend reading the best blogs on Harness Engineering. The practices that come up most often:
We now know that the harness today matters as much as the model behind it
Here are the techniques that stand out the most:
1. Memory lives outside the context
the repo, the filesystem and git serve as memory. Each session picks up where the previous one left off, and the context is never the source of truth
2. Treat the context limit with care
An overly full context leads to hallucinations and lower performance. To limit this, you need to load tools and skills on demand and offload large outputs to a file on disk. Not to mention keeping a stable prompt prefix for the cache
3. Rules are enforced by code
Not by prompts. Linters, tests, hooks and sandboxes make constraints verifiable. The agent must be able to self-verify (tests, logs, screenshots) before saying a task is done
4. Durability and observability
Checkpoint each step, make actions idempotent and make everything traceable. Agents will fail, sessions will sometimes be disconnected or stop. You need to be able to ensure that everything can be resumed exactly where it stopped
5. The harness must remain malleable
With production feedback, your harness will have to change to adapt. Keeping it minimal and malleable will let you adapt quickly
LinkedIn Sources
- Profile: Pierre Jean Duvivier dit Sage (LinkedIn)
- Shared author: Jérémy Surget (LinkedIn)
The post I spent the weekend reading the best blogs on Harness Engineering. The practices that come up most often: appeared first on les plumes qui mordent.
Frequently Asked Questions
FAQs Harness Engineering
Beginner Questions
What is Harness Engineering
Its the practice of designing systems so that the harness the tooling pipelines guardrails and feedback loops around your code makes good engineering the easy path and bad engineering hard
Why does it matter
Because most quality problems come from friction not carelessness A good harness catches mistakes early automates the boring stuff and lets teams ship faster with fewer surprises
What are the core parts of a harness
Typically CICD pipelines automated tests static analysis and linters precommit hooks observability and clear deployment guardrails
Do I need a big team to start
No Start with the basics a CI pipeline automated tests and a linter You can grow the harness as the codebase and team grow
Whats the difference between a harness and regular DevOps tooling
DevOps tooling is the infrastructure harness engineering is the deliberate design of how that tooling guides and constrains engineers day to day Its about the developer experience not just the tools
Intermediate Questions
What benefits show up most often in practice
Faster feedback loops fewer production incidents more consistent code quality easier onboarding and less time spent on manual checks and firefighting
What are the most common problems teams hit
Slow pipelines flaky tests too much noise from linters and alerts and guardrails so strict they block legitimate work The usual fix is tuning for speed and signal not adding more checks
How do I deal with flaky tests
Treat flakes as bugs Quarantine them fix or delete them quickly and track flake rates over time A flaky test in the harness trains people to ignore the harness
Whats a good first improvement to make
Speed up feedback Get CI under ten minutes and add precommit hooks for formatting and linting Fast feedback changes behavior more than any policy document
How do I get buyin from the team
Show the time saved and the incidents avoided Engineers adopt harness improvements when the harness makes their day easier not when it adds steps
Advanced Questions
How do I design guardrails that dont slow people down
Make the safe path the default and the fast path
