Where AI saves me time and where it slows me down
The New Stack Laureano Gonzalez
A Webflow engineer breaks down where AI actually helps and hurts in daily coding work. Writing code got faster — reviewing and owning it got a lot harder.
Based on reporting by The New Stack, Laureano Gonzalez — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Every engineer who's touched an AI coding tool has felt some version of this: the blank page disappears fast, and then something else shows up to take its place. A Webflow engineer laid out that shift in detail on The New Stack, and the piece is refreshingly free of hype. The argument isn't that AI is magic or that it's overrated. It's that AI moved the hard parts of the job somewhere else, rather than removing them.
The biggest win, by the engineer's own account, is at the start of a task. Before AI, a normal day meant bouncing between Slack, Jira, Confluence, internal docs, framework docs, and eventually Stack Overflow or a teammate who'd seen the same bug before. Now, with MCP and connected tools, an assistant can pull that context together directly. Webflow's own developer platform supports MCP, letting agents work with Webflow workflows through tools like Claude, Cursor, and Postman. That's the part the engineer finds genuinely useful — not a chatbot guessing in isolation, but something that can reach into the actual systems where the work lives.
Execution gets faster too. Full-stack work, infrastructure changes, migrations, dashboards — all of it becomes more approachable when AI can produce a working first draft. Testing benefits especially: generating mocks, suggesting edge cases, updating existing tests. None of this hands over expertise, the engineer is careful to note, but it shrinks the gap between being stuck and being useful.
The catch shows up right after that first draft lands. Code that compiles and passes tests isn't automatically the right code for the system it's dropped into. It might miss a constraint, misjudge a pattern, or solve a bigger problem than the one that was actually asked. So the engineer now spends more time reading generated code the way you'd review a colleague's pull request — checking edge cases, confirming architectural fit, trimming anything unnecessary. Skip that step, the piece argues, and AI doesn't save time at all; it just produces future work with better formatting.
There's a second, less obvious bottleneck: too much work in progress. Because starting something is now cheap, it's easy to end up with more branches, more PRs, and more review requests than a team can actually absorb in order. The question stops being whether one person can build something and becomes whether the team can safely merge it. Coordination, sequencing, and keeping pull requests small matter more now, not less, because the cost of generating extra work has dropped.
The engineer's conclusion is blunt: AI didn't erase the hard parts of engineering, it relocated them from typing to verifying, from searching to judging, from building to owning. That's presented as a fair trade, not a downgrade — faster starts, harder finishes, and a reminder that whoever ships the code is still on the hook for it.
My take — AI-written commentary, not fact-checked reporting
This is the honest version of the AI-productivity story that most vendor pitches skip: speeding up drafts doesn't speed up ownership, and pretending otherwise just pushes debugging debt onto someone's future Tuesday. Teams chasing velocity metrics from AI-assisted coding should watch their PR queues, not their commit counts — if branches are piling up faster than reviewers can absorb them, that's not productivity, that's a new kind of traffic jam. The tools got better at starting things; nobody built an equivalent tool for finishing them, and that gap is where the real engineering still happens.
Read more about this at: The New Stack
