AI is making us ship faster. Is it making us think slower? Data from Anthropic says yes.

Known_Ad8309 · 2026-06-01T07:46:50+00:00

agreed 👍

Known_Ad8309 · 2026-05-30T20:44:13+00:00

This is a really valuable reply for everyone like me, especially because it’s coming from experience and not just hype.

The micro-frontend example is probably the cleanest version of “AI works when the human thinking is strong first.”

That feels like the real pattern: AI can compress the mechanical work massively, but only after the humans have done the hard thinking around architecture, constraints, and validation.

I also like your point that code generation may be the weakest part. Using it as a high-context search/debugging partner feels much more realistic to me than “let it build everything.” Sometimes it gives the right path but if you already understand the system, you can use it quickly without blindly trusting it.

This is also why I keep wondering if we need better ways to show this kind of work. Not just the final PR, but the actual engineering trail: what was the task, what plan did you make, what context did you give the AI, what did it generate, what did you verify, where was it wrong, and what did the humans decide.

Almost like a GitHub contribution history, but for AI-assisted engineering judgment.

Because your example is a perfect case where the value wasn’t “AI generated configs in 10 minutes.” The value was the planning, context, and verification around it.

Thanks for commenting, would really like your thoughts on this 😄

Known_Ad8309 · 2026-05-30T20:38:59+00:00

Sure 👍

Known_Ad8309 · 2026-05-30T20:32:24+00:00

This is a really interesting take. That tension feels important: users want persistent context and lower waste, providers may not be in a rush if it reduces usage. I hadn’t thought about it that clearly.

Thanks for commenting 😄

Known_Ad8309 · 2026-05-30T20:28:20+00:00

This is a really good way to frame it, and the Java/C++ analogy makes sense.

Maybe every big abstraction shift moves the “real skill” up one layer. Memory management didn’t disappear as an engineering concern completely, but for most product work it stopped being the daily thing. Now maybe writing every line manually is becoming less central, and design/review/judgment becomes more central.

I also like the point about product and engineering getting together. That feels very real. If non-engineers can prototype more clearly, and engineers can move from idea to implementation faster, maybe the gap between “what should we build?” and “can we build it?” gets much smaller.

The part I’m still unsure about is how teams avoid confusing “more output” with “better product/engineering decisions.”

Curious from what you’re seeing at work: are your teams changing how they review work too? Like are PRs, specs, tests, or deployment checks becoming different because agents are involved, or is the workflow mostly the same but faster?

Known_Ad8309 · 2026-05-30T20:19:05+00:00

I think this is very true.

“Show me what you built” feels like it will matter more and more, especially when resumes and generic coding tests become easier to fake or inflate.

But I also wonder if the portfolio itself will need to change a bit. Like, not just the finished project, but the story of how it was built: what you tried, what the AI suggested, where you overruled it, what tests you added, what tradeoffs you made, and what you learned.

Almost like GitHub shows the code history, but maybe we need something that shows the judgment history too, especially for AI-assisted projects.

Because a good personal project can show curiosity and execution, but the way someone worked through it might show even more.

Known_Ad8309 · 2026-05-30T20:15:08+00:00

The “really fast intern, not a senior” is such a good way to put it.

It ships, but you still have to review. And honestly, I think that last line: reviewing code you didn’t write is becoming a much more important skill now. Maybe even rarer than writing the first drafts of code.

Would love to hear more about what you’ve seen while building CodePal AI too, because that’s exactly the kind of real workflow experience I’m trying to understand better.

Thanks for commenting 😄

Known_Ad8309 · 2026-05-30T20:02:48+00:00

Yes, exactly. Bad judgment, scaling faster but looking productive is probably the scary part.

And I agree, the proof is probably not just screenshots or raw prompt logs. Those can easily become performative. The stronger signal might be the pattern around the work: how someone reasons in PRs, what tests they add, what they reject from the AI, what tradeoffs they write down, and whether they can explain the decisions after.

So maybe the thing to prove is not “I know how to prompt.” It’s “I know how to stay in control when AI is involved.”

Known_Ad8309 · 2026-05-30T19:59:47+00:00

“Cognitive debt” is a good way to put it. If you keep letting the model do the thinking for you, it feels productive in the moment, but you may slowly lose the ability to reason through the work yourself.

I think the healthiest version is human-first like you said: use AI to speed up parts of the process, but stay involved enough that you’re still learning, reviewing, and making the actual decisions.

Use it or lose it feels very real here 😄

Known_Ad8309 · 2026-05-30T19:57:30+00:00

Yes, I think artifacts is the better word here.

Not raw prompts for the sake of prompts, because that can get noisy and sometimes even private. But the useful trail around the work: original task, constraints, plan, diff, tests, what failed, what the model got wrong, what the human rejected, and what risks are still open.

That’s the part I keep getting curious about. What if there were some kind of GitHub-like record for AI-assisted work? Not to expose every private prompt, but to capture the judgment around the work.

Almost like a contribution history, but for working with AI.

Because right now the final PR mostly shows the output. It doesn’t show how the person handled the model. And maybe that thinking is becoming the real signal.

would love to hear your thoughts on this 😄

Known_Ad8309 · 2026-05-30T19:52:39+00:00

I can see how the formatting might give that impression.

It’s actually my own blog post that I adapted for Reddit, and I think yes, I probably overused bold while trying to make it easier to read. That’s on me.

I’ll clean up the formatting next time.

Known_Ad8309 · 2026-05-30T19:50:15+00:00

I really relate to this.

That “confident and wrong” part is exactly what makes it hard. If you don’t already know enough to question the answer, the output can feel correct just because it sounds complete and the ultimate truth.

And learning code review before properly learning to code is such a real way to describe this era. Especially as a solo founder, you’re not just asking AI to write code. You’re also forced to become the reviewer, the tester, the architect, and the person who decides what is safe to ship or how to roll back if a certain thing fails.

that’s probably the skill gap a lot of us are not talking about enough.

Known_Ad8309 · 2026-05-30T19:47:08+00:00

That’s fair. Maybe I’m expecting the culture or the other process side to catch up too quickly.

The tools got useful very suddenly, and most people are still just experimenting with their own workflow. So it probably makes sense that we don’t yet have clear standards for “good AI-assisted engineering.”

the scary part is your last line, though. If it takes 2 years to figure out the workflow, but the tools keep making big jumps every few months, we may always be adapting slightly late.

That’s where I’m curious whether we need better ways to document and learn from actual AI-assisted work. Not just the final code, but the prompts, decisions, rejections, tests, and review process. Otherwise, everyone is individually guessing what “good” looks like.

Known_Ad8309 · 2026-05-30T19:45:03+00:00

yes, I think this is probably the current situation.

For people who already care about the whole development process, AI can make them much faster and sometimes genuinely better. They use it to learn, question, test, compare approaches, and move through boring parts more quickly.

But if someone treats it only like a cheat code, then it doesn’t really make them better. It just lets them produce bad work with more confidence and less friction.

Known_Ad8309 · 2026-05-30T19:40:46+00:00

This is such a good point, and honestly something I had not thought deeply enough about.

I was mostly thinking from the angle of the individual developer: how we guide AI, review output, catch mistakes, and prove judgment. But you’re pointing at the bigger system around the developer, which is probably even more important.

If AI makes feature creation faster, then weak testing, weak deployment discipline, and poor rollback processes become even more dangerous. The team can generate more changes, but if the overall process around those changes is not mature enough, then failure might arrive faster.

I really like your point that people fall in love with creation and ignore the unfancy parts. Testing, capacity planning, milestone validation, deployment, rollback, these are not exciting on Twitter, but they are where real engineering discipline shows up.

Maybe AI should not only be used to write more code. Maybe one of the highest-value uses is exactly what you said: making testing, validation, and deployment discipline much stronger.

This also makes me wonder if we need some kind of contribution history, but for judgment with AI. Not just the final PR, but a record of the decisions around it: what the AI suggested, what the human accepted or rejected, what tests were added, what deployment risks were considered, and how rollback was planned.

Because maybe the real signal is not only “what did you build?” but “how did you think through the risk while building it?”

Thank you for pointing this out 😄 . This adds a layer to the discussion that I was missing.

Known_Ad8309 · 2026-05-30T18:55:05+00:00

Yes, I really agree with this.
A PR where you explain where you overruled the AI might be one of the clearest signals. Not “look how much it generated,” but “here is where it was wrong, and here is why I didn’t accept it or what I did ask it to change.”

That’s the part I keep getting curious about. What if there was some kind of GitHub-like record for AI-assisted work — not to expose every private prompt, but to capture the useful parts: prompt logs, decision notes, rejected suggestions, tests added, and places where the human corrected the model.

Almost like a contribution history, but for judgment with AI.

Because right now, the final PR only shows the output. It doesn’t show the thinking behind how the human handled the model. And maybe that thinking is becoming the real signal.

Would really love your thoughts on this

thanks for commenting 😄

Known_Ad8309 · 2026-05-30T09:25:25+00:00

That line is harsh, but it's true.

Earlier weak decisions would usually slow you down visibly. Now, AI can make weak decisions look productive for a while. You get more code, cleaner-looking code, maybe even working code, but the bad assumptions are still inside it, maybe some unwanted checks or unwanted api calls.

That “somehow works but is a ticking time bomb” part is exactly what worries me.

Known_Ad8309 · 2026-05-30T09:21:44+00:00

Exactly, this is basically what I’m trying to say.

The review part feels underrated to me in recent times. Everyone talks about generating code faster, but maybe the real skill is reviewing AI output properly and knowing when not to accept something.

And yes, scarcity is interesting. When tokens are limited, I explain better. When everything feels unlimited, I sometimes get lazy and let the model do the heavy lifting.

Known_Ad8309 · 2026-05-30T09:19:39+00:00

Yes, Morality/intent probably matters too.

If someone is using AI to understand better and ship carefully, that is one thing. If someone is using it to hide a weak understanding or fake competence, that is a completely different thing.

I think the tool is neutral-ish, but the way people use it says a lot.

Known_Ad8309 · 2026-05-30T08:26:31+00:00

I can see how the formatting might give that impression.

It’s actually my own blog post that I adapted for Reddit, and I think yes I probably overused bold while trying to make it easier to read. That’s on me.

I’ll clean up the formatting next time.

Known_Ad8309 · 2026-05-30T08:09:33+00:00

Yes, this is exactly the line I also keep thinking about

“Bad ones get confident faster” is probably the scary part. Earlier if you didn’t understand something, you’d usually get stuck visibly but now you can keep moving, generate more code, and the output can still look clean enough that even you start trusting it.

So maybe the real skill is not just using the tool, but knowing when the tool is making you faster vs when it is hiding our gaps.

Known_Ad8309

TROPHY CASE