The 5 skills that matter when AI writes the code

My team and I had been working on a software product for about six months when we realized we needed a full rebuild. New codebase, new architecture, and the core logic in a new programming language, Rust. I had never written a single line of Rust in my life. I'm the Python guy. That's what I've been doing for 10 years.

Two weeks later, I had personally rebuilt the entire desktop application in Rust. It works. It runs better than the previous version. And I didn't write a single line of code myself. AI wrote all of it.

The ironic part is that the only time I tried to manually interfere with the codebase, I introduced bugs, like you always do when you write code by hand. That was the moment I realized I'm genuinely past the point of writing code by hand. It's no longer the most effective way for me to work.

If you're being honest with yourself, you're probably experiencing something similar. The 30-minute code tutorial you used to watch is now a single prompt. The documentation you used to work through now goes into Claude Code as a URL, and it does the work for you. A lot of developers feel this shift without knowing what to do with it yet. This post skips the prompt techniques and the tool tutorials and covers the five deeper skills that keep you competitive as an engineer when AI handles the implementation.

The implementation bottleneck is gone

For over three decades, the bottleneck of software was implementation, turning ideas into functioning code. That's why coding tutorials exist. That's why you followed those bootcamps and spent years mastering a language or framework. Building was the hard part.

That bottleneck is now gone. And when you remove it, something interesting happens. The things that used to be filed under soft skills, or under responsibilities reserved for senior engineers, become the actual hard skills. Effective communication, critical thinking, system design, architecture. Those now determine whether you ship something great or whether it falls apart.

Think in building blocks, not lines of code

You don't need to understand your codebase at the line level anymore. You do need to understand it at the component level. That means knowing what the building blocks of your system are, how they connect, how data flows from one block to the next, and what happens when one of them fails.

This is systems thinking, and it's what made the Rust project possible. I didn't need to know Rust syntax. I needed to understand how data moves from the backend to the frontend, which components the application needs, and how to wire them together. That understanding is what I gave to AI, and AI turned it into a working codebase.

When I say I don't write code anymore, I don't mean I'm purely vibe coding. I'm very much involved in the process, constantly reviewing the work from an architectural and component level, because I know what good looks like at the system level.

If you want to get better at this, read Designing Data-Intensive Applications by Martin Kleppmann. It's probably the most recommended system design book out there, for a reason. It won't teach you how to write code. It teaches you how to think about data flows, failure modes, and tradeoffs when designing systems. That's the thinking you need.

Practically, before jumping into any project with AI, research the architectural patterns for the type of application you're building and the languages you're using. Then don't tell the AI to build you an app. Tell it what the system should look like.

Go full stack

You need to become a full stack engineer. Seriously. This may sound controversial, but think it through. If AI can work in any language and any framework, being a hyper-specialist who can only do one thing becomes a liability. If you can only do frontend, or only data pipelines, or only backend, you become the bottleneck in a system where AI can work 24/7.

AI doesn't need to wait for a frontend developer to deliver before the project moves forward. It can do frontend, databases, and backend all at the same time, with multiple agents in parallel. But it needs someone who understands the full picture to direct and govern it. That someone needs to be you, or someone else will step in.

The Rust project was the perfect example. I'd never written a line of Rust, but I knew what the database looked like and what type of backend we were using. Because of that, I could connect everything together and guide the AI through it.

This doesn't mean becoming an expert at everything. That's impossible. You need to be comfortable enough to direct AI across the full stack, and you can only do that if you understand how all the pieces fit together. Which brings us back to building blocks.

I'd challenge you to pick a language you've never used before and give yourself a week to build and deploy an end-to-end solution. Not a tutorial. An actual project that solves a real problem in your work or life right now. Local development, database, deploy to a server, CI/CD. Make it work. You'll quickly find the language barrier is gone. What matters is the system understanding.

Your communication is now the code

This is the skill most people still underestimate. We used to write code to give the computer instructions. Now we talk to a model, the model writes the code, and the code instructs the computer. We've created a higher abstraction layer. When you direct AI, natural language is the programming language.

The quality of your code output is directly proportional to the clarity of your input. Vague instructions get you vague code. Precise, well-structured descriptions of what you want and why get you significantly better output. Same model, completely different results. The difference is how you communicate. It's the same principle that drives context engineering for AI agents. What you put in determines what you get out.

One practical change made a real difference in how I work. I'm a big fan of speech-to-text apps. You press a single button, start talking, and the text appears on screen. When I speak instead of type, I structure my thoughts more clearly because I have to say them out loud, so my prompts and context get better. It's also a lot faster. This takes practice, but if you're not using a speech-to-text app yet, download one and start talking to your AI instead of typing.

GenAI Accelerator

The gap between a demo and production

Anyone can wire up an LLM call. The real skill is designing, evaluating, and shipping systems that hold up.

See Curriculum

Plan big, then ruthlessly simplify

What separates the professionals from the vibe coders is how good you are at maintaining a simple, clean codebase. AI has a tendency to output a lot of tokens, to bloat, to create AI slop. Left unchecked, you end up spending more time debugging than you gained by using AI in the first place.

This happens because most people don't have a process or a loop. They produce, they accept, they move on. The loop I follow is to start big picture, create a plan, build it, test it, then simplify. Ruthlessly. The simplification step is the one most people skip, and it's where I spend most of my time.

In that step I'm checking which lines of code and which components we can remove while still passing the tests. I ask AI about best practices and let it do research. I question naming conventions, code structure, even file structures and names. You get a smaller, cleaner codebase that's easier to maintain. You also start to understand it from first principles, down to the core building blocks where removing anything breaks the system. That's where I like my codebases to be.

To get better at this, pick a recent project and run these prompts on it. Ask AI to refactor and simplify. Ask how to reduce lines of code. Question the project structure and the naming conventions. See if you can break it down to the most fundamental building blocks you understand, while stripping out the bloat that AI probably introduced.

Testing is non-negotiable

Testing, testing, testing. If you ask AI to write tests for you, be careful, because AI is often overly optimistic. It writes some tests, declares everything passing, and you find out it mocked pretty much everything it was supposed to test.

So get familiar with the testing frameworks for the projects and languages you work with. Spend time understanding how they work, how to structure tests, and the differences between the types of tests you need to run. Then look online for a testing skill you can put into your project, so AI creates real tests instead of blindly trusting mocks.

Think critically about what could really go wrong and which edge cases you want covered. There's a simple exercise you can do today. Pick a project you're working on or recently worked on, look at the tests it has, understand them, add more, and figure out how to run them automatically in your CI/CD pipeline.

Next step

Pick one of the exercises and do it this week, whether that's the one-week build in a language you've never used, the simplification pass on a recent project, or the test audit. Each one trains the judgment that AI can't supply.

These five skills are the career layer of a bigger shift in how software gets built. For the engineering side of that shift, start with the hub on how to build production AI systems. And once you're comfortable directing AI on single projects, the next level is building a full AI operating system for yourself, your company, or your clients. I share how I'm building mine in how to build your own AI platform.

The full story, including the Rust rebuild, is in the original video, I stopped writing code, these 5 skills are all that matter.

FAQ

Do developers still need to learn how to code?

You need to read and understand code at the component level, not type it at the line level. I shipped a Rust desktop app in two weeks with zero prior Rust, but 10 years of Python gave me the system understanding to direct AI through it. The fundamentals still matter. Memorizing syntax for every language does not.

Will AI replace software engineers?

AI replaces the implementation work, not the engineering judgment. It can run frontend, backend, and database work in parallel 24/7, but it needs someone who understands the full picture to direct and govern it. If that someone isn't you, someone else will step in.

Is system design still worth learning in 2026?

Yes, more than ever. Implementation used to be the bottleneck; now system design is the skill that determines whether AI-built software holds together. Designing Data-Intensive Applications by Martin Kleppmann is the book I recommend. It's about data flows, failure modes, and tradeoffs rather than syntax.

How do you stop AI from bloating your codebase?

Follow a loop that goes big picture, plan, build, test, then ruthlessly simplify. In the simplify step, ask which lines and components can be removed while still passing the tests, question naming conventions and file structure, and let AI do its own research on what to cut. Most people skip this step. It's where I spend most of my time.

Can you trust AI-written tests?

Not by default. AI is overly optimistic. It will write tests, report that everything passes, and mock the very things it should be testing. Learn the testing frameworks for your language yourself, think through the edge cases, and run the tests automatically in CI/CD.