Why Stevinator Is Becoming an AI Engineering Channel

So here is the thing. Stevinator is changing direction.

The channel started with programming tutorials, Dart, Flutter, and a large collection of Exercism solutions. I am not deleting that work. It is part of the channel’s history and it still helps people.

But general programming tutorials are no longer what I want to put in the middle of Stevinator.

From here, Stevinator will be an AI engineering channel.

That does not mean an endless stream of model announcements. It also does not mean turning the website into a catalogue of apps I built.

I want to understand how AI is changing programming, software architecture, project management, and the way we deliver products. Then I want to explain what I learn through YouTube, this blog, and eventually a practical course.

The projects are there to test the ideas. They are not the whole point.

Why AI engineering

AI is already changing how developers work.

We can ask a coding agent to explore a repository, implement a feature, write tests, or explain code in a language we barely know. A small team can prototype something in days that previously took weeks.

That is exciting. It is also easy to misunderstand.

Writing code faster does not automatically mean we are delivering better software. Somebody still has to decide what should be built, give the agent useful context, review the output, test the result, protect customer data, and own the release.

The developer’s job is not disappearing into one large prompt. It is changing.

That change is what I want to explore here.

More than another AI tutorial

There is already plenty of AI content online.

A new model launches and, within a few hours, everybody has a summary. Somebody builds an agent in five minutes. The agent calls one tool, returns the expected answer, and the tutorial ends.

That content can be useful when you are getting started. But experienced developers quickly run into different questions:

• How much autonomy should the agent have?
• What context does it need?
• How do I know whether its answer is actually good?
• How do I review a large amount of generated code?
• What happens when the model or one of its tools is wrong?
• How does this change planning, estimates, testing, and team roles?
• What should stay under human control?

Those questions are not only about building AI apps. They are about being a software engineer in a world where AI is part of the development process.

What Stevinator will talk about

The main subject is AI, viewed through three connected areas.

Practical AI engineering

This includes agents, model APIs, MCP, structured output, RAG, model routing, context engineering, evals, and the tools developers use to build with AI.

I want to explain how these systems work, when they are useful, and where a simpler solution would be better.

Programming, architecture, and delivery

AI does not exist outside normal software engineering.

We still need architecture, testing, observability, deployment, security, cost control, and maintainable code. We also need to understand how coding agents change specifications, pull requests, code review, and the speed at which teams can safely work.

This is where programming and project management meet the AI topic.

Senior judgment and leadership

I have spent more than twelve years working across software engineering and project delivery. I have built for web, mobile, and desktop, worked inside automotive software organizations, and delivered software under real deadlines.

That experience affects how I look at AI.

I am interested in what happens to estimates when implementation becomes faster but review becomes harder. I want to discuss how teams should introduce AI tools, how hiring signals may change, and why technical judgment becomes more important when producing code is cheap.

These are engineering and leadership questions, not only model questions.

YouTube comes first

YouTube will be the main way people discover Stevinator.

The videos should make difficult AI engineering topics understandable. Some will be technical walkthroughs. Some will compare approaches. Others will be about software delivery, project management, or what AI is changing for experienced developers.

The website has a different job.

The blog is where I can go deeper than a video. It can hold the architecture, code, references, test results, and the parts that need more careful explanation. A reader should be able to come back months later and still find something useful.

Over time, the strongest material from both will become the foundation for a practical course. I do not want to create the course by guessing what people need. I want the videos, articles, questions, and real experiments to show me which problems are worth teaching properly.

Where the projects fit

Stevinator will still have projects and apps.

They are useful because I do not want to talk about AI only in theory. Projectinator, the AI Arena, and future experiments let me test claims against real code and real model behavior.

But the apps are supporting material.

For example, Projectinator is not interesting only because it can generate a small web app. It gives us something concrete to discuss:

• whether several AI roles are better than one agent
• how a PM model creates a dependency-aware backlog
• where a human approval gate belongs
• how browser testing changes the feedback loop
• whether model routing saves money
• what happens when generated commands are not sandboxed

The project gives the lesson evidence. The lesson is what belongs in the middle of Stevinator.

What I will try to avoid

I do not want this to become an AI news site.

I will talk about a new model or tool when there is something useful to test or explain. I do not need to summarize every announcement before the documentation is finished.

I also want to avoid generic articles that could have been written without doing the work. No “ten ways AI will revolutionize programming.” No pretending every agent is production-ready because it completed one happy path.

When possible, I want to show:

• what I tried
• what failed
• what it cost
• what changed after testing
• what I still do not know
• and what I would recommend to another developer

The tone should stay practical. No hype, but also no pretending AI is a small change that developers can ignore.

What you should expect

The content will mainly use TypeScript and Python because both matter in the current AI ecosystem. Go will appear where it makes sense for a smaller systems component. Flutter will return later through a focused AI-on-mobile lane rather than general beginner tutorials.

The topics will move between hands-on engineering and the wider delivery questions around it.

You should expect articles and videos about:

• building and evaluating agents
• coding-agent workflows
• RAG and retrieval quality
• MCP and tool use
• observability, cost, and failure handling
• specifications and project planning for agents
• reviewing AI-generated code
• how AI changes teams, hiring, and technical leadership

Some articles will use Stevinator projects as examples. Others will stand on their own as explanations, comparisons, or reflections from my experience.

The simple version

Stevinator is becoming a place for developers who want to understand AI beyond the announcement and beyond the five-minute demo.

The main subject is AI engineering and how it changes the way we program, design systems, manage projects, and lead software delivery.

YouTube will explain and demonstrate it. The blog will go deeper. The projects will test the ideas. The future course will organize the lessons that prove genuinely useful.

That is the direction.