What I know now.

In the app repo. Every single time.

• Solves false positives. Tests change in the same commit as the code, so a red build means a bug, not an intended change.
• Solves late feedback. You hear about a break on the commit that caused it, not after it reaches the test environment.
• Shared responsibilities. Developers fix broken tests. QAs test the app and write the missing tests.
• Gives QAs mental space to actually test the app and write the missing tests, instead of living in maintenance hell.
• Solves capacity constraints. Maintenance is one of the key challenges as the test count grows. When everyone owns the tests, the burden doesn't fall on a single person.

Put the tests where the code is. Everything else follows.

The developers’ language. Every single time.

• Solves ownership. Developers can read, review, and fix a test written in their own language. A test in a language they do not know is a test they will never touch.
• Solves the two-toolchain problem. One build, one linter, one package manager, one CI job. No second ecosystem to keep alive.
• Solves duplication. Tests reuse the app’s types, models, fixtures, and clients instead of rebuilding the domain in another language.
• Solves scale versus maintenance. When tests speak the team’s language, the whole team maintains them, not only QA.
• Gives QAs a stronger skill. Learning the developers’ language makes you a better engineer, not just a better tester.
• No need to hire an army of QAs because the number of tests grows over time and becomes too much for one person to maintain. Everyone maintains. QAs can test and add new tests.

Learn their language. Then the tests belong to everyone.

Unit and integration. System tests only for what nothing below can see.

• Most functionality belongs at unit level. Business rules, validations, calculations, edge cases. Every branch of logic, tested in isolation, in milliseconds.
• Most integration issues belong at component level. Wiring, contracts, serialisation, queries, configuration. Test the seams where two parts meet, with the real parts on both sides.
• Most system tests are checks that could live lower. They exist because QA cannot see the tests underneath. Read the unit and component tests first. Then write only what is missing.
• System tests cover only what nothing below can. That the deployed app starts and its pieces are wired together. That one request goes in through the real UI and comes back out with the right data persisted. That login, permissions, and navigation hold across the whole stack.
• System journeys, not user journeys. A system journey cuts vertically through frontend, middleware, and backend inside your application’s boundary. A user journey runs horizontally across systems you do not control. Stub what sits outside the boundary and cover it with a contract test.
• Leave the user journey to a human. Automation tells you whether you are building it right. Only a person walking the product tells you whether you are building the right product, and finds the UX issues on the way.
• Fast and, above all, reliable. A system suite that finishes in minutes and passes whenever nothing is broken. A flaky test is worse than no test: it teaches the team to ignore red.

Push every check as low as it can go. What remains is your system suite: small, vertical, fast, and reliable.

App native. Espresso on Android, XCUITest on iOS. Two native tools over one tool in the middle. Every single time.

• “One tool” is really three. Appium puts a server, a driver, and a client library between your test and the app. Every layer is a place to be slow, to be flaky, and to lag behind the next OS release.
• Google builds Espresso. Apple builds XCUITest. One man created Appium. And no, it is not the same as Linux or Git. When the company that builds the platform also builds the test tool, the tool knows the platform from the inside. It ships with the OS, it is updated the day the platform changes, and it is not going away.
• Same repo, same language, same build. The test sits beside the screen it tests, in Kotlin or Swift, and runs with the developers’ build in CI. Lessons 01, 02, and 03 come for free.
• Developers already know them. Android and iOS developers learn Espresso and XCUITest as part of their craft. Nobody has to learn a WebDriver dialect to help QA.
• Fast and reliable. In-process, no network hop, no session to set up. Hundreds of native UI tests finish in the time a bridge takes to launch.
• Yes, you write it twice. Two small, simple, native suites cost less than one large, slow, shared one. And each platform team owns exactly one of them.

Appium’s promise of one test for both iOS and Android is tempting. But one shared test means one outside repo, with the sync problems from lesson 01, and an architecture that trades speed and reliability for portability. Over time it becomes more nuisance than help. Espresso and XCUITest are fast and reliable. Appium is neither. The cost lands on the whole team, every day, for years.

Pick the tool the developer would pick. Then you never test alone.

Don’t just improve. Evolve.

• You can build apps now. Frontend, backend, deployment. Six months ago I could not build a full-stack app. Today I have more than one running, intended for profit and for education: VATEzPz, a product I am taking to market, and TaskFlow, which demonstrates trunk-based development with feature flags.
• The old limit was the brain. The field was too vast for one head to hold, so engineering split into business analysts, frontend and backend developers, QAs, architects, DevOps, security. Each held a fragment.
• That limit is gone. Agents carry the knowledge and the skills. You carry the judgment.
• Agents work best with full context. Knowledge scattered across seven roles is exactly what they struggle with. One person who understands the whole thing, end to end, gets the most out of them.
• The industry is already moving. A quarter of Y Combinator’s recent startups had most of their code written by AI, and some reach ten million in revenue with fewer than ten people. A Harvard and INSEAD study finds AI-native companies are a quarter smaller than their peers, with more engineers and fewer layers. A handful of people now ship what used to take a department.

The limitations of before do not exist anymore. You can learn anything. Build anything.

Reuse is fine. Reuse without asking why is not. Look at old problems with fresh eyes.

Case study: agentic-semver, semantic versioning rebuilt from the question up.

• The reused answer. Conventional Commits. Prefix every commit with feat:, fix: or BREAKING CHANGE, and let a tool count prefixes. Adopted everywhere because it exists, not because anyone asked whether it is right.
• Ask what a version actually is. A statement about what changed for the people who depend on your code. Not a record of how a developer typed a commit message at six in the evening.
• So read the change, not the message. agentic-semver sends the pull request diff to a model, which classifies it as patch, minor or major and drafts the changelog entry. No convention to learn, nothing to forget, and a squash merge cannot lose it.
• Keep the human on the irreversible part. The recommendation lands as a label on the pull request. Disagree? Swap the label. The label wins. The number is reviewed by a person, the prose is written by the machine.
• Fix the race nobody mentions. Two open pull requests read the same baseline and compute the same next version. Whichever merges second overwrites a release or is silently skipped. So decide on the pull request, but write after the merge, serially, against main as it actually stands.
• The result. One action on the pull request, one after the merge, one release. Seven ecosystems’ version files detected automatically. No bot commit ever touches your branch.

First principles is not about ignoring what exists. It is about earning the right to use it.

Essential. AI amplifies what you already know. Learn the basics, and it becomes a super power. Skip them, and it becomes confident nonsense you cannot judge.

• Continuous delivery. Small changes, merged often, shipped on every green build. This is the plumbing that turns AI-written code into something a user can touch. Start at continuousdelivery.com, the source the rest of the industry quotes.
• Branching strategy. Trunk-based development with feature flags. Long-lived branches are where agent output goes to rot. Start at trunkbaseddevelopment.com. I wrote about it with flags and without, and TaskFlow shows it running.
• Programming fundamentals and clean code. You will now read far more code than you write. Reading well is the skill. Clean Code, Head First Java and Functional Programming in Java taught me to tell good code from code that merely runs.
• DevOps. Git, Docker, the command line. The agent can write the Dockerfile. You have to know when it is wrong. The Git manual, Learn Docker in a Month of Lunches and The Linux Command Line are the three I keep coming back to.
• Lifecycle management. Where a change is in its life, from idea to production to retirement, tells you what to ask the agent for next. Without that map, every prompt starts from zero.
• The pattern underneath. Every item on this list is cheap to learn now, because the same agent that writes your code will explain any of them for as long as you keep asking. What it cannot do is decide for you which answer is right.

The full list is on my books page. Not one of them is about AI. Every one of them makes AI more useful.

The super power has no judgment of its own. Yours comes from the basics.