2025-11-23 12:27:25
Like many developers, I've been obsessed with using AI to automate my workflows. I started small—using individual n8n automations for individual tasks. The more I used it, the more I wondered: "How can I bring all these workflows together?"
Then the question shifted. It wasn't just about efficiency anymore. It became: "If AI can do this, what's stopping it from doing my entire job?"
That thought kept nagging at me. I'm a product manager, and I spend a lot of time creating the same artifacts over and over: user stories, acceptance criteria, feature breakdowns, database schemas, wireframes. These are the things that bridge the gap between "we want to build X" and "here's what engineers need to code."
What if I could build something that maintains the core context of a product idea and uses it to generate all the related artifacts? Not just one or two, but everything a product manager would typically create—and do it in a way that keeps everything in sync.
I had this idea brewing for months, but I couldn't find the time to work on it. Between my day job and life's usual demands, it kept getting pushed to the back burner. I was frustrated. I knew this could be something, but I just couldn't dedicate the time.
Then I broke my finger.
It was a stupid accident, honestly. But it gave me something I hadn't had in a long time: time off work. 3 months to focus entirely on building.
So I did (Thanks to speech-to-text and some one-handed typing…)
I called it VibeMap—a platform that takes your raw product idea and generates a complete development blueprint. But I didn't want to build a monolithic system that would be hard to extend. Instead, I designed a multi-agent architecture where each artifact type has its own specialized subagent.
The core idea is simple: maintain a single source of truth (the project context) and have specialized agents generate different artifacts from that context. Each agent is optimized for its specific task:
The real challenge wasn't generating individual artifacts—it was keeping everything in sync. When you update a feature, the related user stories, acceptance criteria, and database schema should all reflect that change.
I built a Context Management Service that:
On top of the individual subagents, I added a Generation Orchestration Subagent that:
This architecture means I can easily add new artifact types in the future. Want to generate API documentation? Add an API docs subagent. Need test plans? Add a test planning subagent. The system is designed to scale. The beauty of this is that the project plan provides the base that everything else needs.
Right now, VibeMap can take a product description like:
"I want to build a mobile e-commerce app where users can browse products, add items to cart, make secure payments, and track their orders. Sellers should be able to list products, manage inventory, and view sales analytics."
And generate:
All of this happens in real-time with streaming, so you can watch the blueprint build as it generates.
Three months later, my finger has finally healed. I'm getting ready to go back to work. But now I have something I didn't have before: a product that I'm genuinely excited to share with the world.
Building VibeMap taught me something important. The question isn't "Will AI replace me?" It's "How can I use AI to do the work that matters?"
The repetitive, time-consuming parts of product management—creating artifacts, maintaining consistency, ensuring nothing falls through the cracks—those can be automated. What can't be automated (at least not yet) is the strategic thinking, the stakeholder communication, the judgment calls, the vision.
VibeMap doesn't replace product managers. It frees them to focus on the parts of the job that require human insight. It also helps non-technical founders communicate ideas to teams or have a solid foundation for any vibe coding they want to do.
Context is everything. The hardest part wasn't generating artifacts—it was maintaining context across all of them. A change to a feature should ripple through user stories, acceptance criteria, and schema automatically.
Modularity enables growth. The multi-agent architecture means I can add new capabilities without rewriting the core system. Each subagent is a self-contained module that follows consistent patterns.
Real-time feedback matters. Watching the blueprint generate in real-time isn't just a nice-to-have—it helps users understand what's being created and catch issues early.
The future of PM work isn't replacement—it's augmentation. Tools like VibeMap handle the mechanical work so PMs can focus on strategy, communication, and decision-making.
VibeMap is in alpha right now. The core generation works well, but I'm actively refining prompts, improving the editing experience, and adding more customization options.
I'm looking for early users who are willing to try it out and share honest feedback. Especially:
Try it out:
What I'd love feedback on:
I'm particularly interested in hearing from teams that have tried other AI planning tools or have specific workflows I should support. Your feedback will directly shape what VibeMap becomes.
My finger is healed, but the building isn't done. I'm back to juggling work and side projects, but now I have something concrete to show for those three months. More importantly, I have a clearer vision of how AI can augment—not replace—the work we do.
If you're curious about the technical implementation, the multi-agent architecture, or just want to chat about the future of product management, I'd love to hear from you. And if you try VibeMap, let me know what you think.
The future of PM work is being written right now. I'm excited to be part of shaping it.
Links:
2025-11-23 12:20:59
This is the #1 question every CTO asks. And usually, the answer is "It depends."
But "it depends" doesn't pay the bills.
In this post, we are going to do the math. We will compare the costs of running a production AI app using AWS Bedrock, OpenAI, and Self-Hosted Open Source Models.
Most managed AI services charge by the "Token" (roughly 0.75 words).
As of late 2024, these are the two kings.
| Model | Input Cost (per 1M tokens) | Output Cost (per 1M tokens) |
|---|---|---|
| OpenAI GPT-4o | $5.00 | $15.00 |
| Bedrock Claude 3.5 Sonnet | $3.00 | $15.00 |
The Verdict: Claude 3.5 Sonnet on Bedrock is cheaper on input.
If you are building a RAG app (where you send huge documents as input), Bedrock will save you ~40% on input costs.
OpenAI is great, but for Enterprise, it has hidden costs:
AWS Bedrock Advantage:
"Why don't we just run Llama 3 on our own servers? It's free!"
Spoiler: It is not free.
To run a decent model (like Llama 3 70B) fast enough for a chatbot, you need powerful GPUs.
g5.12xlarge (4x NVIDIA A10G GPUs)The Math:
The Rule of Thumb:
Don't self-host until your Bedrock/OpenAI bill hits $5,000/month. Until then, the "Serverless" pay-per-token model is cheaper.
Stop overpaying for AI. Do the math first.
Want more Cloud FinOps tips? Follow me! 👇
2025-11-23 12:18:06
Between 1985 and 1987, a radiation therapy machine called the Therac-25 killed three people and seriously injured three others. The machine was supposed to deliver controlled doses of radiation to cancer patients. Instead, it delivered radiation doses hundreds of times higher than intended.
The cause? A race condition in the C code controlling the machine. When an operator entered treatment parameters too quickly, the software would configure the machine for high-energy electron mode while the safety mechanisms thought it was in low-energy X-ray mode. The patients received massive radiation overdoses.
One victim, a 33-year-old woman, felt an intense burning sensation during treatment. She died from radiation poisoning. Another patient, a man receiving treatment for a tumor, received such a massive dose that he developed radiation burns throughout his body. He died five months later.
The Therac-25 disaster wasn't caused by sophisticated hackers or nation-state attackers. It was caused by a simple bug—the kind of concurrency error that CERT C rules are specifically designed to prevent.
This is what happens when C code controlling life-critical systems has bugs. People die. And the industries that learned this lesson the hard way are now desperate for developers who understand how to write secure C code.
Let me show you which industries need CERT C expertise—and more importantly, why their software can't afford to have the vulnerabilities that secure coding practices eliminate.
Flight control software runs on embedded systems with no room for error. You're at 35,000 feet when the autopilot makes a calculation. That calculation depends on sensor data stored in memory. If a buffer overflow corrupts the memory location next to that sensor data, the autopilot is now making decisions based on garbage values.
For those of you educated in secure coding in C, you'll immediately recognize this scenario. The gets() function in C will copy characters into a buffer regardless of the buffer's size. If you're reading sensor data and use gets() or don't properly validate array bounds, you can overwrite adjacent memory. That adjacent memory might be storing your altitude. Or your airspeed. Or your pitch angle.
Aerospace companies mandate CERT C compliance because they've debugged these exact bugs in code that was controlling actual aircraft. This isn't theoretical—it's the accumulated knowledge from decades of incidents where software bugs caused crashes.
When aerospace engineers read CERT C Rule ARR30-C—"Do not form or use out-of-bounds pointers or array subscripts"—they're not reading a style guideline. They're reading a rule written in blood.
I want you to imagine something. You're driving on the highway. Your adaptive cruise control maintains distance from the car ahead. The distance sensor returns a measurement. The code multiplies this measurement by a constant to calculate braking force.
What happens when that multiplication overflows?
In C, when you multiply two integers and the result exceeds the maximum value the integer type can hold, you don't get an error. You get wraparound. A large positive number becomes small. Or negative, if you're unlucky. Then that negative value gets cast to unsigned—and suddenly you have a massive number that makes no physical sense.
Your car's computer thinks the vehicle ahead is either impossibly close or impossibly far away. It calculates braking force based on corrupted data. Either it slams the brakes when it shouldn't, causing the car behind you to rear-end you at highway speed—or it doesn't brake at all, and you slam into the car ahead.
Modern vehicles have millions of lines of C code controlling anti-lock brakes, airbag deployment, electronic stability control, and autonomous driving features. The automotive industry requires secure coding practices because integer overflows have caused real crashes with real injuries. Automotive engineers have spent weeks debugging crashes where someone forgot to check for overflow before doing arithmetic on sensor data.
If automotive software is dangerous when it fails, medical device software is even worse. Because when medical device code has bugs, there's no recall notice. There's no software update. The code is running inside someone's body.
A pacemaker is a small computer implanted in your chest. It monitors your heart rhythm and delivers electrical impulses when needed. The code running on that device is written in C because the hardware is resource-constrained and needs direct memory access for real-time performance.
Now imagine the code has a null pointer dereference. In a desktop application, you'd get a segmentation fault, the program would crash, and you'd restart it. In a pacemaker implanted in someone's chest, the device crashes and stops monitoring heart rhythm. If the patient has a life-threatening arrhythmia in those seconds while the device is crashed, there's no one watching. No one delivering the electrical impulse that keeps them alive.
Or consider an insulin pump. It calculates insulin delivery based on blood glucose readings. The glucose meter sends data to the pump. If the input parsing code has a buffer overflow, an attacker could inject malicious data—but even without an attacker, a simple bounds checking error could cause the pump to misread glucose values. Too much insulin delivered means hypoglycemic shock, seizure, coma, death.
Medical device manufacturers face strict regulations precisely because these bugs kill people. The Therac-25 disaster taught the industry that radiation therapy machines need rigorous software safety practices. Modern medical device manufacturers learned from that tragedy.
CERT C exists to eliminate undefined behavior before code gets implanted in someone's body. Before it's trusted to keep them alive.
Beyond individual safety, there's another domain where C coding bugs threaten lives at scale: the infrastructure systems that keep civilization running.
Industrial Control Systems weren't designed for security. They were designed in the 1970s and 80s when "security" meant a chain-link fence and a guard at the gate. The control software was written in C with zero consideration for security because these systems weren't networked.
That's changed. SCADA systems now connect to corporate networks, which connect to the internet. A water treatment plant's SCADA system is potentially accessible to anyone who can compromise the network perimeter.
Here's what a format string vulnerability can do to a water treatment plant:
The SCADA software logs sensor readings from the chlorine monitors. The logging code uses printf() with user-controlled input directly in the format string—a classic mistake. An attacker sends a crafted sensor reading that includes format specifiers like %x to leak memory or %n to write to arbitrary memory addresses.
The %x specifiers dump memory contents, potentially revealing cryptographic keys or the state of safety systems. The %n specifier writes values to memory. An attacker can now modify the SCADA system's state. They disable the chlorine monitors that detect when water isn't properly disinfected. Contaminated water flows to thousands of homes. People get sick. Some die.
In 2021, an attacker accessed a water treatment facility's SCADA system and attempted to poison the water supply by remotely changing chemical levels. The attack was detected and stopped—but it demonstrated that these systems are accessible and vulnerable.
Format string vulnerabilities aren't coding style issues when you're writing SCADA software. They're potential weapons that attackers can use to kill people.
Smart locks on apartment doors. Baby monitors in bedrooms. Industrial sensors in manufacturing plants. Medical devices in hospitals. These devices are projected to reach 39.6 billion by 2033.
Most run embedded C code on processors with no memory protection, no operating system security features, no runtime bounds checking. When there's a bug in the code, there's no safety net. A buffer overflow in a smart lock's firmware means attackers can remotely unlock doors. A use-after-free bug in an industrial sensor means attackers can manipulate the readings that automated systems depend on.
IoT devices experience 5,400 attacks per month on average. These attacks succeed because developers used strcpy() instead of strncpy(). Because they didn't validate array indices. Because they assumed input would be well-formed.
Take a look at a simple example. You're writing firmware for a smart thermostat. The device receives temperature setpoint commands over the network. Your code looks like this:
char buffer[64];
gets(buffer); // Read the setpoint command
For those of you educated in secure coding in C, you immediately see the problem. The gets() function—the same function that enabled the Morris worm back in 1988—copies input into the buffer regardless of size. An attacker sends 200 bytes. Your 64-byte buffer overflows. Adjacent memory gets corrupted. That adjacent memory might be the authentication token. Or the network credentials. Or function pointers that the attacker can redirect to malicious code.
The device is now compromised. Multiply this by millions of IoT devices all making the same mistake, and you have a massive botnet capable of taking down internet infrastructure.
CERT C rules force you to write code that's secure even when attackers are actively trying to exploit it. They eliminate the assumptions that lead to vulnerabilities.
82% of software vulnerabilities come from coding errors. Not zero-days. Not sophisticated exploits. Just bugs in the code.
The CERT C Coding Standard was developed by over 1,900 security experts who analyzed real-world vulnerabilities and documented the coding practices that prevent them. Each rule addresses a specific class of bug that has caused actual security incidents or safety failures.
When aerospace companies require CERT C compliance, they're not checking a regulatory box. They're requiring proof that you won't repeat the mistakes that brought down aircraft. When automotive manufacturers require it, they're requiring proof that your code won't be the reason for a recall—or a fatality. When medical device companies require it, they're requiring proof that your code won't fail inside someone's body.
The Therac-25 killed people because of a race condition that proper coding practices would have prevented. Modern industries learned from that disaster. They know that undefined behavior in C isn't an academic curiosity—it's the difference between a working safety system and a death trap.
If you're learning CERT C, you're not just learning rules. You're learning the accumulated wisdom from decades of debugging failures that killed people. You're learning how to write code that saves lives.
Thanks for reading this blog!
2025-11-23 12:17:46
We all love ChatGPT. But have you ever tried to ask it about a specific error in your company's private code?
"I'm sorry, I don't have access to your internal repositories."
Or asked it why your specific AWS bill is so high this month?
"I cannot access your real-time billing data."
This is the "Context Gap." Generic AI is smart, but it's blind to your work.
Enter Amazon Q.
Think of Amazon Q as an AI assistant that lives inside your AWS account and your IDE (VS Code / IntelliJ).
It’s not just trained on the internet; it connects to your data:
You can install Amazon Q as a plugin in VS Code. Here is what it can do:
Highlight a complex 200-line function written by a developer who left 3 years ago.
You: "What does this code do?"
Q: "This function processes user payments, but it has a potential bug on line 45 where it doesn't handle currency conversion."
This is the killer feature. If you have an app running on Java 8, Q can automatically upgrade it to Java 17.
It doesn't just give advice; it rewrites the code, updates dependencies, and fixes breaking changes.
Stop searching StackOverflow for "How to configure VPC peering."
Just ask Q in the AWS Console:
"Why can't my Lambda function connect to my S3 bucket?"
Q will analyze your actual IAM roles and Security Groups and tell you:
"Your Lambda execution role is missing the
s3:GetObjectpermission. Click here to fix it."
It debugs your infrastructure for you.
Amazon Q isn't just for coders. You can connect it to your company's Google Drive, Slack, or Salesforce.
Marketing Manager: "What is the latest brand guideline for our logo?"
Q: "According to the PDF 'Brand_Kit_2024.pdf' in Google Drive, the logo must always have 20px padding."
It turns your scattered documents into a searchable brain.
The future isn't just "AI." It's AI that knows you.
Have you tried Amazon Q yet? Let me know in the comments if it's better than Copilot! 👇
2025-11-23 12:17:00
Based on my personal experience. But blend with a Journalist-like story to make it more interesting.
Kuala Lumpur — It’s a scene familiar to many in the tech world: a young developer, lit by the glow of a laptop screen, celebrates the launch of their first simple web application. But for seasoned software engineer Ahmad (not his real name), that moment was just the first step of a decade-long journey climbing from novice coder to technical architect—a journey marked less by the mastery of CRUD (Create, Read, Update, Delete) and more by a relentless pursuit of growth and complexity.
“I still remember the first time my own app let someone add and delete a note,” Ahmad recalls. “It felt like magic. CRUD opened the gate to programming for me. But I eventually realized it’s really just basic survival.”
For years, CRUD skills sufficed. Ahmad bounced between languages—PHP, JavaScript, Go—building countless forms and tables, spinning up databases, and deploying apps that managed users and lists. The early victories, however, gave way to a sense of monotony. “It’s easy to fall into the loop,” he says. “Every project starts to look the same. You wonder, is this all I’m going to do?”
Industry veterans say that realization marks an important inflection point—the plateau that separates junior developers from their more senior peers. “Moving past CRUD is not about abandoning the basics,” says Maya, Ahmad’s former mentor and team lead. “It’s about asking bigger questions: How does this system work for the business? What happens if traffic doubles? If a bug wipes out the database, are we ready?”
For Ahmad, the turning point came when his team was tasked with integrating real-time payments and automated reporting into their platform. CRUD apps, he discovered, could not answer questions about reliability, scalability, error recovery, or business impact. “Suddenly, I had to think like an architect, not a form designer,” he tells us. “From database indexing to API reliability, every decision mattered.”
The role of a Senior Developer, Ahmad explains, is less about coding individual features and more about designing systems and processes. He describes late nights debugging production issues, painstaking data modeling, and the challenge of translating technical risks to cross-department stakeholders. “You don’t just write the code. You explain why, negotiate trade-offs, and make sure the solution actually solves a real-world problem.”
Beyond the technical, communication skills emerge as critical. “The bigger the system, the more people involved,” Ahmad notes. “You need to speak business, not just code. Convincing marketing or ops to invest in better logging or infrastructure—that's what really moves projects forward.”
This ethos of perpetual learning runs deep. Technologies like Laravel Collections, he says, seem straightforward—until new custom methods reinvent familiar workflows. Ahmad regularly returns to old documentation, finding surprises in the details. “Even when it’s a repeat topic, there’s always something new,” he reflects. “The best engineers constantly re-learn and re-invest in their fundamentals.”
Experts echo this view. “In the real world, seniors spend as much time mentoring, designing, and testing as they do coding,” Maya explains. “The real ascent is about growing as a leader and problem-solver, not just a programmer.”
Today, Ahmad mentors teams across departments, reviews code, drafts architectural diagrams, and steers projects from conception to completion. “I see junior devs excited about CRUD. I tell them it’s a great start. But don’t stop there—your road is far longer and richer.”
As the tech world races forward, Ahmad’s story serves as both blueprint and inspiration—a testament to the climb from CRUD to creativity, from novice to senior, and from solitary coder to collaborative leader.
“CRUD is the start of the story,” Ahmad concludes, “but the most exciting chapters come after.”
2025-11-23 12:15:08
Usually, when people talk about AWS, they talk about servers, databases, and billing alarms. 😴
But recently, AWS released something completely different. It’s called PartyRock, and it’s the most fun I’ve had with AI in years.
Here is the pitch:
It lets you build your own "Mini AI Apps" just by describing them.
Anything that takes text in and gives text/images out.
We are going to build an app where you type in a person's interests, and it suggests 3 unique gifts + generates an image of the wrapping paper.
Head over to https://partyrock.aws/ and sign in with Apple, Google, or Amazon.
You will see a box that says "Describe the app you want to build."
Type this:
"An app that suggests 3 unique gift ideas based on a person's age and hobbies. It should also generate a custom image of festive wrapping paper based on those hobbies."
Click "Generate App".
PartyRock will use AI (Bedrock) to write the code for itself.
In about 10 seconds, you will see a dashboard with:
Even though it looks like a toy, it's powered by serious tech.
If you are a Startup Founder or Product Manager, this is the fastest way to prototype.
Have an idea for a "Legal Contract Summarizer"?
Don't hire a dev team yet. Go to PartyRock, build it in 1 minute, and send the link to your friends. If they use it, then build the real thing on AWS.
Go build something fun today! 👇
partyrock.aws
Built something cool? Drop the link in the comments! 👇