AI Can't Fix Your Engineering (Yet)

There's an interesting parallel between AI and Captain America's Super Soldier Serum: both of them greatly amplify who you fundamentally are as a person. If you're a competent engineer who knows what you're doing, AI will 10x your output. If you're an incompetent one, relying on AI as a crutch, and aren't anal about sound coding standards and engineering, it amplifies that too. (If you've seen the films, Captain America vs Red Skull should ring a bell)

Personally, having been using AI tools extensively myself, the one insight I've found is this: AI is a force multiplier, but it's far from a replacement for sound engineering judgement. Using AI tools effectively is itself a skill, one that must be learned and perfected.

Software Engineering Fundamentals

Let's go back to the fundamentals. The 4 stages to software engineering that we're familiar with haven't changed at all, even with the advent of AI:

1. Research: understanding the actual problem.
2. Plan: deciding on an approach and planning what needs to be done.
3. Implement: writing the actual code.
4. Review: reviewing and testing the code that was written.

If you're only using AI to implement, but are skipping any of the research, plan, or review steps, you are set up for failure. You're such a user if you immediately dive into asking the agent to do up a non-trivial feature by giving a one-liner prompt. Maybe if you're feeling a little bit more hardworking, you start reviewing and steering them once the code is done. This is extremely ineffective, both in terms of token usage and your time.

The better approach is to continue with these 4 stages as per usual, but have AI assist you in each stage. The most important stage is the planning: it's where you decide whether the approach is correct or not, not after the code has already been written. Think of yourself as the Tech Lead, and the AI tool as a very hardworking (but ultimately) junior engineer. You'd likely be extremely careful about everything they did, from their overall approach, all the way to how they're writing each line of code. Steer the AI during the planning stage, not during the implementation stage.

PR Discipline

Ever since agentic coding became a thing, open sourced repos have been taking the brunt of PR spams. This same problem occurs everywhere: when the cost to produce code no longer takes tangible human time, it's easier than ever to bloat up PRs.

Similarly, the fundamentals of what makes a good PR haven't changed. You know the drill: scope each PR tightly, separate feature changes from unrelated bug fixes or refactoring, etc. Resist the temptation to let the agent go wild and start "cleaning" up things just because.

You still own the diff, and the burden of reviewing the PR still falls on your teammates. Your respect for their time doesn't change whether you're using an agent or not.

Ditching AI

Over reliance on AI is a real phenomenon, and we need to know when to ditch it. It's fine to let AI write the code for you, the same way it's perfectly fine for a mathematician to rely on a calculator. However, a mathematician who uses a calculator still ultimately understands what the calculation represents, why they're performing it, and whether the result makes sense. Likewise, you as the agentic user must still understand what the generated code does, and why the agent wrote it that way. If you disagree with it, or spot improvements to be made - fix it. Your critical thinking must never be outsourced.

It's also imperative to understand that AI is extremely bad at domain specific knowledge, especially when that domain happens to be your business/company, of which it likely has 0 context of. The weird edge case that was handled for in a "hacky" manner, or the supposedly redundant line of code - these are context that only lives within you and your teammates' heads. Knowing these limitations exist is the first step in not over indexing on AI where it won't perform well in.

Efficient Context Engineering

"Context Engineering" feels like a buzzword. But it's an extremely important concept that an effective user of AI must know how to manage well. The common misconception is that more context is always better. Opus and Gemini for example, can theoretically handle up to 1M of tokens in their context window. Practically speaking however, the model performance degrades with respect to the context used. See Chroma's "Context Rot" study, which tested 18 frontier models and found that every single one exhibited dramatic degradation in performance as input length grew.

The basic principle is to keep your context as minimal and as focused as possible. Here's some practical things you can try:

• Start fresh sessions for new tasks: between unrelated work (eg. different independent features, bug fixes, etc.), always start a fresh session. Don't let the residual context of a previous work contaminate a totally different task.
• Know where your model's context limits are: no, not the 1M theoretical limit. The practical limit that's far lower (oftentimes 40%-60%) of the theoretical max. Knowing where the limits are allows you to know when things are getting out of hand.
• Reset sessions that are out of control: if a session feels like it's going on an endless path of wrong decisions after wrong decisions, it's often easier and more effective to simply start afresh with a new session. This way, you don't have a large part of the context filled with the wrong ideas.

Resisting Shiny Object Syndrome

In AI land, something new seems to launch every 3 hours: new tools, new models, new frameworks, new harnesses. With each new launch comes a torrent of Twitter threads and blog posts about why this or that tool is the one to use.

Resist touching that shiny new object.

In truth, most frontier models and their harnesses are quite similar in capability already. The differences are less than marginal for practical engineering work. Having mastery of a single tool, knowing when it breaks and how to exploit it to its full potential, is much more important than chasing for the new model/harness that achieved some arbitrary percentage point on an arbitrary benchmark.

It's no different from choosing and mastering a programming language. You must invest the time to truly understand it: learn how it manages its memories, how best to prompt it for different tasks, where its context window breaks, its various strengths and weaknesses. There is a real learning curve and the best tool is the one you are a master of.

Conclusion

AI is but another tool in the software engineer's toolkit. One that is exceptionally worth mastering. As the tools become better, the engineer must adapt and improve as well - but this has always been the norm in the tech industry. Lucky for us, the fundamentals haven't changed (yet).

The serum amplifies who you are. Make sure what it's amplifying is worth amplifying.