|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
HSO explains how embedding AI agents into ERP and business workflows is accelerating implementations, improving data transformation, and driving real user adoption through industry-specific automation.
The post AI Agent & Copilot Podcast: How HSO Is Embedding AI Agents into Core Business Operations appeared first on Cloud Wars.
Dona Sarkar explains why AI should be viewed as a tool for empowerment rather than job replacement, urging professionals to become “AI power users” who learn how to harness AI within their own roles and industries.
The post AI Agent & Copilot Podcast: Dona Sarkar of Microsoft on Why AI Won’t Replace You—But AI Power Users Will appeared first on Cloud Wars.
By 2026, I don’t need to tell you vibe coding is useful, you’ve probably already tried it. Still, thinking about it as a way of thinking that will solve all of your problems is probably a bit too optimistic.
It’s easy to get carried away while you’re typing prompts, but there are several real challenges with vibe coding that you need to think about. It almost always works until it doesn’t work anymore.
From a personal (and business) standpoint, vibe coding at the start of a project is probably its best use. Since I feel a personal example is better than three abstract claims, I’ll share my own.
Throughout my career, I often got overwhelmed by tasks and had troubles organizing them in a way that my brain likes. Projects, writing, editing, sending interview questions and getting them back, for example. None of these are big tasks on their own but they’re very different in nature.
Finding a good task manager app was next to impossible, but I have managed to create a simple dashboard web app that has all the things I need and nothing more.
For many, my AI tool might be useless, but for me it’s the only one that works precisely the way my brain does.
The appeal is real, and undeniable. Because you know best what you want, getting AI to do it is just a matter of sending messages and tailoring the “thing” into whatever you’d like. For me it was a real solution for a problem I face every day, but for someone else it might be a prototype of a new app or service that went from brain to screen in three hours.
The problems start when vibe coding moves into production, and I’ve seen that with my eyes as well. While we all know what things should look like for the end user, most of us from non-technical fields do not have any idea what’s happening under the hood. That’s why you need to think about more than just vibes.
Code you don’t understand is code you can’t maintain. Easy enough; if you create a beast of a tool, app, or an entire service you intend to share with others, it’s very tricky to maintain it if you know nothing about it.
For example, it’s fine to create a massive SaaS solution you would use since you can troubleshoot issues with AI in your own time; there’s no real risk. But if you’re shipping the service to others, what happens if something breaks at 3 am for someone who paid for that service?
Security gaps stack up. Every security expert will tell you that nobody cares about security until something goes wrong. With vibe coding and AI, the “wrong” part can be built-in during the creation of the tools. AI sometimes just embeds API keys or other secret info in the code, doesn’t sanitize the code properly, and leaves a lot of open doors in general. If you’re not savvy and don’t think about this, you’re going to have a bad time. Also, remember that hackers also use AI to find weaknesses.
The DORA AI report shows what we’re all thinking. The 2024 DORA report found that AI adoption actually correlated with a 7.2% reduction in delivery stability. More telling: 39% of respondents said they had little to no trust in AI-generated code, yet nearly everyone was using it anyway.
The risk here is over-reliance on AI tools that leave you, their creator, sitting on the sidelines wondering what’s even going on.
In my experience, there are a few signals that you are perhaps in too deep into vibe coding, and it’s starting to become a liability. I’m not saying you should go and seek professional help, but for some of these help is really the only solution.
I know that asking a senior engineer to help you fix your vibe coded app might be one of the more stressful experiences in your life, but if you’re set to be a vibe coder, that’s a chance you’ve got to take.
Don’t get me wrong here, I’m not saying that you should lose Claude Code and start typing everything manually (or by pasting from StackOverflow).
What I’m saying is that the ones who make the most out of vibe coding apps are the ones who could, theoretically, make the same apps themselves.
What I’ve found in the last month is that AI adoption and tendency to vibe code things is a pendulum: you either think it’s bad, complex and don’t want to touch it, and once you do start you can’t get enough of it. I’ve heard comparisons with “prime Call of Duty”, which is a reference only gamers would understand, but paints the picture.
A good vibe coding experience is like driving a convertible on a coastal road at sunset.
In 2026, people are exceptionally interested in making anything with Claude Code and other tools and the truth is that we don’t really need 90% of those.
So when vibing, I’d advise you to think small, and think about problems that you have. It’s ok to create a task management tool for you, and not to make money on, and it’s okay to vibe code a prototype of a new idea before presenting it.
I’d just like you to make sure to understand that using a tool mainly used by software engineers does NOT make you one, and you need to spend a lot of time understanding what the tool built in order to get close to the “real world.”
Vibe coding is a development approach where you describe what you want in natural language and let AI generate the code. It’s fast and easy, but works best when the person in charge knows what good code looks like.
The main risks are shipping code you don’t understand, accumulating security gaps from unvalidated outputs, and losing the ability to debug or maintain what you’ve built.
Not by itself, but it carries risks in production environments. These are around security, maintainability, and code that can’t be explained without AI.
Yes, but with limits. Personal tools and prototypes are fair game. Anything you ship to paying users needs someone who can own the code and knows how to fix it.
According to the 2024 DORA report, AI adoption correlated with a 7.2% reduction in delivery stability, suggesting that bigger productivity on paper doesn’t mean better software.
The post A Non-Engineer Look at Vibe Coding Mistakes (And How to Avoid Them) appeared first on ShiftMag.
39 projects, 6 finalists, and a weekend of IDE-native AI in San Francisco.
Earlier this month, we brought developers together in San Francisco for the inaugural JetBrains x Codex Hackathon. Over the course of one weekend, teams built 39 IDE-native AI projects, from which six finalists emerged. The event highlighted just how rapidly developers are transforming AI within the IDE into sophisticated workflows, tools, and products.
AI in the IDE is a vibrant conversation in software right now. From agents and copilots to context windows and orchestration, developers are brimming with ideas about where this is all heading. A hackathon remains one of the best formats for channeling that energy into working code, giving people the space to pursue ambitious projects within a weekend window.
The response was immense: 443 developers applied, resulting in 39 completed projects. Roughly half were IDE plugins or tools built on the IntelliJ Platform SDK – the kind of work that directly shapes the future of how engineering teams build. JetBrains believes in the power of convening a room like this, fueled by working tools and a real deadline. Leading technologists gave up their Sunday to judge, because the conversations and innovations that took place in that room were worth showing up for.
The weekend’s top prize went to hyperreasoning, a solo build by Aditya Mangalampalli. One person, one laptop, 24 hours – and a coding agent that decides which reasoning paths are worth exploring before it generates a single line of code. It’s the kind of project that justifies the hackathon format: a dormant idea finally prototyped by someone with the conviction to see it through solo over the course of a weekend. We’ll share the full story in a follow-up blog post.
Second place went to Scopecreep (Bhavik Sheoran, Kenneth Ross, Roman Javadyan, and Joon Im). Third place went to mesh-code (Ayush Ojha, Coco Cao, Kush Ise, and AL DRAM). Both teams, along with our three other finalists, will get their own spotlights in the next blog post.
Zooming out from individual projects, a few things stood out across the finalist pool. Roughly half the submissions were JetBrains plugins or IDE-native tools, built directly against the IntelliJ Platform SDK rather than around it. Two of our six finalists were solo builders – a remarkable feat in a format that usually rewards more hands. The work that impressed the judges wasn’t necessarily the work that generated code the fastest; it was the work that gave developers more visibility into what their agents were doing, more guardrails around it, and a clearer sense of when to trust the output.
That last part matters. Speed makes for good demos, but the projects people in the room kept coming back to were those building toward something that lasts past the demo: correctness, safety, context, and review. Better, not just faster.
“The most valuable part was building directly against the IDE rather than around it.”
Participant feedback
A weekend like this only happens when the entire ecosystem shows up. OpenAI brought Codex to the heart of the event, sent a judge, and gave every attendee ChatGPT Pro credits. Cerebral Valley managed the experience seamlessly from start to finish. AuthZed contributed two judges and provided cloud credits for every builder in the room.
Nebius sent a judge and backed the winning team, while Supabase and BKey each sent judges and anchored key layers of the tech stack. Clerk and Vercel joined as community partners, and Shack15 hosted us. A stack that tight is precisely what allows a two-person team to ship something production-looking by Sunday night.
For instructors teaching software development, one of the biggest logistical challenges is assignment distribution and feedback at scale. How do you give large groups of students access to course materials, keep solution code private, and still deliver meaningful, contextual feedback without lots of administrative overhead?
The GitLab for Education program provides qualifying institutions with free access to GitLab Ultimate, enabling instructors to build professional-grade workflows that mirror real-world software development environments. In this article, you'll learn how Stephen G. Dame, a lecturer in the Computing and Software Systems department at the University of Washington, Bothell, uses simple workflows in GitLab to manage everything from course materials to student feedback across multiple classes.
Dame came to academia with years of experience as a chief software engineer at Boeing Commercial Airplanes, where GitLab was used for aerospace projects. As an adjunct professor, he became an early advocate for GitLab within the university, joining the GitLab for Education program to access the full feature set needed to run structured, scalable course workflows.
"GitLab provides the greatest way to organize multiple classes, student assignments, lectures, and code samples through the use of Groups and Subgroups, which I found to be unique to GitLab compared to other repository platforms."
- Stephen G. Dame, University of Washington, Bothell
The foundation of an effective GitLab-based course is a well-planned group hierarchy. GitLab's Groups and Subgroups allow instructors to model the natural structure of a university department institution, course, and role with precise, inheritable permissions at every level.
Dame's structure places the university at the root (UWTeaching), with each course occupying its own subgroup (e.g. css430). Within each course sit repositories for lecture-materials and code, alongside dedicated Subgroups for students and graders. Instructor materials remain private, while student and grader subgroups are configured with controlled permissions so that assignment briefs and solutions are visible only to the right people.
Permissions cascade downward through the hierarchy via Manage > Members, allowing Dame to add students to a course's students subgroup with Reporter access and an expiration date tied to the end of the academic quarter. Students can clone and pull from assignment repositories but cannot push — keeping solution code firmly under instructor control.
Students are guided to set up SSH keys across all their working environments (local machines, cloud shells, virtual machines) so they can clone repositories and receive weekly updates via git pull. They copy relevant code into their own private repositories to manage their own version history.
Tip for large classes: For larger cohorts, adding students by hand is impractical. GitLab's REST API lets you automate subgroup creation and membership from a list of usernames. Below is a sample Python script that handles this:
Log in
import gitlab
from datetime import datetime
# Connect to your GitLab instance
gl = gitlab.Gitlab('https://gitlab.com', private_token='YOUR_PRIVATE_TOKEN')
# Target parent group ID (e.g., the ID for "css430 > students")
parent_group_id = 12345678
# Set expiration: typically the beginning of the next month after quarter end
expiry_date = '2025-01-01'
# List of collected student usernames
student_list = ['alice_css430', 'bob_css430', 'carol_css430', 'dave_css430', 'eve_css430']
for username in student_list:
try:
# 1. Create a personal subgroup for the student
subgroup = gl.groups.create({
'name': username,
'path': username,
'parent_id': parent_group_id,
'visibility': 'private'
})
# 2. Add student to the new subgroup with Expiration
user = gl.users.list(username=username)[0]
subgroup.members.create({
'user_id': user.id,
'access_level': gitlab.const.REPORTER_ACCESS,
'expires_at': expiry_date
})
print(f"Success: Subgroup created and student added for {username}")
except Exception as e:
print(f"Error processing {username}: {e}")
There is also an open source project that automates class management published by GitLab that provides additional tooling for this workflow.
Once the structure is in place, the feedback workflow is where GitLab's value becomes most apparent to students. Dame asks students to submit assignments by opening a merge request in their repository. This gives instructors an immediate, clean diff of everything the student has written.
Instructors can click any line of code and leave an inline comment — not just flagging what is wrong, but explaining why, and pointing to what to look at next. Students receive this feedback in direct context with their code, which is far more actionable than a comment at the bottom of a submitted document.
Setting up your first GitLab assignment takes some initial effort, but once the structure is in place it largely runs itself. The real payoff goes beyond organization: Students graduate having worked daily in an environment that mirrors professional software development, building habits around version control and code review rather than learning them as abstract concepts.
If you are just getting started, keep it simple. Begin with a single course group, one assignment template, and a basic pipeline. The structure will grow naturally alongside your confidence with the platform.
Make sure to sign up for GitLab for Education so that you and your students can access all top-tier features, including unlimited reviewers on merge requests, additional compute minutes, and expanded storage.