Andrew Ng, founder of DeepLearning.AI and former lead of Google Brain, sums up the shift in one sentence: "AI is the new electricity."
Think about what electricity is not. It is not a product you buy and use once in a while, like a microwave. It is the invisible base in the wall of every home and company, the thing that supports everything else. Nobody "uses electricity" as an isolated task. Ng's bet is that AI will take that same place: it will stop being a tool you open now and then and become the infrastructure underneath the entire job.
The electrification of factories is a case studied in economics, and the lesson is more specific than it seems. When electric power reached factories in the late 19th century, most companies simply replaced the steam engine with an electric motor, keeping the rest of the process intact. Economist Paul David documented the result in the classic "The Dynamo and the Computer" (1990): almost three decades of productivity stagnation, even with the new technology installed.
The gain only appeared for those who redesigned the production architecture around the new technology. Ford did this in 1913 by reorganizing the entire production line around the flow of work, and the assembly time of the Ford T dropped from more than 12 hours to about 90 minutes, an 8x gain (sources: History.com, Library of Congress, Ford Motor Company).
This pattern has a name in the literature: general-purpose technologies (like electricity, the computer, and now AI) only deliver their exponential value when the process is redesigned around them. Used in a linear way, plugged on top of the old process, they deliver marginal gain.
The key idea adopting AI is not swapping the tool, it is rethinking how the work is done. This is the thread that connects everything else in this playbook.
LLM stands for Large Language Model. It is what powers ChatGPT, Claude, and Gemini.
Think about the autocorrect on your phone. You type "I'm going to have lunch at" and it suggests "home." It does not know where you are going to have lunch. It has seen millions of similar sentences and guessed the most likely continuation. An LLM is that same mechanism taken to the extreme: it writes entire texts by predicting one word after another, based on the patterns it learned reading a gigantic fraction of everything ever written.
Now let's open the hood, in three stages.
Training. The model is exposed to billions of texts and its task is always the same: given a passage, predict the next word. On each error, the model's internal parameters (numbers that define its behavior, in the billions) are adjusted a little. Repeating this at an absurd scale, the model internalizes patterns of grammar, facts, writing styles, and even reasoning.
Inference. When you talk to the AI, it receives your text as input, computes a probability distribution over which token comes next, and picks one. Then it repeats the process, now including the token it just generated, until it forms the complete answer (output). Every word you read was chosen this way, one at a time.
The architecture behind it. All of this only became viable at scale because of a 2017 paper called "Attention Is All You Need," by Google researchers. It introduced the Transformer architecture, whose central mechanism is attention: the ability of each word in the text to "look" at all the others at the same time and decide which are relevant to it. Before that, models read text sequentially, word by word, which was slow and lost long-distance relationships. The Transformer processes everything in parallel, which unlocked training at a giant scale. Practically all current text AI descends from that paper (source: Vaswani et al., "Attention Is All You Need", 2017).
With this behavior in mind, the AI's famous flaw stops being a mystery. The model does not consult a database of facts. It generates the most likely text given what it saw in training. When the likely coincides with the true, it gets it right. When it does not coincide, it gets it wrong with the same fluency and the same confidence. This is the "hallucination": it is not an occasional bug, it is a direct consequence of the probabilistic nature of the mechanism.
The key idea the LLM predicts the most likely text, not the truth. Treat its answer as an excellent draft that always deserves verification, never as a final source.
Think of a desk. It fits a limited amount of paper on top. While a topic is on the desk you work with it freely, but the desk has an edge: when it fills up, new paper pushes old paper off, and that vanishes from your sight. The "memory" of a conversation with AI works like this.
Token. AI does not process text letter by letter nor word by word. The text is broken into units called tokens by a component called a tokenizer. A token averages 4 characters, which is about 0.75 of a word in English (in Portuguese the ratio varies a bit). "Desenvolvimento," for example, can become 3 or 4 tokens. Everything is measured in tokens: what you send, what the model answers, and what you pay, since AI APIs charge per input and output token.
Context window. It is the maximum number of tokens the model can process in a single interaction. And here is the detail many people miss: this window includes everything combined. Your instruction, the full conversation history, the documents you attached, and the very answer the model is generating all compete for the same space. The limit exists for a physical reason: the attention mechanism compares each token with all the others, so the computational and memory cost grows quadratically with the size of the text. Doubling the context quadruples the work.
In 2026 windows range from about 128 thousand tokens in lightweight models up to 1 million or more in top-tier models (source: LLM context-window comparisons, 2026, Morph and Codingscape).
A large window does not mean full use. There is an effect documented since 2023 and replicated across several models, nicknamed "lost in the middle": the model's accuracy is high for information at the beginning and the end of the context, and drops by 20% to 40% for information buried in the middle of a long text. It is like a two-hour meeting: you remember the beginning and the end, and the middle becomes a blur.
This has an immediate practical consequence: in long prompts, place the main instruction and the critical information at the beginning or the end, never buried in the middle. And prefer lean, relevant contexts over dumping everything you have.
The key idea context is a finite and poorly distributed resource. Whoever manages context well extracts much more from the same model.
Every new technology arrives with a promise of magic and delivers a list of new problems along with it. With AI it is no different. Knowing the pains in advance spares you the frustration of thinking the problem is you.
Stack Overflow's annual survey of more than 49 thousand developers in 177 countries shows the size of the tension. 84% already use or plan to use AI at work, but only 29% trust the accuracy of what it generates. 66% say the answer comes "almost right, but not quite." And 45% report losing significant time debugging AI-generated code (source: Stack Overflow Developer Survey 2025).
Notice the paradox: adoption rising and trust falling at the same time. This does not mean AI is bad. It means it is a powerful draft that still needs a human in command.
The key idea AI amplifies, but does not replace judgment. The real pain is not a lack of AI, it is a lack of review.
Each term below exists to attack one of the pains from section 4.
Think of the wall socket. There is a single standard fitting, so any appliance plugs in and works, with no workaround per connection.
In practice, it is an open protocol that standardizes how applications provide context and tools to LLMs. An MCP server exposes resources (data) and tools (actions) in a standard format, and any compatible model can consume them. Instead of writing a custom integration for each tool-model pair, you write an MCP server once and it works with any compatible client. It attacks the integration pain.
Think of the laminated recipe on the kitchen wall. The cook already knows how to cook, but the recipe ensures that dish comes out right every time, without relying on memory.
In practice, a Skill is a process or knowledge packaged in a markdown file that the model loads when the task requires it. It contains the task's instructions, conventions, examples, and constraints. The advantage over heavier alternatives is simplicity: it is a text file that is versionable, auditable, and easy to maintain. It attacks the context and reliability pains, because it standardizes how the model approaches recurring tasks.
Here is a direct recommendation: there is a growing movement to solve with Skills what used to be attempted with agents, precisely because of the simplicity. Watch this video — it is the best practical entry point on the topic and teaches you to create your first Skill in a few minutes:
Think of the intern to whom you delegate an entire mission ("solve this for me") instead of dictating each action.
In practice, an agent is an instance of an LLM with its own context window, access to tools, and an execution loop: it receives a goal, decides the next action, executes, observes the result, and repeats until it finishes or fails. Autonomy is the power and the risk at the same time. It is worth calibrating expectations with real data: 52% of developers still do not use agents or prefer simpler tools (source: Stack Overflow Developer Survey 2025). It is an emerging frontier, not a consensus.
Think of it this way: the model on its own is the engine. The harness is the whole car around it: steering wheel, pedals, dashboard. An engine without a car takes you nowhere.
In practice, a harness is the set of tools and infrastructure that surrounds the model so it can actually work: access to the terminal, the file system, code execution, permission control. Claude Code and Codex are examples. The quality of the harness matters as much as that of the model, because it is what defines what the model can actually do.
Think of a manual transmission versus cruise control. In manual you shift each gear. In automatic you program the destination and supervise.
In practice, prompt engineering is the way of working in which you are the loop: you write the instruction, evaluate the result, refine, and resend. All the quality control goes through you, on every round. Loop engineering is designing systems in which the system itself is the loop: you define the intent, the goal, and the stopping condition, and the system iterates on its own until it meets the criterion, without intervention at each step. You evaluate only the final result. The choice between the two is an engineering decision based on the task's risk and your trust in the process.
Think of the architect's blueprint before the brick. Nobody builds a building by guessing and adjusts the foundation later.
In practice, SDD is the approach in which the specification comes before the code and serves as the primary source of truth. The flow inverts: first you write (with AI's help, too) a clear spec of what needs to exist, with requirements, constraints, and acceptance criteria. Then the AI generates the code from the spec, and the code is validated against it. This attacks the reliability pain head-on, because it shifts the human effort from "writing code" to "defining and verifying what the code should do," which is where human judgment pays off the most.
The key idea each term in this vocabulary solves a concrete pain. When you link the name to the problem it attacks, the jargon becomes a toolbox.
Remember the factory that only swapped the engine? Here are the two modern versions of that story, one on each side.
The company already had its developers using a licensed Copilot, but the gain was small. Human coding remained the central bottleneck, now with occasional help. They swapped the tool and kept the process, the classic mistake.
The turning point came from redesigning the entire flow. AI took over context, code, and volume. The humans moved to supervision, refinement, and decision-making. And documentation, once a bureaucracy done at the end, became a strategic artifact produced right at the start, because now it feeds the AI's context. Result: a work front estimated at 150 days of individual effort was delivered in 30 days (source: Vibbra, "Case Dígitro", maio/2026).
Notice that Dígitro's redesign is the practical application of the vocabulary from section 5: well-managed context, specification and documentation before code, the human in the reviewer's role.
Klarna did a real redesign of its customer support. Instead of pasting a chatbot on top of the process, it integrated AI with authenticated access to each customer's real history. The initial numbers were impressive: 2.3 million conversations in the first month (the equivalent of about 700 full-time agents), resolution time dropping from 11 minutes to less than 2, and 25% fewer repeat tickets.
But they treated AI as a total replacement for humans, and that is where it broke. In 2025 they had to rehire people for the complex and emotional cases, after satisfaction plummeted exactly where human empathy was irreplaceable (source: consolidated 2026 coverage, including statements by CEO Sebastian Siemiatkowski).
The key idea redesigning works, but you have to redesign the right thing. The question is not "what can be replaced by AI" but "where does each part, human or artificial, deliver the most value".
Think of a lever. It multiplies your force. In the right direction, you move a rock you would never move on your own. In the wrong direction, you just break things faster. AI is that lever applied to work.
AI generates in seconds what would take you hours to write. If you have the fundamentals to evaluate what it generated, that gain is real: you review, correct, and deliver more in less time. If you do not, the gain is illusory: you accept code that looks right, the error enters the system, and the cost shows up later, multiplied, in the form of a production bug and rework.
That figure from section 4 (45% of developers lose time debugging AI code) is exactly this happening at scale. Without the fundamentals to review, AI's speed becomes speed of error. The conclusion is counterintuitive for someone starting out: the fundamentals of software engineering did not become obsolete with AI. They became more valuable, because they are now what separates those who multiply value from those who multiply mess.
The practical barriers to adoption confirm the pattern: disorganization, poorly managed context, laziness about reviewing what AI generated, and the illusion that it is all magic. None of them is a limitation of the model. All are the discipline of the person using it.
There is a rare skill that has gained enormous weight in this scenario: taste, technical good taste. It is the mix of your personal experience with your technical ability, that instinct to know that one solution is elegant and another is a patch, even if both "work." It is not fully replicable because it is born from each person's unique experience. AI executes, but the judgment of "did this turn out well?" remains yours. Big tech companies talk about this more and more, and it is worth developing on purpose: studying well-written code, comparing solutions, and asking for critique.
The key idea AI multiplies what you already are. Investing in fundamentals and in taste is not the opposite of using AI. It is what makes AI worth it.
The safe path to apply all of this without falling into the traps we saw:
This playbook is a beginning, not an end. It gave you the vocabulary, the logic behind it, and the first practical step. Learning AI is like learning to swim: no amount of reading replaces getting into the water.