2026-01-27 06:26:34
Stop bloating your context window.
TL;DR: Create small, specialized files with specific rules to keep your AI focused, accurate and preventing hallucinations.
You know the drill - you paste your entire project documentation or every coding rule into a single massive Readme.md or Agents.md.
\ Then you expect the AI to somehow remember everything at once.
\ This overwhelms the model and leads to "hallucinations" or ignored instructions.
Modern AI models have a limited "attention span."
\ When you dump too much information on them, the model literally loses track of the middle part of your prompt.
\ Breaking instructions into "skills" mimics how human experts actually work: they pull specific knowledge from their toolbox only when a specific problem comes up.
\ Skills.md is an open, standardized format for packaging procedural knowledge that agents can use.
\ Originally developed by Anthropic and now adopted across multiple agent platforms.
\ A SKILL.md file contains instructions in a structured format with YAML.
\ The file also has progressive disclosure. Agents first see only the skill name and description, then load full instructions only when relevant (when the trigger is pulled).
Bad prompt 🚫
Here are 50 pages of our company coding standards and business rules.
Now, please write a simple function to calculate taxes.
Good prompt 👉
\ After you install your skill:
Good Prompt
Use the PHP-Clean-Code skill.
Create a tax calculator function
from the business specification taxes.md
Follow the 'Early Return' rule defined in that skill.
Using skills for small projects is overkill.
\ If all your code fits comfortably in your context window, you're wasting time writing agents.md or skills.md files.
\ You also need to keep your skills updated regularly.
\ If your project architecture changes, your skill files must change too, or the AI will give you outdated advice.
\ Remember, outdated documentation is much worse than no documentation at all.
[X] Semi-Automatic
Don't go crazy creating too many tiny skills.
\ If you have 100 skills for one project, you'll spend more time managing files than actually coding.
\ Group related rules into logical sets.
[X] Intermediate
Modular skills turn a generic AI into a specialized engineer that knows exactly how you want your code written.
\ When you keep your instructions small, incremental, and sharp, you get better results.
https://skills.sh/?embedable=true
https://agentskills.io/home?embedable=true
Most skills come in different flavors for:
The views expressed here are my own.
\ I am a human who writes as best as possible for other humans.
\ I use AI proofreading tools to improve some texts.
\ I welcome constructive criticism and dialogue.
\ I shape these insights through 30 years in the software industry, 25 years of teaching, and writing over 500 articles and a book.
This article is part of the AI Coding Tip series.
https://hackernoon.com/ai-coding-tip-003-force-read-only-planning?embedable=true
\
2026-01-27 00:02:58
How are you, hacker?
🪐 What’s happening in tech today, January 26, 2026?
The HackerNoon Newsletter brings the HackerNoon homepage straight to your inbox. On this day, First Performance of Mozart's Opera "The Marriage of Figaro" in 1786, India officially became a republic in 1950, The Apollo Theater in New York launched its first Amateur Night in 1934, and we present you with these top quality stories. From Choosing an LLM in 2026: The Practical Comparison Table (Specs, Cost, Latency, Compatibility) to With CBDCs, Central Banks Are Making the Same Mistake Kodak Made, let’s dive right in.
By @nathanbsmith729 [ 4 Min read ] Final Week Results Read More.
By @b128s [ 6 Min read ] Your release process isnt neutral. It reflects what youre most afraid of: breaking production or building something nobody wants. Read More.
By @superorange0707 [ 6 Min read ] Compare top LLMs by context, cost, latency and tool support—plus a simple decision checklist to match “model + prompt + scenario”. Read More.
By @edwinliavaa [ 11 Min read ] Central banks are repeating Kodak’s biggest mistake. Why CBDCs may fail—and why Bitcoin represents a deeper monetary paradigm shift. Read More.
By @aimodels44 [ 9 Min read ]
This is a Plain English Papers summary of a research paper called Generating Piano Music with Transformers: A Comparative Study of Scale, Data, and Metrics. If you like these kinds of analysis, join AIModels.fyi or follow us on Twitter.
Before diving into models and architectures, theres a more fundamental question hiding beneath all the technical choices: what does it actually mean to succeed at music generation?
For decades, the answer was easy. AI-generated music sounded robotic, lifeless, predictable in ways youd notice immediately. But something has shifted. Researchers have begun asking whether an algorithm could fool a listener in a blind test. Not whether it matches some mathematical criterion, but whether a person sitting down to listen could tell the difference between a piece composed by a human and one generated by a machine.
This is the north star of the research. Everything else serves this single question. And the answer turns out to be surprising: when built correctly, a transformer trained on enough diverse piano data can produce music that humans genuinely struggle to distinguish from human composition.
The researchers ran a Turing-style listening study where participants heard piano pieces and had to guess whether each was human or AI-composed. For the best-performing model, results hovered near 50% accuracy. Thats not a typo. It means listeners were essentially guessing, unable to confidently separate human from machine.
Confusion matrix from the musical Turing test showing listener accuracy in distinguishing AI-composed from human-composed pieces across all genres
The confusion matrix reveals something elegant: the model crossed a genuine threshold. Not because researchers found a clever trick, but because they systematically understood what actually moves the needle on the one metric that matters.
But heres the uncomfortable truth that most music generation research glosses over: the quantitative metrics researchers have relied on for years dont predict what humans actually think.
Imagine youre evaluating music using a standard metric like prediction accuracy. The model learns to predict the next note correctly with high confidence. Thats measurable. Thats publishable. But high accuracy doesnt guarantee the music feels alive or interesting. It might just mean the model learned to play it safe, following familiar patterns. The best human composers break rules. They surprise listeners. Those surprises might actually lower the models prediction accuracy while raising its artistic value.
This gap between metrics and reality creates a trap: optimize for the wrong numbers and you build a model that scores well on paper but fails in practice. The research here cuts through that noise by comparing quantitative metrics directly against human judgments collected in the listening study. Which metrics actually correlate with listeners thinking the music sounds human? Which ones mislead you into optimizing the wrong thing?
This reframing changes how you should think about model development. Instead of treating all metrics equally, you can ask: does my model score higher on these metrics than lower-performing models? If not, that metric isnt measuring what I care about. If yes, I should probably care more about it. Its a simple idea but one thats missing from much of the music generation literature.
Now comes the actual research question: what makes one music generation model better than another?
The researchers didnt build a single system and declare victory. They systematically varied three independent dimensions and compared results. First, model size. How many parameters does the transformer need? Second, training data. What dataset should you train on, and how much does diversity matter compared to curation? Third, training strategy. Should you train from scratch, or pre-train on one dataset then fine-tune on another?
Each lever has tradeoffs. Bigger models demand more compute. Larger datasets take longer to collect and clean. Different training strategies require different computational schedules. The real question isnt which lever is best in the abstract, but which gives you the most improvement for the effort and cost youre willing to spend.
This systematic approach separates this work from the typical narrative in deep learning research, where the implicit assumption is always bigger equals better. The researchers built many models, compared them carefully, and asked what actually matters. Thats methodologically sound, and it yields insights that directly help practitioners make real tradeoffs.
Start with the data question. The researchers compared two main sources: MAESTRO, which is meticulously curated with about 200 hours of recordings and high-quality MIDI annotations, and Aria-Deduped, which is much larger and messier with around 80K MIDI files from diverse genres and sources.
The conventional wisdom in machine learning suggests you should invest in data quality. Carefully curated datasets reduce noise and bias. They represent gold standard examples. But the listening study results tell a different story. Models trained on the larger, more diverse Aria dataset outperformed models trained on the smaller MAESTRO dataset.
This is where the papers central insight emerges: bigger data beats bigger models. But thats only half the story. The critical detail is diversity. The Aria dataset contains piano music from many genres, styles, and recording conditions. Its messier precisely because its broader. A model trained on that breadth learns richer statistical patterns than one trained on pristine examples from a narrow slice of music.
Think about how language models develop intuition. They dont learn by studying 10,000 perfectly edited sentences in one style. They learn by reading millions of texts written by millions of people in different contexts, tones, and registers. The variety teaches the model what varies and what stays constant across language. The same principle applies to music. Diverse data teaches the model whats essential to the grammar of piano music versus whats incidental to a particular recording or performance style.
Training curves comparing models pre-trained on Aria-Deduped against the baseline model trained only on MAESTRO, showing faster convergence and better final performance from the larger dataset
The gap widens as you train longer. The model pre-trained on Aria continued improving on downstream tasks even with limited fine-tuning data, while the MAESTRO-only model plateaued earlier. This has a practical implication: if youre building a music generation system and you can either spend time curating a smaller dataset or gathering more diverse data (even if its rougher), choose the latter.
Model scaling is the gospel of modern deep learning. Build a bigger model, throw more compute at it, and performance improves. This has held true across language, vision, and many other domains. But even a good principle has limits.
The researchers compared transformers of different sizes, all trained on the same datasets. A 155M-parameter model. A 355M-parameter model. A 550M-parameter model. A 950M-parameter model. As youd expect, larger models generally performed better in pre-training. But the gains diminish. Each doubling of model size gives increasingly smaller improvements.
More importantly, the interaction between model size and data size matters. A 950M-parameter model trained on large, diverse data beats a smaller model trained on the same data. But a larger model trained on small, curated data doesnt dramatically outperform a smaller model trained on the same limited data. The model gets larger but has fewer diverse examples to learn from, so it ends up memorizing rather than generalizing. Youve wasted parameters on overfitting.
Training loss curves for MAESTRO models of different sizes, showing how performance gains diminish as model size increases when training data is limited
This tells you something crucial: find the sweet spot where your model has enough capacity to express patterns in your data without being so oversized that it memorizes. For the 80K Aria dataset, that sweet spot appears to be in the 950M range. A 155M model trained on the same data was close behind, suggesting the marginal benefit of going bigger is limited.
The practical insight: dont automatically assume you need to build the largest possible model. You need a model large enough that data diversity, not model capacity, is your bottleneck. Build bigger than that and youre spending compute on diminishing returns.
Training strategy introduces another variable. What if you didnt train only on one dataset? What if you pre-trained on large, diverse data to learn the fundamentals of piano music, then fine-tuned on smaller, curated expert data to learn the specific style or qualities you care about?
This is where the pre-training and fine-tuning paradigm reveals its power. A model trained only on MAESTRO learns from limited examples. Its slow to train because theres not much data. But a model pre-trained on the 80K Aria files, then fine-tuned on MAESTRO, learns rapidly. The pre-training phase captures broad patterns of piano music. The fine-tuning phase refines those patterns toward MAESTROs particular characteristics.
Training curves for models pre-trained on Aria-Deduped and fine-tuned on MAESTRO, showing rapid convergence and superior performance compared to training from scratch
This matters because it solves a real problem in music generation: the highest-quality datasets are small and expensive to create, while large datasets are often noisier. Pre-training lets you leverage both. You gather whatever diverse data you can find, train on it to establish a foundation, then apply limited expert data where it counts most.
The fine-tuning experiments with different context window sizes (how much previous music the model can see when generating the next note) further confirm this principle. A model that started with broader pre-training learned to use context windows more effectively during fine-tuning than a model starting from scratch.
Fine-tuning curves for models with different context sizes, showing how architectural choices interact with training strategy
The practical takeaway: if you have access to limited high-quality data in a specific domain or style, dont waste it training from scratch. Pre-train broadly first, then fine-tune precisely. Youll converge faster and achieve better results with less total training time.
All these choices, all this careful ablation, point toward one question: can the best model actually fool human listeners?
The researchers collected human judgments through a listening study where participants heard pieces of piano music and had to classify each as human or AI-composed. They didnt tell listeners whether they were comparing against the best model or a baseline. They just asked: does this sound human?
The confusion matrix shows the results. The best-performing model, a 950M-parameter transformer trained on 80K diverse MIDI files, achieved near 50% accuracy in the classification task. Thats the threshold where humans cant reliably tell the difference.
Accuracy of listener classifications broken down by genre, showing which genres the model fools most and least convincingly
But accuracy varies by genre. Some musical styles are easier to fool humans with than others. Looking at accuracy separated by both genre and whether the piece was AI or human reveals the models strengths and weaknesses.
Performance broken down by both genre and origin, showing where the model excels and where listeners can still detect the AI
This variation is instructive. Its not that the model universally reaches human-level performance. Rather, it reaches human-level performance on some genres while still having tells on others. Classical perhaps. Jazz perhaps not. This reflects the training data composition, the diversity of examples the model saw during training.
The distribution of listener guesses shows whether people had an intrinsic bias to guess human or AI.
Response bias showing whether listeners tended to guess human or AI composition, which affects how to interpret the raw accuracy numbers
Humans dont classify randomly. They have biases, preferences, hunches. Some people might assume that anything unusual-sounding must be AI. Others might assume that complexity implies human authorship. Understanding these biases matters for interpreting what the 50% accuracy actually means. If people had a strong bias, 50% might actually represent strong model performance despite the bias pulling toward one label.
The listening study validates what the metrics couldnt quite capture on their own. The model produces something genuinely musical. Not just statistically plausible note sequences, but pieces that engage listeners the way human-composed music does.
The full picture across all these decisions reveals a pattern. Success in music generation didnt come from finding one clever architectural innovation or discovering that one weird trick. It came from systematically understanding how three variables interact: how much capacity your model needs, how diverse your training data should be, and how to efficiently transfer learning from general to specific.
The best model wasnt the biggest. It was the one trained on the most diverse data, with enough capacity to express what it learned. Thats a lesson that extends far beyond piano music. Across domains where youre generating structured sequences, the same principle likely holds. Diversity in training data often outweighs curation. Pre-training on broad data before fine-tuning on specific data accelerates learning. And model size matters, but only until youve given the model enough room to express the patterns in your training data.
The real achievement here is methodological. By building many models and comparing them systematically against human judgment, the researchers created a framework for developing better music generation systems. They didnt declare that one architectural choice is optimal for all time. They showed how to ask the right questions and how to measure the answers in a way that actually corresponds to what matters in practice: whether the music sounds human.
Original post: Read on AIModels.fyi
Read More.🧑💻 What happened in your world this week?
It's been said that writing can help consolidate technical knowledge, establish credibility, and contribute to emerging community standards. Feeling stuck? We got you covered ⬇️⬇️⬇️
ANSWER THESE GREATEST INTERVIEW QUESTIONS OF ALL TIME
We hope you enjoy this worth of free reading material. Feel free to forward this email to a nerdy friend who'll love you for it.See you on Planet Internet! With love, The HackerNoon Team ✌️
2026-01-26 23:40:21
Enterprise performance management (EPM) initiatives increasingly determine how global organizations forecast growth, allocate capital, and manage financial risk. While many enterprises adopt modern EPM platforms, relatively few professionals possess the depth of technical and business expertise required to architect solutions that operate reliably at scale while delivering measurable operational gains. Among these specialists, Maheshwar Gourishetti has distinguished himself through original, enterprise-wide EPM architectures that have transformed financial planning and consolidation processes across multiple industries.
\ With over 15 years of specialized experience spanning retail, technology, life sciences, and energy sectors, Gourishetti has led and architected large-scale implementations of OneStream and Oracle EPM Cloud platforms for complex, multi-entity organizations. His work consistently goes beyond standard platform configuration, focusing instead on designing scalable architectures that replace fragmented legacy systems, reduce manual effort, and materially improve decision-making accuracy.
A defining aspect of Gourishetti’s work is his ability to design original EPM architectures tailored to complex operational realities rather than relying on out-of-the-box implementations. In one enterprise retail engagement, he architected a OneStream-based FP&A solution integrating data from more than a dozen source systems, including SAP and enterprise data warehouses. His design introduced custom business rules and automated reconciliation frameworks that reduced financial close timelines by over 50 percent while eliminating thousands of hours of recurring manual effort annually.
\ Rather than adopting standard integration patterns, Gourishetti designed customized Cube2Cube and App2App data pipelines to support high-volume consolidations without performance degradation. These architectural decisions enabled finance teams to shift from spreadsheet-based forecasting to real-time scenario modeling, significantly improving forecast accuracy and operational responsiveness.
Effective EPM architecture is not about deploying tools—it’s about designing systems that finance teams can trust at scale,” Gourishetti explains. “My focus has always been on building solutions that eliminate manual risk while enabling leadership to act on timely, accurate data.
Across multiple enterprise environments, Gourishetti has served in leading and critical roles where his architectural decisions directly influenced organizational outcomes. In several implementations, he was responsible for end-to-end solution design, including requirements definition, technical architecture, security models, and deployment strategy. Business stakeholders and implementation teams relied on his guidance to resolve complex planning and consolidation challenges involving logistics P&L modeling, grant management, treasury forecasting, and multi-entity consolidations.
\ In one global implementation, his architecture enabled field users across multiple regions to perform detailed P&L analysis by distribution center, a capability previously unavailable due to system limitations. The resulting solution became the organization’s standard financial planning platform, supporting hundreds of users and multiple business functions.
Gourishetti’s work spans Oracle EPM Cloud (EPBCS, PBCS, EDMCS), OneStream, and legacy Hyperion platforms, positioning him as a cross-platform architect capable of guiding organizations through complex migrations. He has led transitions from on-premise Hyperion environments to cloud-native architectures, designing migration strategies that preserved data integrity while improving performance, scalability, and governance.
\ His technical expertise includes developing advanced business rules using VB.NET and Groovy, architecting automated validation frameworks, and implementing role-based dashboards that balance usability with enterprise security requirements. These solutions have enabled finance organizations to reduce dependency on IT intervention while maintaining strong data governance.
Maheshwar Gourishetti is a certified EPM/CPM consultant and enterprise solution architect with more than 15 years of experience delivering large-scale financial planning, budgeting, forecasting, and consolidation solutions. His work has produced measurable operational improvements, including reduced close cycles, improved forecast accuracy, and significant efficiency gains across global organizations. Known for his ability to translate complex financial requirements into scalable, high-performance architectures, Gourishetti continues to shape how enterprises leverage modern EPM platforms to support strategic decision-making.
\
:::tip This story was distributed as a release by Sanya Kapoor under HackerNoon’s Business Blogging Program.
:::
\
2026-01-26 23:30:03
Welcome one, welcome all to another HackerNoon Company of the Week feature.
Every week, we highlight a standout company from our Tech Company Database that’s making waves in the global tech ecosystem and the lives of its users. Our database features everything from S&P giants to rising stars in the Startup scene.
This week, all eyes are on Beldex - a privacy-centric blockchain ecosystem built to enable secure, anonymous digital interactions and transactions across Web3.
:::tip Want to be featured on HackerNoon’s Company of the Week?
Request Your Tech Company Page on HackerNoon Today!
:::
https://coinmarketcap.com/cmc-ai/beldex/what-is/?embedable=true
\
Then there’s identity. Beldex Names let users replace long wallet strings with readable identifiers, without turning those identities into tracking vectors. It’s a small touch, but one that shows privacy and usability don’t have to cancel each other out.
While much of the crypto space is busy optimizing for speed, hype, or financial engineering, Beldex is focused on something quieter and harder to fake: giving people a way to exist online without constantly giving themselves away.
\
Beldex has been a consistent voice on HackerNoon, with articles that explore how real privacy tools can coexist with everyday internet habits - from secure messaging to decentralized networking - at a time when digital surveillance and data harvesting are mainstream concerns.
Some of their most engaging pieces include:
Selective Privacy: How BelNet’s Split Tunneling Balances Speed and Security
From Chatbots to Guardians of Data: How BChat Harnesses AI for Secure Messaging
UK, EU, India: As VPN Regulations Tighten, BelNet Downloads Surge
\
HackerNoon’s Business Blogging Program is one of the many ways we help brands grow their reach and connect with the right audience. This program lets businesses publish content directly on HackerNoon to boost brand awareness and build SEO authority by tapping into ours.
Here’s what’s in it for you:
:::tip Publish Your First Story with HackerNoon Today
:::
And that’s all for this week, hackers.
Stay creative, Stay iconic.
HackerNoon Team
2026-01-26 23:28:36
The artificial intelligence landscape is undergoing a tectonic shift. We are moving from the era of "Chatbot" systems that generate content to the era of "Agentic AI" where systems execute complex workflows intelligently. This transition from passive assistants to active, autonomous agents requires more than just better models; it demands a fundamental rethinking of enterprise software architecture.
Leading this charge are engineering executives who bridge the gap between theoretical AI research and mission-critical reliability. Among them is Sudarshan Venkataraman, a Principal AI Engineering Manager whose work on multi-agent meshes and autonomous support ecosystems offers a blueprint for the future of enterprise automation.
With a background spanning high-scale distributed systems and AI-first transformations, Sudarshan argues that the true value of AI isn't in its ability to converse, but in its ability to act. "The goal isn't just to build a smarter chatbot" Sudarshan notes. "It is to architect a 'nervous system' for the enterprise, a mesh of interoperable agents that can reason, route, and resolve complex issues without human intervention."
For years, enterprise support meant "human-in-the-loop" workflows. The shift to fully "Zero-Touch" operations requires a rigorous engineering approach that prioritizes governance over unrestricted generation.
Sudarshan spearheaded the development of one of the industry's first Self-Driving Support Ecosystems. Moving beyond simple script-following bots, his team architected a "Multi-Agent Mesh" where specialized AI entities, specifically a Transactional Workflow Agent, a Semantic Intent Engine, and a Continuous Learning RAG System collaborate to solve contact center enterprise problems.
"We had to solve the problem of 'Agentic Interoperability,'" explains Sudarshan. "We built an architecture where the Semantic Engine acts as the brain, understanding the user's need, and then dynamically delegates tasks to the Transactional Agent, which acts as the hands. This separation of concerns is critical for reliability."
The impact of this architectural shift was profound. By deploying these autonomous agents, the platform successfully automated a high 7-figure volume of voice incidents monthly. This transition from human-centric to agent-centric workflows generated 8-figure revenue streams and delivered 9-figure annual cost savings for enterprise clients, proving that autonomous agents are no longer experimental toys but essential drivers of operational efficiency.
In the world of enterprise telephony and real-time communication, "latency" is the enemy and "uptime" is the only metric that matters. Building AI that works in a lab is different from building AI that works while processing millions of concurrent voice streams.
Sudarshan’s leadership was pivotal in engineering a Cloud-Native Communication Infrastructure. Leading a distributed engineering organization, he enforced strict reliability standards that allowed the system to maintain 99.99% uptime while delivering sub-two-second response times for AI decisioning.
"Reliability is the primary feature of autonomy," Sudarshan asserts. "If an agent fails, it doesn't just frustrate a user; it breaks a business process."
Under his technical direction, the platform scaled to support tens of thousands of concurrent calls and 8-figure monthly conversations. By optimizing the "Semantic Intent Engine" to handle real-time sentiment analysis and routing, his team improved First Contact Resolution metrics by approximately 40%. This robustness allowed the platform to capture significant market share in the multi-billion dollar enterprise communications market, serving 6-figure monthly active users.
One of the most persistent bottlenecks in enterprise support is the manual triage of incoming requests. Sudarshan recognized that this was a data problem, not a staffing problem.
He architected a "Context-Enriched Intelligence" platform designed to achieve "Zero-Touch Triage." By moving away from keyword-based routing to probabilistic intent modeling, the system could ingest 8-figure monthly units (emails, tickets, signals) and instantly categorize them with near-perfect accuracy.
"Building this required a 'Configuration-First' mindset," Sudarshan notes. "We designed the system to be resilient to transient failures, using asynchronous retry mechanisms to ensure data integrity."
The result was a platform that met a strict 30-second Service Level Agreement (SLA) for case creation with 99.99% reliability. By eliminating the need for human triage, the system not only reduced operational overhead but also created a cleaner data layer for future AI training a virtuous cycle of improvement.
In today's fragmented SaaS ecosystem, data is often trapped in silos. A key pillar of Sudarshan’s engineering philosophy is "Interoperability." He led the initiative to embed AI capabilities across competing enterprise ecosystems, breaking down the traditional "walled gardens" of software.
By architecting a "Sidecar" integration pattern, his team successfully embedded autonomous capabilities directly into third-party platforms. This "Host-Agnostic" approach allowed the AI to provide real-time, contextual guidance to agents regardless of the underlying CRM they were using.
"We focused on meeting the user where they work," says Sudarshan. "By decoupling our AI from our own proprietary interface, we unlocked massive value for customers with heterogeneous tech stacks." This strategy drove platform adoption to over 6-figure monthly active users and secured contracts with major fintech enterprises who valued the flexibility of the architecture.
Behind every scalable system is a scalable team. Sudarshan’s contributions extend beyond code to the very culture of engineering leadership in the AI era. He believes that leading an AI-first organization requires a fundamental shift from "managing tasks" to "architecting outcomes."
"In an era where AI writes code, the role of the engineer shifts to system design and validation," Sudarshan explains. "My role as a leader is to empower my team to make that shift - to move from being 'coders' to being 'architects of autonomy'."
Sudarshan is known for his philosophy of "Leading from the Front." He maintains deep technical relevance, often "dogfooding" the very agentic tools his teams build to understand the developer experience firsthand. This "Technical Empathy" allows him to remove friction effectively, creating an environment where engineers feel understood and supported.
His leadership results speak as loudly as his technical ones. Known for building high-performance teams from scratch, Sudarshan has maintained near-perfect retention rates in a hyper-competitive talent market. By mentoring senior engineers into management roles and fostering a culture of "Empowerment and Accountability," he has built organizations that don't just follow roadmaps they define them.
As the industry pivots to Agentic AI, the need for rigorous engineering leadership has never been greater. Sudarshan represents the new archetype of the AI executive: one who combines the strategic vision to define the future of work with the technical depth to architect the systems that make it possible. Through his work on autonomous meshes, carrier-grade platforms, and interoperable agents, he is not just participating in the AI revolution, he is engineering its foundation.
Sudarshan is a distinguished Principal AI Engineering Manager specializing in AI-first transformations, autonomous agent development, and large-scale platform architecture. With a Master of Science in Computer Science from the University at Buffalo and a background in distributed systems, he has spent over eight years pioneering enterprise-grade AI solutions. His work includes architecting fully autonomous contact center platforms and building high-performance engineering organizations that deliver 8-figure business impact. He is a recognized thought leader in the field of Agentic AI and Engineering Management.
\
:::tip This story was distributed as a release by Sanya Kapoor under HackerNoon’s Business Blogging Program.
:::
\
2026-01-26 23:18:22
Swift Concurrency has fundamentally changed how we write asynchronous code, making it more readable and safer.
However, the real world is still full of legacy APIs and SDKs that rely on completion handlers and delegates. You cannot simply rewrite every library overnight. This is where Continuations come in. They act as a powerful bridge, allowing us to wrap older asynchronous patterns into modern async functions, ensuring that our codebases remain clean and consistent even when dealing with legacy code.
For years, iOS developers relied on two fundamental approaches for asynchronous operations: completion closures and delegate callbacks. Consider a typical network request using completion handlers:
func fetchUserData(completion: @escaping (User?, Error?) -> Void) {
URLSession.shared.dataTask(with: url) { data, response, error in
// Handle response in a different scope
if let error = error {
completion(nil, error)
return
}
// Process data...
completion(user, nil)
}.resume()
}
Copy
\ Similarly, delegate patterns scatter logic across multiple methods:
class LocationManager: NSObject, CLLocationManagerDelegate {
func locationManager(_ manager: CLLocationManager,
didUpdateLocations locations: [CLLocation]) {
// Handle success in one method
}
func locationManager(_ manager: CLLocationManager,
didFailWithError error: Error) {
// Handle failure in another method
}
}
Copy
\ Both approaches share a critical weakness: they fragment your program’s control flow. Instead of reading code from top to bottom, developers must mentally jump between closures, delegate methods, and completion callbacks. This cognitive overhead breeds subtle bugs-forgetting to invoke a completion handler, calling it multiple times, or losing track of error paths through nested callbacks.
Continuations transform these fragmented patterns into linear, readable code. They provide the missing link between callback-based APIs and Swift’s structured concurrency model. By wrapping legacy asynchronous operations, you can write code that suspends at natural points and resumes when results arrive-without modifying the underlying implementation.
Here’s the transformation in action. Our callback-based network function becomes:
func fetchUserData() async throws -> User {
try await withCheckedThrowingContinuation { continuation in
URLSession.shared.dataTask(with: url) { data, response, error in
if let error = error {
continuation.resume(throwing: error)
return
}
// Process and resume with result
continuation.resume(returning: user)
}.resume()
}
}
Copy
Now calling code flows naturally:
do {
let user = try await fetchUserData()
let profile = try await fetchProfile(for: user)
updateUI(with: profile)
} catch {
showError(error)
}
A continuation represents a frozen moment in your program’s execution. When you mark a suspension point with await, Swift doesn’t simply pause and wait, it captures the entire execution context into a lightweight continuation object. This includes local variables, the program counter, and the call stack state.
This design enables Swift’s runtime to operate efficiently. Rather than dedicating one thread per asynchronous operation (the traditional approach that leads to thread explosion), the concurrency system maintains a thread pool sized to match your CPU cores. When a task suspends, its thread becomes available for other work. When the task is ready to resume, the runtime uses any available thread to reconstruct the execution state from the continuation.
Consider what happens during a network call:
func processData() async throws {
let config = loadConfiguration() // Runs immediately
let data = try await downloadData() // Suspends here
let result = transform(data, with: config) // Resumes here
return result
}
Copy
At the await point, Swift creates a continuation capturing config and the program location. The current thread is freed for other tasks. When downloadData() completes, the runtime schedules resumption—but not necessarily on the same thread. The continuation ensures all local state travels with the execution, making thread switching transparent.
Swift provides two continuation variants, each addressing different needs:
CheckedContinuation performs runtime validation, detecting common errors like resuming twice or forgetting to resume. This safety net makes it the default choice during development:func getCurrentLocation() async throws -> CLLocation {
try await withCheckedThrowingContinuation { continuation in
let manager = CLLocationManager()
manager.requestLocation()
manager.locationHandler = { locations in
if let location = locations.first {
continuation.resume(returning: location)
}
}
manager.errorHandler = { error in
continuation.resume(throwing: error)
}
}
}
\
If you accidentally resume twice, you’ll see a runtime warning: SWIFT TASK CONTINUATION MISUSE: continuation resumed multiple times.
UnsafeContinuation removes these checks for maximum performance. Use it only in hot paths where profiling confirms the overhead matters, and you’ve thoroughly verified correctness:func criticalOperation() async -> Result {
await withUnsafeContinuation { continuation in
performHighFrequencyCallback { result in
continuation.resume(returning: result)
}
}
}
\
The continuation API enforces a strict contract: resume exactly once. This guarantee prevents resource leaks and ensures predictable execution. Swift provides four resume methods to cover different scenarios:
resume() for operations without return values:func waitForAnimation() async {
await withCheckedContinuation { continuation in
UIView.animate(withDuration: 0.3, animations: {
self.view.alpha = 0
}) { _ in
continuation.resume()
}
}
}
\
resume(returning:) to provide a result:func promptUser(message: String) async -> Bool {
await withCheckedContinuation { continuation in
let alert = UIAlertController(title: message, message: nil, preferredStyle: .alert)
alert.addAction(UIAlertAction(title: "Yes", style: .default) { _ in
continuation.resume(returning: true)
})
alert.addAction(UIAlertAction(title: "No", style: .cancel) { _ in
continuation.resume(returning: false)
})
present(alert, animated: true)
}
}
\
resume(throwing:) for error propagation:func authenticateUser() async throws -> User {
try await withCheckedThrowingContinuation { continuation in
authService.login { result in
switch result {
case .success(let user):
continuation.resume(returning: user)
case .failure(let error):
continuation.resume(throwing: error)
}
}
}
}
\
resume(with:) as a convenient shorthand for Result types:func loadImage(from url: URL) async throws -> UIImage {
try await withCheckedThrowingContinuation { continuation in
imageLoader.fetch(url) { result in
continuation.resume(with: result)
}
}
}
When migrating real-world code, certain patterns emerge repeatedly. Here’s how to handle a delegate-based API with multiple possible outcomes:
class NotificationPermissionManager: NSObject, UNUserNotificationCenterDelegate {
func requestPermission() async throws -> Bool {
try await withCheckedThrowingContinuation { continuation in
UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .sound]) { granted, error in
if let error = error {
continuation.resume(throwing: error)
} else {
continuation.resume(returning: granted)
}
}
}
}
}
\ For callbacks that might never fire (like user cancellation), ensure you handle all paths:
func selectPhoto() async -> UIImage? {
await withCheckedContinuation { continuation in
let picker = UIImagePickerController()
picker.didSelect = { image in
continuation.resume(returning: image)
}
picker.didCancel = {
continuation.resume(returning: nil)
}
present(picker, animated: true)
}
}
\
Continuations represent more than a compatibility layer they embody Swift’s pragmatic approach to evolution. By providing clean integration between legacy and modern patterns, they enable gradual migration rather than forcing disruptive rewrites. As you encounter older APIs in your codebase, continuations offer a path forward that maintains both backward compatibility and forward-looking code quality.
The safety guarantees of CheckedContinuation make experimentation low-risk, while UnsafeContinuation provides an escape hatch for proven, performance-critical code. Master these tools, and you’ll find that even the most callback-laden legacy code can integrate seamlessly into modern async workflows.
\
