I'm not worried about AI job loss

Systems engineering is an extremely hard computer science domain with few engineers either interested in it, or good at it.

Building dashboards is tedious and requires organizational structure to deliver on. This is the bread and butter of what agents are good at building right now. You still need organization and communication skills in your company and to direct the coding agents towards that dashboard you want and need. Until you hit a implementation wall and someone will need to spend time trying to understand some of the code. At least with dashboards, you can probably just start over from scratch.

It's arguably more work to prompt in english to an AI agent to assist you in hard systems problems, and the signals the agent would need to add value aren't readily available (yet?!). Plus, there's no way systems engineers would feel comfortable taking generated code at face-value. So they definitely will spend the extra mental energy to read what is output.

So I don't know. I think we're going to keep marching forward, because that's what we do, but I also don't think this "vibe-coded" automated code generator phase we're in right now will ultimately last. It'll likely fall apart and the pieces we put back together will likely return us to some new kind of normal, but we'll all still need to know how to be damn good software engineers.

This is no different than onboarding a new member of the team, and I think openAI was working on that "frontier"

>We started by looking at how enterprises already scale people. They create onboarding processes. They teach institutional knowledge and internal language. They allow learning through experience and improve performance through feedback. They grant access to the right systems and set boundaries. AI coworkers need the same things.

And tribal knowledge will not be a moat once execs realize that all they need to do is prioritize documentation instead of "code velocity" as a metric (sure any metric gets goodhearted, but LLMs are great at sifting through garbage to find the high perplexity tokens).

>But context limitation is fundamental to the technology in its current form

This may not be the case, large enough context-windows plus external scratchpads would mostly obviate the need for true in context learning. The main issue today is that "agent harnesses" suck. The fact that claude code is considered good is more an indication of how bad everything else is. Tool traces read like a drunken newb brute-forcing his way through tasks. LLMs can mostly "one-shot" individual functions, but orchestrating everything is the blocker. (Yes there's progress in metr or whatever but I don't trust any of that, else we'd actually see the results in real-world open source projects).

LLMs don't really know how to interact with subagents. They're generally sort of myopic even with tool calls. They'll spend 20 minutes trying to fix build issues going down a rabbit hole without stepping back to think. I think some sort of self-play might end up solving all of these things, they need to develop a "theory of mind" in the same way that humans do, to understand how to delegate and interact with the subagents they spawn. (Today a failure case is agents often don't realize subagents don't share the same context.)

Some of this is certainly in the base model and pretraining, but it needs to be brought out in the same way RL was needed for tool use.

Good accounting teams will have more time and resources to do things like identify fraud, waste, duplicated processes, etc. They will also have time to streamline/optimize existing practices.

Good teams will earn many multiples of their cost in terms of savings or increased earnings.

There may be increased competition for the low-cost “just meet the legal compliance requirements” offerings, but any business that makes money and wants to make more will gladly spend more than the minimum for better service.