Every major technological shift produces two extreme reactions.
One side says nothing will change. The other says everything will disappear.
AI h...
For further actions, you may consider blocking this person and/or reporting abuse
"Execution becomes abundant. Decision-making becomes scarce" — this is the framing I've been trying to articulate for months. We're building with AI every day at 13F Insight and the shift is real: the bottleneck has moved from writing code to defining the right problems and owning the consequences. The bit about poor architecture built faster being still poor architecture hits hard. Thanks for putting this so clearly.
Thank you for sharing that perspective. It’s great to hear this confirmed by teams building with AI every day. What you described is exactly the shift many engineers are experiencing: once execution accelerates, the real constraint becomes problem definition, architecture, and ownership of outcomes.
And yes, the architecture point is critical. AI can compress the time required to build something, but it doesn’t change the underlying quality of the design. Poor architecture simply arrives faster, which makes architectural judgment even more valuable than before.
I appreciate you bringing the experience from 13F Insight into the conversation. It’s helpful to see how this shift is playing out in real teams.
Appreciate that. I keep coming back to the idea that AI doesn't eliminate engineering judgment—it redistributes where it matters most.
When code generation gets cheaper, the bottleneck moves upstream: choosing the right problem, defining constraints, and designing systems that can absorb speed without turning into entropy. We've felt that directly at 13F Insight. Shipping got faster, but the cost of unclear architecture or fuzzy product decisions also became visible much sooner.
So I’m with you: the leverage is real, but it rewards teams that get sharper about ownership, interfaces, and long-term design.
Thank you for sharing that perspective, it’s a very clear articulation of what many teams are starting to experience.
I like how you framed it: AI doesn’t eliminate engineering judgment, it redistributes it. When code generation becomes cheap, the real leverage shifts upstream into problem selection, constraint definition, and architectural clarity. The system has to be designed to absorb speed without accumulating entropy, otherwise the acceleration simply exposes weak decisions faster.
Your observation about shipping becoming faster while architectural mistakes surface sooner is especially important. AI compresses the feedback loop: good design compounds quickly, but unclear boundaries or fuzzy product thinking become visible almost immediately.
That’s why the teams seeing the most benefit tend to double down on ownership, well-defined interfaces, and long-term system thinking. Speed alone isn’t the advantage, speed combined with disciplined design is. I appreciate you bringing the experience from 13F Insight into the discussion.
Yep — and I think that shift also changes how teams should measure engineering performance. If AI can compress implementation time, then the bottleneck becomes whether the team is choosing the right abstractions and keeping system boundaries legible as the product evolves.
In finance-facing products, I’ve found the hidden cost is not bad code generation, it’s premature ambiguity: if the data model, ownership model, or review standards are fuzzy, AI just helps you create inconsistency faster. The upside is that teams with strong interface discipline can suddenly move at startup speed without losing institutional memory.
Feels like the winners will be the teams that treat architecture as a force multiplier instead of a documentation artifact.
Appreciate this thoughtful follow-up. That “speed without entropy” framing is exactly the tension I’m seeing too.
One thing I’ve noticed building 13F Insight is that AI makes the implementation layer dramatically cheaper, but it also raises the cost of vague thinking. If the product question is fuzzy, the model will happily generate a lot of technically valid but strategically wrong work. So the bottleneck shifts from typing code to defining the right abstractions, evaluation loops, and ownership boundaries.
My current heuristic is: let AI accelerate local execution, but keep humans responsible for system shape and truth-testing. The teams that win won’t just ship faster — they’ll learn faster without corrupting the architecture.
Really enjoyed the post.
Thank you for such a sharp and grounded reflection. The way you framed it, AI lowers the cost of implementation but raises the cost of vague thinking, is exactly the tension many teams are starting to feel.
Your heuristic is a strong one:
let AI handle local execution
keep humans responsible for system shape and truth-testing
That separation preserves both speed and integrity. Without it, as you said, models will generate technically correct but strategically misaligned work, and that misalignment compounds quickly.
I also like your emphasis on learning speed without corrupting architecture. That’s a subtle but critical distinction. Many teams optimize for output velocity, but the real advantage is in how quickly they can test, understand, and refine decisions without introducing hidden complexity.
Really appreciate you sharing insights!
That’s a very sharp extension of the idea, and I think you’re exactly right, AI is forcing a rethink of how we measure engineering performance.
When implementation is no longer the bottleneck, metrics tied to output (lines of code, tickets closed, even raw velocity) start to lose meaning. What matters more is:
quality of abstractions
clarity of system boundaries
consistency of decisions over time
Your point about premature ambiguity is especially important. In domains like finance, where correctness and trust are critical, vague data models or unclear ownership don’t just create noise, they create risk. And AI accelerates that risk by scaling inconsistency faster than before.
I really like your contrast:
weak structure → faster inconsistency
strong interface discipline → startup speed + retained coherence
That’s the real leverage.
Appreciate you bringing in the finance perspective as well. It highlights how these ideas aren’t just theoretical, they have real consequences in high-stakes environments.
"Execution becomes abundant. Decision-making becomes scarce." — this is the right framing.
But I'd push it further: what also becomes scarce is verification. We talk a lot about AI generating code, but not enough about the growing cost of checking whether that code is right.
The METR study is relevant here: developers perceived 24% speedup from AI, but actually measured 19% slowdown. Generation is instant. Verification is where the time goes. And verifying code someone else wrote (including AI) requires a different skill than writing it yourself — you need to understand the intent and the implementation simultaneously.
So the stack you describe — system design, constraint definition, behavior modeling — I'd add "verification infrastructure" to that list. The teams getting the most value from AI right now are the ones investing heavily in tests, type systems, and CI pipelines. Not because AI is bad at code, but because when code generation is cheap, the bottleneck moves to "how do you know it's correct?"
I strongly agree with adding verification infrastructure as a first-class layer alongside system design and constraint definition. Tests, types, CI pipelines, observability, and evaluation loops are becoming the real multipliers, not because AI writes bad code, but because cheap generation increases the surface area that must be trusted.
In a way, AI doesn’t remove engineering rigor; it makes rigor unavoidable. When code is abundant, correctness becomes the scarce resource. Thanks for pushing the framing further, this is a very important evolution of the conversation.
AI is not ending the software engineering. It will redefine it.