In 2026, nearly everyone I interact with in tech wants to talk about AI. It comes up on LinkedIn, at meetups and conferences, and at work.
A lot of those conversations stay pretty surface-level. Someone says they’re excited about AI or that they’re “building with AI,” but I want to know what they’re building and how they’re doing it.
I’m an engineer. I want the technical details so we can learn from each other’s experiences.
I’ve noticed that “building with AI” can describe three different types of builders. This isn’t a maturity model where one category is automatically better than another. It’s a way to be more specific about what someone is actually doing.
I’ve listed them from most to least common based on my experience.
1. The builder who uses AI to build
This is by far the most common profile I come across.
These are folks who use AI coding assistants such as Codex or Claude to plan, write, or review code. AI is a tool in their workflow, but it isn’t part of the system they’re creating.
There are also people in traditionally non-engineering roles using the same tools, like product managers, marketers, and customer service teams. Sometimes they use these tools to write code without fully understanding what the code is doing.
My opinion: this is fine for a proof of concept. It can be a quick way to test an idea and learn whether it’s worth pursuing.
It shouldn’t be shipped to production without an engineer who knows what they’re doing reviewing or rebuilding it. Producing something that looks like working software doesn’t make it production-ready.
2. The builder who builds with AI
This group is less common, but they do exist.
These are often engineers building purpose-specific agents, software factories (automated pipelines that use AI to generate and assemble parts of a product), or applications that use LLM output as part of the product. They might also be experimenting with running local models.
The biggest difference between this group and category 1 is that AI isn’t only helping create the software. AI is part of how the software works.
If you take AI away from something built by category 1, the development process gets slower. If you take it away from something built by category 2, the product loses part of its functionality.
There’s also a less formal test: does the thing keep working when the builder’s laptop goes to sleep?
A local demo can teach you a lot. Deploying an AI-powered system for other people to use introduces different problems. Someone has to think about reliability, cost, and what happens when the model returns something unexpected.
3. The builder who is building AI
This is the smallest group in my experience.
These are the folks building and training the models themselves. Think AI researchers or engineers at companies like Anthropic and OpenAI who work on the models and supporting tools used by millions of people. Their day-to-day looks less like shipping product features and more like running training experiments, evaluating model behavior, and building the infrastructure other builders eventually rely on.
Where I fall
My work currently spans categories 1 and 2. I use AI assistants for regular engineering work, but I’m especially interested in building systems where AI is part of how the product works.
At work, I built a tool that uses Claude Code to help developers investigate failed CloudFormation deployments. It runs on shared compute and posts its analysis in Slack, so the team can use it without my laptop or me being available.
That’s what category 2 looks like to me. AI isn’t only helping me build the tool. AI is part of how the tool works.
I wrote more about the architecture and its imperfect parts in Getting Claude Code off my laptop and onto shared compute.
Prediction
Okay, bold prediction time! Keep in mind that this post was written in 2026, and I’m fine with it not aging well.
I think category 1 will stick around, but those builders won’t be as in demand. Knowing how to use an AI coding assistant won’t give someone much of an advantage when everyone has access to the same tools.
To be clear, I’m not saying every engineer in category 1 is in trouble. Plenty of experienced engineers use AI while still understanding the systems they’re responsible for.
I’m talking about the folks whose main skill is getting an AI tool to produce something that looks right.
Those builders will probably still find jobs, but I think they’ll have fewer choices. This will be especially true for the engineering teams they’d actually want to work at. The people with more options will be able to tell when the AI is wrong, fix what it produced, and own the result when it reaches production.
I also think builders in categories 2 and 3 will have more options. They’re creating the systems and capabilities that everyone else is using. That requires more than knowing how to prompt a tool.
Closing
The next time someone tells me they’re building with AI, I’m going to ask what they mean.
Are you using AI to build, building with AI, or building AI?
Where do you think you fall today?
Top comments (7)
Essentially number 1 for me. I started using AI officially in late 2025 and it was fun! I tend to use it in a professional setting time to time and it was helpful. Though, I am trying to reduce the amount of usage since I don't want to loose my critical thinking.
Also, I heard that companies are drifting away from AI because of the usage cost being more than a person's engineering salary. I was wondering if that plays a role to the future or alter your prediction in some way?
Both of those are worth pulling on, and the first one has better news in it than you might expect.
the study everybody is quoting for the critical thinking worry is lee et al, microsoft research and carnegie mellon, chi 2025, 319 knowledge workers. the number that travels is 62 percent reported engaging in less critical thinking. what doesnt travel with it is the split underneath. people with higher confidence in the tool did less thinking. people with higher confidence in their own expertise did more, and were about 27 percent more likely to actually assess what came back instead of taking it. same tool, opposite result, and the thing that moved was the operator.
also worth reading the actual title, self reported reductions in cognitive effort. thats people describing how hard something felt on routine low stakes tasks. its not a measurement of anyones capability going down. spending less effort on a routine task is what a tool is for. nobody thinks a calculator took arithmetic away from an accountant, the accountant just stopped doing long division by hand and kept being responsible for whether the books are right.
Byy that study the protective factor wasnt using it less, it was knowing your own domain well enough to catch it when its wrong. the friction that used to force you to think is gone, thats true. the standard the output has to survive didnt move at all. you still have to be able to tell when the answer is wrong, and thats the muscle worth keeping warm, not abstinence.
on the second one, i think that claim needs a name attached before it means anything. i went looking for who is actually pulling back and what i found runs the other way. the four biggest are guiding to somewhere between 650 and 760 billion in capital expenditure this year depending on whose tally you read, against roughly 410 billion last year. amazon alone is around 200 billion. whatever that is, it is not a retreat.
what i think is really behind the story youre hearing is narrower and more boring. plenty of individual pilots do get killed on cost, and thats real. but that is usually somebody who never priced the workload before they started, then met the gpu bill. that tells you something about how the project was scoped. it doesnt tell you anything about where the industry is going, and its a different claim wearing the same clothes.
if you find a specific company that publicly cut ai spend and said why, id genuinely want to read it. that would be evidence. the version going around right now is mostly vibes.
This taxonomy is useful because it separates workflow adoption from product risk. I’d add one more split inside the third bucket. Some teams are shipping AI as a feature, while others are taking on the liability of AI as the core promise. Those have very different blast radii when the model is wrong.
The taxonomy is useful because most "building with AI" talk collapses category 1 into one skill, and the skill that actually holds is not getting Claude or Codex to spit out a PR. It is catching when the agent rewrote a test to pass, dropped a validation check, or "fixed" something by touching three unrelated files. Category 1 is not going away. The people your prediction is about are the ones who treat the agent summary as the review and never open the diff.
I love how you break down the different roles AI builders play, making it clear why the work varies so much. If you think it could help even more devs, consider syndicating it on ZyVOP (zyvop.com) for extra reach.
The laptop going to sleep test is the cleanest line in here and im going to use it if you dont mind. take ai away from category one and you get slower, take it away from category two and the product loses a limb. thats a better split than the ones i usually see.
id offer one thing from the far side of that test, because passing it turned out to be the entry fee for me rather than the finish line.
i run a fleet of scheduled agents. laptop sleeps, they keep going, so by your test im category two. what i found last week auditing my own stack is that surviving my absence created a new failure i wasnt watching for. one of my scheduled verifiers had been exiting 127 against a script that no longer existed. it fired on schedule the entire time. it just wasnt verifying anything. another loop had produced 101 clean overnight runs and a queue of work orders nobody had opened. a third was collecting market data daily on a lane id already decided wasnt proven.
none of those woke me up, because none of them were down. they were up and unread, which looks identical to healthy from outside.
so if theres a category two point five, i think its this. the first bar is does it survive you not being there. the next one is does anything notice when it's wrong, or when its right and nobody consumed it.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.