The weekly letter from Systems Thinking Lab: systems thinking insights for junior engineers, framed through the seven building blocks.
Fortune reported last week that Cisco's president, Jeetu Patel, has given a 27-year-old engineer no cap on AI tokens and a goal of refactoring 98% of Cisco's legacy code within 24 months. The engineer says a two-person team can do it. The article is clear that this is a goal, not a result. The engineer has four weeks to show it can be done.
Patel says companies need young people who challenge the status quo. Elsewhere in the piece he describes his team as three groups: experienced operators, "outside-in systems thinkers," and AI-native founders and engineers.
The Hacker News thread under the story was mostly worried, and I think the worry was the right one. Legacy code is code that few people at the company still understand. Hand it to a machine to translate, and you can end up with new code that nobody understands either, just written in a newer language and a lot faster.
I did not want to stop at agreeing, so I left two comments on the thread. Here is the part that matters:
But what if while the code was being refactored the AI was asked in addition to keep a ledger of the changes it made and why.
And then:
That ledger could be the basis of providing understanding to a code base that most likely had minimal corporate understanding in the first place.
I said "most likely" on purpose, because I do not know what Cisco's code looks like inside. A ledger is text. It can be read by the next person, searched, and corrected, which means the understanding does not stay in one team's heads. It can travel.
The line in my comment that I care about most is this one: "I don’t believe it has to be this zero sum game where either you use AI and lose understanding or you don’t use AI and gain understanding." I think there is a way to do both, because "if used properly, AI could be the best teacher we’ve had."
Here is the practice version. You do not need a Cisco-sized project to try it. Take the module you have been meaning to refactor, maybe this Friday. Before the agent touches anything, write down what you expect to find: what the module does, what depends on it, what you think is ugly and why. Then ask the agent to keep a record as it works, what it found and what it changed and why it changed it.
Then read that record. This is the step people skip, and it is where the learning is. Every place where the agent found something you did not predict is a place where your picture of the system was wrong. Every change it explains badly is a change you should not accept yet. The agent does the typing. The judgment lives in the reading.
Kay
P.S. The ledger habit is the same one Course 0 teaches as the plan-first loop: say what you expect, let the agent work, then read what it recorded. Course 0 starts here: https://systemthinkinglab.ai/course-0