If you’ve been reading recent Hacker News threads, you’ve probably noticed a recurring tone: a recurring mourning for “craftsmanship” in software, for the clay-in-hands feeling of shaping code line by line.

Here’s some evidence:

• “We mourn our craft”
• “I miss thinking hard”
• “I started programming when I was 7… the thing I loved has changed”
• And, of course, existential dread about “slop” eating the internet

If we borrow the “five stages of grief” as a metaphor, it feels like part of our industry is hovering around depression. Not because people are lacking resilience, but because the change is structural, not cosmetic. And structural change hits identity.

The next stage is acceptance.

Not “AI will code everything,” but “AI will code most of it”, and in many teams, it already does. But what does that mean? Simply put, software engineers will delegate most tasks to AI.

Here’s some truth about professional software:

Most developer time isn’t cathedral-building. It’s digital plumbing.

It’s reading code, changing code, moving data between systems, integrating APIs, handling edge cases, and keeping production stable.

That’s exactly where “agentic coding” is already meaningfully useful, because it’s fast at the repetitive, low-cognition parts, and when you can verify outputs/diffs (with your own eyes) cheaply. So why not use it in this context?

But bear in mind: most tasks don’t mean most value. So at a minimum treat agentic coding as a great tool to delegate lower-value tasks so that you can spend more time on higher-value work.

A practical ladder (most to least delegable)

There are many levels of delegation; it isn’t (and shouldn’t be) all-or-nothing. The less complex, less sensitive, and more reversible a task is, the more you can delegate the bulk of the work and let the agent drive. At the other end of the spectrum: complex or high-stakes work where failures are costly and reversals are painful, you keep your hands on the wheel.

What I’ve experienced in real projects

When the codebase has clear boundaries and coherent architecture, agents can be genuinely productive. When it’s spaghetti code, agents degrade quickly and produce mediocre output, because the system itself has weak signals.

Starting projects from scratch with agentic tools is also possible, but usually harder. You can make it work, but only if you provide much stronger specs. The broader and more ambiguous the task, the worse the output variance.

In other words, agents excel when scope is narrower, objectives are explicit, and review is cheap. The best use cases are tasks you’d feel comfortable coding yourself: you can write clear instructions, verify results, and do small adjustments before shipping.

That’s where the efficiency gains are real.

So, how to stay ahead in an agentic world

It isn’t about typing faster. It’s about moving craftsmanship upstream.

When agents write more of the code, the “handmade” part doesn’t disappear, it relocates. Craft becomes the ability to shape intent into constraints, turn ambiguity into decisions, and build systems where correctness is the default, not a happy accident.

Acceptance is not surrender. It’s admitting that most work is plumbing, and choosing to spend your human attention where it compounds: on higher-value, higher-stakes tasks.

So I say embrace the new paradigm agentic tools enable, where specification and intent are ever more important, low-complexity tasks delegated in bulk, and we can leverage our time to focus on higher-level challenges.

In Oct/2024 I asked ChatGPT for a portfolio to endure a messy world (original post here). At that time I expected the Israel–Palestine conflict (on top of Russia–Ukraine) to be the main driver of financial uncertainty in the coming months.

Fifteen months later, the conflicts are still there, but the volatility came from a different menu: U.S. surprises, Trump’s tariff war, a U.S. strike on an Iranian nuclear facility, and most recently Maduro’s capture.

This post is my promised check-in: what would have happened if I’d followed ChatGPT’s financial advice? I re-ran the original constraints using a 2024 model snapshot, translated the output into a real ETF portfolio, and measured the results.

The portfolio setup

The original post suggested a broad allocation. To make it testable, I re-ran a prompt in the old GPT-4o model (via OpenAI’s API, specifically gpt-4o-2024-08-06 to avoid lookahead bias) to generate a concrete, investable portfolio, using the exact constraints from that post.

Here’s the generated response:

This gave me a realistic, investable snapshot of “what ChatGPT would have done” at the time.

The results (Oct 4, 2024 → Jan 27, 2026)

A couple of days ago I pulled the adjusted prices (dividends, splits, capital gains) from Yahoo Finance (e.g., GLD history) and calculated the ROI for each sleeve.

Portfolio result: +23.74% over 15 months. Not bad.

Closing thoughts

Net result: the portfolio held up. Most of it came from a surprisingly good gold run, with stocks doing their job and everything else mostly hovering. That’s encouraging, since diversification did its job, and also a warning, because one lucky ingredient can dominate the outcome.

So: would you trust an AI to build your portfolio, or are you already using it (even if just as a second opinion)?

I walked into a budget meeting expecting the usual spreadsheet tour: what went up, what went down, and where we should trim next year. We did that. But in the middle of the call, something else surfaced: we were debating how decisions should happen, not just what the numbers were.

Someone suggested a simple rule: any spend above a threshold should go to a committee for approval. It was well-intentioned, practical, and it looked good on paper.

My first reaction was: this won’t work.

Not because the threshold was too high or too low. But because the framing was off. It pushed strategy down to the operational level. It asked leaders across the company to act like mini-CFOs, to weigh trade-offs they don’t have context for. It created a system that depended on individual judgment instead of a repeatable path.

That’s the opposite of systems thinking.

Systems thinking

Systems thinking means you don’t fix outcomes only by giving people more decisions, you fix outcomes by designing the system that shapes decisions. If you want different behavior, you redesign the structure: the incentives, the sequence, the guardrails.

In practice, that means leadership has to do the hard part: define the path and remove ambiguity. The operation executes within that path.

So instead of telling everyone “spend less,” I prefer to ask: what are the rails that will naturally lead to better spending?

Enabling constraints (the rails)

That’s where enabling constraints come in. They are rules and flows that:

• limit the decision space,
• make the right choice the default,
• without killing autonomy.

In our case, the first draft of the policy was “anything above X needs approval.” The system-thinking version was different:

• First, internalize. If a request is about an external vendor, the first step is always to route it through the internal capability. Only if that path is exhausted does the approval flow even start. The point isn’t “protecting internal teams.” It’s reducing avoidable spend and fragmentation when the capability already exists, and escalating fast when it doesn’t.
• Second, decide in the right moment. The worst time to approve a vendor is when the proposal is already on the table and the deadline is tomorrow. The flow needs to exist upstream, where the decision can be made calmly.
• Third, separate strategy from execution. Teams should focus on delivery and client outcomes. Leadership should define guardrails with the people who run the work and monitor the system.

The difference is subtle but huge. Instead of asking people to make better decisions in chaotic situations, you reshape the process so the right decision is the easy one.

None of this eliminates judgment. It just moves judgment to the right layer: design the default path once, then let the organization run it repeatedly.

What I proposed

I proposed a lightweight “rail system” built around the reality of our operation:

1. Define the default path. For certain categories (vendors, external analysis, specialized work), the default is internal first. If it can’t be done internally, the request escalates.
2. Make the moment explicit. Add checkpoints inside the workflow where the request must be raised early, not when it’s already late.
3. Keep approvals simple. No ceremonies, no weekly meetings, no bureaucracy. Just clear inputs, fast review, and a decision trail. Clear inputs = scope, deadline, expected outcome, alternatives considered, and a rough cost envelope.
4. Define exception paths. Legal/compliance requirements, incident response, hard external deadlines, or unique expertise not available internally. If an exception applies, the flow skips steps, but still leaves a decision trail.

In other words: leadership designs the system; the team follows the rails.

Closing thoughts

This is not about being “tough on costs.” It’s about clarity. If you want a company to scale, you cannot rely on individual heroics or ad-hoc judgments. You need a system that consistently nudges people toward the strategic path.

And building those systems is not easy. You need to identify what should change, understand why the current structure enables the old behavior, visualize alternatives, and think through side effects, incentives, and how to earn buy-in from the people involved. That’s real work.

You know the rails are working when urgent approvals go down, repeat vendors consolidate, and lead time for “yes/no” decisions becomes predictable.

The easy thing is to outsource the problem to leaders who are already constrained in their day-to-day. “Just approve everything” sounds simple, but it’s naive to think that passing the burden downstream will solve the root issue.

Build the rails. Then let the train move fast.