Bobo Lin | AI notes

The biggest risk of AI in software engineering isn't that machines will replace developers. It's that developers will slowly become operators of work they no longer understand. When AI writes the specs, builds the features, creates the tests and explains the results, it's easy to confuse a finished workflow with a solved problem. Code ships, but understanding doesn't. The cost shows up later: bugs nobody can trace, systems nobody can explain, junior engineers who never build fundamentals, and experienced developers who lose the habit of thinking through problems themselves. The engineers who stay valuable won't be the ones who generate the most code. They'll be the ones who can challenge AI's output, understand the architecture, make decisions without a prompt, and know when the result is actually good enough. Use AI to reduce the time spent writing code, not the effort spent understanding it. Speed is useful, but judgment is what keeps software from falling apart. Are you seeing this happen at work too? 👇

The next wave of high-paying AI jobs won't look like traditional software jobs. As AI takes over more routine coding, the demand is shifting toward people who can build agent systems, manage their execution, evaluate their reliability, secure their access, and connect them to real businesses. Some of the emerging roles include Agent Engineers, AI Evaluators, Context Engineers, AI Security Specialists, Forward Deployed Engineers, and AI Infrastructure Engineers. The real shift is that writing code is becoming only one part of the job. Knowing how to direct AI, verify its output, and make it work reliably in production is becoming just as valuable. The opportunity is already taking shape. Start building the skills and projects that prove you can do this before the market catches up.

Claude Code needs more than a good model to work like a senior developer. Give it reusable skills to follow proven workflows, and Context7 to check current documentation instead of guessing from outdated knowledge. Add Graphify to map how your codebase connects, and 21st MCP to turn UI ideas into polished components. Then bring in Strix to find security flaws before they become production problems. Writing code is the easy part. Understanding the system, making good design decisions and securing what you build is what separates a senior developer. Bookmark these tools for your next build.

6 AI startup ideas I'd love to see someone build. I'm not building them myself, so consider this an open invitation. A security watchdog for AI startups. Catch leaked API keys, exposed secrets and risky dependencies before they become incidents. Security shouldn't start after a breach. A trust layer for AI extensions. Show users who audited an extension, when it was checked and what it can access. In an ecosystem full of plugins, trust is becoming a product. A real customer acquisition engine for vibe-coded apps. Find the first 10 paying users, write the outreach, and get payments live. Shipping an app is no longer the hard part. An evaluation platform for AI agents. Turn real failures into test suites, regression reports and public benchmarks. Demos get attention, but reliable results get customers. An AI cost dashboard that makes every dollar accountable. Connect model spend to users, features and prompts so teams know exactly what they're paying for. I'm giving these ideas away. Pick one, build it, and tell me what I'm missing. I'd love to see someone prove there's a business here.

If I wanted to become an Applied AI Engineer, I wouldn't start by collecting prompt tricks. I'd learn how to measure models first: token costs, latency, context limits, structured outputs, and the trade-offs between different providers. Then I'd build the systems around them: context assembly, RAG, model routing, fine-tuning, and agent workflows that can use tools without losing control. But shipping is where the real engineering begins. Evals, regression tests, observability, safety boundaries, fallbacks, and cost attribution are what separate a working demo from a product people can trust. I'd finish by shipping real applications, publishing measurable results, and documenting the decisions behind them. Knowing how to use a model gets you started. Knowing how to make it work reliably is what makes you an engineer. Bookmark and Repost!

Your AI app isn't ready to launch just because it works on your machine. Before going live, make sure your secrets are protected, permissions are enforced on the server, user data is isolated, and every input is validated. One exposed key or missing access check can ruin the launch. Then put limits around the things that can quietly drain your money. Rate-limit your APIs, cap AI spending, monitor errors, and make sure failed requests don't turn into an endless bill. Test the product like a real user would. Use a cheap phone, complete signup and payment, reset a password, check email delivery, and see what happens when something breaks. And have a way back. Back up your database, test the restore, write down how to roll back, and give users a real way to contact you. Launch day is not the time to discover you have no recovery plan. Bookmark this before your next launch. Your first users shouldn't be your QA team.

Stop building agents that only look impressive in demos. The next wave belongs to systems that can use computers, recover from crashes, survive bad tool calls, and resume work without starting over. Your agent needs more than a smart model. It needs durable state, strict permissions, reliable memory, structured tool interfaces, and a way to verify every important action. Stop wasting compute on work that can be cached, stop sending every request to your most expensive model, and stop trusting a green status when the actual task is still incomplete. The wrapper era is fading. Build systems that can execute, recover, prove what they did, and keep working when things go wrong. Bookmark this before building your next agent.

If you want to work at the frontier of AI, learn to build models, not just use them. Understand how models learn, how data shapes their behavior, and how architectures like MoE and state-space models change the way computation works. Knowing the theory is useful, but implementing it from scratch is what makes the knowledge real. Learn to train and align models, build synthetic data pipelines, and understand why a model that performs well in training can still fail in practice. The quality of the data, the training process, and the evaluation matter as much as the architecture. Then learn the systems behind production AI. Distributed training, GPU memory, inference optimization, multimodal fusion, and interpretability are not separate skills. They determine whether your ideas can actually run, scale, and be trusted. Finally, reproduce new papers, publish your experiments, and make your work verifiable. The people who can turn research into working systems, explain what failed, and prove what improved will always have something valuable to offer AI labs. Bookmark this roadmap and build your way into AI Research Engineering.

If you want to work at the frontier of AI, learn to build models, not just use them. Understand how models learn, how data shapes their behavior, and how architectures like MoE and state-space models change the way computation works. Knowing the theory is useful, but implementing it from scratch is what makes the knowledge real. Learn to train and align models, build synthetic data pipelines, and understand why a model that performs well in training can still fail in practice. The quality of the data, the training process, and the evaluation matter as much as the architecture. Then learn the systems behind production AI. Distributed training, GPU memory, inference optimization, multimodal fusion, and interpretability are not separate skills. They determine whether your ideas can actually run, scale, and be trusted. Finally, reproduce new papers, publish your experiments, and make your work verifiable. The people who can turn research into working systems, explain what failed, and prove what improved will always have something valuable to offer AI labs. Bookmark this roadmap and build your way into AI Research Engineering.

If you want your app to feel faster, stop guessing and start fixing the bottlenecks. Find where time is actually being wasted, from slow queries and oversized assets to unnecessary JavaScript and repeated rendering. Make the app do less work, load only what users need, and move expensive tasks out of the critical path. A faster backend means little if the page still feels frozen, so pay attention to loading states and when users can actually interact. Measure before and after every change. Your users won't report a slow app. They'll simply stop coming back. Bookmark this before your next performance cleanup.

The fastest way to waste time vibe coding is to start with an empty folder and a vague idea. Before writing code, give your AI a clear product brief, architecture, design direction, coding rules, task breakdown and progress log. These files turn scattered instructions into a shared plan the AI can actually follow. Without them, every missing decision becomes another guess, another correction and another round of rework. Spend 10 minutes defining the project before spending 10 hours fixing what the AI misunderstood.

Most people think an AI agent is just a chatbot with tools. That's only the surface. An agent needs a model to make decisions, prompts to define its role, memory and context to retain information, and planning to turn goals into steps. It needs tools to interact with the world, RAG and vector search to find relevant information, and reasoning loops to act, check results, and try again. When one agent isn't enough, orchestrators coordinate multiple agents and sub-agents. MCP connects external services, while guardrails and human approval keep actions within boundaries. But none of this matters if you can't tell whether it works. Evals measure performance, observability exposes behavior, and latency and token costs determine whether the system is practical. Chatbots generate answers. Agents operate systems. Bookmark this before building your next agent.

The fastest way to launch an app is also a great way to inherit legal problems. A weekend project can quietly create six different risks: children's privacy, font licensing and data sharing, session recording, marketing emails, subscription renewals, and user-uploaded content. Before going live, check your age gates, consent flows, unsubscribe links, renewal disclosures, and DMCA agent registration. Small implementation details can become expensive compliance problems. Ask Claude to audit these areas, identify what can be fixed in the code, and separate the things that require your own action. Shipping fast is great, but don't let a weekend launch turn into a legal cleanup project. This isn't legal advice; get a lawyer to review your specific situation.

If I had 6 months to break into Agentic AI engineering, I wouldn't spend them collecting certificates or watching endless tutorials. I'd start by learning how to build reliable systems: Python, async execution, APIs, event-driven workflows, and error handling. Then I'd get comfortable with LLMs, context, token costs, tool calling, structured outputs, and memory. Next, I'd build agents that can plan, use tools, recover from errors, and work together. I'd learn where human approval is needed, how to evaluate failures, and how to trace every important decision. Then comes the part most tutorials skip: security, deployment, scaling, monitoring, and recovery in production. An agent that works in a demo is only the beginning. I'd finish by shipping real projects, publishing architecture breakdowns, contributing to open source, and building a portfolio people can actually inspect. Stop studying agents in theory. Build one that survives the real world. (Bookmark it)

If you want to become an Agent Engineer, stop collecting frameworks and start building systems. Build agents that can handle concurrency, manage their own context, recover from failures and coordinate multiple specialized roles. A working demo is easy. Keeping it reliable under real workloads is the hard part. Learn to control what agents can access, execute and spend. Sandboxing, typed tool calls, approval gates and cost limits are not optional extras once agents touch real infrastructure. Make every run observable and testable. Trace tool calls, replay trajectories, compare new versions in shadow mode and turn production failures into regression tests. The next generation of Agent Engineers won't stand out because they know the most frameworks. They'll stand out because they can build systems that remain reliable when things go wrong. Build systems, not demos. Bookmark this before your next agent project.

If I had 6 months to break into GenAI engineering, I wouldn't spend them collecting certificates or watching endless tutorials. I'd learn to build the whole stack, from async Python and multimodal models to RAG, orchestration, and inference infrastructure. Then I'd focus on what separates a demo from a real product: reliable state, strict permissions, cost controls, observability, and recovery when things fail. I'd turn that knowledge into public projects, measurable evaluations, architecture write-ups, and real deployments that people can inspect. The goal isn't to know every AI framework. It's to become someone who can build, debug, and ship AI systems that actually work. Bookmark this roadmap.

Every vibe coder eventually discovers that building a website is the easy part. You ask why Google can't find it, and suddenly you're dealing with rendering, indexing, redirects, canonical URLs, structured data, broken links and Core Web Vitals. Then comes the content work: original writing, real author profiles, useful internal links, image optimization and backlinks people actually trust. You wanted a website that ranks. You accidentally signed up to learn technical SEO, performance engineering and content strategy. Bookmark this checklist, give it to Claude Code, and remember that the last two still need a human.

If you want to stand out as a GenAI Engineer, stop building another chatbot. Build the infrastructure that makes AI work in production. Start with the foundations: streaming gateways, structured output enforcement, multimodal pipelines and local inference. Make models fast, responsive and predictable before adding more intelligence. Then build agents that can survive reality. Give them durable state, reliable orchestration, retrieval that knows when to abstain, and recovery paths that don't repeat failed actions. The real engineering starts with control. Trace every decision, test complete execution trajectories, isolate agent permissions, prevent runaway costs and compare new models without putting live users at risk. Anyone can wrap an API. Build systems that can explain their failures, recover from them and scale under pressure. That's what separates a GenAI demo from production engineering. Bookmark this before building your next AI project.

If you want to build with AI, learn what happens behind the chat window. Start with the basics: LLMs predict tokens, prompts shape their responses, context windows limit what they can see, and inference is what turns a trained model into an actual answer. Latency, temperature and hallucinations matter more than most beginners expect. Then learn how models get better at finding information. Embeddings turn text into vectors, chunking breaks documents into searchable pieces, RAG retrieves relevant context, and reranking decides what deserves attention first. Agents are where things get more interesting. Tool calling, MCP, memory, skills, subagents and orchestration turn a model into a system that can take actions. But guardrails, prompt injection, permissions and human approval determine how safely it can operate. Finally, understand the infrastructure: GPUs, quantization, LoRA, fine-tuning, distillation, caching, rate limits, streaming, evals and benchmarks. These are the things that decide whether your AI project actually works beyond a demo. Bookmark this before your next AI build.

If I had 6 months to become an AI/ML Engineer, I wouldn't waste them collecting certificates or watching endless tutorials. I'd start by learning how models actually work. PyTorch internals, tensor operations, CUDA, attention, memory management and mixed precision. If you can't understand the computation, you'll struggle to optimize it. Then I'd learn how to build and adapt models. Data curation, synthetic data, LoRA, QLoRA, DPO, reward modeling, MoE and multimodal architectures. Not just how to call an API, but how to change the model itself. Next, I'd focus on making models useful in the real world. Distributed training, quantization, KV cache, speculative decoding, vLLM, SGLang, model routing, evaluation and red teaming. Speed means nothing if the system can't deliver reliable results. Finally, I'd build things people can inspect. Reproduce papers, publish fine-tunes, write model cards, run benchmarks and share your work on GitHub and Hugging Face. Watching tutorials makes you familiar with AI. Building and shipping systems makes you an engineer.

Preparing for an AI engineer interview? Knowing how LLMs work won't be enough. You need to explain how agents reason, choose tools, manage memory, retrieve information, and coordinate with other agents. Be ready to design real systems, from customer support and flight booking to multi-agent workflows, with proper permissions and human approval. The real test is what happens when things go wrong: failed tools, prompt injection, hallucinations, infinite loops, rising costs, and millions of users. Anyone can talk about AI. Far fewer can explain how to build, evaluate, debug, and scale systems that actually work. Bookmark this before your next AI engineering interview, and send it to someone preparing for one.