# Engineering and DevOps

Published articles for Engineering and DevOps.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## From AI Code to Trusted Software: Harness Engineering in Practice

DevFeed: [From AI Code to Trusted Software: Harness Engineering in Practice](<https://devfeed.tech/articles/from-ai-code-to-trusted-software-harness-engineering-in-practice-33270.md>)

Original publisher: [Read original article](<https://8thlight.com/insights/harness-engineering-in-practice>)

Author: Travis Frisinger

Published: 2026-09-04T21:55:00Z

Content type: opinion

Language: en

Sources: [8th Light](<https://devfeed.tech/sources/8th-light.md>), [8th Light Insights](<https://devfeed.tech/sources/8th-light-insights.md>)

Topics: [AI-assisted coding](<https://devfeed.tech/topics/ai-assisted-coding.md>), [Software](<https://devfeed.tech/topics/software.md>), [trust](<https://devfeed.tech/topics/trust.md>), [observability](<https://devfeed.tech/topics/observability.md>), [Authorization](<https://devfeed.tech/topics/authorization.md>)

Tags: [agent](<https://devfeed.tech/tags/agent.md>), [ai](<https://devfeed.tech/tags/ai.md>), [ai-and-emerging-tech](<https://devfeed.tech/tags/ai-and-emerging-tech.md>), [code](<https://devfeed.tech/tags/code.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [engineering-and-devops](<https://devfeed.tech/tags/engineering-and-devops.md>), [observability](<https://devfeed.tech/tags/observability.md>), [permissions](<https://devfeed.tech/tags/permissions.md>), [trust](<https://devfeed.tech/tags/trust.md>), [verification](<https://devfeed.tech/tags/verification.md>)

### AI overview

The article presents harness engineering as a repository-centered discipline for making AI-generated software more trustworthy. It argues that prompts and written standards are insufficient, and that permissions, quality gates, evidence, and observability should enforce organizational standards and support verification.

### Source excerpt

If the same reasoning path writes the system change and defines the proof of success, you may be setting yourself up for an avoidable failure in the future. Harness engineering is meant to act as an extension of your own organizational guardrails, which were always meant to reduce risk and improve quality. Travis Frisinger, Head of Agentic AI Your team is shipping more AI-written code every quarter. How do you know it is any good? Good means it meets your standards, and you have probably already tried handing your agents the standards: a context file, a style guide, the wiki pasted into the prompt. The agent reads them, agrees, and still breaks them, because instructions to a model are suggestions. What the repository permits is what actually happens. Your people absorb standards through review comments and hallway corrections, and the lessons stick. An agent apologizes and forgets by the next session. The only place its lessons can accumulate is the repository itself. That gap used to be an annoyance. With AI doing real engineering work, the quality gap is the whole game. Harness engineering is the discipline that closes it. It is the process of imbuing a repository with your standards so that the repository itself enforces them: permissions and boundaries that say what any actor may touch, quality gates that fail closed, evidence attached to every change, and observability that spans runs rather than moments. Models supply software delivery capacity. The harness supplies observable accountability: every change carries what was done, which rule allowed it, and what happened as a result, no matter which model, agent, or person did the work. Why now The industry started using the term harness engineering back in February, 2026. Since then, Thoughtworks, LangChain, and others have built serious thought leadership around the same shape. When several firms independently converge on the same word, it usually means they are trying to name the same problem. The real proble

## TDD: The Missing Protocol for Effective AI Assisted Software Development

DevFeed: [TDD: The Missing Protocol for Effective AI Assisted Software Development](<https://devfeed.tech/articles/tdd-the-missing-protocol-for-effective-ai-assisted-software-development-33279.md>)

Original publisher: [Read original article](<https://8thlight.com/insights/tdd-effective-ai-collaboration>)

Author: John Riccardi

Published: 2025-05-28T18:14:00Z

Content type: tutorial

Language: en

Sources: [8th Light Insights](<https://devfeed.tech/sources/8th-light-insights.md>)

Topics: [Test-driven development](<https://devfeed.tech/topics/tdd.md>), [Large Language Model](<https://devfeed.tech/topics/llm.md>), [AI Development](<https://devfeed.tech/topics/ai-development.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Prompt Engineering](<https://devfeed.tech/topics/prompt-engineering.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [coding](<https://devfeed.tech/tags/coding.md>), [core](<https://devfeed.tech/tags/core.md>), [engineering-and-devops](<https://devfeed.tech/tags/engineering-and-devops.md>), [llm](<https://devfeed.tech/tags/llm.md>), [prompting](<https://devfeed.tech/tags/prompting.md>), [quality](<https://devfeed.tech/tags/quality.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [tdd](<https://devfeed.tech/tags/tdd.md>)

### AI overview

This article argues that test-driven development provides a structured communication protocol for collaborating with AI coding tools. It explains that large language models often struggle with broad, ambiguous software tasks because developers provide insufficient context, constraints, and edge cases, and recommends writing tests first before using AI to implement solutions.

### Source excerpt

Bottom Line Up Front The goal isn't to replace human developers but to offload repetitive tasks so we can focus on creativity and architecture--where human expertise is irreplaceable. Start your next feature by writing tests first, then let AI help implement the solution. You'll deliver higher quality code faster, with greater confidence. Large Language Models Aren't as Simple as They Seem Large language models (LLMs) have a fundamental flaw: they appear deceptively easy to use. That blinking cursor invites you to interact with an LLM as if it were another human being--one that understands your intent, the context of your questions, and the logic behind your requests. You type a prompt, hit send, and then disappointment sets in. While it's exciting to watch it generate multiple files of code for your new project, the moment you try to run that code, it often fails to work as intended or doesn't run at all. As you continue prompting it to iterate on previous outputs, the LLM may go in circles, change direction entirely, or simply stall. The core issue is that we ask LLMs to do too much while providing too little direction and context--effectively setting them up for failure. It's like the classic PB&J experiment, where a father follows his children's sandwich-making instructions literally. We believe we're being clear, but we drastically underestimate how much implicit context AI lacks about the problems we're trying to solve. What we need is a better communication protocol--one that structures our requests in a way AI tools can reliably understand and execute. Why AI Struggles With Large, Ambiguous Problems Despite their impressive capabilities, current LLMs consistently struggle with large, vague problems. The issue is not primarily token limitations or technical constraints; it's a deeper problem in how we frame our requests. When developers ask AI to "build a complete authentication system" or "create an e-commerce checkout flow," they inadvertently set the AI up to