Yesterday I was listening to a podcast with a software engineer in his forties.

One comment caught my attention.

He said that he barely uses his IDE for writing code anymore.

At first, that sounded exaggerated. After all, most of us still spend a large part of the day inside VS Code, JetBrains, Zed, or some other editor.

But the more I thought about it, the more I realized he might be right.

The IDE is still open all day.

The difference is that writing code is no longer the primary activity happening inside it.

For most of my career, the editor was the center of software development. We opened files, navigated classes, wrote functions, fixed bugs, ran builds, and committed changes. Everything revolved around the act of typing code.

Today my screen looks very different.

Part of it is still source code.

Another part is a conversation with Claude Code.

Another window contains terminal sessions running automated tasks.

There is GitHub Copilot making suggestions.

There are documentation tools, search tools, agents reviewing changes, generating tests, explaining unfamiliar code, or proposing refactorings.

The IDE has quietly become an orchestration environment.

The code editor is still there, but it is no longer the main character.

The data suggests this is not just a niche trend. According to the 2025 Stack Overflow Developer Survey, 84% of developers are already using or planning to use AI tools in their development process, and more than half of professional developers use them daily. JetBrains reports similar adoption levels, with most developers now using at least one coding assistant or agent regularly. The conversation has moved well beyond autocomplete.

What I find most interesting is that the skill being developed is not simply writing code faster.

It is learning how to direct, review, validate, and coordinate multiple sources of intelligence.

In some ways, this reminds me of the transition many engineers experience when moving into leadership roles.

The value shifts from producing every output personally to creating the conditions that allow good outcomes to emerge.

The difference is that now some of the collaborators happen to be machines.

While building projects like Founder and AppGrid, I have noticed that the bottleneck is rarely typing speed anymore. The harder problems are deciding what should be built, evaluating alternatives, spotting mistakes, maintaining coherence across the product, and making trade-offs when several solutions look plausible.

Those are still very human activities.

The tools have changed.

The work is changing.

The judgment remains.

One challenge, however, is staying connected to how other engineers are adapting. Many of these workflow changes spread through conversations long before they appear in official documentation. Podcasts, blogs, conference talks, YouTube channels, newsletters, and discussions between practitioners often reveal shifts that are already happening in the field.

A few years ago, I spent most of my learning time exploring frameworks, languages, and architectural patterns.

Lately, I find myself paying much closer attention to workflows.

How are experienced developers working?

What tools have become indispensable?

What tasks are they delegating?

What are they still doing themselves?

The answers seem to be evolving every few months.

I’m curious.

How do you stay connected to what other software engineers are doing?

Related Sparkio Products

AppGrid Platform designed to help independent developers connect their products with potential customers.

Founder Interactive business history simulator inspired by the stories and decisions behind the world's most influential companies.