ML/AI, CV
Stop Doomscrolling. Start Building.
AI is moving fast enough that it can feel impossible to keep up. Every morning there is another model, another benchmark, another agent framework, another coding tool, another company claiming that software development has changed forever.
The natural reaction is to consume more. More X. More LinkedIn. More Hacker News. More YouTube. More release notes.
But knowing everything happening in AI is becoming less valuable than knowing how to use a small part of it well.
The better strategy is simple: stop doomscrolling, start building.
Spend 15-20 minutes a day tracking the AI shift
You don't need three hours of AI news every day. You need enough awareness to understand what is changing.
Spend 15-20 minutes checking:
- important model releases
- new developer tools
- changes in agent frameworks
- useful open-source projects
- new infrastructure patterns
- major changes in cost, latency or capability
Then stop.
The goal isn't to become a real-time AI news feed. It's to identify things that might actually change how you build software.
A new benchmark is interesting. A new capability that eliminates three days of engineering work is useful. Learn to distinguish between the two.
The question that does the filtering
Not "is this impressive?" but "would this remove work I am currently doing by hand?" Almost everything fails the second question, and that is the point - the filter is supposed to reject most of what it sees.
Learn one new thing - then apply it immediately
Reading about technology creates the illusion of progress. Building with it creates understanding.
If you discover a new tool, API or pattern, don't bookmark it into a collection of 400 links you'll never revisit. Build something small.
| If you're learning | Don't read about it - do this |
|---|---|
| MCP | Connect one tool |
| A2A | Make two agents exchange a task |
| Structured outputs | Replace one fragile prompt parser |
| A new coding agent | Give it a small real feature, not a toy example |
| Local models | Run one inside an application |
Several of those have companion posts here if you want the deeper version: MCP gave agents tools, A2A gives agents colleagues for the protocol boundary, the model is not your agent for what a coding agent actually is, and generate one token at a time for running a local model end to end. Read one, then go and build the small thing.
The feedback loop should be:
This is how knowledge compounds. You stop remembering what a technology claims it can do and start understanding what it can actually do.
Build more than you consume
The AI ecosystem currently rewards attention. Every launch wants you to stop what you're doing and investigate it.
But constantly switching tools has a cost. If you rebuild your stack every time a new framework appears, you'll become very good at starting projects and surprisingly bad at finishing them.
A useful rule is that your building time should massively exceed your AI-news time.
If you spend 20 minutes discovering something interesting, spend an hour experimenting with it. If it improves your workflow, keep it. If it doesn't, move on.
You don't need loyalty to tools. You need loyalty to outcomes.
Stay a student, even when you're senior
One of the biggest risks for experienced engineers isn't lack of knowledge. It's becoming too comfortable with existing knowledge.
For years, experience meant knowing which abstraction, architecture or pattern was likely to work. That still matters. But AI is changing some of the assumptions underneath those patterns.
Tasks that once took days can take hours. Interfaces that once required deterministic workflows can sometimes become conversational. Software that once needed dozens of manually implemented integrations can increasingly delegate work to agents and tools.
The answer isn't to throw away engineering fundamentals. It's the opposite. Strong fundamentals plus curiosity is an enormous advantage.
Senior engineers shouldn't compete with juniors on who can type code faster with an AI assistant. Their advantage is knowing what to build and what not to, where AI is trustworthy and where deterministic systems still matter.
Experience becomes more valuable when it stays adaptable.
The comfortable failure mode
It rarely looks like falling behind. It looks like being confident that the way you already build things is still the best way, and never running the small experiment that would tell you otherwise.
Don't try to predict everything
Nobody knows exactly where this is going. Not the vendors. Not the researchers. Not the people posting confident predictions every six hours.
So don't optimise your career around predicting the final form of AI. Optimise for learning velocity.
Be the person who can look at a new capability, understand it quickly, test it against a real problem and decide whether it matters. That skill survives model generations, frameworks and hype cycles.
The developers who thrive through this transition probably won't be the people who read every announcement. They'll be the people who repeatedly turn new capabilities into working systems.
The routine
Keep it simple.
- Track the shift. Twenty minutes, then stop.
- Learn one thing. Not five.
- Build something with it. Small, real, finished.
- Stay a student. Especially when you're senior.
Then do it again tomorrow.