Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The anatomy of an AI-native org

ajeygore.in

Post reply on HN
Print view View original

31–40 of 43 posts

Re: The anatomy of an AI-native org

#31

Post by g-b-r »

Morromist wrote: post #20

I love how this article has 3 sentences and then stops to quote the first two sentences. Also peppered with a lot of bad, redundant writing: "That’s the shape I’m watching for. That’s the shape I think wins." - those sentences both say the same thing and you didn't need either of them. I feel like that indicates they may not have understood HOW to write a coherent and professional article here, or, indeed, an article…

The how was not among the 5% of text that the agent shouldn't touch unsupervised

Re: The anatomy of an AI-native org

#32

Post by wuliwong »

>Not “product managers” in the old sense — not the ticket-writing, JIRA-grooming, sprint-planning archetype.

In my experience this is what a lot of product managers do but more importantly they are talking to users, talking to stakeholders, and having discussions with the the team to define the product. His description seems more of the project manager role.

> If a manager isn’t contributing to the why, the what, or the trust system that holds the how, it’s hard to say what they’re doing.

I think people management is a large part of engineering management. There are definitely other aspects that are significant but I the author made no argument for AI taking over people management nor did they really mention it at all. Also if the other work is all translation and is getting compressed, I don't think the author made any argument as to why the 'non contributing manager' suddenly has to contribute?

Seems like the author's old thesis was that non-contributing managers are inefficient or something. Then, without really explaining why they are saying that AI has made his argument stronger.

Re: The anatomy of an AI-native org

#33

Post by wuliwong »

Morromist wrote: post #20

I love how this article has 3 sentences and then stops to quote the first two sentences. Also peppered with a lot of bad, redundant writing: "That’s the shape I’m watching for. That’s the shape I think wins." - those sentences both say the same thing and you didn't need either of them. I feel like that indicates they may not have understood HOW to write a coherent and professional article here, or, indeed, an article…

Also, the overuse of the term 'harness' as if it was some normal CS term we have been using to describe our systems for years was a red flag.

Re: The anatomy of an AI-native org

#35

Post by chaboud »

p4ul wrote: post #9

> The work that’s left is more interesting and more valuable than the work that’s leaving. I'm not sure I agree with that. Many (or most) of the software engineers I know find the heavy reliance on AI coding agents/assistants pretty soul-sucking and uninteresting. I feel the same, and I'm looking for some kind of middle ground. For example, I will only use agents when doing so would not deprive me of learning and dis…

Agents can actually accelerate learning and discovery. Have them read out the work to you and ground it in terms you're familiar with (e.g., memory and threading models between C++, rust, java, python), and use them to research concepts while they also have a view of the code. However, if the model+harness doesn't have serious grounding in "why" and "what", they'll spiral off into the weeds, funny enough, just like a junior developer operating on directed work without clarity of purpose.

I've been explaining it like this:

Programming was 1% judgment and 99% effort, where lots of folks could carve out productive careers carrying that effort and receiving that judgment.

Agentic coding has cut that 99% down by at least a couple of orders of magnitude for some work. Well-judged and well-described systems can manifest quickly where effort alone would fail. The 1% is still there, but, by ratio after optimization of the sweaty part, it's at least half of where the value is.

I had an example of this this morning, where Claude Code left to run overnight on an open problem had made an absolute hash of multi-source grounded clustering. I course-corrected it with a rule (I don't like magic number tuning on small datasets) and a specific approach (use clustering with separating anchors/seeds), and it had the system working in 15 minutes (confirmed after a couple of hours of processing). These are the same techniques that we would use with junior engineers.

Along the way, it drafted reports and ran experiments that taught me about some of the limits of SOTA listening/characterization systems that I otherwise would have had to spend time researching.

Just make teaching you an explicit goal of the system, and you'll be able to swivel from opacity to illumination.

Re: The anatomy of an AI-native org

#36

Post by enjo »

>The 5% of the codebase the agent shouldn’t touch unsupervised.

This jumped off the page to me and it's an assumption that underlies everything else in the article. For the record I agree with the author that if it is true that 95% of the codebase should be unsupervised, the how layer does indeed become very small.

But my experience has given me little reason to believe that it's true. Code doesn't conveniently break in the 5% you choose to care about. Systems fail in seemingly random places very often in the seemingly uninteresting parts of the system. The macro and micro decisions that make code actually work have to be of high quality everywhere. They have to be fixable in the worst case by a human and that still very much requires a human to review nearly everything the agents generate.

As always there's a risk-management question here. You can choose to take on a lot of risk by increasing the amount of code that only agents touch. And maybe I am still too in the oughts with a belief that code should be secure, do what it says, and do it reliably. Turning over your code to unsupervised agents in such large quantities amps that risk level up to a place that I (at least) am not comfortable with it.

So ya I think the author is right in their model. Why, what, how is a great way to think about orgs. I agree that the output of the how layer has been pretty turbocharged and I agree that the how layer is going to shrink but I think I disagree with them by how much.

Re: The anatomy of an AI-native org

#37

Post by gabrieledarrigo »

Morromist wrote: post #20

I love how this article has 3 sentences and then stops to quote the first two sentences. Also peppered with a lot of bad, redundant writing: "That’s the shape I’m watching for. That’s the shape I think wins." - those sentences both say the same thing and you didn't need either of them. I feel like that indicates they may not have understood HOW to write a coherent and professional article here, or, indeed, an article…

> AI didn’t come for a job title. AI came for a task type

I just stopped reading here. It's frustrating how so many people can't simply write an article, a document, or a ticket.

Just use your words, come on!

Re: The anatomy of an AI-native org

#39

Post by blamestross »

This is all built on a premise that kinda scares me. Its not a new idea, it's one I have participated in my entire career. That concentration of power at the top labeled "why". It doesn't actually make sense, it just gives the people with power a narrative of security. "Why" should be a conversation up and down the org chart. If "what" doesn't come with why, you make the wrong "what". If "how" doesn't come with "why" you sabotage yourself. If your "why" can't survive effective communication and context, it was probably a bad call. If you feel like you "need to go fast" you are just gambling and looking at the world with survivorship bias.

Every engineering decision and debate I have seen has always boiled down to 2 things "people don't know the motivation for an action" and "people have incomplete knowledge of the situation". Normally both. Every single conversation, when poised in a "this is the high level goal" context, went from a debate to a constructive design session in seconds.

Failure to "propagate the why" is a tar-pit for execution and decision making.

Re: The anatomy of an AI-native org

#40

Post by p4ul »

chaboud wrote: post #35
p4ul wrote: post #9

> The work that’s left is more interesting and more valuable than the work that’s leaving. I'm not sure I agree with that. Many (or most) of the software engineers I know find the heavy reliance on AI coding agents/assistants pretty soul-sucking and uninteresting. I feel the same, and I'm looking for some kind of middle ground. For example, I will only use agents when doing so would not deprive me of learning and dis…

Agents can actually accelerate learning and discovery. Have them read out the work to you and ground it in terms you're familiar with (e.g., memory and threading models between C++, rust, java, python), and use them to research concepts while they also have a view of the code. However, if the model+harness doesn't have serious grounding in "why" and "what", they'll spiral off into the weeds, funny enough, just like a…

Thanks for your comments, @chaboud! I definitely agree that LLMs _can_ be an amazing tool for learning, but as you note, one must be intentional about using them that way. I feel like the messages being pushed down from leadership are NOT of the form "Use AI to learn topics deeply and discover new things." The leadership's perspective is more like "Use all the AI you can to ship as fast as you can."

Your comment about programming historically being 1% judgement and 99% effort is interesting. I'm not sure I agree with those exact percentages, but nonetheless, I think the more consequential part of your comment is that the 99% is being reduced by a couple of orders of magnitude. I think that's what ought to trouble us as software engineers. Expending effort is often how we learn and grow. This is true in the context of physical activity (e.g., going to the gym to strengthen muscles) as well as in the context of intellectual activity (e.g., struggling through a problem set). If I go to the gym with my forklift, I can lift things, but I'm not likely to get stronger. Similarly, if I have Claude write all my code, I'm probably not learning much.

Post reply on HN