AI and 2026

It’s true: I am a significantly more productive software engineer with AI coding assistants. I’m shipping more complex features, faster. Debugging is faster.

My tool set hasn’t changed much since my AI and Software Engineering August 2025 post, but how much I use each tool has changed slightly. I did add Claude’s web interface (2%). Claude/Claude Code (90%), ChatGPT (5%), Cursor(3%).

My experience so far hasn’t convinced me software engineering roles will disappear any time soon.

My day to day work still has ambiguity, communication, and coordination challenges. It feels like the current tools can help with these challenges and compound them!

Where AI Still Struggles

As much as AI has helped me produce code, the areas it struggles with are outside of the codebase entirely.

Collective system ownership makes it harder to provide the correct context to the AI tools. The most important context exists outside of code. Examples: resolving conflicting priorities, strategic changes, organizational restructuring, and reacting to externalities. Each of these shifts can cause churn in software but they occur outside of the codebase.

Companies still have to agree on which problems matter, make decisions around cross-cutting concerns, and disseminate that information clearly enough for humans (and increasingly AI tools) to act on it.

The output of AI tools is only as good as the context provided to the tool. The tools aren’t sophisticated enough to ask “Should we even solve this problem?”, and the solution space they explore is a context-local-maxima of sorts.

Finally, I contribute to a team. I’m not a solo-entrepneur-lone-genius-developer, I rarely ship projects that scratch my own itches. The systems I contribute to are far from Disposable Software. Businesses and their customers depend on it. This means other people have to approve the changes to systems. AI tools are (yet) not autonomously operating software, and actual humans have to be involved when they break.

While AI coding tools can enable rapid change cycles, I still have to take special care not to break integrations. A healthy test suite can be an excellent defense against AI coding tools breaking these integrations. See also Hyrum’s Law.

Communication Help

The Google SWE book defines Software Engineering as programming integrated over time. A nontrivial part of “integrated over time” is communication with your leaders and peers.

I’m regularly surprised at how much AI tools can help with the parts of Software Engineering that aren’t writing code. I’m also surprised at how infrequently AI-forward Software Engineers reach for these tools that would help them a ton.

I use Claude and ChatGPT regularly to do the following:

  • Produce simple diagrams (LucidChart MCP)
  • Writing assistant, but in really specific ways.
    • Prepending “ELI5” can be really helpful when you’re communicating complex concepts with folks that aren’t as familiar and don’t need in-depth understanding.
    • Catch grammar and sentence structure problems.
    • My writing can be verbose. I use the AI tools to rephrase or summarize.
    • Seeding a way to communicate trade offs. “Compare these two solutions and decide on one. Explain your reason.”
  • Help generating a Brag Doc by scanning MCPs for GitHub, Slack, Jira, Notion, Email, Calendars, etc.
  • Help generating weekly progress updates by scanning MCPs GitHub, Slack, Jira, Notion, Email, Calendars, etc.

AI Reviewers

There’s a lot of content out there about AI tools doing coding reviews and also performing targeted reviews for specific types of defects: security, performance, race conditions, etc. These are all excellent. Codex is my current favorite general purpose code reviewer.

Bootstrapping existing Repos for AI

I recently contributed to a repo I’ve contributed to many times, including in the dark ages before AI tools. The most recent time, the team invested time in its AGENTS.md, skills, and some of the types of things that can make AI tooling more effective. I had contributed to the repository many times with Claude before, but it had been a month or two since my most recent contribution. The difference was significant with the new AI tooling integration: I spent less time guiding the AI tooling and more time refining my plan before it was executed. The plan “we” generated was more effective than previous efforts: there was less rework after the execution phase.

Multiple Repo Context

AI has changed how I work through feature work that spans multiple systems. Let me explain.

There’s Full Stack Engineers and then there’s Full Stack Engineers for AI Infrastructure companies. When I work on a project that needs changes at several layers, the context required and often the code contributions themselves span multiple repositories.

As an example, adding a new end to end feature could mean:

  • Update an API Spec and docs
  • Update Frontend Dashboard with controls that call new APIs
  • Update Data Models
  • Update Control Plane mechanisms
  • Deliver a new component to Hypervisor / DPU
  • Update Hypervisor / DPU configuration
  • Add monitoring and metrics for the new feature’s performance / health

Early on I’ll open a claude session that is in a parent directory of all of my cloned copies of these repositories. In that session, I’ll work to understand feasibility, where the challenges are, and begin sketching a plan. I maintain a markdown file that maps which repository contains which responsibilities and possibly specific paths if there are repos with multiple responsibilities.

AI tools haven’t solved this problem for me, but it’s made this type of problem much more approachable.

What’s different?

  • I barely hand write code anymore.
  • The tedium around communication is lower.
    • I spend way less time diagramming or creating other communication aides.
    • I spend less time gathering context from disparate sources with MCPs that integrate into sources of context outside of the codebase.
  • The hard part is harder.
    • Since the cost to produce code is so much lower, our collective eyes have gotten bigger than our stomachs. The bottlenecks are largely the same but now the bottlenecks are so much more pronounced. Things like selecting the problem to solve, understanding the problem to solve, and making decisions on how to solve the problem are the bottlenecks. There’s probably another post on this entirely.

Coda

AI tooling greatly improved since my post last year about this topic. AI tooling isn’t perfect, and there’s tradeoffs you should be aware of before diving into them.

I’m bullish on AI for software engineering.