On terminals, IDEs, chat boxes, and everything in between.
I used to think I preferred coding agents in the terminal.
Part of it was practical, but part of it was probably just habit. I liked seeing the files, the commands, the logs and the diffs. I liked typing git add ., git commit, and doing the little rituals that made me feel like I was properly developing something.
An IDE felt familiar. A terminal felt even more familiar. A browser chat felt more like somewhere you went to ask AI a question.
Then I realised I had started dragging the Claude Code terminal up until it covered almost my entire screen.
I would only pull it back down when I needed to edit something like .env.
At some point it became hard to maintain the idea that the terminal itself was what made the workflow “technical”. I was already spending most of my time talking to an agent in a giant text box.
Moving some of that work into Codex and browser-based Claude Code also made the conversation easier to read, and made it much easier to switch between multiple tasks without juggling terminal windows.
That was probably when I stopped caring quite so much about whether I was using a terminal, an IDE or a browser.
The more useful questions were what the agent could see, what tools it could use, how much context I gave it, and how carefully I reviewed the result.
For the record, I was using em dashes before AI made them look suspicious.
Vibe coding is useful
It is genuinely much easier to build things now.
Someone who has never written much code can describe an idea and get surprisingly far. You can prototype a workflow, make a small internal tool, automate something repetitive, or simply test whether an idea is worth pursuing.
That is part of what makes vibe coding useful.
At its best, it lowers the cost of turning an idea into something tangible.
If you have an idea, try it. You do not need to understand every layer of the technology stack before you start.
Same interface, very different ways of working
Where things get confusing is when vibe coding and agentic development are treated as though they are separated by the tool itself.
Two people can be looking at almost the same interface and be doing very different things.
One person might ask:
Make me a leave application website.
and keep iterating until something useful appears.
Another might give the agent an existing repository, architecture context, coding standards and a test suite, then ask it to implement a change, run the tests, investigate failures and show the resulting diff for review.
The difference is not the chat box.
It is how the agent is being used.
Andrej Karpathy, who coined the term vibe coding, has since used agentic engineering to describe a more deliberate way of working with coding agents. I like his point that engineering still has an “art & science and expertise to it” — something people learn and get better at.
That is probably the most useful distinction.
A simpler interface does not mean simpler work
This is the part I think technical people sometimes underestimate.
We spend years becoming comfortable with editors, terminals, debuggers, build systems and frameworks. Those tools are useful, but familiarity with them can make us overvalue the interface itself.
What matters more is what the environment actually gives the agent access to.
If the relevant tools are available, an agent can inspect files, run commands, execute tests, call APIs, query databases and read the results much like we would during development.
The important change is not that testing, debugging or verification disappear.
They still need to happen.
What changes is that we no longer have to manually drive every step of that loop ourselves.
And that is where the real shift is happening.
Engineering skill is moving up the stack
AI is getting very good at producing code.
That does not mean software engineering has become easy.
A reasonable-looking implementation can still introduce a security issue, duplicate something that already exists, misunderstand a business rule, create an awkward dependency, or solve the wrong problem entirely.
Experienced engineers build up judgement around those things.
They know what tends to break. They recognise where shortcuts become expensive. They can tell when a small change has consequences elsewhere.
That judgement becomes more useful when an agent can generate a lot of plausible-looking work very quickly.
So I do not think the value of technical skill is disappearing.
I think it is moving.
Less value sits in manually typing every implementation detail.
More value sits in problem framing, system design, context, trade-offs, verification, security, and knowing when the agent is confidently wrong.
That is probably why strong engineers remain so valuable even as coding agents improve.
The agent gives them leverage.
More people can build, and engineers get more leverage
These two things can be true at the same time.
People without deep technical backgrounds can now build much more than they could before.
That is good.
Experienced engineers can use the same tools to move faster through implementation and spend more time on design, architecture, review and verification.
That is also good.
A prototype made in an afternoon does not need the same level of engineering as a production system serving millions of transactions.
That was true before AI and remains true now.
What is changing is that the same class of tools can support much more of that spectrum.
So whether you are technical or not, the advice is probably similar:
Start using the tools.
If you are new to building, experiment and learn by making things.
If you are experienced, do not worry too much about whether the interface looks sufficiently “developer-like”.
Your engineering knowledge still shows up in how you direct, constrain and evaluate the agent.
Because in the end, agentic development is more than a chat box.
It is the context we give, the tools we make available, the judgement we apply, and what we choose to build with it.