My problem with spec driven development is that no one reads the specs (writer or reviewer), invariably they have issues (because we learn as we build), and then code changes end up modifying specs and Linear tickets. Or they don’t and they get out of sync.
Is there a solution within SDD?
There’s a moment when you can tell a person has started posting completely on behalf of their sponsors. And that realization is accompanied by thinking about the calculus (when were they promoting something and I just didn’t realize). And this is painful because if we looked up to that person, we probably saw ourselves in them. And it feels like a betrayal.
Anyhoo, how about all cool shit SpaceXAI is doing????
An agent just suggested a simpler way to do something. @claudeai Opus 5.5 may just be AGI.
I’m constantly amazed by how well engineers can read and analyze graphs in DD. This is something I want to improve on.
Words and phrases I never want to hear again because AI:
- drain
- “rides along with”
- input bag/data bag
- snapshot
- outbox
Day 1 using @bot for work. I like the primitive of a coworker, but so far, not terribly impressed with how it functions. Hitting a lot of “no, I didn’t actually look” when I ask it “are you sure?”
So I guess it’s sort of like a real coworker in that regard.
The number of likes or follower a person has does not correlate to their ability as an engineer. Nor does one style of engineering work well everywhere. Engineering a successful solo project prob doesn’t translate to working on a team, yet their voices are the loudest.
> look at repo's dependencies to learn more about TypeScript open source projects
> first dependency "node-cache"
> open up GitHub and look at the code
> written in CoffeeScript
The best time to teach kids programming is probably right after they have solved a bunch of algebra equations. “Hey, this is tedious and sucks, right? What if I told you that you there’s a way to make the computer solve these?“
Just had a full day of work. Had AI agents running for most of it. Sat in meetings for half of it.
Coding nor software engineering is solved.
Well…. shit.
The thing I learned this year is that when engineers say they like working on “hard problems”, they actually don't. What they like is puzzle solving, and having a repertoire of patterns that they can pattern match onto traditionally hard problems, usually involving databases or something with scale, etc. And they know that the industry used to pay you a lot for how deep and broad this repertoire was. Unfortunately, in 2026, well, you have a cheat code machine that has infinite breadth and depth for pattern matching. So the question is, do you actually like hard problems? Because there are now hard problems that are a complection of engineering, product, society, culture, politics, and they are fairly intractable, probably unsolvable! Because if you do want to work on those actually hard problems, there is so much money that people will pay you for it. But you’ll have to face that truth about yourself first.
Had a rough day with the agent today. The code -> review -> feedback loop blew up a (relatively) minor task into something I needed to split into 3 PRs. And the more I went along, the less confidence I had that we were getting closer to the solution.
I dislike that feeling. How do I prevent it from happening within a session?
I love the idea of @cursor_ai Projects, but they feel a little overreaching. Behavior is opt-out rather than opt-in. I don’t want you merge PRs, leave review comments, or change the code based on a teammate’s suggestion: leave those executive decisions to me.
For people who job hop frequently: how do you deal with having to watch so many harassment training videos each year?
I think the future is an inverted pyramid of testing. Unit tests: few people read because there are so many of them. A codebase at 100% test coverage is going to make changes more painful, and token cost explodes. Without careful guidance (telling the agent “these 5 tests locked in shitty behavior, change the tests”) the agent is going to write weird hacks to make the original test pass with the new behavior.
Now how to make e2e and integration tests fast is another problem all together. 😅
Yep. Then they’ll tell you how to make it work for your company, and where it falls short is your fault.
There will be no doubt books written on the AI revolution. I’m most excited to read the one about how companies and people botched the transition.
Ranging from the corps who held an all hands and said “you are worse than an LLM so start using it” to the ones who didn’t use LLMs at all. Most interesting in my limited experience is how poorly companies try to raise the floor on LLM adoption or empathize with their employees.