Is writing code the same as building software?
I spent a long time thinking at the code level.
Take an issue. Write code. Open a PR. Smoke test it. Fix CI. Debug. Review. Merge.
When I started using agents, I carried that same workflow across:
“Take issue X. Refine it first. Follow the acceptance criteria. Implement it. Review the output. Smoke test it. Rebase it for human review.”
That works but it was still code-level thinking.
What clicked for me was that I needed to operate one level up: designing the system around the work, not just directing the code inside it.
Now the questions are different:
“Review the latest merge. What changed for the user? What outcome could this unlock for the business? What are the risks? Coordinate the build, and show me a working local version before it reaches production.”
Agents did not remove the need for judgment. They moved the center of gravity: from producing code to owning the system that produces outcomes.
How has your mindset shifted since you started building with agents?
Replies
I’ve started asking my agent what could go wrong before asking it to implement anything. That small change has helped me catch issues i would have missed when I was focused mainly on the code.
Curious do you now write fewer detailed tickets bcz the agent can handle more ambiguity?
That shift from “implement this ticket” to “own this outcome” is where agents start becoming genuinely useful. Code becomes just one part of the job, while the human focuses more on direction, risk, and what should exist next.
Do you find yourself writing fewer detailed specs now, or just different ones?