As someone else mentioned here: not all technical debt is created equal. I agree, sometimes the problem are changing requirements, etc. But it is also true that there is technical debt caused by developers who don't take the time to properly design features and will simply implement the first thing that came to their minds. I agree with the author, this kind of technical debt is caused by a mediocre attitude which often propagates to all the team if there is no one that calls it out.
The more interesting discussion to me is: how do you solve this problem once it exists in a team? I guess there are many approaches, but I tend to think that 'lead by the example' is the best you can do as an engineer, but a top-down approach might work better which is what happened at Microsoft when Satya Nadella became CEO.
perhaps that was involved, but one thing clearly purposeful was people were seriously filtered for particular skills and personality (apple fit it was called back then), which created groups where individuals had unique skills and collectively the group members would naturally want to collaborate. it worked great.
(as an aside, this contrasts diametrically with Amazon, where i worked for a year for healthcare, not needing to because of Apple years' savings, but after a genomics startup i had joined ran out of funding, and wanting a new challenge; there skilled engineering types were presumed to be fungible assets for (not kidding) at least 7 layers of do-nothing bureaucrats making huge salaries...they could survive because sales on the amazon store extract something like the 30% royalty to amazon)
> "I expect us to go back to extending our agents with the most accessible programming language: natural language."
I don't agree with this. Natural language is so ambiguous. At least for software development the hard work is still coming up with clearly defined solutions.
There is a reason for why math has its own domain specific language.
Natural language can be bent into arbitrary precision. Write something, then enter a read-rewrite-reread loop as the devil's advocate (this is key) until it stops being ambiguous or having multiple conceivable interpretations.
Yes with English this process can be a pain in the butt, until you get the hang of it.
The problem is that it's very hard to anticipate all possible edge cases. Programming languages force you to do a lot of that work up front, English doesn't. It's the difference between writing Javascript and writing Typescript, except orders of magnitude worse.
The problem is, what's ambiguous or precise is subjective. Your devil's advocate needs to reflect all of the possible readers, and that isn't possible.
There's a good reason we use jargon in professions, or more constrained and less ambiguous languages for maths/coding
Was a pain to set up, but you can score the context completion and then if the score is under 98% or something, “ask” clarifying questions of the requesting agent or person or system
You’re never going to make a nontrivial statement in English that you couldn’t find two people who wouldn’t perfectly agree on its meaning. Or probably even a trivial one. Sure, at some point you can say “no, you’re clearly misinterpreting what I’ve said” or “you’re inferring something that wasn’t implied”, but English doesn’t have a formal spec or a reference implementation, so that’s kind of meaningless.
I was thinking the same thing. Maybe is that at the end the author seems to imply that agentic AI will work simply because models have become better regardless of the way we make them agentic (i.e. MCPs, skills, etc).
I think this is purely first mover advantage. We get stuck with bad products simply because those were the first products on the market. It is difficult to change them once everyone uses them. The same applies to the adoption of IT on the banking industry. Now we are stuck with COBOL and systems that are hard to migrate without damaging the economy.
The more interesting discussion to me is: how do you solve this problem once it exists in a team? I guess there are many approaches, but I tend to think that 'lead by the example' is the best you can do as an engineer, but a top-down approach might work better which is what happened at Microsoft when Satya Nadella became CEO.
reply