Software engineering is changing. Again.
I've spent the last two years applying AI across prototyping, internal tools, production systems, and team workflows. I've watched it generate elegant solutions in seconds and confidently produce complete nonsense. I've seen it save hours on boilerplate and cost hours debugging hallucinated APIs.
One thing has become clear: AI doesn't make engineering easier. It shifts where the hard parts are.
The teams I've seen succeed with AI aren't the ones using it everywhere. They're the ones using it deliberately, knowing when to trust it, when to verify, and when to ignore it entirely.
Here's a working set of principles I've found useful. They aren't finished and will evolve with the tools. But they help keep me grounded in what actually matters.
intelligent Engineering Principles
These principles fall into two buckets: what is new, and what remains timeless but more important than ever.
AI-Native Principles
These principles exist because of AI. They address challenges that didn't matter before.
AI augments, humans stay accountable.
AI can help you move faster and see options you'd miss on your own. But it can't own the outcome. Engineering judgment stays with you. When something breaks in production, "the AI suggested it" isn't an acceptable answer.
Context is everything.
AI output reflects what you put in. Vague requests get vague results. Bring useful context: project constraints, coding standards, relevant examples, what you've already tried.
As systems grow, context management becomes a discipline of its own. How do new teammates get AI tools primed with the right information? How do you keep that context current? When context exceeds what fits in a prompt, you'll need solutions like modular documentation.
Smarter AI needs smarter guardrails.
Faster generation demands sharper review. AI-produced code still needs validation: Is it correct? Secure? Does it solve the right problem?
Shape AI deliberately.
I've seen teams adopt whatever AI tools are trending without asking whether they fit. Six months later, half the codebase assumed Copilot's import ordering, onboarding docs referenced prompts that no longer worked, and no one remembered why. Decide upfront: where does AI help us? Where does it not? What happens when we switch tools?
Learning never stops.
At the start of 2025, AI practices evolved weekly. By year's end, monthly. That's still faster than most teams are used to. What didn't work three months ago might work now. The only way to know is to keep experimenting.
I've settled on 90% getting work done, 10% experimenting. Try new ways to solve the same problem. Revisit old problems to see if there's a simpler solution now. Check if techniques you learned last quarter still make sense.
Timeless Foundations
These aren't new, but AI makes them more important.
Learn fast, adapt continuously.
Start small, validate often, and shorten feedback loops. If an AI-assisted workflow isn't helping, change it. Don't let sunk cost keep you on a bad path.
Fast doesn't mean good.
AI makes it easy to generate code fast. That doesn't mean the code is worth keeping. Unmaintainable, insecure, or rigid solutions cost more than they save. Build the right thing, not just the quick thing.
What This Looks Like in Practice
Here's what this means day-to-day:
- I use AI to draft implementations, then spend more time reviewing than I saved generating. The review is where the real work happens.
- When AI suggests an approach, I ask "why?" If I can't explain the choice to a teammate, I don't use it.
- I've learned to be specific. "Write a function to parse dates" gets garbage. "Parse ISO 8601 dates, handle timezone offsets, return None for invalid input" gets something useful.
- I treat AI output like code from a confident junior developer: often correct, sometimes subtly wrong, occasionally completely off base.
The craft hasn't changed. I still need to understand the problem, reason about edge cases, and take responsibility for what ships.
Skills Worth Building
Principles guide decisions. Skills make them possible.
Here's what I've found worth investing in:
Context engineering matters more than prompt engineering. A clever prompt won't fix bad context. I spend more time curating what information the model sees than crafting how I ask for things. Project documentation, coding standards, relevant examples. These matter more than prompt tricks.
Understanding tokens and context windows helps. You don't need to become an ML engineer. But it helps to know why your 50-file codebase overwhelms the model, or why it "forgets" earlier instructions.
Agentic workflow primitives matter more than AI theory. You won't build RAG systems from scratch. You'll use tools with these built in. What matters is configuring them: hooks that customize behavior, skills that extend capabilities, context management that keeps information relevant. I spend more time learning how my tools' hooks work or how to structure context files than reading ML papers.
For a comprehensive guide to building these skills, see A Skill Map for Learning AI-Assisted Development.
Why This Matters
I've seen what happens when teams adopt AI without thinking it through. Prototypes that demo well but collapse under real load. Codebases where no one understands why decisions were made because "the AI suggested it." Bugs that take days to track down because the generated code looked plausible but handled edge cases incorrectly.
The failure mode isn't dramatic. It's slow erosion: teams that gradually stop reasoning deeply because the model provides answers quickly.
The alternative isn't avoiding AI. It's using it with intention. The engineers I've seen do this well have gotten faster and more thoughtful. They use AI to handle the routine and focus on the hard problems.
What's Next
These principles aren't final. I expect to revise them as tools improve and as I learn what actually works versus what sounds good in theory.
If you're experimenting with AI in your engineering work, I'd be curious to hear what's working for you. What would you add? What would you challenge?
Credits
This blog would not have been possible without the review and feedback from Greg Reiser, George Song and Karthika Vijayan for reviewing multiple versions of this post and providing patient feedback 😀.
This content has been written on the shoulders of giants (at and outside Sahaj).
Top comments (0)