“If you do not have to babysit and watch your agent do the work, then the harness you have built is the right kind. Without that, you will constantly be babysitting your agent, and that's not getting maximum benefit out of the agent.”
The New Stack Podcast · Hands-On Engineering Podcasts · November 2026
Context
Asked how a team can tell whether its investment in an agent harness is paying off, Kumar names not having to supervise long-running agents as the first sign. This was a sponsored conversation; she works for the sponsor, Thoughtworks.
Transcript
…development work actual software development work so that's how fundamentally it is shifting now that we want we have definitely moved away matured away from casually chatting with the ide to get line level method level uplift so that's that's the shift i'm definitely feeling every single day
so quite a bit of planning uh or some planning before you move into the actual doing yes wonderful and what would a team uh be able to see uh how would they know that their investment in the harness is actually paying off
definitely um so the first thing like i stated is being able to run long running agents like if you do not have to babysit and watch your agent do the work then your harness is the right kind you have built it is the harness is doing the work without that you will constantly be babysitting your agent and that's not getting maximum benefit out of agent so a long running agent that produces quality results is first sign your ability to run parallel agents without them stepping on each other and your fellow developer doing something similar that is also another signal that the harness is doing its job it also has kind of shifted what we measure as measure of success it usually is pr request door metrics those those still matter but we also start measuring how much how much fluid is the human agent interaction how often do you have to course correct how often do you have to um correct some of its decisions or reverse some of those decisions those are the things that we are starting to measure as is our harness…
and how do spec driven development and context engineering fit into thoughtworks approach to harness engineering and what are some common misconceptions about how these three concepts all work together
oh i love that question um so spectrum and development it's it's it's a way to break down the work you want to do in a structured way and it is not a single approach there is a spectrum of ways of doing spec Driven development. The lowest end of the spectrum is spec first, where you just start with…
And then they all kind of work together in orchestration. You know, what you do in one kind of impacts the next one and so on.
More from The New Stack Podcast
