A few days ago I published a lighthearted post about building a coding mascot generator with Google AI Studio. The app itself โ MascotCraft Studio,...
For further actions, you may consider blocking this person and/or reporting abuse
Hey, this article appears to have been generated with the assistance of ChatGPT or possibly some other AI tool.
We allow our community members to use AI assistance when writing articles as long as they abide by our guidelines. Please review the guidelines and edit your post to add a disclaimer.
Failure to follow these guidelines could result in DEV admin lowering the score of your post, making it less visible to the rest of the community. Or, if upon review we find this post to be particularly harmful, we may decide to unpublish it completely.
We hope you understand and take care to follow our guidelines going forward!
When personal computers were first introduced, some choose to use it for office tasks, some choose to use it for gaming and some for making those software.
At the end of the day programming is all about giving instructions to the computer.
Whether they pass through assembler or python's interpreter or chatgpt's prompt, we get results.
Bottlenecks are present in all times:
In c world its about pointers and memory , in python world its about objects and references, and in rust world its about ownership and borrow checker, and in AI world its about context, memory and tokens.
Its true that Judgment is key, but I think its just about looking at the output!
If the output is matching our needs and expectations then its fine!
But, one thing we need to differentiate here:
Good Judgment or judgement is about making AI to work and get quality results
Its different from identifying worthwhile problems!
Because, not just AI, any thing like a programming language or any tool is just a tool.
We can't decide for what it should be used for!
For an office accountant only excel and PowerBI are worthwhile things, because they solve their problems.
For a Marketing guy or a designer, figma is worthwhile.
For, a pro gamer, video games are the worthwhile things.
Now, think atleast for video games, many people used to think they are waste of time and money, yet they exist!
A kid draws a sketch with a pencil, thats the same tool used to draw a pro drawing.
Can we say the kid has no right to use pencil for some rough sketches?
All I want to say is a professional in his office time will handle the real important things using AI as craft,
while a guy in his free time will enjoy the outputs of AI as art!
Really enjoyed this perspective! ๐ The bottleneck-per-era framing is a great way to think about it โ pointers in C, ownership in Rust, context and tokens in AI. Each era has its own version of "the thing you have to actually understand to get quality results."
And the pencil analogy is spot on โ the tool doesn't define the worthwhile problem, the person holding it does. I think where I'd add a nuance is that "looking at the output" as judgment works well when you already have enough domain knowledge to know what good looks like. The tricky part is when someone is new enough to a space that the output looks right without them being able to tell it isn'tโwhich is where the deeper judgment piece comes in. But that's probably a whole separate post! ๐ธ
"The tricky part is when someone is new enough to a space that the output looks right without them being able to tell it isn'tโwhich is where the deeper judgment piece comes in."
True, I agree!
Glad that landed! ๐ It's probably the trickiest part of the whole shiftโthe less you know, the harder it is to spot what's wrong, which is exactly when you're most likely to trust the output without question.
Thank you for sharing such an excellent post. I really enjoyed reading it.
Iโm a Python Full-Stack Engineer with over 10 years of experience designing and building scalable software solutions for clients across a variety of industries. Along the way, Iโve learned that successful projects depend not only on strong technical execution but also on creating real business value.
With my recent contract completed, Iโm exploring new opportunities to collaborate with professionals who value innovation, practical problem-solving, and long-term partnerships. I enjoy discussing ideas that combine technical excellence with sound business strategy, creating outcomes that benefit everyone involved.
I believe every connection has the potential to become something meaningful. If you're interested in exchanging ideas, exploring opportunities, or simply connecting with someone who enjoys building impactful technology, I'd be happy to hear from you.
Wishing you success in your future endeavors, and I look forward to connecting.
Thank you! Wishing you all the best in your future endeavors as well! ๐ธ
Thanks. Don't you have any intention of working together to achieve something biggest?
I appreciate the thought! I'm pretty heads down on my own projects right now, but best of luck with yours.
It will not interfere with your work.
You can gain sufficient additional benefits while building your experience.
You will likely understand this if you have a detailed conversation with me.
Best
We've spent years learning how to build things. Now we are learning how to decide which things are worth building.
That one sentence captures the whole shift perfectly. ๐ The tools for building have never been more accessible โ which makes the "worth building" question the one that actually separates good outcomes from fast ones.
Your closing question โ "deliberately practice judgment rather than accumulate it accidentally" โ is the exact problem I've been trying to solve operationally.
What worked for me: treat judgments as inspectable state, not internal feelings. Every architectural decision goes into a separate store with status (proposed/accepted/locked) and a reason field. A few months in, the store is already a readable trace of how my judgment actually evolved โ which calls I got right, which I reversed, why. Practicing judgment turns into reading your own record.
Wrote up the framework angle separately: dev.to/jugeni/vibe-coding-is-not-a-level-its-an-axis-12gb โ yours is the why this matters, mine is one possible how.
This is a really practical approachโ"inspectable state, not internal feelings" is such a useful reframe. The idea of a decision store with a reason field is something I hadn't considered, but it makes a lot of sense: you can't really review a judgment you never recorded, and most of us just carry it around implicitly until something goes wrong and forces a retrospective.
Reading your own record as the practice is elegant too โ it turns judgment from something abstract into something you can actually audit. Going to check out your piece on the framework angle now! ๐ธ
"Something you can actually audit" is the frame that matters โ once it's a record you can review, the practice mostly runs itself. Most retros only fire when something breaks; a decision store flips that to retros the file schedules, not ones pain forces. Hope the framework piece lands.
"Retros the file schedules, not one's pain "forces"โthat's a really clean distinction. Reactive retros only catch what already went wrong visibly; a scheduled review catches the drift before it compounds. Read the framework piece and left a comment there too! ๐ธ
Yeah โ "catches the drift before it compounds" lands. Reactive retros also self-select on visible failure, so the drift that hasn't broken anything yet just stays drift until it does. Scheduled review moves the catch upstream of the breakage. Will look for your comment โ thanks for the second read.
"Self-selects on visible failure" is exactly the gap โ anything that's drifting but hasn't broken yet is invisible to a reactive process by definition. Scheduled review is the only way to catch what hasn't announced itself yet. Really enjoyed this whole thread!
The quote you kept coming back to is the whole shift in one sentence. The part people underweight is 'recognizing whether the result is actually good.' That judgment doesn't scale by hiring more reviewers, because at generation speed the volume outruns them. It scales when the requirements are encoded as something the output gets checked against, so 'is this good' stops being a per-PR gut call and becomes a property you can enforce. Defining clear requirements is becoming the real engineering.
"Defining clear requirements is becoming the real engineering" โ that reframe is really sharp. The bottleneck isn't just human judgment at the review stage, it's whether the standard for "good" is encoded anywhere that can actually keep pace with generation speed. Moving "is this good" from a per-PR gut call to an enforceable property is a completely different kind of problem than the one most teams are set up to solve. Really useful extension of the idea โ thank you! ๐ธ
Hi,
Thanks for sharing your article. I really liked your perspective that AI is shifting the bottleneck from implementation to judgmentโit highlights a practical understanding that building software is no longer just about writing code, but making sound technical decisions and evaluating trade-offs.
I have a couple of technical questions related to our current project:
Thank you for the kind words! ๐ Those are really interesting questions, though I have to be honest โ smart contract validation and blockchain backend architecture are quite a bit outside my current area of focus (I'm primarily in iOS/Swift land!). I wouldn't want to give you half-baked answers on something as critical as on-chain payment systems.
For those specific challenges, you'd likely get much better responses from developers with direct production blockchain experience โ might be worth posting them as a standalone discussion thread on DEV where that community can weigh in properly!
Thanks for your honest and thoughtful responseโI really appreciate the transparency.
Of course! ๐ Always better to be upfront than to guess on something that critical. Good luck with the project!
๐
The "what would a wrong but plausible-looking version look like" habit is the one I'd steal from this. Most code review trains you to check "does it work", which AI output sails right past because it usually does work, just not the way you needed. On your open question, the thing that's grown my own judgment fastest is writing down what I expect before I run something, then seeing where I was off. You don't get that feedback loop if you only ever look at the result after it's already right. Have you tried keeping a record of the calls Gemini made that you'd have made differently?
"Writing down what I expect before I run something" โ that's such a concrete way to build the feedback loop, and I hadn't thought about it quite that way before. The gap between prediction and result is where the actual learning happens, and you're right that skipping straight to the output short-circuits that entirely.
I haven't kept a formal record of Gemini's calls I'd have made differently, but after reading this I'm genuinely considering it โ especially the localStorage gallery decision, which is the exact kind of thing that would've shown up in that kind of log. Thanks for the practical suggestion! ๐ธ
Your line "what would a wrong but plausible-looking version of this look like" is the whole skill in one sentence, and it is also the answer to your closing question. You sharpen judgment by forcing yourself to produce the plausible-wrong version on purpose, before you trust the real one.
Concretely, the practice that has moved my judgment fastest: before I accept any non-trivial output, I write the failing test first, the one that should fail if the thing is wrong, and I make it actually fail for the reason I expect before I let the fix make it pass. The discipline is not the test, it is that I have to articulate what wrong looks like in advance. If I cannot describe the failure, I do not understand the thing well enough to judge the output yet. That gap is the signal.
The other half is refusing to accept "it works" as evidence. It works is the happy path. Judgment lives in the failure modes, so I make myself enumerate them: what does this do on malformed input, on a dropped node, on the edge state. Most plausible-wrong output passes the happy path and dies in exactly the case I did not think to name. The 90 percent right version is more dangerous than the obviously broken one, because nothing trips an alarm.
So to your question directly: judgment does not accumulate as a side effect of experience, it accumulates from the habit of predicting failure before you look for it. Experience only sharpens it if every time you are surprised, you ask why your model of "wrong" missed that case. The surprises are the training signal, not the successes.
"If I cannot describe the failure, I do not understand the thing well enough to judge the output yet" โ that line alone is worth saving. It reframes the whole question from "does this look right" to "can I articulate what wrong would look like," which is a much harder and more honest bar.
The point about the 90% right version being more dangerous than the obviously broken one really landed too. The thing that trips no alarms is exactly the thing that costs the most later, because nothing flags it for review and it gets built on top of.
And yes โ "judgment accumulates from the habit of predicting failure before you look for it" is the clearest answer to my closing question I've seen in any of the comments. The surprises being the training signal, not the successes, is going to change how I think about this going forward. Thank you for this! ๐ธ
Glad it landed. The one caution I would add to "surprises are the training signal": only if you actually log the surprise the moment it happens. My instinct when something surprises me is to fix it and move on, and the lesson evaporates. The habit that makes the signal real is writing down what my model predicted versus what happened, right then, before the fix makes it obvious in hindsight. The surprise is only training data if you capture it while it still feels like a surprise.
That caveat is really important โ "before the fix makes it obvious in hindsight" is the key phrase. Once you've solved it, the gap between prediction and reality collapses and the surprise stops feeling like a surprise, which is exactly when the lesson quietly disappears. Capturing it while it still feels wrong is the whole thing. This is basically the same point Nazar made about writing down expectations before running something โ the discipline has to happen before you know the answer, not after.
ุดูุฑุง ุนูู ูุฐุง ู ูุงู
OMG YES! This is exactly what I've been trying to put into words. As AI speeds up execution, judgment really does become the bottleneck. Such a refreshing perspective. ๐ฅ๐
Yes, exactlyโit's one of those things that feels obvious once you name it but is surprisingly hard to articulate before that! Really glad it resonated! ๐ฅ