Dalia's Visit, Vibe Coding, and Shipping Slower

This reflection ties together three connected ideas: Dalia Abo Sheasha's class visit, Jake Nation's "Vibe Coding Our Way to Disaster," and Namanyay's "AI Makes You Code Faster, But Ship Slower." Across all three, the same theme stands out to me: speed in coding is only valuable when it is paired with understanding, accountability, and quality.

Dalia emphasized that professional engineering is about solving real problems for customers, not just producing code quickly. The two readings reinforced that point by showing how AI-assisted speed can create hidden slowdowns later when code is unclear, fragile, or hard to maintain. My overall takeaway is that strong engineering means using modern tools while still owning correctness, testing, and long-term reliability.

Dalia's Visit Notes: Developer Tools, Craft, and Career Mindset

This week, Dalia Abo Sheasha from Microsoft visited our class and shared insights from her experience in industry. She has worked at IBM as both a Software Engineer and a Software Engineering Team Lead, and she now works as a Project Manager for Visual Studio (not Visual Studio Code). One of the things I appreciated most was how practical her advice was: she focused less on hype and more on mindset, craftsmanship, and problem-solving in real engineering environments.

What Stood Out Most

One of the strongest themes in her talk was the ongoing evolution of developer tools. She emphasized that every generation of engineers faces major shifts in technology, and long-term success depends on whether you're willing to keep learning and adapting.

She encouraged us to experiment with tools rather than fear them. A few examples she mentioned were:

• GitHub Copilot API
• Comparing GitHub CLI with VS Code Chat for different workflows

Her perspective was reassuring: new tools will keep appearing, but curiosity and adaptability are what keep you relevant.

Memorable Quotes

This question reframed software work for me. It's easy to focus only on code quality or technical output, but this reminded me that engineering is ultimately about people and impact. It also made me think about how easy it is to lose sight of users when we get deep into implementation details. We can spend hours optimizing architecture or polishing syntax, but if we are not clear on who benefits and what pain point we are solving, the work can still miss the mark. I liked this quote because it turns technical decision-making into a values question and keeps customer needs at the center.

This was a strong reminder that professional software development has real-world consequences. Reliability, testing, and ownership are non-negotiable in industry. In school, bugs are often treated as isolated mistakes with limited impact, but in production a small oversight can affect thousands of users, interrupt business operations, or damage trust in a product. This quote helped me better understand why engineering teams put so much emphasis on code reviews, testing discipline, and clear rollback plans. It is not about perfectionism; it is about reducing risk when consequences are real.

That quote captures the difference between school assignments and actual engineering work. Writing code is one part of the job; solving meaningful problems is the real goal. I found this especially valuable because it shifts how success should be measured. Success is not just finishing tasks or shipping quickly, but delivering outcomes that actually help people. It also connects to collaboration, since solving customer problems usually requires communication with teammates, product thinking, and tradeoff decisions, not just individual coding skill. This mindset feels like the bridge between being a student programmer and becoming an effective engineer.

This connects to her larger message about technology shifts: when tools and workflows change, there's always a chance to grow for people who are willing to adapt. Instead of treating disruption as a threat, this quote frames it as a moment to build new skills and differentiate yourself. That perspective feels important right now with AI changing workflows so quickly. People who experiment thoughtfully, learn continuously, and stay grounded in fundamentals can turn uncertainty into an advantage. For me, this quote was a reminder to stay flexible and proactive rather than defensive when new tools appear.

What She Looks For in Engineers

Dalia shared the core qualities she values when evaluating engineers:

1. Curiosity: asks "why," not just "how"
2. Pride in craft: cares about every line of code
3. Willingness to experiment: tries new tools to build better products
4. Problem-solving: can break down hard problems and work through them

I liked this list because none of these traits are about memorizing the most technologies. They are habits and attitudes that make someone effective over the long term.

Networking Advice I Want to Apply

She also stressed that networking matters and gave a practical outreach approach: after hearing someone share an interesting insight, send a message that is specific and respectful, then ask for a short 1:1 conversation. She also suggested using communities like Meetup to find events and connect with professionals in the field.

This felt actionable and realistic. It's not about "networking" in a superficial way; it's about genuine curiosity and building relationships over time.

Vibe Coding

After reading Jake Nation's "Vibe Coding Our Way to Disaster", what stood out to me was the idea that most bugs in human-written code come from misunderstanding the problem rather than from implementation errors. The key to solving a problem well with an AI-assisted workflow is to first deeply understand the problem, then use AI to help implement that understanding. If you skip the understanding step and jump straight into coding with AI, you can end up with code that doesn't really solve the problem, even if it looks correct on the surface.

AI Makes You Slower

In Namanyay's "AI Makes You Code Faster, But Ship Slower" the central point is that local coding speed and team delivery speed are not the same thing. AI can help produce code quickly, but teams often pay for that speed later when they have to review unclear logic, debug brittle implementations, or refactor over-generated solutions.

I connected this directly to Dalia's message about ownership and production quality. If engineering is about delivering value, then correctness and maintainability matter as much as raw output speed. This reading helped me see that shipping reliably requires discipline: testing, clear reasoning, and accountability for what gets merged.

My favorite quote from the article was:

Nogramming

This week, I will make progress on my Nogramming assignment by finishing outreach and confirming interview times with everyone on my list. After scheduling is complete, I will finalize my interview questions and run one pilot interview to check clarity and quality. My goal by the end of the week is to have confirmed meetings, a polished question set, and at least one completed interview so I can move into response collection efficiently.

~Shree