David Young

You might believe you should spend less time thinking about code because of AI. I strongly disagree! We’re watching this play out live where tons of AI generated code becomes a liability. At the end of the day, an engineer needs to be responsible / on call for code that gets shipped to production. If you don’t understand the system you’re trying to debug, you’re probably going to have a bad time. Yes, AI can help with all of this, if you set up the proper systems. You can have agents triage prod logs, look at errors, etc. You can speed up parts of the investigation, but an engineer needs to make the call. There might be serious customer or financial implications from that change. I expect the trend continue for trimming dependencies, vendoring code so you can modify it directly, preferring simpler systems with fewer abstractions, and spending waaaay more time thinking about system design and code maintenance. I’ve said this before, but it’s a great time to get familiar with CS fundamentals and some of the history behind what great software looks like. Many parts will be different in the coming years as AI progresses, but also a lot more than people realize will stay the same.

People that are building real things are all coming to this conclusion. You could argue that it’s because software engineers care about the code quality more than they should, but it’s really because if you don’t, you will get up with software that does not work well.

@tedcruz You suck

I am deeply concerned about what we are hearing about an Iran “deal,” being pushed by some voices in the administration. President Trump’s decision to strike Iran was the most consequential decision of his second term. He was right to do so, and we achieved extraordinary military results—including destroying all of their missiles & drones and sinking their entire navy. If the result of all that is to be an Iranian regime—still run by Islamists who chant “death to America”—now receiving billions of dollars, being able to enrich uranium & develop nuclear weapons, and having effective control over the Strait of Hormuz, then that outcome would be a disastrous mistake. The details are still coming out—and I pray the early reports are wrong—but the fact that Biden’s Rob Malley is praising the deal is not encouraging. President Trump believes in peace through strength, and his strong leadership has already made America much safer. He should continue to hold the line, defend America & enforce the red lines he has repeatedly drawn.

Ok, confession time: I use agentic coding *all the time* and *every day*. And have been doing so for many months. I am *terrified* of skill deterioration on my side. I see the studies, I can feel it myself. The agents make me much more productive, but I feel I need to force...

The main thing that LLMs have done in software is bring back the idea that productivity is measured in lines of code per day. An idea that has been debunked, disproven, and discredited repeatedly every few years in my long software career.

@iammukeshm I have a system running on aspire that is .net, rust, go, and JavaScript. You can run whatever with it and it is awesome

Aspire vs Docker Compose is not the right comparison. They are two different things, sitting on two different layers of the stack. Docker Compose manages containers. It does not care what runs inside them. To Compose, a .NET API and a Python worker are the same thing: a process inside a container with a port and a volume. Aspire is an application model for .NET. It understands your projects natively. It can run an ASP.NET Core API without putting it in a container. It wires OpenTelemetry, health checks, and resilience into the project itself, not into the container around it. The dashboard shows logs, traces, and metrics for each project, with correlation IDs, in one place. For local .NET development with multiple services, this is the better experience. You get a dependency graph, hot reload still works, and you skip the docker-compose.yml drift between developers. For production deployment across heterogeneous stacks, Compose, Kubernetes, or your cloud's container service is still where you end up. Aspire is not trying to replace any of them. They are not competitors. They solve different problems. If you mostly work on .NET projects, Aspire is what makes local development easier. Docker Compose or Kubernetes is what you still use to deploy. I break down .NET tools like this every Tuesday in my newsletter. Link in profile.

This was a pretty incredible journey. I rememeber when .NET had its own version of distributed tracing (didn't everyone before otel??). Now it's a no brainer, if you aren't using otel for tracing you should be. aspire.dev/dashboard/stan… #otel #aspiredev @aspiredotdev

In an early meeting at Facebook (c. 2007), when I was describing the goals of Facebook Platform (an area I oversaw) Bill Gates yelled at me/us. His quote has stuck with me to this day: “This isn’t a platform. A platform is where the collective sum of revenues of the participants exceeds those of the platform itself.” Ladies and gentlemen, I present to you the tokenmaxxing circle jerk.

Creator of C++, Bjarne Stroustrup: AI-generated code isn't ready — it generates more bugs, more bloat, more security holes, and is nearly impossible to validate "senior developers are already retiring rather than deal with it" The problem is that even a small prompt change can shift the entire codebase in unpredictable ways

Amazon set weekly AI usage targets for employees, and now they're using an internal Claude clone called MeshClaw to do pointless work to hit quota. Congratulations on inventing the billable hour from first principles.

The issue with AI capex so far is that, even though the tools are useful (and I’m the first one using them), they don't provide an ROI meaningful enough to justify the investment. Sure, deep research and agents are cool, and the help with coding as well, but at the end of the day the areas where these can be applied at an economic profit (ie. accounting for opportunity costs and hidden labor costs) are limited. Ask yourself: if these tools provide such a big productivity increase, why aren't there more innovative products being built? Most of what you see in the indie space is dashboards or spam tools, and on the corporate side, not much either.

There are other big culture lessons about being willing to let go of things that have made you successful in the past in order to pave the way for the future. - Communication still matters - Product feedback from customers is still important - We still need software engineers that can steer the agents - cost of production has gone done, cost of maintenance has not gone down

A really good post to read to think about what's happening in tech right now, largely SaaS but also the FAANG companies. There was a point at a former job where I lifted my head up from being in the product world for a few years and saw what had become a wildly large company where suddenly there were people and projects just to feed people and projects. empire builders built shanty towns of headcount just full of context carriers. i'd see 3 people saying they "owned" the same middle context between product and customer facing people. gatekeepers who owned gates in an open field with no fences. Then there was a point at a former job where i'm pretty sure 2/3 of the people I spoke to were context carriers..

"Nobody reviews compiler output, why review AI code?" Wrong. We do review compiler output. Godbolt exists. Disassemblers exist. Anyone doing serious performance work reads what the compiler produced. The premise is false. But the analogy itself is flawed. It compares two things that aren't comparable. A compiler takes a formal language as input. Languages with grammars and semantics defined precisely enough that "what does this code mean" has only one answer. An LLM takes natural language as input. Natural languages are ambiguous. "Write me a function that handles user input safely" has a thousand valid interpretations and a thousand more invalid ones. The LLM picks one. You don't know which. Unless you look at the code. Compilers are built from specifications and designed to meet them. The output is the result of a defined translation. When the output violates the spec, it's a bug. LLMs are built from whatever was in their training data. There is no spec. There can't be one, natural languages have no defined semantics that map to code. Compilers are semantically deterministic. The same input produces output with the same behaviour, every time. LLMs are not. Partly by design and partly due to hardware variance, batch size, inference order, and floating point operations (and no setting temperature to zero does not address those). All of which can push the same prompt to produce different code. Compilers complain loudly when the input is nonsensical. LLMs fail silently, producing plausible-looking, but wrong code. We trust compiler output because the trust was earned across decades of use, with millions of engineers using the same tools. Early compilers were reviewed heavily. Hand-written assembly was the default because trust hadn't been earned yet. We're at the hand-written assembly stage with AI. We may never get to the trust-the-output stage for the reasons explained above. If you’re a software developer, you should own what goes to production. The compiler analogy is a way of skipping that responsibility.

Every time I see a team celebrating their new "shared module," I remember this lesson. Reuse is a dangerous form of coupling. They found the same logic in two places and did what good engineers do: put it in one place and called it a win. Clean, responsible, textbook. Six months later, someone needs to change it. Suddenly, a small update for one team's requirements breaks three services, blocks two releases, and triggers an emergency meeting between people who've never talked to each other before. This is the cost nobody preaches about. DRY is one of those principles that feels unquestionably right until you apply it across team boundaries. The moment you share a module between domains, you're not just sharing code. You're creating a dependency that nobody owns and everyone resents. Before you reuse, ask: Will this change often? Does it belong to one domain? Are the consumers truly aligned in purpose? Will one team’s change surprise another team? If the answer to any of these is "I'm not sure," stop. Duplicate it. I know how that sounds. It feels lazy. It feels like the thing a junior developer does before they know better. But here's what nobody wants to say out loud: two independent implementations you control are almost always cheaper than one shared one serving masters with different goals. Duplication is a local problem. Coupling is an organizational problem. One of them you can fix in an afternoon. The other requires a meeting with five teams and someone's manager. Reuse isn't free. Treat it like the trade-off it is.

Understanding implementation details will still be a differentiator for you as a software engineer.

Most developers think productivity comes from writing more code faster. In reality, productivity comes from writing less code with fewer consequences. Every line you add increases maintenance, complexity, and future risk. The best engineers are not the fastest writers, but the most selective ones.

We can do orders of magnitude more with agents, but it turns out that building bug free reliable software still takes a huge amount of effort. Now that we can do more, we have to much even more effort into making the software reliable. You can see these companies crank out more features, but rarely are they high quality. You can feel the jank after the honeymoon phase of the first 5 minutes of use.

Compiler construction is one of the oldest, best understood CS fields. It's decades of work by the brightest minds, and it's grounded in logic, informed by experience and strictly deterministic. Comparing that with LLM-based coding agents is just wrong. x.com/IceSolst/statu…