Category: Thoughts

  • C# .NET Bootcamp

    C# .NET Bootcamp

    Welcome to the C#/.NET Bootcamp. This curriculum is designed to be hands-on and execution-focused. Each section will include links to either a blog post or a GitHub repository—your job is to follow those links, complete the work as instructed, and focus on building real understanding through doing. If something is unclear, don’t move on—pause, investigate, and ask questions. Progress comes from curiosity, ownership, and consistent execution.

    In the era of AI an engineer needs to know OOP, prompting, and systems thinking.

    Weeks

    1. Onboarding and introductions
    2. Dev containers
    3. Contained APIs
    4. API Maturity
  • AI Enablement

    AI Enablement

    The Best Way to Reduce AI Anxiety During AI Onboarding

    A lot of AI adoption fails before it starts because people feel the pressure before they feel the value.

    Engineers worry that coding agents are a threat to their craft. Leaders worry they are falling behind. Everyone hears big promises, but very few teams get a safe, practical space to learn what these tools can actually do. That is where the anxiety comes from.

    If you want voluntary AI adoption, do not start with a mandate. Start with a team exercise.

    This is not a sales pitch. It is not about forcing people to love AI. It is a way to build empathy, learn new workflows together, and give people hands-on experience with coding agents in a setting that feels useful instead of threatening.

    A good place to start is with six simple questions.

    1. Which tools do you use?

    These are your MCPs, integrations, and sources of context.

    Most anxiety gets worse when AI feels vague or magical. It gets better when the team can see the actual tools involved. Which systems can the agent access? Tickets, docs, specs, code, tests, logs, GitHub?

    The more grounded the workflow is, the less scary it feels. People do not need more hype. They need to see the boundaries.

    2. What are your roles?

    These are your sub-agents.

    Not every agent needs to be “the coder.” One may refine tickets. Another may break work into specs. Another may review code, generate tests, or help draft release notes.

    This matters because AI is more approachable when it is framed as support for real roles instead of replacement for real people. Teams can start to see where agents help and where human judgment still leads.

    3. Who do you work with?

    These are your agent teams.

    Software is already a team sport. Engineers work with product, QA, platform, security, design, and leadership. Agentic engineering should reflect that reality.

    When teams map out who works with whom, they often realize something important: AI does not remove collaboration. It makes good collaboration even more important.

    4. What are your skills?

    These are your prompts, playbooks, and reusable workflows.

    Teams that get value from AI usually do not just “prompt better.” They learn better working patterns. They know how to refine a ticket, break work into steps, define acceptance criteria, review generated code, and tighten the feedback loop.

    That is one of the biggest mindset shifts. If humans are responsible for AI-assisted work, then human skill matters more, not less.

    5. What does success look like?

    This is where trust starts to replace fear. How we measure success can’t change.

    Success cannot be measured in LoC (lines of code), token utilization, or increased velocity. If you were measuring success with MAU (monthly active users), NPS (net promoter score), DORA (DevOps Research and Assessment), or dollars you have to keep the measurement or you’ll risk creating a culture of reward hacking.

    Reward hacking is when an AI finds a shortcut to maximize a metric. Engineers will do this too. If you’re rewarding ambitious AI adoption, you may unintentionally foster a culture where your “best employees” are doing whatever the LLMs tell them to.

    6. How will you practice?

    This is the most important question.

    The best way to lower AI anxiety is not another presentation. It is a shared practice session.

    Pick a real ticket. Use a refinement skill to improve the problem statement. Use a work breakdown skill to turn it into specs that get published to GitHub as part of the repo. Open one spec and generate code from it. Have the agent review its own work. Have it test itself with Playwright. Then ship a pull request with a meaningful commit message.

    After that, talk about what happened. What felt useful? What felt awkward? What still needed human judgment? What should change before the next round?

    That conversation is where confidence starts to grow.

    What companies are learning the hard way

    A lot of companies are discovering that AI does not remove the need for strong humans. It exposes where strong humans were already needed.

    Weak requirements are still weak requirements. Bad handoffs are still bad handoffs. Undefined success criteria are still undefined success criteria. AI can accelerate output, but it can also accelerate confusion if the team is not aligned.

    That is why this matters so much. If humans are still responsible for quality, direction, and judgment, then teams need to get better at those things as AI gets more capable.

    That should not create more fear. It should create confidence.

    The real goal

    The goal is not to pressure people into adoption. The goal is to make adoption feel safe, useful, and worth choosing.

    When teams learn together, anxiety goes down. People stop filling in the blanks with fear. Engineers get to see that coding agents are not magic, and not a substitute for thinking. Leaders get a better view of who can work effectively in AI-assisted workflows. Everyone gets a more realistic understanding of what these tools can and cannot do.

    That is how voluntary adoption happens.

    Not from mandates. Not from hype. From practice, trust, and a better feedback loop.

  • If you want to sell your vibe-coded app B2B, you need to know these 10 tools (MCPs)

    If you want to sell your vibe-coded app B2B, you need to know these 10 tools (MCPs)

    I’m still working on this one, but I wanted to share what’s coming. This post will demonstrate MCP installation, use cases, and prompts for the 10 tools you need to know before you try to sell your vibe-coded app B2B.

    My goal is to make it simple enough to follow without losing the bigger picture.

    When it’s done, you’ll be able to set up an agent that can support your product development work.