Two years after I could barely write code, I was teaching 20+ engineers and senior leaders how to use AI workflows in real engineering work.
That sounds like a LinkedIn exaggeration.
So here is the receipt stack.
I finished mechanical engineering at TUM in roughly the top 4% while training seriously as an athlete.
At the start of my thesis, I did not know how to write a basic Python for loop, had not used Linux, did not know how to use an IDE, and lacked the math, PyTorch, and deep-learning background the topic required.
Six months later, I had self-studied six graduate-level AI/ML courses, built a data pipeline, studied autonomous-driving research papers, ran experiments, improved the training process, and finished the thesis with a 1.3.
The thesis topic had originally been intended for master’s students.
That helped me land a machine-learning research internship at the Bosch Center for Artificial Intelligence.
Later, I grew an English-language channel to 60,000+ subscribers and 1M+ views in four months, then turned the audience into 120+ customers and up to €5,800/month in revenue.
At the time, I was living on government support, in a €400/month student apartment, from a working-class family, with a barely working laptop and unreliable Wi-Fi.
No media company.
No team.
No agency.
No distribution machine.
Then KONUX created a full-time engineering role for me without a job posting, resume screen, coding challenge, or formal interview loop.
I was still a data-science intern, and the signal was not a credential. It was that the Data & Cloud Platform lead had watched me brute-force my way through Docker, Kubernetes, AWS, Poetry, and deployment problems with ChatGPT.
In my first month as a full-time engineer, I completed a 5-story-point Java task in 5 days.
The month-6 expectation was 5 story points in 8 days, and a senior engineer working on a similar task in parallel finished slightly after me.
I had never written Java before, did not know IntelliJ IDEA existed, and had no prior production experience with APIs, unit tests, integration tests, end-to-end tests, or hexagonal architecture.
A few months later, I was teaching engineers, senior engineers, engineering leads, a principal engineer, and business leaders how to use AI coding workflows in real work.
Not just “use ChatGPT.”
Actual workflows.
When to use an MCP server.
When to activate a skill.
When to clean up context.
When to delegate to a sub-agent.
When to use built-in coding-assistant features.
When not to use them.
How to move from a Jira ticket to context, plan, code, review, and reusable method.
After one workshop, a colleague praised the session publicly in Slack, and both the CEO and Head of Engineering added recognition underneath.
So the question is not whether I had the right background.
I often did not.
The question is:
How did I repeatedly enter domains where I was underprepared on paper, then become useful fast enough that more experienced people started adopting my methods?
This article is my current answer.
Not a motivational story.
Not “just work hard.”
Not “AI makes everyone an expert.”
These are the 7 adaptability cheat codes I used.
Cheat Code 1: Learn just in time, not just in case
Most education starts with a curriculum.
First fundamentals.
Then intermediate concepts.
Then advanced material.
Then, finally, application.
That works when the domain is stable and the path is known.
But it has a hidden cost:
Knowledge decays.
Learning is not a permanent asset by default.
If you learn something and do not use it, the forgetting curve starts taxing it immediately.
That is why I do not like learning entire domains just in case.
I prefer learning just in time.
My thesis forced this.
The normal path would have been:
Learn programming.
Then Python.
Then Linux.
Then statistics.
Then linear algebra.
Then machine learning.
Then deep learning.
Then PyTorch.
Then research papers.
Then the thesis.
I did not have that timeline.
So I reversed the order.
The thesis became the curriculum.
I learned Python because the data pipeline required Python.
I learned Linux because the tooling lived there.
I learned PyTorch because the experiments required it.
I learned the math because the papers stopped making sense without it.
I read the papers because I needed to understand the model well enough to change the training process.
The problem determined the learning sequence.
That is the cheat code:
Do not learn the domain from the curriculum forward. Learn it from the required output backward.
This is not anti-depth.
It is anti-premature-depth.
Once a real problem proves that a concept matters, I go deep.
But I do not want to spend months building a perfect foundation for a domain I may never need again.
Cheat Code 2: Optimize for transferable expected utility
Most people ask:
What skill helps me finish this task?
I think the better question is:
What skill helps me across this task, the next task, the next project, the next job, and the next domain?
That changes where you invest.
You can become faster as a software engineer by learning one programming language more deeply.
That can be valuable.
But you can also become faster by building a transferable productivity layer:
Keyboard shortcuts.
IDE navigation.
Terminal fluency.
Browser workflows.
Documentation lookup speed.
Meeting-to-requirements workflows.
AI-assisted context gathering.
Reusable project-scoping methods.
Those skills are less glamorous than “I know Java deeply.”
But they transfer.
Across languages.
Across repositories.
Across companies.
Across jobs.
Across domains.
And speed changes behavior.
If looking something up takes too long, you skip it.
If opening the right docs, searching the right repo, checking the right ticket, or comparing the right context takes seconds, you do it.
That means speed does not only make work faster.
It changes which actions happen at all.
This matters because many engineering mistakes are not caused by slow typing.
They are caused by missing context.
Wrong requirements.
Unclear ownership.
Unseen constraints.
Misread documentation.
A misunderstood system boundary.
Building the wrong thing quickly is still failure.
So I prefer skills that reduce the chance of that happening.
The cheat code is:
Do not only optimize for the current task. Optimize for the highest-transfer skill that improves many future tasks.
That is why I care so much about meta-skills.
They compound longer than most domain-specific skills.
Cheat Code 3: Immerse until you find the roots
In university, most students followed the semester structure.
A lecture here.
A tutorial there.
Another subject later in the day.
Another disconnected topic tomorrow.
I found that this made me scratch the surface.
I could collect fragments.
But I did not see the roots.
So I changed the method.
Instead of studying many subjects in parallel every week, I would immerse myself in one subject from the first lecture to the last lecture in one concentrated block.
Usually one or two weeks.
Then I built what I called a cookbook.
Not notes.
A cookbook.
A recipe book for solving that subject’s exam problems.
What kinds of questions exist?
What cases repeat?
Which variables matter?
Which formula applies?
What is the decision tree?
What steps should I follow when this problem appears again?
Once I had the cookbook, the subject felt partially automated.
When exam phase came, I did not rediscover the subject.
I reopened the cookbook and practiced applying recipes.
That became a general principle:
Deep immersion reveals the mechanics. Systematization prevents rediscovery.
I use the same idea in engineering.
If the same pull request feedback appears repeatedly, it should become a checklist or skill.
If the same repository confusion appears repeatedly, the repository needs a map.
If the same setup mistake appears repeatedly, the setup needs an executable procedure.
If the same business-context explanation appears repeatedly, it should become reusable context.
If the same ticket-scoping confusion appears repeatedly, the scoping method should become a template.
The cheat code is:
Do not just solve the current instance. Extract the reusable root behind it.
That is how a one-time solution becomes a method.
Cheat Code 4: Trade time for assets, not only output
Many software engineers think the output of work is code in production.
That is true.
But incomplete.
The code in production is the visible output.
The more valuable output is often the asset created while producing it.
That asset can be:
A script.
A checklist.
A repository map.
A reusable prompt.
A skill.
An API wrapper.
An MCP server.
A sub-agent.
An onboarding workflow.
An agent that performs part of the work next time.
If I only complete the task, I get one completed task.
If I complete the task and build the reusable asset, I get two things:
The work gets done.
And the next similar unit of work becomes cheaper.
That is the compounding difference.
Most people trade time for output.
Some people trade time for money.
I try to trade time for assets.
And then those assets produce more output later.
This is why agents are interesting to me.
Not because they are cool.
Because they can become work-producing assets.
The question is not only:
How do I finish this task?
The better question is:
Can I build something that makes every future instance of this task cheaper?
That is why AI tooling mattered.
Local agent harnesses, MCP servers, procedural skills, sub-agents, setup instructions, and onboarding workflows were not just productivity tricks.
They were assets.
At first, they made my work cheaper.
Then other people started using them.
That is when the asset stopped being personal.
It became shared leverage.
Cheat Code 5: Automate only past the break-even point
The asset mindset also applies outside work.
For example, job applications.
Manual job applications are a bad compounding profile.
You spend time and energy.
You get a probabilistic chance at an outcome.
If you send 20 applications and get 20 rejections, the time is gone.
To send the next 20, you must spend the same energy again.
The asset version asks:
What if I build an agent that searches, filters, prepares, and submits applications when the role matches my criteria and the questions are answerable?
The first version takes longer.
Maybe longer than doing 20 applications manually.
But the point is not the first 20.
The point is the break-even curve.
At some volume, the automation pays back the setup cost.
After that, each additional application becomes cheaper.
But this does not mean everything should be automated.
If checking email takes two minutes per day, it may not be worth building a complex inbox automation.
The setup and maintenance cost might exceed the benefit.
So automation needs expected utility.
I roughly think about it like this:
Automation value = future repetitions × time saved × energy saved × probability of reuse − build cost − maintenance cost − risk cost.
That means a task is automation-worthy when it is:
Frequent.
Draining.
Repetitive.
High-volume.
Error-prone.
Context-switch-heavy.
Likely to appear again.
Useful beyond the exact current case.
The cheat code is:
Do not automate because automation is cool. Automate when the break-even curve is attractive.
Cheat Code 6: Use AI to compress context, not replace judgment
The wrong way to think about AI is:
AI replaces expertise.
That is not how I use it.
The better framing is:
AI compresses the path toward useful judgment.
Most real work requires context before action.
What does the ticket actually ask for?
Which repository owns the behavior?
Which API matters?
Which environment matters?
Which previous pull request is relevant?
Which documentation page explains the missing concept?
Which Slack discussion contains the real requirement?
What would make this safe?
What would make this wrong?
Without AI, gathering that context is slow.
Because it is slow, people skip parts of it.
They build from partial understanding.
They rely on memory.
They read less documentation.
They ask fewer questions.
They implement what the ticket says instead of what the situation needs.
AI changes that.
Not because the model magically knows the truth.
But because a good AI workflow helps gather, summarize, compare, and organize context faster.
The human still judges.
The human still verifies.
The human still decides.
But the path to judgment becomes shorter.
That is how I could enter unfamiliar technical domains faster.
I did not need to already know everything.
I needed a workflow for finding out what mattered quickly.
The cheat code is:
Use AI to reduce the cost of acquiring context, not to avoid thinking.
That is why I teach workflows, not just tools.
When to activate an MCP server.
When to activate a skill.
When to clean up context.
When to delegate to a sub-agent.
When to stop the agent.
When to verify manually.
When not to automate.
That is the difference between “using AI” and working with AI as an engineering capability.
Cheat Code 7: Turn personal leverage into shared leverage
At first, my AI workflows were for me.
I wanted to move faster.
Understand repositories faster.
Prepare implementation plans faster.
Stop rebuilding the same context from scratch.
But personal leverage has a ceiling.
If only I can use the tool, the organization gets my output.
If others can use the tool, improve it, and add their own methods, the organization gets a compounding system.
That is why adoption mattered.
The goal was not:
Look at my AI demo.
The goal was:
Here is a practical way to work with AI inside real engineering workflows.
That means teaching the sequence.
Start from the Jira ticket.
Pull in the right context.
Activate the right MCP server.
Use the right skill.
Keep the context clean.
Delegate when the chat gets overloaded.
Review the output.
Capture the reusable method.
Improve the workflow for next time.
Some workshops were conceptual.
They shifted beliefs.
Other sessions were practical.
I shared my screen and worked through code.
Some onboardings were 15 minutes.
Some were an hour.
Some happened because someone had a specific problem right now.
That is how adoption actually spreads.
Not through generic AI excitement.
Through specific workflow upgrades.
The cheat code is:
First make yourself faster. Then extract the method. Then make the method teachable. Then make it installable. Then help others apply it to their own work.
That is how personal leverage becomes shared leverage.
What actually compounded
Looking back, the surprising part is not one result.
It is the repeated shape of the results.
Mechanical engineering to deep learning.
Deep learning to Bosch AI.
Engineering student to creator business.
Creator business back to software engineering.
Data-science intern to full-time engineering role.
No Java to senior-comparable first-month velocity.
Personal AI workflows to senior-engineer adoption.
The mechanism was not talent alone.
It was not confidence alone.
It was not AI alone.
It was a set of compounding behaviors:
Learn just in time.
Optimize for transferable expected utility.
Immerse until the roots are visible.
Turn understanding into cookbooks.
Trade time for assets.
Automate only past the break-even point.
Use AI to compress context.
Turn personal leverage into shared leverage.
Each behavior makes the next one stronger.
Just-in-time learning makes it easier to enter a domain.
Transferable skills make each investment useful across more domains.
Immersion reveals the mechanics.
Cookbooks preserve the mechanics.
Assets make future work cheaper.
Automation scales repeated work.
AI compresses context.
Shared leverage turns personal speed into team capability.
That is the ultra-adaptability loop.
The takeaway
I did not go from my first line of code to teaching 20+ senior engineers AI workflows because I skipped expertise.
I did it because I used a different strategy for acquiring and packaging expertise.
I did not learn everything just in case.
I let real problems pull the next required knowledge into focus.
I did not only optimize for the current task.
I invested in transferable skills that would help across future tasks.
I did not only complete work.
I tried to turn work into assets.
I did not automate everything.
I automated when the break-even curve made sense.
I did not use AI to replace judgment.
I used it to shorten the path toward judgment.
And I did not keep the leverage private.
I turned it into workflows, tools, skills, and onboarding paths other people could use.
That is the real cheat code:
Become useful before your background says you should be ready. Then capture how you did it. Then make the next version cheaper. Then share the asset.
That is how adaptability compounds.