Introduction
Engineers love building their own tools. If not built in-house, the second best is well-maintained and well-documented tools. Switching tools is painful because engineers have to re-learn everything behind the tool, and the more complex they are, the more time is spent just getting their hands dirty before doing actual work.
With AI, the landscape is moving faster than engineers can settle. First, it was GitHub Copilot for “cool” autocompletions. Then Cursor and Windsurf (Devin) for AI-powered IDEs. Now Claude Code, Codex, and Windsurf’s Cascade for agentic workflows. Tools like Lovable and Replit opened up app development to non-engineers entirely (and vibe-coding!). And the list will keep growing.
The AI space is both exciting and exhausting. With these mixed feelings, there are real challenges engineers face when adopting these tools. In this post, we’ll cover three of them.
Challenge 1: Tool-switching and meta-learning friction
Tools and frameworks generally come with their own concepts and mental models. The same applies to AI. Each AI tool manages its context window differently (e.g., files like CLAUDE.md vs AGENTS.md vs Cursor rules). Each tool has recommended workflows, strengths, and limitations. Setting up new tools is easy, but re-learning how they work and the underlying differences can be exhausting for engineers.
The same applies to any technology. On a high level, two databases like PostgreSQL and MySQL look similar. Both are relational, both use SQL, and both support indexing. But underneath, they have critical differences: default page sizes, how they handle concurrency, and index implementations (B-Tree vs GIN). The friction is not in knowing one database technology, but understanding the fundamentals well enough to evaluate and learn new technologies.
For AI, each tool switch carries a hidden cost: markdown files, prompt patterns, your team’s workflows, all of it has to be rebuilt or adapted.
Challenge 2: More review work, less hands-on coding
There’s a shift happening in what engineering work looks like. Engineers used to spend most of their time writing code. Now, a growing chunk of that time goes to reviewing, verifying, and debugging AI-generated output. According to Faros AI’s 2026 Acceleration Whiplash report, a telemetry collected from 22,000 developers found that while engineering throughput increased, median review times grew 5x and bugs per PR increased by 28%. This means that more code is being written with AI, but more time is being spent reviewing it.
Some engineers find this energising. Others find it frustrating because the creative part of the job, building from scratch, gets replaced by quality assurance on code you didn’t write. Gergely Orosz, author of the Pragmatic Engineer newsletter, published a survey on AI’s impact on engineers and found that “builder” type engineers report feeling overwhelmed by reviewing AI-generated code, and some experience a sense of identity loss from no longer doing hands-on coding.
AI slop is a real challenge. Review work is cognitively demanding, but doesn’t feel like building as before. The risk is that engineers start rubber-stamping and blindly approving AI output because the volume is high and the review fatigue is real. Junior engineers are more subject to relying on AI-generated code, while senior engineers have more reviewing to do. It is challenging and requires more engineering time for reviewing AI’s results.
Challenge 3: Cognitive Surrender
We wrote about cognitive surrender in a previous post. The short version: cognitive surrender is when engineers stop forming their own view of the system and accept AI’s output at face value.
Examples like: merging AI-generated code without reviewing the logic. Giving AI root access to modify infrastructure. Letting AI modify architecture without giving feedback on the design.
The opposite of surrender is being intentional. A cloud engineer can ask AI to help provision AWS infrastructure, but they know the environment well enough to spot when the output is wrong. An engineer can use AI agents for feature development, but they understand the requirements and constraints well enough to assess the result. Cognitive surrender happens when that domain knowledge isn’t there, or when fatigue makes you stop applying it.
Solution
Developing transferable skills is the solution. The tools will keep changing, the review burden will keep growing, and the temptation to surrender will always be there. Chasing every new tool isn’t the answer. What helps is developing skills that transfer regardless of which tool you use today. Skills that work in Cursor also work in Claude Code. Skills that help you review AI output today will help you review whatever AI produces next year.
Here are 3 examples of transferable skills:
Prompting as a skill. Being accurate, precise, and simple in how you direct AI is a transferable skill. Engineers who know how to explain and point AI at the right problem get better results faster. For example, “fix this bug” is a vague prompt that gives AI no context to work with (and burns more tokens!). A better prompt would be to explain the problem, the current behaviour, and the expected outcome.
An example prompt would be: “There is a memory leak in this web service when consuming messages from the SQS. The service receives a certain payload and should upload to an S3 bucket within seconds. Analyse these logs and the application code to investigate the root cause of this memory leak.”
Good prompting works with any LLM, doesn’t depend on which tool you’re using. For guidelines, I recommend reading Anthropic’s prompting best practices.
Identifying automation. Any manual process that follows a series of well-defined steps is an opportunity for automation: routing requests for production access, collecting product metrics, deploying new environments. The skill isn’t just spotting what to automate. It’s knowing how to integrate it into your existing workflows. That means understanding where an AI agent fits into your CI/CD pipeline, pre/post commits, how it interacts with your existing tools, and what guardrails to put around it. The principles apply regardless of which AI agent you use.
Critical review as a discipline. Engineers and architects should advocate for AI usage and stay skeptical when reviewing its output. Domain expertise is what separates someone who uses AI effectively from someone who is used by it (e.g., vibe-coding). Know the problem space well enough to catch what the AI gets wrong. That skill builds over time and it’s also what separates great engineers from the rest.
Conclusion
These challenges will continue to exist in 2027. New AI tools will launch, old ones will fade, and engineers will be expected to adapt. That’s not going to change. However, the good news is that engineers can stay ahead by building skills that transfer from one technology to another. Learning how to use LLMs efficiently, strong prompting, understanding context windows, and learning how to spot automation opportunities. Building the habit of reviewing AI output in chunks (small PR-style) will further develop an engineer’s reviewing skill. Architects and engineers can use those skills across every tool, framework, and workflow. They’ll be the ones who got good at meta-learning and staying intentional without cognitively surrendering to AI’s latest models.
📚 Resources
- https://icepanel.io/blog/cognitive-surrender-with-ai
- https://www.ibm.com/think/topics/context-window
- https://www.faros.ai/research/ai-acceleration-whiplash
- https://newsletter.pragmaticengineer.com/p/the-impact-of-ai-on-software-engineers-2026
- https://claude.com/blog/best-practices-for-prompt-engineering
