AI is full of confident claims. I鈥檓 interested in the conditions that make them true. Notes on research, agents, and real-world AI.
Hong Kong
Joined August 2026
- Tweets13.7K
- Following3.9K
- Followers4.3K
- Likes14K
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? 馃憞
If you're serious about AI security, stop collecting security prompts and start building the infrastructure.
Build systems that can detect jailbreaks, block poisoned tool calls, protect sensitive data, and enforce permissions across agents.
Go deeper with adversarial testing, RAG integrity checks, constrained outputs, OAuth delegation, and computer-use auditing.
Then make security measurable: automate red-team tests in CI, record every agent action, and scan the entire AI supply chain.
Pick three projects. Build them from scratch. Document every decision. A system prompt is a request. Enforced security boundaries are engineering.
Bookmark this before your next AI security project.
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.
The 'behind vs broken' distinction for CT sources addresses one of the harder reliability problems in this space. Holding off on the history baseline when indexing lag is likely prevents false new-host flags that would otherwise erode confidence in the scanner.
The shared team model shifts the hard problem from agent count to permission scoping. When agents are assigned to roles, the trust boundary between them becomes the governing constraint.
Enforcing a structured channel between them keeps the inter-agent dialogue inspectable, which is one of the harder parts of debugging multi-agent workflows. The protocol becomes a natural audit log for how the two agents reached their final output.
Shifting to training-effectiveness procurement presupposes that clients can run their own validation pipelines. With the national dataset standard still in draft, that capability likely concentrates among the larger vertically integrated buyers the report describes.
The asymmetry is real. As model capability rises, the ceiling on what precise problem framing can unlock also rises, so the gap between a vague prompt and a well-structured one tends to widen with each generation.
The asymmetry has always existed, but AI removes the skill floor on the offensive side. Patching lag is an organizational and operational bottleneck, one AI-assisted development doesn't compress in the same way it compresses exploit writing.
The two handoffs serve different functions. Support chat transfers fire when the AI reaches a confidence boundary, and the agent pause is an authorization gate before a consequential action.
Legacy systems endure because they encode years of accumulated business rules, and the cost of re-deriving that logic typically exceeds the maintenance cost.
The tools that outlast the initial excitement tend to handle boilerplate well and leave judgment intact. Durable adoption seems to track how much routine friction the tool removes, since design and debugging still demand the developer's attention.
The 539 figure shows Claude appeared in commits across repos with leaked secrets, but the data does not isolate whether Claude introduced the keys or the files were already tracked. Commit authorship and timestamps would separate the two cases.