Tony Alicea

Tony Alicea

@tonyalicea.dev

Senior Experience Specialist @ NN/G | Deep Dive Technical Educator, Speaker, Dev, UX Strategist - https://dontimitate.dev | https://tonyalicea.dev/ 370,000 students and counting. Don't Imitate, Understand.

571 followers117 following476 posts

Pinned

I'm pleased to present, for free, the first hour of my new course Understanding AI-Assisted Software Development on YouTube! This course is designed to be agnostic to any one AI tool, and instead provide a mental model and best practices for you and your team. 👇

We programmers have been abstracting ourselves further and further away from the "real code" for decades now. Memory management used to be a skill until modern languages and garbage collection.

Thanks to vibe coding, all those unnecessary UIs in movies that you couldn't have imagined a real coder taking the time to make...are now totally believable.

Introducing Sloptris! A Tetris clone that satires what AI-generated coding is like. I've felt a lot like AI-assisted dev shares elements of game experiences. This is a fun little idea I had to express the experience within a game. 👇

I've been so pleased to see the reaction to the UX.md concept in the design and product community. I'm happy to share an interactive report of my own small experiments with how UX-context impacts product features that AI generates. 👇

There's a lot of possibility for using AI to build great software. But the simple act of using AI to build software is no guarantee of greatness.

The most popular AI loop seems to be: 1. Human: "I'm bad at writing." 2. <Asks AI to write for them> 3. <AI output is more difficult to read than what the human would have written.> 4. Human posts the AI slop. 5. Human gets worse at writing due to lack of practice. 6. Go to 1.

Stop telling me about how many PRs you shipped. Faster implementation doesn’t mean faster thinking. If anything, it questions how much thought went into what you’re doing.

"How fast we can build" and "how fast we can think" are not the same thing. It is a skill and cultural regression for product teams to conflate the two.

With every new iteration of tooling and advancement in software development, the hope of organizations seems to be that we can skip that pesky, time-consuming part called thinking. That's never true.

This idea that you can now constantly change software based on 'feedback' with no up-front research assumes that users will stick around while you keep changing software under their feet. If people have to constantly re-learn your software, what's keeping them from moving on?

It's extraordinary to me to watch professional people use AI to generate a three sentence comment in their native language. It takes more effort to prompt the AI to write the comment than it does to write it yourself. And the comment is obviously AI-written. It's sad.

There's a lot of devs who are trying to become product engineers and forward-deployed engineers and will be sent to go talk to users...and have no idea that talking to users, getting them to open up, and not biasing them is a learned skill. For example, contextual inquiry.

Announcing my new agent skill: /de-div It cleans up div soup and helps you author semantic, accessible HTML, working with you when a semantic choice is unclear and generating a report for you to learn from at the end. 👇

Got this nice comment on my new do-i-understand agent skill: "Thanks for this skill — it's genuinely useful, and we got real value from it while adopting it in one of our repos." Running this skill benefits your knowledge and your app security. github.com/AnthonyPAlic...

github.comGitHub - AnthonyPAlicea/skills: Skills for Devs Who Want to UnderstandSkills for Devs Who Want to Understand. Contribute to AnthonyPAlicea/skills development by creating an account on GitHub.

I just released my first agent skill: /do-i-understand As a technical educator for many years, I want to maintain my own skill and that of those around me. This agent skill makes sure you understand what you're shipping before you merge it. Here's how it works 👇

View full thread

Third, for open source maintainers. You can ask for a do-i-understand report in PRs as a light honor-system check. It's a bit of intentional friction before a merge request. Free and open, link below. I really enjoy using it, so let me know what you think.

I just released my first agent skill: /do-i-understand As a technical educator for many years, I want to maintain my own skill and that of those around me. This agent skill makes sure you understand what you're shipping before you merge it. Here's how it works 👇

View full thread

Second, with junior engineers. Require it on their PRs, but build the safe space first. "I don't know" has to be a welcome answer, one that invites pair coding and mentorship instead of something to hide.

I just released my first agent skill: /do-i-understand As a technical educator for many years, I want to maintain my own skill and that of those around me. This agent skill makes sure you understand what you're shipping before you merge it. Here's how it works 👇

Run /do-i-understand and it looks at the change you're about to push (or point it at earlier commits). It prioritizes changes, then probes your reasoning, your assumptions, and the ways the change could fail. It's looking for the parts you don't yet fully understand.

At the end it writes a short report. Paste it into your PR description for your reviewer, or keep it as a personal record. The goal is simple: *push code only once you can be accountable for it*.

If your process is now to make feature requests into tickets and have your agent constantly turn tickets into PRs...with no triage of those feature requests or root cause analysis...you are going to end up with terrible, terrible software.

Devs: in the age of AI you need to differentiate with good user experience, know how to talk to your users, and build product taste and sense...to do that you should be getting familiar with Nielsen Norman Group (if you aren't already). Seriously: www.nngroup.com

nngroup.comNielsen Norman Group: UX Training, Consulting, & ResearchA leader in the user experience field, NN/g conducts groundbreaking research, trains and certifies UX practitioners, and provides UX consulting to clients.

Zero LLM is an effort to take some time without an LLM. 1) Agree to some time without AI. Do things yourself. 2) Start a session to track your time. 3) When you feel the addictive itch to ask AI for help, go to the site instead. 4) End your session and share with #0llm.

I had this idea. We are using LLMs too much. We need a recalibration sometimes. A bit of time where you agree with yourself to do things manually, keep your skill and your voice. Check out 0llm. If you use it, share it with the hashtag #0llm.

A problem with AI output is what we’ll call “effort bias”. Because an output (text, image, video, etc.) looks like things that have historically taken a lot of human effort and thinking, we assume a degree of correctness.

Words matter. Let's stop calling human evaluation of AI output a "bottleneck." It's human review *tempering* AI output. This isn't holding back a wave of progress, it's stacking sandbags as a storm surge hits.