How coding assistants get in the way of constraints discovery
Earlier this week we published “Coding assistants are solving the wrong problem”, which made it to the HackerNews front page and drew responses from developers across industries and roles.
We learned a lot from the (40+) survey responses that poured in, as well as the heated debate on how coding assistants impact software development. The latter deserves its own article-a separate post curating best practices in coding agent setup is in the works.
For this follow-up article however, we will focus on main findings that connected the dots for us why AI adoption on average led to an increase in time spent on review, rework and re-alignment tasks commensurate with the development time that it saves (Atlassian, 2025). We will use firsthand accounts from commentators to illustrate friction points along the entire product lifecycle.
Finding 1: Communication friction is *the* distinguishing pain point
We asked developers: when do you discover that the code doesn’t work the way people think it does? And separately: who needs to know when you find a technical constraint?
Left: A third of technical constraints were already in a product conversation. Right: 70% of those constraints need to reach people who don’t regularly interact with the codebase.
These two charts, taken together, reveals the deeply cross-functional nature of the problem we are dealing with.
Let’s start with an observation from the first graph: one-third of constraints are discovered during planning sessions - sprint planning, product-engineering syncs, 1:1s with their PM. That’s great, that means they can be addressed during initial discussions right? Not so fast-
The issue is all context. Small decisions have to be made by design/eng based on discovery of product constraints, but communicating this to stakeholders is hard and time consuming and often doesn’t work.
... continue reading