What to make of AI in 2026

If you are a developer in 2026 and are thinking of deeply integrating AI in your daily job you're probably flustered by all the online noise. I was in that exact spot about half a year ago so I can make an attempt at helping you figure things out in a pragmatic manner without having a course to sell you :).

First the two categories of AI development, which are quite different in terms of what they demand from you:

• Vibe Coding
• AI-assisted engineering (there's a better term our there for sure, or it's just "development")

Vibe coding

This is the most visible category, the one you will see numerous videos and LinkedIn posts about. It's the thing CMOs love to pull you aside for, to show you what they built in 1 hour on their laptop. But don't let my tone discredit them as there are genuine, valuable and useful cases for that:

• Static websites: Marketing websites, small docs pages, short-lived promotional pages are some examples that are now much cheaper (and better, many times) than what you would traditionally pay an agency a couple of thousands $ to build. This is the part of our industry that is already being heavily disrupted and the hard truth is that you just can't plan on surviving solely on selling these websites: you will either have to differentiate somehow (on design, hands-off hosting/management, updatability) or scale this site generation beyond what's humanly possible (1 person agency managing 100+ websites). Keep in mind that static websites generated by coding agents (Claude, Codex, Gemini) or online platforms (V0, Lovable) are still not perfect and are definitely not usable by dropping one prompt: their design is reproducible (once you start noticing their color palettes, animation patterns, border radius, font families you will never unsee them), fine tuned changes are often hard to nail, and they're definitely not easy to keep track of as a non-technical user (domains, servers, emails etc), so this post-onboarding difficulty could be what you can focus your business on.
• Prototyping: The same tools as above can generate the same artifacts as above, but in some cases they might the perfect fit out of the box such as in prototyping. You don't care about vibey design looks if you're need to share a three-step UX flow with your team instead of writing down a detailed PRD. Or, you might babysit an agent through the smallest of a UI's details in a throwaway html prototype that you can use as a high-fidelity design, instead of using figma.
• Internal tooling: This is the most fun case for many developers as they finally get to do two of their most favorite things: build tools for their own needs and not pay money for it. A cli tool that tracks token usage of your agents, or an internal CRM replacement, these are tools that you can build in hours without caring about long term maintainability.

These are just some of the use cases of vibe coding and it's way more than what cringey LinkedIn posts make it appear.

AI Assisted Engineering

Like everyone, I discovered how capable coding agents became in November 2025 and it took me a while to dial in the level of control I needed to give them. And this is the only hard part in this case: how much oversight you need to give a coding agent because there are currently no more issues about an agent producing non-working code. The keyword-bashing, prompt-rage issues you see online come from either bad context management or insufficient prompting – granted, some agents need less detailed prompting and less context window pruning, but overall you will not get one-liners that don't work, as was the case 2 years ago.

It is helpful to understand how a coding agent works in order to understand how much control you give it. An agent is nothing more than a loop of llm calling and tool calling, until a goal is achieved:

• LLM calling is what you do when you ask your ChatGPT: you invoke the underlying model with a prompt and get back an answer. This is the brain of your coding agent.
• Tool calling is what your agent does in order to communicate with the environment. It might use bash to create files, run scripts, list commands, create folders and lately call CLIs (like the Github cli to open a PR, Linear cli to read a ticket etc), fetch to access urls such as documentation, or to make API calls. I'm sure that you are now starting to shape a picture in your head of how an agent is completing development tasks.
• If not, the last part of the puzzle is the loop. An agent is great at breaking down tasks, understanding the output of a file read, suggesting a code change, reading an app's logs to see if the code change was successful... and it will happily work in many iterations of a loop and add up to your total token usage in the process.

So, now that you know how an agent works, you can understand the difference a detail in your prompt can make in the number of loops your agent can take until, for example, it discovers that you have named 3 parts of your codebase in the same way (so grepping by a specific term might yield the wrong result and your agent then spends 20 minutes iterating in the wrong feature).

So, the answer to "how involved must I be" is "it depends":

• On the complexity of your codebase and/or the existence of good instructions in each part of your codebase (either by using Agents.md , Readme.md, or just good coding patterns).
• The complexity of the task you give it.
• The clarity of your request ("implement feature x" versus "create component x in view y, that calls service z, in order to perform action b, and don't forget to add tests like fff.spec.ts).

If that sounds like something you might not hate doing, then buy yourself a 20$ claude subscription (or a cheaper alternative like kimi or codex) and start experimenting by keeping the above in your mind. You will soon start dabbling with other techniques, such as using skills.md, fleets of agents but by understanding the above you can already get ahead of your past self.

Then, you will get into the topic of reviewing and understanding the code your agent produces but this is a different discussion.