A month ago I sent a cold message to a meetup organizer with a rough idea for a short talk about AI-assisted coding chaos.
At that point it was basically just a rant: "Why does asking an LLM to add one button end with half the repo rewritten?"
Since then:
— I gave the first version of the talk
— turned it into a dev.to article
— got surprisingly good discussions out of it
— and now I'm doing another session for Azure Meetup Konstanz
One thing I realized during this process: writing about engineering and speaking about engineering are completely different skills. When you write, you can edit weak parts away. When you speak, weak ideas become visible immediately.
The topic is still the same: how to use AI coding tools without turning your project into entropy.
If you're curious — here's the meetup link:
https://www.meetup.com/azure-meetup-konstanz-region/events/314158692/
And the original article:
https://dev.to/klem42/i-asked-an-llm-to-add-one-button-it-rewrote-half-my-repo-1l1f
Top comments (3)
This is such an accurate observation about engineering communication 😄.
Writing lets you refine ideas quietly, but speaking exposes whether the idea actually survives real-time human parsing.
The “add one button, rewrite half the repo” experience is also becoming the unofficial onboarding ritual for AI-assisted development 😂.
What makes talks like this valuable is that they focus less on AI hype and more on operational reality — context drift, entropy, unintended refactors, and maintaining architectural discipline.
A lot of developers are discovering that using AI coding tools effectively is closer to engineering management than autocomplete.
It’s also cool to see how a simple rant evolved into a meetup talk and broader discussion; that’s usually a sign the problem resonates deeply with other engineers.
Really solid topic, especially now that “AI-generated technical debt” is becoming its own category of software engineering.
The "AI-generated technical debt" angle is actually really interesting. What really caught me off guard is how fast code review turns into straight-up architecture archaeology.
You stop asking: "Is this code correct?"
And instead you're like: "Wait... why did the model even touch this part of the system?"
That shift is way bigger than I would expect at first
Exactly 😄. Traditional code review was mostly logic validation, but AI-assisted development quietly turns it into intent reconstruction and system-boundary analysis. The scary part is that the generated code often “works,” so the real cost appears later as architectural entropy and hidden coupling. By the way, I really like your perspective on this topic — would love to connect outside the thread if you’re open to sharing your Telegram, LinkedIn, or contact info.