I often look at today's IDEs and wonder what programming interfaces will feel like just a few years from now. In five years, are we still going to use modern IDEs the same way we do today? Will the code be the primary IDE artifact, or will it evolve into something very different? I don't know for sure, but I'm more and more convinced that programming interfaces are going through a major shift because of AI, and I think Claude Code is pioneering that movement.
Claude Code is often described as an agentic coding tool, but to me, it feels more like an interactive programming environment. It's magical software. I might be reaching here, but I believe it's as foundational and visionary as Smalltalk-80 was in its time. Smalltalk set a new vision of the ways how different people could effectively and joyfully use computer power. I think Claude Code is doing something similar, but with raw intelligence.
Still, the reason I sat down to write this post wasn't Claude Code's similarity to Smalltalk (though I'll get to that a bit later). What pushed me was a moment of quiet surprise at work watching engineers I admire and respect treat Claude Code lightly, almost as if it's a toy.
That got me thinking: why is it that I'm taking Claude Code so seriously while others can ignore it? What do I see that they don't? And more importantly, why am I so sure that Claude Code might be the foundation of the next paradigm of programming interfaces?
So I set out on a writing journey. To make my case. To explore what makes Claude Code feel so magical to me, and what it does or doesn't do for others. Writing is how I think best, and this post is my attempt to lay it all out and maybe even convince you to give it a real try.
Another reason I like writing about the intersection of AI and software engineering is because I care deeply about the future of coding. I want to do my part, even in a small way, to help teach it. I truly believe everything we know about programming is changing, and I want us to stay ahead by building AI-native teams.
From Smalltalk-80 to Claude Code
I'm a big fan of Smalltalk-80. I've never used it directly, but I've read and studied it enough to see how deeply it shaped what we now think of as modern software engineering. It pushed forward human centric ideas about simplicity, uniformity, and most importantly, the view of software as something dynamic and malleable.
Smalltalk-80's GUI wasn't just a layer of aesthetic. It was a core part of its vision, a reflection of Alan Kay's dream of the Dynabook where we can have a personal computer that anyone could learn to use and program, no matter their background.
If Smalltalk created a living, inspectable system around object messaging, then Claude Code is doing the same around intent messaging. Both aim for the same goal: turning software into a medium for thinking. Programming, in this view, is less about writing code and more about shaping ideas as they form.
In Smalltalk, you weren't just writing, compiling, and running code. You lived inside a live system. It felt more like molding clay than editing text. You could get instant feedback, build fast, and feel like you were having a real conversation with your program.
Claude Code, to me, is reaching for something similar. It's trying to reimagine how we build applications by letting us describe what we want in a way that feels closer to how we naturally think about solutions.
Claude Code gives me a feel for design not in the visual sense, but in knowing how to use the tools I already have to shape the system around me with the least effort and the most impact.
That's why I believe Claude Code builds on the work of Smalltalk-80. And building on the work of others is how real progress happens in any field.
There weren't many new programming concepts to learn to understand Smalltalk. Claude Code feels the same. It requires no new knowledge to get started, and if you approach it with a beginner's mind, it quickly becomes an environment you won't want to build without.
Now let's talk about Claude Code and what makes it a compelling interface to build software with.
Getting started with Claude Code
Claude Code runs in the terminal, so it should be a natural fit for most engineers. You can use it in your favorite terminal (I like Ghostty and iTerm), or run it directly inside your IDE like Cursor or IntelliJ.
Use this command to install in your system. It does require Node.js 18+ though.
npm install -g @anthropic-ai/claude-codeOnce you're set up, I strongly recommend watching this 30-minute video. It covers the most basic CC (Claude Code) workflows in half an hour to be fully productive.
If you're curious how I actually use Claude Code day to day – from collecting knowledge to building software – I'll walk through that in the next section.
How I work with Claude Code
The thing is, I love programming and never ever want to lose touch with it. There is, of course, the economic value of AI programming, but also something deeper – the human value of expression and the feelings you experience when programming. I never want to lose that.
I just think AI is a new type of leverage. It gives us a mechanism where a small change, or sometimes no change at all, in the input can result in a larger change in output.
With AI tools, the barrier to learn new areas almost collapses. This means the ability to generate new ideas and knowledge becomes extremely high leverage work. Egoistically, I think for most people, including for us developers, that type of work might be more fulfilling and more fun.
The Claude Code workflows I describe in this section are tools of leverage for me to produce more output with less work, so I can execute faster and save time.
What I'll also explain below is that more output, especially for code, is not always good. For code specifically, it should be good output, not just output.
Terminal Tools
People sometimes forget that Claude Code is a terminal-based application, which means it has full access to your shell environment. This includes all the existing scripts and CLI tools you already know and use, Claude Code can use them too.
Here are some common ways I combine Claude Code with bash tools to create simple, composable commands:
npm audit | claude -p "Prioritize security vulnerabilities by severity"
git log --oneline -10 | claude -p "Generate a release summary from these commits"
tail -f /var/log/mysql/error.log | claude -p "Explain any database errors in plain English and suggest fixes"
cat foo.txt | claudeSince Claude Code works so well with command-line tools, I prefer using CLI tools over MCPs whenever possible. One example: I use the Github CLI to interact with Github instead of relying on the Github MCP. It's faster, more reliable, and avoids problems like context rot from too much MCP usage.
For most coding tasks, I'd even go as far as recommending not using MCPs at all if you can. Save them for context gathering and planning. Claude Sonnet and Opus 4.0 are both amazing models, and they've been tuned specifically for tool use inside Claude Code. You should take full advantage of that.
Claude Code can also spawn sub-agents for more complex tasks. Here's an example prompt for a Java-based project that will spin up multiple parallel sub-agents:
Analyze the Java classes in this directory and document the common patterns we're using. Focus on naming conventions, error-handling patterns, and structure across service, controller, and model layers so new team members can follow the same approach. You should start 3 sub-agents with different focuses and compare their results.
Sometimes, I run multiple Claude Code sessions. I'll ask one agent to review my code changes, and open another session to address the feedback. That said, I recommend starting with simpler, sequential workflows especially when you're just getting used to it.
You can also create custom slash commands. It's much easier than people think. I've noticed some hesitation around them, but they're simple to set up and incredibly useful for repeated workflows.
Here's how I create a custom slash command for one of my common workflows:
echo "Find and fix the JIRA issue #\$ARGUMENTS using the registry MCP. Follow these steps: 1. Understand the issue described in the ticket 2. Locate the relevant code in the current codebase. If nothing is relevant, use the same MCP to search the sourcegraph codebases 3. Implement the fix 4. Write tests 5. Create a PR" > ~/.claude/commands/fix-jira.mdBackend vs UI
For backend work, Claude Code is excellent. There's a clear feedback loop: write code, run tests, fix issues, repeat. The agent is highly capable here.
UI work is trickier. Models still struggle with visual taste and design aesthetics. You can see it in the AI-generated UI output. I can't quite describe it, but it just looks bad. I see it in apps built with Lovable, v0.dev, and others. They often lack taste. For people who care about aesthetics and visual clarity, human-built UIs are still much better.
If you're building UIs with Claude Code, one approach that has worked ok for me is to add screenshots of the app to a screenshots directory. You can then ask CC to use them for inspiration or to better understand what you want it to build.
For UI development, I mostly rely on Cursor, but I often have Claude Code running in a separate terminal session inside Cursor. The Cursor and CC integration is great and when you select text in the editor, CC automatically picks it up as part of the context.
The reality is, when I started using Claude Code when it was first released, I never thought it would become the kind of tool I'd use for my daily coding workflows. I felt lost and overwhelmed. I didn't get the hype, at least not until I spent real time learning it and becoming somewhat fluent in the environment. Even now, I still feel like an amateur when it comes to being a true power user of CC. There's so much more for me to learn.
But over time, I fell in love with it. It gave me a glimpse into what the future of coding might look like. If agents, and especially background agents, become a core part of how we build software, I can't think of a better home for them than the terminal. Terminals are already built for background tasks, and they feel like the natural place for agentic development to grow.
Adoption of agentic AI tools among software engineers
Before drafting this post, this was the first section I wanted to write. It's something I've been consistently thinking about. How can we help current software engineers become AI-enhanced? How can we increase the adoption of AI tools in a way that feels natural and has a low barrier to entry?
I've taken a lot of rough notes on this over time, both from my own experiences and from conversations with new and existing users of AI developer tools.
Agentic coding is a softer development process where AI agents actively take part in how code gets written. In the world of AI, I see two broad trends:
- make experts faster (e.g. Claude Code, Cursor)
- make anyone an expert (e.g. v0.dev, lovable)
I believe we in big tech can benefit from both. My focus, though, is on the first trend not because the second isn't important, but because I feel more equipped to contribute to it. As an experienced programmer and a power user of these tools, I know where the friction is, and I can better spot the ways AI can help us move faster.
To be fair, Claude Code adoption at my current company is going pretty well, I "think". And yet when I speak with my peers I notice that many either do not know how to start or feel overwhelmed because they think it is too late for them. Some tried CC briefly and did not have a good experience. Below is the list of reasons I have gathered from my notes and chats.
Overwhelmed and not sure where to start
A lot of people feel behind when it comes to tools like Claude Code. Some think it's too late to learn, or that it's too hard to catch up, which makes them even less likely to try. I'm not exactly sure where this feeling comes from, but I suspect the hype around AI contributes to the sense of overwhelm.
My main message is this: it's still very early. The industry is still figuring out what works and what doesn't. The learning curve is real, and I agree it can feel high at first. But once you get the hang of it, the productivity gains start to compound fast.
It's also possible we haven't done a great job reducing documentation sprawl. Right now, the information is scattered across forums, manuals, and internal docs. I think we'd benefit a lot from having one centralized place where engineers can go to learn agentic programming and get started with the tools.
Not happy with tool output
Most people have very high expectations and expect the agents to behave like senior engineers. That is not where we are right now. I treat them more like junior engineers and explain them the same way I would to a junior teammate. That means giving them enough context to do the job well, but not so much that it becomes confusing. This has been the best mental model I've found for setting the right expectations and getting useful results.
It's true that many tools can produce verbose or low-quality code. It often depends on your prompt and the codebase. I've found that being clear and direct helps. When asking for a code change, I usually ask the agent to keep it simple and skip edge cases at first. That helps avoid unnecessary complexity. Among all the coding agents I've used, CC is the most thoughtful and tends to produce cleaner, more tasteful output.
I've also heard that people think Claude Code is too confident when making changes. I agree with that. This is why I always recommend starting with the plan mode on. Let it create a plan first, review it, make any edits, and only then move forward with execution.
Too slow
Claude Code is slow, but I believe it will get faster over time. Chatting is actually the smallest part of what it does. Claude Code has to understand your entire codebase, figure out what files need changes, write the code, test it, and sometimes go back and fix things. That takes time.
I don't think slowness is the main issue. These agents are still much faster than humans at many complex coding tasks. What matters more is the accuracy and quality of the code, not how quickly it gets written. In most cases, we are talking about a few minutes, not hours.
What we should ask from Claude Code or Cursor is to help us build the best software, not all software.
Reviewing changes gets harder
The bottleneck in software development is starting to shift. As code becomes cheaper to produce and easier to generate, the real challenge moves to reviewing, testing, and delivering that code with confidence.
I'm already seeing (are you not?) this in my day-to-day work. PRs are getting larger and more frequent. This isn't ideal and can be hard to manage. We need better ways to test these changes in CI so that we can feel confident before pushing anything to production.
Since Claude Code can't interact with most of our services yet, I usually ask it to write a "test plan" based on my code changes. I then manually check off the steps and include the plan in the PR description. It's a small thing, but it helps keep the process clear and thoughtful.
It can get costly
I have a somewhat controversial take here. At this stage of AI and where we are with GenAI developer tooling, I think we should actively encourage engineers to spend more with agents. Spending more means using them more, which leads to greater adoption and real productivity gains.
Once these tools become a normal part of our everyday work, we can start thinking about ways to reduce token usage and bring down the cost. But for now, the focus should be on learning, experimenting, and making the most of what these agents can offer.
Closing thoughts
AI is a new kind of leverage. It gives us a way to turn the same input, or sometimes no new input at all, into much more output. That's the heart of what makes it so powerful. If you look at history, the biggest leaps in value creation came from three kinds of leverage: human labor, capital, and code or media. AI is now joining that list. It is still early, but the reach is expanding. The biggest shift is that the barrier to learning new areas is collapsing. AI tools make it possible to pick up new knowledge quickly.
As software engineers, we now have access to a kind of leverage that combines both human labor and code. Used well, AI agents can save us real time conservatively three or four hours per week at least, even with basic workflows I described above. That might sound small, but scaled to a company of our size, that could mean several hundred million dollars in productivity gains each year. And that's before even counting the long-term compounding value of better tools, better learning, and more fulfilling work.
The real opportunity is to help more engineers see AI this way, not as a shortcut, but as a new set of tools to go faster and go further. I believe the teams that learn to work this way will be the ones that shape what software looks like in the next decade.
Let's build AI-native teams. Let's make it part of how we work. And let's not wait for someone else to figure it out.
Thanks for reading.