Professional Development – 2025 – Week 35

AI

AI Is a Hype-Fueled Dumpster Fire

  • (Personally, I found the title misleading. It should have been something like “Understanding the Ethics and Risks of Current AI Tools”.)
  • Ethics — moral problems that require balancing benefits and harms to individuals and society
  • Risks — matters that should be on your business’ risk register
  • Ethical concerns
    • Common Crawl has a fair use policy for research, but not for products (which they can prove LLMs are doing by having them emit verbatim text). This has led to lawsuits by organizations whose content was used against fair use.
    • Data workers to evaluate model output are exploited
    • Energy usage (training, inference) is increasing; see Jevon’s paradox
  • Risk concerns
    • LLMs are biased because they’ve consumed the Internet (i.e., embedded bias). In some countries, if a tool your company uses causes unlawful discrimination, your company is liable.
    • Hallucinations… LLMs are stochastic parrots (it doesn’t have knowledge, it has probability distributions).
    • Bullshit summarization. If the text to summarize looks a lot like the training data, the training data has more influence on the output than the input text.
    • Psychology… Having relationships with AI, being encouraged to commit suicide.

Advanced Context Engineering for Agents (by Dexter Horthy)

  • Caveats from Geoff
    • I’m not linking to the YouTube video because I don’t think it’s worth giving it SEO.
    • It’s my opinion there’s a great deal of hype around AI, and this is another example.
  • The speaker praises Sean Grove’s talk at the AI Engineer 2025 conference about how code is like assembly language and we should just keep the prompts and throw away the code. I strongly disagree with the sustainability of this approach given the amount of waste (time, energy, cooling) required to start over every time.
  • “LLMs are pure functions.” This is literally false because of the stochastic nature of LLMs.
  • I agree with Geoff Huntley’s comment Dexter raised: “The more you use the context window, the worse the outcomes you’ll get.”
  • The three phases — research, plan, increment — make sense, and I’ve used prompts to do that with decent success.
  • His product (Human Flow) produces intermediate markdown files for HITL. He said, “You have to read this shit!” In my experience, few engineers slow down long enough to examine LLM output. It’s almost a habit to skim and accept at this point.
  • “If the plans are good, that’s good enough.” It seems considerably optimistic that one knows how to create good plans.
  • He bragged about being on a podcast where he used his tools on a 300 KLOC codebase and said there was zero slop. How can he know that given he admitted at the beginning of his talk that he doesn’t read code any more?
  • I looked at his company’s products, as I was especially intrigued what he was selling given his prompts are open source. All he’s selling is infrastructure (storage, SSO) and integrations (Slack, email). I don’t get it.

Coaching

Technical Coaching: From One Team to Many Teams

  • You can’t force coaching on teams: You have to encourage and recruit them.
  • Send a daily status email. What happened today with the teams in terms of value of coaching and team impact? Explain what you did and why it matters.
  • Send a longer summary after the 10-session engagement including things from the retrospective on coaching
  • Llewellyn Falco uses GenAI tools (including voice mode) to speed up this process.
  • Process file = multi-step prompt defining the coaching summary process
  • See https://github.com/sammancoaching/daily-status

Software development

Can We Fix Software Engineering Estimation?

  • Who wants to know when it will be done, and what decision rests on our answer?
  • Providing an estimate tacitly commits you to that number
  • How long it will take is a probability distribution of unknown shape, usually with a long tail (i.e., a lot more opportunity to be late than early or on time)
  • Most of what we do in software is some known thing plus some unknown novel thing
  • The thing you end up finishing can end up bigger than what you estimated (fractal growth)
  • Managers typically want scales (days, weeks, months) rather than point estimates
  • Work typically fits into three categories: too small to estimate, too many unknowns to even start estimating, everything else