Career Development · PiniShv

The End of Courses: Learn From AI Like a Toddler, Or Become Obsolete

Fri, 24 Apr 2026 10:00:00 +0300

Remember when building an application required months of upfront learning? You’d buy a 40-hour video course, read through documentation, and painstakingly memorize syntax before writing a single line of logic.

Today, an AI agent builds that same application in three minutes from a single prompt.

We’re standing at a massive crossroads. Not just in software development, but in how humans acquire knowledge. And most people haven’t realized yet that the learning model they grew up with just flipped upside down. Theory used to come before practice. Now practice comes first, and theory arrives on demand. That’s a different game. We need to relearn how to learn.

What actually died
#

Let me be precise, because this is the part that gets misread.

Courses didn’t disappear. Books didn’t disappear. The sequence did.

For twenty years the path was the same. Read the book. Buy the 40-hour course. Follow the tutorial. Build the toy project. Then, eventually, attempt something real. Learning was structured, linear, and almost entirely theory-first. That sequence is what broke.

An 8-minute deep-dive on a specific trade-off, delivered exactly when you need it, is actually more valuable than ever. Targeted, just-in-time learning is a superpower. What died is the 40-hour prerequisite. The idea that you have to load all the theory before you’re allowed to attempt anything real. The agent collapsed that runway to zero.

And the data is already catching up to what everyone can feel.

The coding bootcamp industry, the market that turned “learn to code in 12 weeks” into a multi-billion-dollar business, consolidated painfully through 2024 and 2025. Entry-level roles got automated or outsourced. Programs that didn’t rebuild around AI shut down. The survivors pivoted from “teach you to write code” to “teach you to work alongside agents.” On Udemy and Coursera, the courses people actually buy now have to be updated within the last 12 months or they’re teaching deprecated APIs. The half-life of “learned knowledge” collapsed.

But the deeper shift isn’t the market. It’s the cognitive model underneath.

I wrote before that AI didn’t change the work, it changed the sequence. The same thing is happening to learning. You’re no longer supposed to load the theory first and then apply it. You apply first, and the theory arrives on demand, exactly when you need it.

Learning is now intuitive, experiential, and strictly on-the-job.

Learn like a toddler
#

Think about how toddlers learn to speak.

Nobody hands a two-year-old a grammar textbook. They don’t attend a workshop on verb conjugation. They hear words in context, try them, get corrected, try again. They absorb meaning through constant exposure, trial, error, and interaction with their environment. The adult in the loop isn’t delivering lectures. The adult is a patient partner who keeps responding, correcting, and raising the bar.

That’s exactly how we have to work with AI now.

There’s actual learning science behind this. Piaget’s stages of cognitive development put hands-on experience and interaction at the center of how humans build real understanding. A recent Springer paper on developmentally aligned AI argues that AI tools work best when they act as scaffolding, not substitution. Temporary support that strengthens the learner’s internal capacity and is gradually removed as competence grows.

Scaffolding means every time the agent generates something, you engage with it, understand it, and internalize what you didn’t know before. Substitution means the agent does it for you, and next time you need the same thing, you still can’t do it without the agent. Both look identical in the commit history. They feel completely different six months in.

This is the choice hiding in every single prompt.

As agents expose us to new architectures, libraries, frameworks, and design patterns on the fly, we have a choice: we can blindly accept the output, or we can choose to learn from it critically. I choose to learn. I choose to treat the agent, which has access to effectively all the knowledge available in the world, as a sparring partner for deep, on-the-job learning.

A sparring partner is different from a thinking partner. A thinking partner you lean on. A sparring partner pushes back. The first makes you weaker over time. The second makes you stronger. Pick the right one.

The crossroads: Operator vs. Kolboynik Architect
#

Every developer right now is standing at the same fork. Two paths. Very different outcomes.

Path 1: The Operator (accept and ship)
#

You accept exactly what the agent generated. You never interrogate the design. You never ask why this database, this pattern, this trade-off. You optimize for throughput.

Honestly? This is perfectly fine for a while. Nobody expects you to match the agent’s raw output speed or carry its encyclopedic knowledge of every framework. If your only goal is absolute scale (ship more, faster, cheaper), you can craft excellent skill.md files, feed the agent the right instructions, and trust it almost blindly to produce working applications. With a small asterisk, but you get the point.

But here’s the warning. If all you do is operate the AI and accept its outputs, you’re a prompt-runner. And a prompt-runner can, and will, be replaced by a motivated middle-schooler.

This isn’t hyperbole. The “prompt engineer” specialty, which was commanding serious salaries just two years ago, has effectively evaporated as a standalone role. Microsoft’s workforce surveys consistently rank it near the bottom of roles companies plan to add. The reason is brutal: as models got dramatically better at intent resolution, the gap between an “expert prompt” and a “decent prompt” shrank to almost nothing. The specialty evaporated because the skill stopped being scarce. Accepting output isn’t a career. It’s a commodity.

I’ve also written about this danger before: the quiet divide between AI operators (fast with prompts, lost when tools fail) and AI-augmented engineers (fast and capable of reasoning from first principles). Both look identical for six months. The gap between them compounds forever after that.

Path 2: The Kolboynik Architect (critical learning)
#

If you want to stay relevant, you have to shift from coder to “Kolboynik”, the Hebrew term for the ultimate generalist who knows a bit of everything, about everything. Not a master of one domain. A master of connecting domains.

The market is already pricing this shift in. Industry analysis is showing a clear trend: demand for roles spanning multiple domains is climbing, while roles with a single narrow skill cluster are falling. The reason is painfully simple: narrow specialization is exactly what AI replicates most efficiently. Depth in one narrow thing doesn’t make you irreplaceable anymore. It makes you replaceable.

Generalists win because they do the thing agents are still bad at. Synthesizing across ambiguous, contradictory, unstructured problem spaces. Bridging systems. Catching second-order effects. Knowing which question to ask next.

Becoming a Kolboynik doesn’t mean you read every book in the library. It means you treat every agent output as a doorway into a new domain you now need to understand just enough to judge. Instead of treating the AI’s output as the finish line, you treat it as the starting point for a deep conversation.

Don’t dive into the lines of code. Zoom out.

Question the design. Why did the agent choose this specific database structure? What alternatives did it silently reject? What would fail at 10x scale?
Challenge the constraints. Ask it about security vulnerabilities, edge cases, cloud costs, compliance implications. Make it show its work.
Interrogate the defaults. Every framework choice is an opinion. Every pattern comes with a cost. If you can’t articulate the trade-off, you don’t understand what shipped.
Guide the process. The agent knows it should write tests. Reminding it sets the standard. Over time, it learns that test coverage is a non-negotiable part of what “done” means on your team.

This deep-dive conversation will probably take longer than the agent took to write the code in the first place. And that is exactly the point. You are the human in the loop, bringing judgment, context, and critical thinking to the table. Everything else got cheap. Judgment is the only thing still scarce.

The cost of skipping the conversation
#

Here’s what the data says about developers who skip the deep-dive and just accept output.

A 2025 MIT Media Lab study found students using AI assistants showed measurably decreased neural engagement and less ownership over their work. Anthropic ran a randomized trial where developers learning a new library with AI scored 17 percentage points lower on mastery than those who learned without it. The biggest gap was in debugging. The one skill you most need when AI-generated code breaks.

More recent research has given this pattern names. Comprehension debt is the gap between how much code you’ve shipped and how much you actually understand. Cognitive debt is the gradual degradation of your team’s problem-solving capability from disuse. Intent debt is the loss of documented rationale in code and commits. The “why” that goes missing when the prompt is the only record.

A 2026 paper on cognitive offloading in agile teams found that AI-only planning significantly degraded risk capture rates. The teams performing best had a hybrid pattern: let AI do estimation and formatting, but require human deliberation for risk assessment and ambiguity resolution. The “boring” cognitive work is exactly the work you can’t offload.

And on the perception side, the numbers keep embarrassing us. Developers feel about 20% faster with AI. Objective measurement shows many of them are actually slower. I’ve referenced METR’s experienced-developer study before: 20% perceived speedup, 19% measured slowdown. The feeling is real. The feeling is wrong.

Karpathy, who literally hasn’t typed a line of code since December 2025, is the clearest voice on what replaces typing. Not passivity. Direction, taste, judgment, oversight, iteration. His own work on MicroGPT was explicitly designed “to demystify the algorithm so both humans and future agents can understand and extend it.” Even the person farthest along the agent curve is obsessed with understanding, not acceptance.

The developers who will compound in value over the next five years aren’t the ones shipping the most agent output. They’re the ones who, for every shipped feature, can also tell you exactly why it exists, what it costs, where it breaks, and what it looked like before they pushed back on the agent’s first answer.

What critical learning looks like in practice
#

This isn’t abstract. It’s a set of small habits you either have or you don’t.

Pause after every accepted suggestion. Before merging an agent’s output, ask yourself one question: if the agent disappeared tomorrow, could I modify this confidently? If no, you haven’t learned anything from this PR. You just shipped borrowed knowledge.

Turn every unfamiliar pattern into a 10-minute tangent. The agent used an event-sourced pattern you’ve never seen? Stop. Ask it to explain why. Ask for two alternatives it considered. Ask for the trade-offs. Ten minutes of critical conversation now beats a 40-hour course later that you’ll never take.

Ask for the rejected options. “What did you consider before choosing this?” is the single highest-leverage prompt I use. It forces the model to expose trade-off space that it otherwise collapses into a confident recommendation.

Argue with the model on purpose. Even when it’s probably right. Especially when it’s probably right. The act of constructing a counter-argument is where your understanding actually forms. A sparring-partner workflow beats a thinking-partner workflow every time, for exactly this reason.

Keep a “things I didn’t know yesterday” log. One file. One line per learning. Review it weekly. It’s the cheapest learning system you’ll ever run, and it’s the closest replacement we have for the structured curriculum that just died.

Re-derive the answer without the model occasionally. The AI-off hours idea I wrote about earlier applies to learning, not just execution. Your mental models don’t build themselves. They atrophy unless you use them.

If that sounds slower than just shipping the agent’s output, it is. By design. Slower code path, faster growth curve. You’re choosing to invest the difference, not spend it.

The big picture
#

We’re past the era where your value was measured by execution speed. Execution is the cheap part now. Generation is the cheap part. First drafts are free.

Your value is now determined by your ability to connect the dots, see the big picture, and deeply understand how systems behave together. It’s determined by the questions you choose to ask, the constraints you choose to enforce, and the second-order effects you choose to catch before they ship. The industry calls this being an AI Architect Programmer. I still prefer Kolboynik. Same idea. Less buzzword.

The good news is better than the bad news
#

Here’s the part I want you to sit with, because it’s easy to miss under all the doom.

The barrier to becoming the best engineer you’ve ever been just collapsed.

Every architectural debate you used to need a senior colleague for? You can have it right now, unlimited, at 2 AM, at whatever depth you want. Every pattern you never got to work on because your team didn’t use it? You can build it, study it, and break it tonight. Every paper, every book, every framework you meant to read? You can now interrogate them chapter by chapter, with the author’s ideas pushed against your specific codebase, in your own words, at your own pace.

The agent is the best teacher any of us have ever had access to. Infinite patience. Infinite availability. Knowledge of every framework, paper, and pattern humanity has written down. No ego. No bad day. It will happily explain the same concept seven different ways until one of them lands.

The only thing it can’t do is decide to learn. That part is still on you. And if you decide to, the growth curve is steeper than anything that came before. Slower code path, faster growth curve. You were never in a better position to become a serious engineer than you are right now. That’s not hype. That’s the actual deal on the table in 2026.

So stop buying 40-hour courses you’ll never finish. Stop pretending that another passive video is the missing piece. The next “thing” ships in three minutes from someone else’s prompt. Your edge isn’t in consuming more theory. It’s in how deeply you engage with what’s already landing in your PRs every single day.

Stop learning syntax. Start learning architecture. The agent has all the answers. You are the only one who knows which questions to ask.

Which path are you on, Operator or Kolboynik? And what’s the last thing the agent taught you that you couldn’t have Googled? Find me on X, Telegram, or LinkedIn. I’d genuinely like to hear it.

Disclaimer: This article references specific studies, surveys, and public commentary for illustrative and educational purposes, including work from Anthropic, METR, MIT Media Lab, Microsoft Research, arXiv preprints, Andrej Karpathy, and industry analyses available at the time of writing. I have not independently verified all claims. The analysis and opinions expressed are my own. I have no financial interest, business relationship, or affiliation with any companies or tools mentioned. This is commentary, not investment, legal, career, or business advice.

Have You Seen All These OpenAI Blueprints? What the Heck Are They Doing, and Why Is (or Isn't) Your Country In?

Sat, 25 Oct 2025 00:00:00 +0000

Hey folks, it’s Pini here. If you’ve been following my writing on how AI is reshaping dev workflows, like in When AI Writes 90% of Your Code or The Magic Behind AI IDEs, you know I’m all about the practical side of this tech revolution. But lately, something bigger caught my eye: OpenAI dropping these “economic blueprints” left and right.

It’s like they’re not content with just building killer models. Now they’re advising entire countries on how to supercharge their economies with AI. As a dev leader, this isn’t just news. It’s a signal for where our careers are headed. Let’s dive in, story style, because who doesn’t love a good yarn about global AI dominance?

The Plot Twist You Didn’t See Coming
#

Picture this: You’re Dan, a 35 year old Israeli software engineer grinding away in a Tel Aviv startup. You’re knee deep in Python, tweaking APIs for an AI health app, and pondering why your fine tuning loop is eating all your GPU hours. During a quick LinkedIn scroll (procrastination, anyone?), you spot it: “OpenAI unveils economic blueprint for Japan. Projected to add 100 trillion yen to GDP.”

Wait, what? OpenAI as economic consultants?

Then you see blueprints for South Korea, Australia, the EU, and the US. It feels like a plot twist in a sci fi novel, but it’s October 2025, and it’s our reality.

What’s Actually Happening Here
#

So, what’s the deal? OpenAI isn’t just peddling ChatGPT anymore. They’re positioning themselves as architects of a global AI economy. These blueprints are detailed policy roadmaps released throughout 2025 that lay out how governments can integrate AI for massive growth.

Think investments in compute power, green energy, data infrastructure, and reskilling programs. The why? To evangelize their tech, snag partnerships (Samsung in Korea, Mercedes in Germany), and set the AI standard worldwide. As OpenAI puts it in their global affairs docs, it’s about “expanding economic opportunities” and turning AI into a “time compression engine” for innovation.

For Dan (and you), this hits close to home.

The US Blueprint: Infrastructure on Steroids
#

Take the US blueprint: It calls for a “National AI Infrastructure Highway” with $175 billion pumped into data centers, chips, and even nuclear fusion for energy. This isn’t abstract. It means more jobs in AI research, defense, and security.

If you’re building secure systems (echoing my Securing Intelligence series), imagine red teaming for national scale AI. The defense and intelligence sectors will need people who understand both AI systems and security architectures at scale.

Europe: Tripling Down on Compute
#

Over in the EU, they’re pushing to triple compute capacity by 2030, with a €1 billion fund for pilots and training for 100 million folks. Free multilingual courses? That’s a boon for devs everywhere, but it ramps up competition. Suddenly, everyone’s prompt engineering like pros.

The EU approach is interesting because it’s balancing AI adoption with their existing regulatory framework. They want the economic benefits without sacrificing their values around privacy and safety. For developers, this means opportunities in building compliant AI systems that work within strict regulatory boundaries.

Asia: Where Things Get Really Interesting
#

Asia’s where the story gets juicy. Japan’s blueprint promises a 16% GDP boost through “watt bit collaboration” (fancy talk for pairing energy with compute). Picture AI robots optimizing factories, diagnosing diseases, or tutoring kids. The integration opportunities are massive.

South Korea’s even more dev relevant: The “Stargate” project with Samsung and SK ramps up chip production and data centers, blending sovereign AI with OpenAI collaboration. For industries like manufacturing (smart shipyards) or healthcare (AI diagnostics), this spells demand for integration experts.

Dan, who’s battled sovereign model builds, sees the upside: More gigs embedding AI, but watch out. Big players could squeeze startups. When you’re competing for talent and resources against Samsung backed AI initiatives, the landscape shifts dramatically.

Australia: The Practical AI Approach
#

Australia’s “10 point plan” focuses on national training and tax breaks for decentralized infrastructure. It’s practical AI for farmers, governments, and educators. Think ChatGPT Edu for personalized learning, tying into tools like AI Agents for Real Productivity.

What I like about Australia’s approach is the focus on immediate, practical applications. They’re not trying to win the AI race. They’re trying to make AI useful for their specific needs. That’s actually a smart strategy for countries that aren’t AI superpowers.

France and Germany: The European Hubs
#

Don’t forget France and Germany: OpenAI’s new offices there (Paris and Munich) foster ties with Sanofi for health AI or Zalando for retail. It’s all under their safety umbrella, like EU pacts and collaborations with US, UK, and Canadian AI institutes. Perfect if you’re into Prompt Injection 2.0 defenses.

The European offices signal something important: OpenAI is adapting to regional needs rather than pushing a one size fits all approach. For developers, this means more opportunities for specialized, localized AI work.

The Million Shekel Question: Why Your Country In (or Out)?
#

Now, the million shekel question: Why your country in (or out)? OpenAI targeted spots with strong foundations. Chips in Korea, regulations in Europe, massive markets in the US and Japan. They’re building alliances, fending off rivals (hello, China), and influencing policy.

Israel? No blueprint yet. We’re AI beasts already (Mobileye, anyone?), but Dan wonders if we’re missing the boat.

OpenAI’s “Academy” trains millions with free certifications and work platforms. If we hop in, expect jobs in sovereign AI, security, or agriculture and health integrations. Skip it, and you’re hustling solo in a global race, as I warn in I’m Pro AI. That’s Exactly Why I’m Worried About Our Next Senior Engineers.

The reality is that these blueprints create network effects. Countries that get in early benefit from the infrastructure investments, training programs, and partnerships. Countries that wait might find themselves playing catch up with less favorable terms.

What This Means for Your Career
#

Here’s where this gets practical. These blueprints aren’t just policy documents. They’re roadmaps for where AI investment is flowing. And where investment flows, jobs follow.

For developers: The demand is shifting from generic full stack work to specialized AI integration. You need to understand not just how to build features, but how to embed AI safely, securely, and in compliance with regional regulations.

For CEOs: Your leadership need to understand the geopolitical landscape of AI. Where is compute located? What regulations apply? Which partnerships create opportunities or constraints? This isn’t abstract policy. It’s the environment your products will operate in.

For everyone: The “post work” shift isn’t about AI replacing jobs. It’s about AI changing what work means. Less grunt work, more strategy. But only if the infrastructure is in place. These blueprints are about building that infrastructure.

The Competition Is Real
#

One thing that strikes me about these blueprints: they’re competitive. OpenAI is making bets on which countries will win the AI race, and they’re helping their chosen partners build advantages.

If you’re in a country with a blueprint, you have access to training, infrastructure, and partnerships that others don’t. If you’re not, you’re working harder for less leverage.

For individual developers, this means thinking strategically about where you build your career. The AI job market isn’t going to be evenly distributed. It’s going to cluster around the hubs that these blueprints help create.

What You Should Actually Do
#

As developers and dev leaders, here’s my practical advice:

Level up your skills. Dive into prompt engineering, spin up GPT projects (check my Build Your First AI Agent This Week guide), grab those certifications. The training infrastructure is being built. Use it.

Understand the policy landscape. You don’t need to be a policy expert, but you should understand the regulatory environment your AI systems will operate in. This is especially true if you’re building for multiple markets.

Think about infrastructure. These blueprints are all about compute, energy, and data infrastructure. Understanding these constraints will make you a better architect. AI isn’t just software. It’s software that needs massive infrastructure to run.

Build for compliance. As these blueprints get implemented, compliance requirements will tighten. Security, privacy, and safety won’t be optional. They’ll be table stakes. If you’re already thinking about securing AI systems, you’re ahead of the curve.

Watch the partnerships. Samsung in Korea, Mercedes in Germany, Sanofi in France. These partnerships signal where industry specific AI work will concentrate. If your expertise aligns with these sectors, opportunities are coming.

The Israeli Angle
#

As someone who’s spent 15+ years building in Israeli tech, I can’t help but wonder about our position in all this. We have incredible AI talent, world class universities, and a thriving startup ecosystem. But we don’t have a blueprint.

Is that a problem? Maybe. Maybe not.

On one hand, we’re small and agile. We don’t need massive government programs to innovate. Our startup culture means we can move fast without bureaucracy.

On the other hand, these blueprints bring resources, infrastructure, and international partnerships. They create ecosystems, not just individual companies. That’s harder to replicate through startups alone.

My guess? We’ll see some kind of initiative soon. The government knows we can’t afford to sit out the AI race. But it might look different from these blueprints. More focused on security and specialized applications, less on broad economic transformation.

The Uneven Reality
#

All of this ties back to something I wrote about in The Uneven Reality of AI Adoption. AI adoption isn’t happening evenly across companies or countries. These blueprints will accelerate that unevenness.

Countries with blueprints get infrastructure, training, and partnerships. Countries without them rely on organic adoption. The gap will widen.

For developers, this creates both opportunities and challenges. Opportunities if you’re positioned to take advantage of the infrastructure being built. Challenges if you’re competing against people who have access to better resources.

The Bottom Line
#

OpenAI’s blueprints aren’t just about selling their technology. They’re about shaping the global AI landscape in their favor. They’re picking winners, building alliances, and creating the infrastructure that will determine which countries thrive in the AI era.

For engineers and tech companies, this matters because it determines where opportunities will be, what skills will be valuable, and what infrastructure you can rely on.

This isn’t just about code anymore. It’s about understanding the bigger picture. The geopolitical landscape, the infrastructure constraints, the regulatory environment, and the competitive dynamics.

Will Israel join? Fingers crossed. It’s not just code. It’s our future.

What do you think? Is your country on the list? Does it matter? Drop your thoughts below. Let’s chat.

Read the Blueprints Yourself
#

Want to dig deeper? Here are the actual OpenAI blueprint documents:

Global Overview:

OpenAI’s Economic Blueprint (Global framework)
Expanding Economic Opportunity with AI

Regional Blueprints:

Country Offices and Partnerships:

Related: For more on AI’s economic impact and career implications, see What’s Holding You Back from Succeeding in the AI Era.

When AI Writes 90% of Your Code, What Are You Actually Doing?

Fri, 17 Oct 2025 00:00:00 +0000

At the Salesforce Dreamforce conference last week, Anthropic CEO Dario Amodei dropped a number that’s been making waves: “I made this prediction that, you know, in six months, 90% of code would be written by AI models. Some people think that prediction is wrong, but within Anthropic and within a number of companies that we work with, that is absolutely true now.”

Ninety percent. That’s not a demo. That’s how one of the world’s leading AI companies actually builds software today.

The immediate reaction: developers are done, engineering teams will shrink, why hire software engineers when AI can write the code?

But when Salesforce CEO Marc Benioff asked if that means Anthropic needs fewer engineers now, Amodei’s answer was the opposite of what people expect.

The 10% That Actually Matters
#

Amodei was clear: “If Claude is writing 90% of the code, what that means, usually, is, you need just as many software engineers. You might need more, because they can then be more leverage. They can focus on the 10% that’s editing the code or writing the 10% that’s the hardest, or supervising a group of AI models. And so what happens is, you know, you just end up being 10 times more productive.”

Ninety percent AI-written code doesn’t mean fewer developers. It means developers doing fundamentally different work.

This isn’t about replacement. It’s about “rebalancing,” as Amodei put it. The job is changing to focus on what actually requires human judgment.

I’ve been saying this for months, and this statement from someone at the bleeding edge confirms what I’ve been seeing: writing code was never the bottleneck. Understanding what to build, how to architect it, and how to guide AI safely were always the hard parts. AI just made that reality impossible to ignore.

What Does That 10% Actually Include?
#

When AI writes 90% of your code, what are you doing with your time?

You’re making architectural decisions that ripple across the entire system. You’re catching edge cases that AI misses. You’re supervising the AI’s output architecturally. Does this approach scale? Is this secure? Does this follow our patterns? You’re debugging the weird stuff when production behavior doesn’t make sense. You’re making trade-off decisions based on business context, team capabilities, and long-term strategy.

This is what I wrote about in hiring developers in the age of AI: the developers who thrive aren’t the ones who can write code fastest. They’re the ones with systems thinking, architectural reasoning, and problem decomposition skills.

The Productivity Multiplier Nobody Talks About
#

Here’s what gets lost in the “AI will replace developers” narrative: if your developers can be 10 times more productive, you don’t need one-tenth the headcount. You build 10 times as much with the same team.

The companies winning aren’t firing developers. They’re building faster than competitors while others argue about whether AI is good enough. But this only works if your developers can actually operate at that level, with deep systems understanding and architectural thinking.

I wrote about this pattern in what’s holding you back from succeeding in the AI era. The developer I called Marcus shipped 247 commits in a month using AI. Impressive numbers. But when I asked him to explain the architecture of a feature he’d shipped, he couldn’t. Three days later, production incident. He’d implemented decisions he didn’t understand.

Marcus isn’t alone. This is the risk nobody’s talking about when they celebrate AI writing 90% of code.

The Divide Between AI Operators and AI-Augmented Engineers
#

Not all developers are getting 10x more productive with AI. Some are getting 10x faster at shipping code they don’t understand.

The ones succeeding use AI to accelerate work they already know how to do. They recognize when AI suggestions are headed down the wrong path and can evaluate trade-offs without running the code. They’re using AI as a thinking partner for implementation while they focus on design and edge cases.

The ones struggling use AI as a crutch for things they never learned properly. They can ship fast but can’t debug what they shipped because they never built the mental models.

This is what I meant when I wrote about being pro-AI while worried about our next senior engineers. The gap between these two types of developers is widening fast. The scary part? They can have nearly identical output metrics for six months. The difference only becomes obvious when things break.

What This Means for Engineering Teams
#

If Anthropic needs the same number of engineers (or more) even with 90% AI-generated code, what should engineering leaders be doing differently?

Stop optimizing for typing speed. Invest in architectural skills and systems thinking. Create oversight mechanisms that review architectural decisions, not individual lines. Measure production incidents per feature, not commit counts. Develop deep expertise in distributed systems, security, and architecture.

This aligns with what I wrote about AI security being a culture problem. You can have the best AI tools, but if your culture treats “works on my machine” as good enough, you’ll have problems.

The Junior Developer Problem
#

If AI writes 90% of code today, how do junior developers build the expertise to be valuable tomorrow?

The teams doing it right are being extremely intentional. Junior developers don’t just accept AI output. They’re required to explain architectural decisions, walk through how features handle edge cases, and defend trade-offs. They use AI to move faster, but must understand everything they ship.

The teams doing it wrong measure productivity by output volume. Junior developers prompt AI, ship code, move to the next ticket. Fast velocity, zero learning.

Six months from now, the first group will have developers who can architect features independently. The second group will have “AI operators” who panic when AI fails.

What About The Other 10%?
#

Amodei said 90% of code is AI-written “for most teams at Anthropic.” Not all teams. That 10% human-written code isn’t random. It’s the hardest stuff: novel algorithms, performance-critical paths, security-sensitive logic, the architectural foundation everything else builds on.

That 10% is where all the leverage comes from. Get that 10% right, and AI can generate the other 90% reliably. Get it wrong, and you’re building on a broken foundation.

This matches what I’ve seen with developer work not changing, just the sequence. The actual job didn’t disappear. What changed is when those activities happen and how much implementation detail developers handle personally.

The Uncomfortable Truth for Developers
#

If you’re a developer whose primary value was writing clean, working code quickly, you’re in trouble. That skill is being commoditized right now.

If your value is understanding complex systems, architecting for scale, catching subtle bugs, making informed trade-offs, and guiding AI to produce maintainable solutions, you’re more valuable than ever.

The uncomfortable part: many developers thought they were the second type, but were actually the first. AI is exposing that gap brutally.

The good news: these skills can be learned. But you have to be intentional. You won’t build them by accident while prompting AI to generate features.

Rebalancing, Not Replacing
#

Amodei’s point about “rebalancing” is the right frame. The work didn’t disappear. It shifted.

Less time writing boilerplate, more time on architecture. Less time debugging syntax errors, more time designing systems that are debuggable. Less time on mechanical tasks, more time on judgment calls.

This is a better job. More interesting, more impactful, more creative. But only if you have the skills to operate at that level.

What Comes Next
#

I keep coming back to something I wrote in from toys to tools: most developer time isn’t typing, it’s understanding. AI writing 90% of code doesn’t eliminate that understanding requirement. If anything, it makes it more critical.

The winning developers aren’t the ones who resist AI or blindly trust it. They’re the ones who use AI to handle implementation details while they focus on the parts that actually require human judgment.

That’s what Amodei is describing. That’s what I’m seeing in successful teams. And that’s where software development is headed.

The question isn’t whether AI will write most of your code. It already does at leading companies, and the rest will follow within months.

The question is whether you’re building the skills to be valuable in that world. To operate at the architectural level. To guide AI effectively. To catch the edge cases. To make the trade-offs. To be the 10% that makes the 90% possible.

Because that’s the job now.

What's Holding You Back from Succeeding in the AI Era?

Wed, 01 Oct 2025 00:00:00 +0000

I’ve been experimenting with AI in development teams. Some experiments have gone well. Developers shipping faster, workflows getting streamlined, genuine productivity gains. Others… not so much. I’m still figuring this out, honestly, but I keep running into patterns that concern me.

Last week, something happened that crystallized these concerns.

A developer I know (let’s call him Marcus) was excited to show me his GitHub stats. Impressive numbers: 247 commits in a month, 23 features shipped, velocity charts trending up. His manager was thrilled. Out of curiosity, I asked him to walk me through the architecture of a feature he’d shipped recently. Simple question: “Why did you structure the caching layer this way?”

He paused. Then admitted he wasn’t sure. The AI had suggested it. It worked. He shipped it. Three days later, that feature caused a production incident. Forty minutes of downtime. Significant revenue impact. All because he’d implemented architecture decisions he didn’t fully understand.

Marcus isn’t failing because AI isn’t good enough. He’s failing because he’s gotten really good at using AI without building the judgment to evaluate what it produces.

This got me thinking about something I’m noticing more often. Not that AI will replace developers (I don’t think that’s the real risk), but that we might be accidentally creating developers who move fast but think shallow, and managers who confuse speed with capability. The numbers are striking: by 2028, 90% of enterprise software engineers will likely be using AI code assistants, up from less than 14% in early 2024. Yet 77% of engineering leaders see integrating AI as a major challenge.

Maybe the issue isn’t AI itself. Maybe it’s that AI amplifies whatever approach you already have. If you think deeply about problems, AI helps you think faster. If you don’t… well, AI helps you not-think faster too.

I’m starting to see a pattern in how this plays out, and I think it’s worth sharing what I’ve noticed.

The Great Divide: Marcus vs. Sarah
#

We’re accidentally creating a divide. Not between people who use AI and people who don’t, but between those who let AI carry them and those who use it to leap forward.

Marcus represents the first group. There’s another developer I’ll call Sarah who seems to represent the second. Same company, similar experience level, both use AI heavily. But when I asked Sarah the same architecture question, she didn’t just answer. She walked me through her reasoning: the trade-offs she’d considered, why she’d rejected the AI’s first two suggestions (one would have created a memory leak under load, the other couldn’t scale horizontally), what she’d validated before shipping, and what monitoring she’d added because she knew this approach had specific failure modes under network latency.

Sarah’s velocity? Nearly identical to Marcus’s. But Sarah’s code doesn’t cause incidents. When it does break (because all code eventually breaks) she diagnoses it in minutes, not hours. She’s using AI to move faster, but her understanding of systems architecture is actually deepening. She treats AI as a thinking partner that suggests solutions, which she then stress-tests against her mental model of how distributed systems behave.

The difference between them isn’t talent. It’s approach. Marcus accepts AI suggestions that look good on the surface. Sarah interrogates them. Marcus ships fast. Sarah ships right. Marcus is becoming dependent. Sarah is becoming more capable.

And here’s what makes this dangerous: for the first six months, they look identical on paper. Same velocity, same feature throughput, same commit frequency. The difference only emerges when systems hit scale, when architectural decisions made months ago come home to roost. By then, Marcus has shipped dozens of features built on shaky foundations, and the technical debt is crushing.

The Self-Deception Patterns
#

Beyond the Marcus/Sarah divide, I’m noticing three patterns that seem to lead to struggles:

The Resisters refuse to engage with AI at all. I know a brilliant engineer who was convinced Copilot would “rot their brain.” Six months later, they were frustrated and behind, trying to catch up with tools they didn’t understand while everyone else had already learned to use them thoughtfully.

The Checkbox Adopters use AI just enough to say they’re using it. They’ll accept a Copilot suggestion here and there, maybe prompt ChatGPT when really stuck, but fundamentally they’re doing things the old way with a thin veneer of AI adoption. They think this is a safe middle ground. It’s actually the worst of both worlds. They’re not building deep AI collaboration skills because they’re not truly engaging. And they’re not building deep foundational skills because they’re using AI as a crutch for the things they don’t want to learn properly.

Meanwhile, the AI world makes huge leaps forward monthly. Not yearly. Monthly. If you learned Copilot in 2023 and called it done, you’re falling behind while convincing yourself you’re staying current. The gap between you and people actively learning these tools isn’t just widening. It’s compounding like interest you can’t afford.

The Manager’s Blind Spot might be the most concerning. I’m hearing more managers wonder if they still need developers at all. AI can write code, ship features, fix bugs. Why keep investing in expensive engineering talent when AI does it faster and cheaper?

I think this is a dangerous miscalculation. They do still need developers. Desperately. But they need a fundamentally different kind. They need developers who can see the whole picture, who can challenge AI when it’s wrong, who understand both the product vision and the code architecture deeply enough to orchestrate AI effectively.

From Privates to Generals
#

Think about it this way: if AI can write the code, you don’t need code writers anymore. You need generals who can command an AI army.

I mean this literally. In military terms, a private follows orders and executes tasks. A general orchestrates entire campaigns: seeing the terrain, understanding the objective, marshaling resources, adapting to changing conditions, and making strategic decisions that ripple across the entire operation.

That’s what developers need to become. Someone who can define the business problem, set architectural constraints, establish quality bars, plan rollout strategy, and then marshal multiple AI tools to execute on that vision while maintaining coherence across the system. Someone who spots when the AI is headed down the wrong path, not because they read every line of generated code, but because they understand the system deeply enough to catch the architectural smell.

The private-to-general shift isn’t about seniority. It’s about thinking level. I’ve seen 25-year-old developers who think like generals and 45-year-old senior engineers who still think like privates. The generals understand systems, trade-offs, second-order effects. The privates understand syntax.

Most managers are still hiring and evaluating for privates while wondering why their team can’t handle complexity. They’re measuring lines of code, tickets closed, features shipped (all private-level metrics). They should be measuring systems thinking, architectural coherence, the ability to spot when AI suggestions don’t fit the bigger picture, and the judgment to maintain quality at AI-augmented speed.

The Invisible Barriers
#

From what I’ve observed working with teams going through this transition, there seem to be five core barriers:

The Fundamentals Gap: I’ve interviewed developers who learned to code entirely in the AI era. They’ve never written a hundred lines without Copilot running. They can ship features fast, but they can’t debug when the AI steers them wrong because they’re missing the mental models that tell you when something smells off. It’s like someone who learned to navigate exclusively with GPS suddenly needing to read a map and orient themselves by landmarks. The skill atrophied before it fully developed.

The Management Gap: When AI handles syntax, what remains is collaboration, problem decomposition, and creative solutions to ambiguous problems. But many engineering managers rose through the ranks by being excellent individual contributors. They know how to review a pull request, but not how to review someone’s AI collaboration process. They can spot a memory leak, but they can’t spot a team that’s becoming dependent on tools that mask their fundamental skill gaps.

The Ethics and Security Blind Spot: Bias in AI-generated code isn’t just a headline. I’ve heard about recommendation algorithms that worked perfectly in testing but systematically disadvantaged certain user groups in production because the training data was skewed. Data privacy leaks happen when someone prompts ChatGPT with actual customer data to debug an issue, and suddenly proprietary information is in OpenAI’s training corpus. These risks are real and can be project killers.

The Burnout Nobody Saw Coming: I know a developer (call him Jason) who went from energized to exhausted in several months of heavy AI use. He wasn’t working more hours. But the cognitive load was crushing him. Before AI, natural breaks were built into his workflow: write code, get stuck, think through the problem, research solutions. With AI, the suggestions come instantly. The code appears. The tests pass. The features ship. There’s no natural stopping point. Jason told me: “I used to finish a feature and feel done. Now I finish a feature and immediately have three AI-generated options for the next one waiting for review. I’m not coding more, but I’m deciding constantly. My brain never gets to rest.” The pressure isn’t about hours anymore. It’s about attention.

The Skill Gap: AI won’t make engineers obsolete. It’ll automate the repetitive work and free you for complex problem-solving. But only if you develop those complex problem-solving skills. If you spend all your time prompting and none of your time learning fundamentals, you’re not building a career. You’re becoming an AI operator. And when the AI gets better, what value do you bring?

What Works for Managers
#

If you lead a team or a group, you’re in the position to shape how AI gets adopted. But first, get honest with yourself about what you actually need. You don’t need a team that can write code faster. You need a team of AI generals.

Here’s what seems to be working from what I’ve observed:

Institute AI literacy training, but make it real. I suggest to a team to try “fundamentals Fridays.” For two hours every Friday afternoon, no AI tools. Period. They work through algorithm problems from scratch, debug performance issues with just a profiler and their understanding of systems, and review code the old-fashioned way. The first few weeks, developers hated it. Three months in, something shifted. They started catching subtle bugs in AI-generated code they would have missed before. They became the team’s quality gatekeepers, not because they rejected AI, but because they could evaluate it critically. Meanwhile, I know about teams that went all-in on AI without fundamentals training having much higher incident rates and senior engineer burnout.

Set KPIs around quality, not just speed. Track code review depth. Measure incident resolution time and root cause quality. Monitor technical debt accumulation. If you only measure velocity, you’ll get velocity at the cost of everything else that matters.

Prioritize soft skills development. Run exercises where developers explain AI outputs in plain English to non-technical stakeholders. If they can’t explain why the AI suggested an approach, they probably shouldn’t ship it.

Implement ethical guidelines before you need them. Create clear policies for AI use: what data can go into prompts, what outputs require human review, how to audit for bias, what the security boundaries are. We want those teams that are avoiding serious incidents not because they got lucky, but because they’ve thought through the risks ahead of time.

Promote work-life balance aggressively. Enforce no-AI-after-hours rules if you need to. Set clear boundaries to prevent the 24/7 treadmill. Burnout destroys teams slowly, then all at once.

Invest in upskilling with real budget and real time. McKinsey’s research highlights that AI accelerates innovation in software development, but only with skilled teams. Make continuous learning part of the job, not something people do on weekends.

What Works for Developers
#

If you’re a developer, you have more control over your trajectory than you might think. Don’t wait for your company to figure this out. Take ownership of your growth.

Master the fundamentals alongside the tools. Spend time every week coding without AI. Implement algorithms from scratch. Debug performance issues using only profiling tools and your understanding of systems. This feels inefficient in the moment. You could ship faster with Copilot. But this is the time investment that makes you valuable. When you’re the person in the room who can debug the AI’s output, who can spot architectural problems before they ship, who can make trade-offs that the model can’t understand, that’s when you become indispensable.

Stay actively current, not passively aware. The AI landscape moves at a pace I’ve never seen before in my career. What’s cutting-edge this month is table stakes next month. One way to stay up to date is to follow me - I regularly share insights about new AI developments and how they impact software development. Beyond that, learn one new AI-related skill or tool every month, minimum. Not just surface-level “I tried it once.” Actually integrate it into your workflow and understand its strengths and limitations. Read about what’s working in production. Try new models when they drop. Understand what changes when context windows expand from 200K to 1M tokens. Stop lying to yourself that minimal engagement is enough. The gap is widening monthly.

Hone your soft skills deliberately. This isn’t fluffy advice. It’s career-critical. Join every code review you can. Present your work to the team regularly. Practice explaining technical decisions to non-technical people. Work on your writing. Clear documentation is a superpower in an AI-augmented world. AI can’t replace your storytelling. It can’t replicate your ability to build consensus, to read the room, to know when to push an idea and when to let it go.

Stay ethical and secure by default. Always validate AI outputs for bias and security implications. Make it a habit. Study real cases of AI projects that failed, not to be scared, but to learn the patterns of what goes wrong. When you’re prompting, be paranoid about what data you’re including.

Manage your time and energy like the finite resources they are. Track your productivity not just in features shipped, but in energy levels and work satisfaction. When you notice the treadmill speeding up, push back. The fastest way to stall your career is to burn out and need many months to recover.

The Uncomfortable Truth About What Comes Next
#

Remember Marcus and Sarah from the beginning? Same tools, same company, similar experience. One caused a six-figure production incident. The other is becoming a more capable engineer every week.

The gap between them isn’t widening linearly. It’s widening exponentially.

One year from now, Marcus will be even more dependent on AI because that’s the only way he knows how to work. When the AI fails (and it will, because all tools fail) he’ll be stuck. When his manager finally realizes he’s been shipping fast but shallow, his career trajectory will have already calcified.

Sarah will be leading architecture discussions. She’ll be mentoring other developers on how to use AI effectively. She’ll be the person who gets pulled into critical incidents because she can diagnose systemic problems, not just fix symptoms. She’ll be positioned for the next level of responsibility because she’s demonstrated judgment, not just velocity.

The market is already splitting, and it’s splitting fast. There are developers who think deeply, paired with AI that moves fast. There are managers who lead boldly, building teams that thrive because of AI, not despite it. These people are pulling ahead at a pace that would have seemed impossible five years ago. They’re not working longer hours. They’re working with deeper understanding and sharper judgment.

Then there are people getting left behind, not because they’re not using AI, but because they’re using it wrong. They’re over-relying without building foundations. They’re resisting out of fear. They’re engaging halfway and calling it done. They look productive today, but they’re accumulating a debt (technical, intellectual, professional) that will come due in ways they don’t yet understand.

McKinsey’s 2025 outlook shows that AI’s impact grows when combined with human ingenuity, not when it replaces it. The differentiator isn’t whether you use AI. By 2028, everyone will. The differentiator is whether you use it as a boost or a crutch. Whether you’re becoming more capable or more dependent. Whether you’re building judgment or eroding it.

Your Move
#

Marcus can still become Sarah. Sarah could still become Marcus if she gets lazy. The trajectory isn’t fixed, but it’s compounding, and the gap widens every month.

If you’re a manager: Your job right now is to build teams of generals, not privates. That means investing in skills deliberately, setting boundaries aggressively, creating psychological safety for experimentation, and holding quality bars even when it’s easier to ship fast and sloppy. It means measuring the right things: systems thinking, architectural coherence, AI collaboration effectiveness, judgment under pressure.

If you’re a developer: Your job is to become someone who elevates AI, not someone who’s elevated by it. That means mastering fundamentals while learning tools. Staying actively current, not passively aware. Building soft skills that AI can’t replicate. Maintaining the judgment that separates generals from privates. Treating AI as a thinking partner, not an autopilot.

The AI era isn’t about surviving. It’s about succeeding. The people who succeed will be the ones who overcome these barriers deliberately, who build both their AI collaboration skills and their independent judgment in parallel, who understand that velocity without understanding is just speed toward the cliff.

Six months from now, you’ll either be further ahead or further behind than you are today. The compounding has already started. The question isn’t whether the AI era is here. It’s whether you’ll be one of the people who define it or one of the people left wondering what happened.

So here’s my question for you: Which path are you choosing today?

Not tomorrow. Not when you have more time. Not when things settle down. Today.

What’s your first step?

The gap between teams that successfully navigate the AI transition and those that struggle often comes down to intentional strategy around skill development and quality standards. If you’re wrestling with how to build AI-augmented teams that maintain deep engineering capability, I’m always up for a conversation.

Model Context Protocol: The Missing Connection Between AI and Your Real Work

Tue, 30 Sep 2025 00:00:00 +0000

Your AI coding assistant can write impressive code. But it can’t read your company’s database schema, your internal documentation, or your production logs. It doesn’t know your team’s conventions, your deployment workflows, or why that weird workaround exists in the payment service.

This is the context gap. And it’s why AI tools feel powerful in demos but limited in real work.

The Model Context Protocol (MCP) is changing that. Not with better models or smarter prompts, but by standardizing how AI connects to the actual systems where your work lives.

Here’s what you need to know, what you can do today, and why this matters more than most AI announcements.

The problem MCP solves
#

AI assistants live in a bubble. They see what you show them: the current file, maybe the conversation history, perhaps a few documentation snippets you paste in.

What they don’t see:

Your database tables and relationships
Your API schemas and internal services
Your Git history and commit patterns
Your company’s documentation and decision records
Your production metrics and error logs
Your team’s code conventions and architectural patterns

Every time you switch contexts, you’re starting over. The AI has to relearn. You spend time explaining things it should already know.

The traditional solution: Build custom integrations. Write a plugin that connects Claude to your database. Write another for ChatGPT. Another for Cursor. Maintain them all as things change.

This doesn’t scale. Three AI tools, five data sources, fifteen custom integrations. Then a new AI tool launches and you start over.

MCP solves this by standardizing the connection layer. Build once, use everywhere.

What MCP actually does
#

MCP is an open protocol that lets AI applications connect to three types of capabilities:

1. Resources (what AI can read)

Your databases, files, documentation, APIs. Anything that provides context the AI needs to understand your work.

Example: Your database exposes its schema as an MCP resource. Now Claude can see your table structure without you pasting it into the chat.

2. Tools (what AI can do)

Search operations, API calls, data queries, workflow triggers. Actions the AI can take on your behalf.

Example: A search tool lets the AI query your documentation. A database tool lets it run read-only queries. A Git tool lets it analyze commit history.

3. Prompts (how AI should think)

Templated workflows for specific tasks. Structured ways to guide AI behavior for your team’s common patterns.

Example: A code review prompt that includes your team’s specific conventions. An incident analysis prompt that knows your logging structure.

Understanding the architecture (if you’ve built APIs, you’ll get this)
#

If you’ve worked with REST APIs, MCP will feel familiar. It’s the same pattern applied to AI integrations.

REST API thinking:

Server exposes endpoints (GET /users, POST /orders)
Client makes requests to those endpoints
Standard protocol (HTTP) means any client can talk to any server
Authentication and authorization control access

MCP thinking:

Server exposes resources, tools, and prompts
Client (AI application) discovers and uses those capabilities
Standard protocol (JSON-RPC) means any MCP client can talk to any MCP server
Host (container for the AI) enforces permissions and approval

The three-layer architecture
#

1. Server (your systems)

The MCP server wraps your existing systems and exposes them through a standard interface. This is like building a REST API for your database, except instead of HTTP endpoints, you’re exposing MCP resources and tools.

Example: Your PostgreSQL database gets an MCP server that exposes:

Resources: schema definitions, table structures
Tools: query execution (read-only to start)
Prompts: common analysis patterns your team uses

2. Client (the connection layer)

The MCP client sits between the AI and the servers. It discovers what’s available, routes requests, and handles responses. Think of it like an API gateway, but for AI integrations.

The client handles:

Connection management to multiple servers
Capability negotiation (what does this server support?)
Message routing and response handling
Security boundaries enforcement

3. Host (the orchestrator)

The host is the container that manages everything. It controls which servers the AI can access, enforces approval flows for sensitive operations, and mediates access to the AI model itself.

This is the security and policy layer. Even if a server offers dangerous tools, the host can require explicit user approval before the AI can invoke them.

How it compares to other integration patterns
#

Like REST APIs:

Standard protocol that anyone can implement
Server/client architecture with clear separation
Discoverability (list available endpoints/resources)
Stateless individual operations, stateful sessions

Like GraphQL:

Clients can discover the schema (what’s available)
Type-safe interactions with JSON Schema validation
Flexible queries for exactly what you need

Like OAuth:

Explicit permission and consent flows
Scoped access to resources
User remains in control of what AI can access

Unlike traditional APIs:

Bidirectional communication (servers can request things from clients)
Built-in support for streaming responses
Designed specifically for AI-to-system integration
Security model assumes untrusted AI behavior

The transport layer (how data moves)
#

MCP uses two primary transports:

stdio (standard input/output): For local processes. The MCP server runs on your machine, communicates through stdin/stdout. Simplest and most secure for desktop applications. This is how Claude Desktop connects to local servers.

Streamable HTTP: For remote servers. JSON-RPC over HTTP with server-sent events for streaming. Use this when you need team-wide access to a server or want to deploy servers in the cloud.

Why this matters: Start with stdio (local, simple, secure). Move to HTTP when you need remote access or horizontal scaling.

The protocol is simple (intentionally)
#

MCP uses JSON-RPC 2.0. If you’ve worked with JSON APIs, the message format will look familiar:

{
 "jsonrpc": "2.0",
 "method": "resources/list",
 "id": 1
}

The simplicity is deliberate. Easy to implement, easy to debug, easy to extend.

Why this architecture works
#

Separation of concerns: Servers don’t need to know about AI models. AI applications don’t need to know about your database internals. The protocol is the contract between them.

Composability: One AI application can connect to multiple servers. One server can serve multiple clients. Mix and match based on needs.

Security boundaries: Servers are isolated from each other. The host enforces what the AI can access. Sensitive operations require explicit approval.

Ecosystem effects: When everyone builds to the same protocol, servers become reusable assets. Your PostgreSQL MCP server works with Claude, ChatGPT, and Gemini. Build once, benefit everywhere.

How to start using MCP today
#

This is the important part. You don’t need to build MCP servers to benefit from MCP. Start by using what exists.

Step 1: Install an MCP-compatible client
#

Claude Desktop is the easiest starting point. Download it, and you already have an MCP client ready to go.

Cursor supports MCP through Claude Desktop integration. If you’re using Cursor for coding, this path makes sense.

Other options: Zed, Windsurf, and Sourcegraph Cody all support MCP. Pick the tool you already use.

Step 2: Add your first MCP server
#

Start simple. The filesystem server lets Claude read your local files.

What this gives you: Instead of copying and pasting code into Claude, you can say “read the authentication module and suggest improvements.” Claude accesses the file directly, sees the full context, and gives better answers.

Five minute setup:

Install the filesystem MCP server
Configure Claude Desktop to use it
Point it at your project directory
Now Claude can read your actual codebase

Step 3: Connect to your databases
#

The PostgreSQL MCP server (and similar for other databases) exposes your schema and enables read-only queries.

What this changes: You can ask “show me all users who signed up in the last week but haven’t completed onboarding” and Claude queries your database directly. No copy-paste, no context switching.

The right way to do this: Start with read-only access. Use environment variables for credentials. Test on development databases first.

Step 4: Add Git context
#

The Git MCP server exposes repository history, branches, and diffs.

What becomes possible: “Analyze the last ten commits to the payment service and summarize what changed.” Claude reads the actual Git log and gives you a coherent summary.

Step 5: Connect to your tools
#

Existing MCP servers cover Google Drive, Slack, GitHub, Postgres, and more. The MCP Registry (in preview) is where you find community servers.

Pick what matters to your workflow. Documentation? Customer data? Production metrics? Connect the systems where your context lives.

What changes when AI has real context
#

This isn’t just convenience. It’s a fundamental shift in how you work with AI.

From manual context to automatic context
#

Before: You spend five minutes explaining your database structure, pasting schema definitions, copying relevant code into the chat.

After: Claude already sees your schema. You skip straight to the actual question.

The compounding effect: Over dozens of interactions per day, you save hours of context-gathering work.

From shallow answers to deep understanding
#

Before: AI suggests generic solutions because it doesn’t know your actual constraints and patterns.

After: AI sees how your team actually structures code, what conventions you follow, what trade-offs you’ve made. Suggestions are specific to your reality.

The quality shift: Fewer “that won’t work here” moments. More “that actually fits our architecture.”

From single-turn to multi-step workflows
#

Before: Every task is a new conversation. AI has no memory of what you’re working on or why.

After: AI can follow multi-step workflows that span files, systems, and contexts. It remembers the goal and carries it forward.

Example: “Analyze the performance metrics for the API, identify the slow endpoints, check the database queries for those endpoints, and suggest optimizations based on our actual schema.”

That’s four different context sources (metrics, API code, database, schema) orchestrated into one coherent workflow.

When to start building your own MCP servers
#

Once you’ve used MCP and see the value, you’ll spot the gaps. Systems specific to your company. Internal tools that don’t have public MCP servers. Workflows unique to your team.

That’s when you build.

The right first server to build
#

Your internal documentation. If you have Confluence, Notion, or internal wikis, an MCP server that exposes them as resources solves an immediate problem.

What it enables: Developers can ask AI questions about your internal systems and get answers sourced from your actual docs. No more hunting through wiki pages.

Technical complexity: Low. Resources are read-only, security is straightforward, and the value is immediate.

The second server: your APIs
#

Expose your internal API schemas and enable AI to understand how services connect.

What becomes possible: “Show me how to call the user service to update preferences” gets a response based on your actual API, not generic examples.

The integration pattern: Start with read-only schema exposure. Add safe test operations. Never expose production-write operations without explicit approval flows.

Building with the official SDKs
#

Official SDKs exist for TypeScript, Python, Java, Kotlin, C#, Go, PHP, Ruby, Rust, and Swift. Pick your stack and start.

The architecture is simple:

Expose resources through resources/list and resources/read
Declare tools through tools/list and handle calls through tools/call
Define prompts that guide AI behavior for your specific use cases

Use the MCP Inspector to test your server. Connect to it, browse resources, invoke tools, see what the AI sees. Essential for debugging.

Security patterns that matter
#

1. Start local, go remote carefully

Local servers (stdio transport) are simpler and more secure. They run on the developer’s machine with their permissions.

Remote servers (HTTP transport) enable team-wide access but require proper authentication, authorization, and audit logging.

2. Read-only first, mutations later

Resources are safe. Tools that modify data are not. Start with exposure, add write operations only when you have proper approval flows.

3. Never trust inputs

Validate everything. Use JSON Schema for tool parameters. Sanitize inputs. Assume the AI might be tricked into sending malicious requests.

4. Handle credentials properly

Environment variables for development. OS keychains for local desktop apps. Proper secret management for remote servers. Never in code, never in logs.

Why OpenAI and Google adopted this so fast
#

MCP launched in November 2024 from Anthropic. By March 2025, OpenAI adopted it. By April, Google announced support.

When competing AI companies agree on a standard in months, not years, pay attention.

The reason: Everyone faces the same integration problem. Claude needs to connect to databases. ChatGPT needs to connect to databases. Gemini needs to connect to databases.

The old approach: Build custom connectors for each AI tool and each data source. Multiplication of effort.

The MCP approach: Build one server that exposes your database through a standard protocol. Every MCP-compatible AI tool can use it immediately.

The ecosystem effect: As more tools adopt MCP, every MCP server you build becomes more valuable. As more servers exist, every AI tool that adopts MCP becomes more useful.

This is infrastructure-level network effects.

What this enables that wasn’t possible before
#

The real shift isn’t about making current work easier. It’s about making new patterns possible.

Contextual code review
#

AI that reviews code with full access to:

Your architecture decision records
Previous similar changes and their outcomes
Production metrics for affected services
Team conventions and style guides

This isn’t generic linting. It’s review that understands your actual system and suggests improvements based on what you’ve learned, not what’s theoretically best.

Predictive debugging
#

When an error occurs, AI with MCP access can:

Read the error logs from your monitoring system
Analyze the relevant code with full repository context
Check similar past incidents and their resolutions
Query the database state at the time of the error
Suggest fixes based on your actual patterns

From hours to minutes. The context gathering that used to take most of the debugging time happens automatically.

Architectural coherence
#

AI that can enforce architectural patterns by:

Seeing your actual service boundaries and dependencies
Understanding the intent behind your design decisions
Catching violations as they’re written, not in review
Suggesting alternatives that fit your established patterns

This moves from reactive to proactive. Instead of fixing architectural drift, you prevent it.

Knowledge continuity
#

When a developer leaves or moves teams, their context doesn’t disappear if it’s encoded in MCP servers. The AI has the same access to systems, docs, and patterns.

Onboarding acceleration: New developers get answers sourced from actual systems, not just wikis that might be outdated.

For managers: the strategic opportunity
#

If you’re leading a team or organization, MCP represents more than a technical standard. It’s a forcing function for better infrastructure.

The immediate productivity play
#

Week 1: Install Claude Desktop for your team. Add filesystem and Git MCP servers. Developers can now ask AI about your actual codebase.

Week 2-4: Add database MCP servers (read-only, development instances). Connect to internal documentation.

Month 2: Measure time saved on context gathering, debugging, and code review.

The ROI is quick and measurable. Developers spend less time hunting for context and more time solving problems.

The platform investment
#

MCP forces you to think about your systems as APIs. What should be exposed? What’s the right level of abstraction? What are the security boundaries?

This work pays dividends beyond AI. Better-defined interfaces, clearer boundaries, improved documentation. You get organizational clarity whether or not MCP becomes the dominant standard.

The competitive positioning
#

AI adoption is uneven across teams. The constraint isn’t model quality, it’s integration with real work.

Teams with good MCP infrastructure can use AI effectively. Teams without it are stuck with generic, context-free interactions.

This creates meaningful differentiation in productivity, quality, and velocity.

The talent development angle
#

Engineers who understand how to build, secure, and scale MCP integrations are developing valuable skills.

This is infrastructure-level knowledge that transfers across companies. It’s not framework-specific or company-specific. It’s fundamental to how AI connects to systems.

Investing in team education here compounds. These skills become more valuable as the ecosystem matures.

The broader pattern: context is infrastructure
#

MCP is part of a larger shift. AI isn’t just about better models. It’s about better connections between models and the systems where work happens.

We’re moving from:

Isolated AI interactions to connected workflows
Generic suggestions to context-specific guidance
Manual context gathering to automatic context access
Single-turn conversations to multi-step orchestration

This is the infrastructure layer for AI-native development. Just like REST APIs became infrastructure for web services, MCP is becoming infrastructure for AI integration.

The companies and teams that recognize this early and build the right connective tissue will have a sustained advantage.

What comes next
#

Near-term (Q4 2025):

MCP 1.0 spec release (November 25, 2025)
Wider IDE integration as standard feature
Improved tooling for building and testing servers
Enterprise adoption at scale

Medium-term (2026):

MCP becomes expected, not optional
Security and compliance frameworks mature
Performance optimizations and caching patterns
Vertical-specific server ecosystems emerge

Long-term trend: AI context shifts from “what you paste in the chat” to “what the AI has access to through proper integrations.”

The quality of AI assistance becomes proportional to the quality of your MCP infrastructure.

For developers: the career angle
#

What’s valuable right now:

Understanding how to use existing MCP servers effectively
Building servers for gaps in your team’s workflow
Implementing security patterns correctly
Designing integrations that scale

What becomes valuable:

Deep expertise in MCP architecture and best practices
Domain-specific integration knowledge (healthcare, finance, etc.)
Platform-level thinking about how AI connects to systems
Security and compliance for AI integrations

The skill combination that matters: Understanding both AI capabilities and production systems. How to give AI the right context without compromising security. How to design integrations that teams actually use.

This is infrastructure work. It’s less flashy than training models but more durable and more broadly applicable.

Start now, build as you go
#

If you’re a developer:

Install Claude Desktop this week
Add filesystem and Git servers to your workflow
Notice where you still need to manually provide context
Build MCP servers for those gaps
Share what you build with your team

If you’re a manager:

Set up MCP infrastructure for your team this month
Measure time saved on context gathering
Identify team-specific systems that need servers
Invest in building those integrations
Make MCP literacy part of onboarding

The best time to start was six months ago when MCP launched. The second best time is today.

The teams that move now will have compound advantages as the ecosystem matures. Not because they predicted the future, but because they built the infrastructure that makes AI actually useful for real work.

Get started:

The gap between AI demos and AI productivity is context. MCP is how you close it.

I'm Pro-AI. That's Exactly Why I'm Worried About Our Next Senior Engineers

Thu, 18 Sep 2025 00:00:00 +0000

I’m the person inside my company who pushes AI. I run pilots, set policies, and cheer when a team ships twice as fast with a good copilot. I’m not a doomer. But I keep bumping into a hard question that’s keeping some people up at night:

What happens to the next generation of senior engineers if AI eats all the work that used to grow them?

This question hits differently depending on where you sit. If you’re an engineering manager, you might have junior developers on your team right now who are impressively good with AI tools but struggle when those tools fail. If you’re a junior developer, you might wonder how to stand out in a world where everyone can prompt their way to working code.

Both of you are facing the same challenge: in a world of AI-assisted development, how do you build (or grow) engineers who can think beyond the tool?

The real problem: AI operators vs. AI-augmented engineers
#

Here’s what I’m seeing across teams: we’re accidentally creating two types of junior developers.

Type 1: AI Operators - They’re fast with prompts, great at stitching together tool outputs, and can ship features quickly. But they struggle when the AI is wrong, when context is missing, or when they need to debug something the model has never seen.

Type 2: AI-Augmented Engineers - They use AI aggressively but maintain the ability to reason from first principles. When the copilot fails, they don’t panic—they switch to manual mode and solve the problem.

Guess which type becomes your next senior engineer?

The difference isn’t talent—it’s how they learned to work with AI. The first group learned with AI as a teacher; the second learned with AI as a tool.

For Engineering Managers: Growing AI-Augmented Engineers
#

If you manage junior developers, you have the power to shape which type they become. Here’s your playbook:

Design “AI-off hours”
#

Block out 2-3 hours per week where your juniors solve problems without AI assistance. Yes, they’ll be slower. That’s the point. They’re building mental models they’ll need when the AI is wrong or unavailable.

Example: Give them a bug that requires reading logs, tracing execution, and writing a fix from scratch. No copilot, no ChatGPT. Just them, the debugger, and their brain.

Create critical-thinking exercises
#

Present two plausible AI-generated solutions to the same problem. Ask your junior to pick one and defend their choice with tests, performance metrics, and trade-off analysis.

Why this works: You’re not testing their ability to prompt—you’re testing their ability to evaluate, which is what senior engineers do all day.

Make AI transparency mandatory
#

In code reviews, ask juniors to include their prompts and explain their verification process. Don’t just review the code—review how they worked with the AI.

Questions to ask: “How did you validate this suggestion?” “What did you do when the first attempt didn’t work?” “How confident are you that this handles edge cases?”

Rotate “first-principles on-call”
#

When systems break, give juniors the first shot at diagnosing (with a senior on backup). They need to learn how to read logs, trace problems, and write clear incident reports without AI assistance.

Pair AI-natives with domain veterans
#

Your best senior engineer might not prompt as smoothly as your junior, but they know every edge case in your system. Pair them. The junior learns context; the senior learns tools.

For Junior Developers: How to Stand Out
#

If you’re a junior developer, here’s how to differentiate yourself from the crowd of AI operators:

Build your “no-AI” skills
#

Spend time every week solving problems without AI assistance. Pick small challenges: write a sorting algorithm by hand, debug a performance issue using only profiling tools, trace through a complex codebase to understand how data flows.

Why this matters: When you’re the only person in the room who can debug the AI’s output, you become indispensable.

Learn to evaluate AI output critically
#

Don’t just accept what the AI gives you. Ask: “Is this the best approach?” “What are the trade-offs?” “How would this perform at scale?” “What happens if this assumption is wrong?”

Practice exercise: Take an AI-generated solution and try to break it. Write tests that expose its weaknesses. Then improve it.

Become an AI transparency expert
#

Document your AI workflows. Show your manager not just what you built, but how you used AI to build it, what you validated, and where you made decisions the AI couldn’t make.

Career benefit: This demonstrates judgment, not just tool proficiency. Judgment is what gets you promoted.

Volunteer for “AI-unfriendly” tasks
#

When something breaks at 2 AM and the AI doesn’t understand your legacy system, volunteer to dive in. When there’s a gnarly performance issue that requires deep system knowledge, raise your hand.

The pattern: While others rely on AI for everything, you become the person who can work when AI can’t help.

Study the fundamentals
#

AI can’t replace understanding of data structures, algorithms, system design, and debugging. Invest time in these foundations. They’re your differentiator in a world of prompt engineers.

Ask senior engineers about their “pre-AI” war stories
#

How did they debug race conditions? How did they optimize that critical query? How did they design that tricky API? Learn from their mental models, not just their code.

The uncomfortable truth about career paths
#

Here’s what I tell the junior developers I mentor: the market is about to be flooded with people who can use AI tools effectively. That’s not special anymore—it’s table stakes.

What’s rare (and valuable) is someone who can use AI tools effectively and think independently when those tools fail. Someone who can prompt well and code well without prompts. Someone who can ship fast with AI and debug deep problems when AI can’t help.

That person is your future senior engineer. The question is: are you building that person, or are you just building better AI operators?

The bottom line
#

I’m not anti-AI—I’m pro-expertise. The future belongs to engineers who can harness AI’s speed while maintaining their ability to think, debug, and solve problems independently.

If you’re a manager, you have the power to shape this. Design deliberate learning experiences. Protect the struggle that builds judgment. Review not just what your juniors build, but how they think through problems.

If you’re a junior developer, the opportunity is enormous. While others become fluent in prompting, become fluent in fundamentals. While others depend on AI, learn to evaluate it. While others panic when tools fail, become the person who steps up and solves the problem.

The market will soon be flooded with AI operators. Don’t be one of them. Be the AI-augmented engineer your future self will thank you for becoming.

Career Development · PiniShv

The End of Courses: Learn From AI Like a Toddler, Or Become Obsolete

What actually died #

Learn like a toddler #

The crossroads: Operator vs. Kolboynik Architect #

Path 1: The Operator (accept and ship) #

Path 2: The Kolboynik Architect (critical learning) #

The cost of skipping the conversation #

What critical learning looks like in practice #

The big picture #

The good news is better than the bad news #

Have You Seen All These OpenAI Blueprints? What the Heck Are They Doing, and Why Is (or Isn't) Your Country In?

The Plot Twist You Didn’t See Coming #

What’s Actually Happening Here #

The US Blueprint: Infrastructure on Steroids #

Europe: Tripling Down on Compute #

Asia: Where Things Get Really Interesting #

Australia: The Practical AI Approach #

France and Germany: The European Hubs #

The Million Shekel Question: Why Your Country In (or Out)? #

What This Means for Your Career #

The Competition Is Real #

What You Should Actually Do #

The Israeli Angle #

The Uneven Reality #

The Bottom Line #

Read the Blueprints Yourself #

When AI Writes 90% of Your Code, What Are You Actually Doing?

The 10% That Actually Matters #

What Does That 10% Actually Include? #

The Productivity Multiplier Nobody Talks About #

The Divide Between AI Operators and AI-Augmented Engineers #

What This Means for Engineering Teams #

The Junior Developer Problem #

What About The Other 10%? #

The Uncomfortable Truth for Developers #

Rebalancing, Not Replacing #

What Comes Next #

What's Holding You Back from Succeeding in the AI Era?

The Great Divide: Marcus vs. Sarah #

The Self-Deception Patterns #

From Privates to Generals #

The Invisible Barriers #

What Works for Managers #

What Works for Developers #

The Uncomfortable Truth About What Comes Next #

Your Move #