Techlarity
New
Series

How AI Really Works

A plain-language series for engineers and IT professionals on what AI is and how it actually works. Press play to start; the rest of the series is in the player's playlist.

Episode 0 · AI Won’t Take Your Job. Someone Using AI Will.

Subscribe Playlists
Intelligence Applied

AI productivity for engineers and IT professionals

Practical ways to use AI in real technical work, built as workflows you can check, trust, and repeat. No hype, no six-month theory course.

Get updates
What the channel covers

Beyond chatbot prompts

Each video starts from a real problem engineers and IT teams face, then shows a workflow and how to check whether it actually worked.

01

Practical AI tooling

Projects, persistent instructions, context management, reusable skills, and agents, and when each one is worth the setup.

02

Technical problem-solving

Understanding unfamiliar codebases, troubleshooting systems, writing small scripts, and researching new technology quickly.

03

Systems engineering

Requirements review, ambiguity detection, traceability, interface reasoning, and verification planning with AI as a partner.

04

Repeatable document workflows

Turning PDFs and specs into structured, usable data with Markdown, JSON, YAML, and Python, the same way every time.

05

Reliability and judgment

Independent checks, tests, error analysis, data protection, and human sign-off. Never asking the model to grade its own work.

06

Career resilience

Concrete skills that keep technical professionals valuable as AI changes the work, grounded in action rather than predictions.

The approach

Clarity over hype

The goal is a measurable improvement in real work, shown honestly.

Verifiable

Every workflow comes with a way to check the result independently instead of taking the model's word for it.

Repeatable

Processes you can run again next week, hand to a teammate, and review, not one-off demos.

Measured

Before-and-after comparisons on realistic material, with the limits stated plainly.

Free updates

Get new workflows by email

New videos, templates, and practical guides for engineers using AI. Occasional emails, no spam.

The email list is launching soon. For now, joining opens an email to add you manually.

Workshops and consulting

Bring it to your team

Hands-on sessions and setup help for engineering and IT teams that want AI workflows they can rely on.

  • Practical AI for systems engineers
  • Setting up AI assistants around your team's own process
  • Verification habits for AI-assisted technical work
Ask about a workshop
Connect

Questions, ideas, or a workflow you want covered?

Suggestions for future videos are welcome, especially real problems from your own work. Find Techlarity wherever you spend your time.

Techlarity Tips

Build a project control panel beside your Claude chat

Paste this prompt into Claude Code in your own project. Claude interviews you first, then builds a private project dashboard that sits in the Artifacts pane next to your chat: your project’s phases and items, where each one stands, and a to-do list where each item opens what you need to act on it.

The prompt
I want a project board I can keep open beside this chat in the Claude desktop app. Build it as a private claude.ai Artifact page and pin it to my sidebar.

WHAT IT SHOULD DO
1. Overview: a diagram of my project's major groupings (phases, epics, workstreams or whatever this project uses). Each grouping lists its items by name, with a progress bar and the next milestone highlighted.
2. Item detail: every item with its stage on a short pipeline (e.g. Draft → Review → Build → Test → Shipped), its due or release date, and a one-line "what's next". Flag anything past its date and not done.
3. Summary tiles at the top: how many are done, how many are in progress, what ships next (and whether it's at risk), and how many to-dos are open or overdue.
4. A to-do list where each item has an owner (me or Claude), a due date and a tag for the item it belongs to. There's a filter for All / Mine / Claude's, and a way to add my own items.
   - The checkbox only marks an item done.
   - Clicking an item's text opens an action panel with a short summary, numbered steps, buttons that open the right tools (https links only), the materials I need (rendered Markdown text and images), and a response form. The form is one of these: Approve / Request changes (a note is required for changes), a decision with options to pick from (label your suggestions as yours), or Mark done with an optional note.
   - My responses are saved on the board. At the start of each session, read them and act on them.

HOW TO BUILD IT
- Keep the data in the artifact's own database (the db capability), not in the HTML: collections for items, todos and materials. Update them with the database tool, reading first and passing the version you read, because I tick things myself and versions change. Only republish the page when its code changes.
- Take the initial status from this project's real sources (status files, docs, the issue tracker, git history). Don't invent status. Tell me which dates or stages you inferred.
- Use this project's own words for things. Check the decision docs or README before you choose labels.
- Before uploading any project files (docs, images, screenshots) as materials, ask me what may go up. Text and images only unless I say otherwise.
- Use the project's brand colours and fonts if it has them. Support light and dark themes and phone width.
- Add `[hidden]{display:none!important}` to the page's CSS, so an overlay with its own display rule still hides.
- Before handing over, run the page locally with a mocked database and the real data. Open an action panel and test each response type at desktop and phone widths. Tell me plainly what you tested and what you couldn't.
- Save a memory note saying where the board is, how its data is laid out and that it must be kept current, so future sessions maintain it.

INTERVIEW ME FIRST
Before you build anything, look through this project, then ask me these questions in one batch, in plain words, with your recommended answer marked for each. Don't build until I've answered.
1. What is a single tracked item here (feature, ticket, chapter, episode…), and what are the groupings and their names?
2. Which stages does an item go through, and what counts as "done"?
3. Where does status really live (which files, tools or people), and how often should the board be refreshed?
4. Which dates matter: due dates, releases, milestones, demos?
5. What goes on the to-do list, and which items are mine versus Claude's?
6. For each common kind of to-do, what does "taking action" mean: review and approve, decide between options, do something in an outside tool? Which tools should the buttons open?
7. Which materials may be uploaded to the page (and which must stay on my computer)? Is anything confidential?
8. Who will see the board: only me, or a team? (If others will edit it, say what that changes.)
9. Any branding, terminology or layout preferences, and what matters most to see first?
After the interview, summarise the plan in five lines or fewer and wait for my OK.