Last newsletter I declared (direct quote) π
Suddenly the new software developer skills became explaining features, architectural know-how, and ability to read and refactor code.
Less emphasis on "how", and much more on "what" (and "why" as well).
You must pivot: from software developer, to software architect π
"How to" is for documentation and MCP
The "classical" how-to article lost most of its value.
An AI can be way more detailed and practical in most cases π€·πΌββοΈ
I won't read a tangentially-related article, when I can ask the AI to provide insights on my specific use case and codebase.
For the "how to" part, I go in two places:
- Directly to the library documentation
- MCP with AI
I don't need the specific APIs, but an higher level understanding of the architecture and flow.
You are a software architect
Not all "how to" are made equal. Let's make a distinction:
- "How to write this in code"
- "How to structure and architect this system"
(1) is losing, (2) is rising ποΈ
Even before opening my IDE, I discuss "what" and "how" to implement a new feature with any generic AI chat. Example of a recent discussion about streaming on the Web:
How does a streaming Request/Response cycle works for streaming as compared to a normal JSON request?
Say I call the Gemini streaming API, what formatting of data should I ask the AI such that I get each feedback separately in JSON format that I can then stream one by one to the client? How would the actual client streaming work? How does the server know when a full object is received from the AI API?
I make sure to understand exactly how I want the feature implemented, all the assumptions and edge cases, from an architectural perspective.
This all inform the prompt that I will submit to the AI.
Pro tip: write as many details and assumptions in your AI prompts.
A detailed prompt avoids a long refactoring session later on.
Principles over implementation details
I know how to architect, and I write a detailed prompt for the AI. The architecture is solid, and the prompt has all the implementation requirements.
Then I step back, enable "accept all edits" (use Git!), and watch.
From writing code, to reviewing it π
Reminder to always review the output of AI Always π€¦
My role as a reviewer:
- Check that the feature implementation is correct
- Check that the code follows patterns and type-safety rules
Reading, understanding, and modifying code are the new meta-skills. Principles became way more important, things like type-safety, linting, immutability, file/folder structure.
Maintainability and clarity
Last key piece of the puzzle: ensure the next prompt works as good as this one.
What I mean here is maintainability π€
You must make sure that the code is strict and type-safe enough to ensure the next AI doesn't introduce 10 bugs while trying to implement 1 feature.
Let me give you a long, prolonged, verbose, full of adjectives prelude on my next declaration here below:
Strict Type Safety is the next big skill of highly effective developers π«΅
When types are strict everywhere checking your codebase, no AI can escape. Types ensure no bug slips in, and the AI is forced to do a good job.
You can now be a x10 developer. Like, for real. When you understand all the piece of the puzzles, the specific implementation becomes an "implementation-detail".
See you next π
