If you look at the marketing materials coming out of major tech companies right now, the message around Generative AI is loud and clear: automated tools and autonomous agents are the absolute future of development.
But if you talk to the engineers actually writing and maintaining software every day, the reality is far more nuanced.
At KotlinConf 2026 in Munich, I decided to step away from the keynotes and presentation stages to run a lightning round survey with attendees. I wanted to gather unfiltered experiences from real-world developers, mobile architects, and industry pioneers regarding how tools like Claude Code and GitHub Copilot are genuinely impacting their workflows, testing strategies, and career outlooks.
The insights were incredibly grounded, highlighting a fascinating divide in our community. Here is a breakdown of what developers on the floor are actually seeing.
1. The Ethical and Structural Stance
We started the conversations by sitting down with Jake Wharton, who offered an uncompromising perspective that focused on the wider implications of relying on these models.
Rather than focusing purely on code generation speed, Jake raised vital concerns regarding copyright and licensing:
“All of these world models that people are using are basically built on the largest copyright infringement in the history of the world. They ingest permissibly licensed software and copyleft code, essentially laundering it through the LLM to remove the license terms.”
He also shared a pragmatic warning regarding structural dependency. With platforms experimenting with usage-based billing, sometimes resulting in individual development bills jumping exponentially, engineers risk becoming overly dependent on a toolchain heavily subsidized by temporary venture capital funding. If those subsidies disappear, developers who rely too heavily on them could be left struggling.
2. Daily Workflow Realities
On the other side of the spectrum, many developers on the floor confirmed they are leveraging these tools extensively in their production environments.
For these teams, tools like Claude Code have rapidly become a standard part of the toolkit. Interestingly, some organizations are even experimenting with expanding access to product managers and UI designers to let them contribute minor adjustments within controlled environments.
When asked what they actually value about the tools, the answers focused heavily on bypassing the “blank page problem”:
- Boilerplate Reduction: Automating predictable structural code setup.
- Refactoring Aid: Giving broad commands to adjust existing structures into a specific pattern.
- Initial Research: Speeding up the time it takes to explore foreign codebases or find specific references in vast projects like AOSP.
However, almost every developer using AI daily noted a severe trade-off: maintainability. The generated code quality is frequently messy. When requirements change, developers often find it faster to re-prompt the model entirely rather than trying to manually read, debug, and maintain the code it previously generated.
3. Verification: How Do We Know It’s Right?
This brought us to a critical technical debate: how do you verify automated code? The community at KotlinConf seemed split into distinct camps:
- Strict TDD: Some senior developers are leaning heavily into Test-Driven Development (TDD). They use the AI primarily to help brainstorm edge cases and generate test suites, then manually curate those tests before letting the AI write the actual implementation.
- The Pitfalls of Spec-Driven Development (SDD): Another approach discussed on the floor was writing all architectural specifications completely upfront to let the AI build the entire feature from a master blueprint. However, engineers noted that this often mirrors old waterfall project failures. Assuming you can cleanly map out every single edge case in your head beforehand rarely works in practice, and you end up inheriting the same structural mistakes downstream.
- The “YOLO” Approach: Other engineers candidly admitted to simply deploying the code to see if it runs, relying entirely on rigorous team peer-review and testing pipelines to catch errors downstream.
A key challenge raised with both structured workflows, TDD and SDD, in an AI environment is network latency. Waiting on an LLM to generate or parse massive responses breaks a developer’s rapid, local feedback loop, which is essential to staying in a proper flow state.
4. The Risk to the Team Ecosystem
The most impactful part of the survey didn’t center on lines of code, but on the human health of development teams. Multiple senior engineers noted a dangerous trend in modern hiring:
Many organizations have slowed or stopped hiring junior developers, under the assumption that AI tools can bridge the productivity gap.
This creates a serious bottleneck. Without entry-level roles, companies aren’t training the next generation of engineers who will eventually need the deep domain context to audit these automated systems. Concurrently, senior engineers are facing burnout as their roles transition away from creative problem-solving into a mechanical cycle of continuous prompt auditing and cleanup. As one attendee noted, it can strip the genuine joy and “aha!” moments out of software craftsmanship.
Final Thoughts
Is software engineering a dying profession? The overwhelming consensus from the floor was a clear no.
Just like previous major technological shifts, such as the emergence of the web in the ‘90s, the core skillset isn’t disappearing; it’s evolving. The value of an engineer is shifting farther away from pure syntax writing and moving heavily toward architecture, system verification, and domain expertise.
To hear the full, unedited responses and see the exact conversations from Munich, you can watch the complete video pulse check on YouTube:
How is your team balancing these tools right now? Are you leaning into strict TDD guardrails, or do you share the ethical and long-term concerns raised by Jake? Let’s discuss in the comments.