Foto von Felix Dreißig, einem jungen Mann in einem gelben Pullover, der aus einem grünen Rahmen herausschaut

Information Security Specialist

Looking for a Kaniko alternative in GitLab CI? Explore 7 options from sticking with Kaniko to redesigning your Runner infrastructure, incl. tools like Buildah.

Seven Ways to Replace Kaniko in your Container Image Builds

codecentric Blog

Machine Learning Specialist

The evolution of AI-assisted development has reached an interesting inflection point. While tools like Claude Code offer powerful coding assistance, the traditional workflow still requires constant human intervention—approving each action, managing permissions, and dealing with the security implications of giving AI broad system access. What if we could change this paradigm entirely?

I've been experimenting with a containerized approach that transforms Claude Code from an interactive assistant into an autonomous developer, capable of working independently while maintaining security and quality standards. My proposed result is a development workflow that feels almost magical in its simplicity: write a GitHub issue, let Claude Code implement the solution completely, then review the finished pull request and even give feedback.

## The Problem with Current AI Development Workflows

Anyone who has used Claude Code extensively knows the friction points. Every file operation requires approval. Each command execution needs permission. The constant interruptions break the flow of development, and the security implications of granting broad system access make many organizations hesitant to adopt AI development tools at scale.

More fundamentally, the interactive nature of current AI development tools doesn't always match how we actually want to work with AI. In most cases we don't want to micro-manage an AI assistant—we want to delegate entire tasks and receive completed, high-quality work.

## A New Workflow Paradigm

The Claude Code Development Container enables a fundamentally different approach. Instead of interactive sessions filled with permission requests, the workflow becomes elegantly simple:

You write a detailed GitHub issue describing what needs to be built, fixed, or improved. Claude receives this issue within a secure, pre-configured container environment and works completely independently. It analyzes requirements, checks for existing pull requests, implements solutions following best practices, creates comprehensive tests, and submits a well-structured pull request. You then review the completed work and either merge it or provide feedback for iteration.

This three-step process—issue, autonomous implementation, review—maximizes both productivity and quality control. Developers can focus on architecture and design decisions while Claude handles the routine but important work of implementation, testing, and documentation.

## Technical Architecture

The solution leverages containerization to create isolated, secure environments where Claude Code can operate without restrictions while being completely separated from the host system. Built on Python 3.11 with a carefully curated toolchain including Git, GitHub CLI, and the UV package manager, the container provides everything needed for modern Python development.

Security remains paramount. The container runs with a non-root user and operates with limited permissions, ensuring Claude cannot accidentally affect the host system while maintaining the autonomy needed for effective development work. Authentication is handled through secure token-based systems, eliminating the complexity of SSH key management.

The real innovation lies in the custom command system which is part of claude code. A sophisticated `issue` command intelligently detects whether it's working on a new implementation or improving an existing pull request based on review feedback. This command encapsulates years of DevOps best practices, automatically handling everything from semantic commit messages to comprehensive testing and PR template generation.

## Beyond Traditional Development Automation

What makes this approach particularly powerful is how it handles the nuanced aspects of software development that simple automation typically misses. When working on an existing pull request, Claude analyzes review comments, categorizes feedback by type, creates improvement checklists, and systematically addresses each point. When implementing new features, it follows test-driven development practices, creates proper documentation, and ensures comprehensive test coverage.

The container environment ensures reproducibility across different systems and team members. Whether running on a developer's laptop or in a CI/CD pipeline, the behavior remains consistent and predictable. This eliminates the common problem of environment-specific issues and makes the AI development process truly portable.

## Real-World Impact

The practical implications of this approach are significant. Development teams can transform their GitHub issue backlogs from growing lists of technical debt into actively addressed items. Issues that might languish for weeks in traditional workflows can be implemented, tested, and submitted for review within hours.

The quality of work remains high because Claude Code operates within well-defined constraints and follows established best practices. The container includes pre-commit hooks, linting tools, and testing frameworks that ensure code quality standards are maintained automatically. The review process provides human oversight while maintaining the efficiency gains of autonomous implementation.

Perhaps most importantly, this approach changes how developers think about AI assistance. Instead of viewing AI as a tool that needs constant guidance, it becomes a capable team member that can be trusted with complete tasks. This mental shift opens up new possibilities for how development teams structure their work and allocate their time.

## Looking Forward

The containerized approach to AI development represents just the beginning of what's possible when we rethink the relationship between human developers and AI assistants. As the technology matures, we can envision more sophisticated delegation models, better integration with existing development workflows, and expanded support for different programming languages and frameworks.

The open architecture makes extension and customization straightforward. Teams can develop their own commands, modify container configurations, and integrate with their specific toolchains and processes. The potential for community-driven improvements and shared best practices is substantial.

This evolution from interactive assistance to autonomous development doesn't replace human developers—it amplifies their capabilities. By handling routine implementation tasks with the same attention to quality that experienced developers demand, AI enables teams to focus on the creative and strategic aspects of software development that truly require human insight.

The future of AI-assisted development isn't about better autocomplete or smarter suggestions. It's about transforming how we think about delegation, automation, and the division of labor between humans and machines in the creative process of building software.

---

*Interested in trying this approach? Check out the [Claude Code Development Container](https://github.com/dstalzjohn/agents-cli-sandbox) for implementation details and setup instructions.*



Go beyond interactive AI. A secure container turns Claude into an autonomous developer that takes a GitHub issue and delivers a complete, tested pull request.

Claude Code: From AI Assistant to Autonomous Developer

From Interactive Assistant to Autonomous Developer: Containerizing Claude Code

Recently, codecentric's security experts were tasked with testing the IT infrastructure security of a company with several hundred employees. The clients believed they were secure: The systems were running on the latest version of Windows 11 and Windows Server 2022, and a commercial antivirus product was in use.

Nevertheless: After two days, codecentric's security experts had become domain administrators with full access to all systems without the client noticing. An attacker in this position could have exfiltrated business data and encrypted or deleted all systems. How could this happen?

## Summary of the Attack

The attack was carried out as part of a so-called "assumed-breach" scenario, meaning we were provided with a normal user account without special permissions, similar to what an attacker might obtain through a phishing attack.

First, we conducted an enumeration of the domain, examining what information and data our user could access. During this process, a shared file storage was discovered through which, due to incorrect configuration, **personal files of other users could be accessed**. Many passwords were found in these files, including an old backup of the IT admin's password manager. A list was created from these passwords, which was then automatically tested against the available systems.

**This allowed access to one of the systems on which a domain administrator was logged in.** The goal was now to read the memory of the process in which the domain administrator's credentials were temporarily stored. However, the execution of malicious code was prevented by Windows Defender and the antivirus product. But **using a self-developed bypass of the AMSI (Antimalware Scan Interface), this defense mechanism was also circumvented**. Subsequently, the domain administrator's credentials could be extracted and finally used to log in to the domain controller.

## Preventative Measures

The attack described above is a good demonstration that defending IT infrastructure on a single level is insufficient. For example, virus protection is at most a temporary obstacle for experienced attackers. A multi-layered approach is necessary, where various products and procedures are used at multiple levels. This concept is also known as [Defense in Depth](https://www.cloudflare.com/de-de/learning/security/glossary/what-is-defense-in-depth/).

Here are some measures that would have made the attack described above more difficult:

- Hardening of the Active Directory domain so that, for example, a normal user can only query the most necessary information
- Introduction of appropriate password management, for example via [LAPS](https://learn.microsoft.com/de-de/windows-server/identity/laps/laps-overview), so that local administrator passwords are not used on multiple systems
- Use of [Credential Guard](https://learn.microsoft.com/de-de/windows/security/identity-protection/credential-guard/), so that credentials cannot be easily extracted from the LSASS process

The measure that would have had the greatest impact on an attacker's chances of success in this case would be the use of tools for logging, monitoring, and alerting, also known as "[Security Information and Event Management](https://de.wikipedia.org/wiki/Security_Information_and_Event_Management)" (SIEM). The idea is to centrally collect log data from various systems, analyze them for potential attacks, and trigger alarms when detected.

This measure creates visibility into the processes on client systems and in the network and **allows responding to an attack before it's too late**. **It makes the attackers' lives significantly more difficult**, because they suddenly have to be careful not to trigger warnings or alarms. They can no longer try things arbitrarily until a security measure is bypassed. The attack described above could have been quickly noticed this way.

## Technical Details of the Attack

### Step 1: Enumerating the Domain

With the provided normally privileged user account, various tools were used to gather more information about the domain:

- [SharpHound + Bloodhound](https://github.com/SpecterOps/BloodHound)
- [adPEAS](https://github.com/61106960/adPEAS)
- Various PowerShell commands

Using these tools, a detailed overview of users, computers, groups, and potential privileges was obtained.

Potential countermeasures:

- [Deny AD users read access to certain objects](https://learn.microsoft.com/en-us/answers/questions/929688/best-practice-to-prevent-active-directory-enumerat)
- Logging & Alerting (SharpHound is easy to detect)
- Make access to PowerShell in Citrix more difficult (it should be noted that completely preventing command-line calls is usually not feasible)

### Step 2: Enumerating Shared Directories

The provided user had access to many shared directories. In these directories, we specifically searched for files that potentially contained credentials. Among other things, a plaintext backup of the IT admin's password manager and credentials of a user with RDP rights were found.

Potential countermeasures:

- Restrict access to shared directories
- Do not share private user data such as Desktop or Documents. The respective user directories should only be accessible to the users themselves.
- Sensitize users so that no password lists or password manager backups are stored in plaintext → Password management
- Logging & Alerting (Automated scanning is easy to detect)

### Step 3: Local Administrator on the Admin Jumphost

Thanks to the domain enumeration, it was known that a computer existed on which domain administrators had valid and active sessions. Using the found credentials, authentication via the Remote Desktop Protocol was possible on this computer. The goal now was to expand the available permissions to read the credentials of the logged-in domain administrators with local administrator privileges.

For this purpose, a list of all known local administrator usernames and another list of all already identified passwords were created. Using the tool [crackmapexec](https://github.com/byt3bl33d3r/CrackMapExec), all combinations of these usernames and passwords were then automatically tried against all computers in the domain. This was deliberately done only against local users and not against domain users to avoid locking domain users and thus restricting availability. Through this method, valid login credentials for an administrator jumphost server were identified, among others. Thus, a login with a local system administrator was possible here.

Countermeasures:

- Introduce appropriate password management, for example via [LAPS](https://learn.microsoft.com/de-de/windows-server/identity/laps/laps-overview)
- Implement appropriate group policies to prevent domain administrators from logging into third-party systems ([Protecting Domain Administrator Groups](https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/plan/security-best-practices/appendix-f--securing-domain-admins-groups-in-active-directory))
- Restrict remote desktop permissions for normal users to a necessary minimum

### Step 4: Reading the LSASS Process

The hashed credentials of active users are stored in Windows in the so-called [LSASS process](https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication). A local administrator has the permission to read this data. However, in this case, this was prevented by the activated virus protection. Using a so-called [AMSI bypass](https://pentestlaboratories.com/2021/05/17/amsi-bypass-methods/), the virus protection could be circumvented, and the process memory could still be read using the [Out-Minidump](https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Out-Minidump.ps1) script. This dump was then transferred to the attacker systems. To read the hashes contained therein, the tool [Mimikatz](https://github.com/gentilkiwi/mimikatz) was used on the attacker systems.

Countermeasures:

- Use of [Credential Guard](https://learn.microsoft.com/de-de/windows/security/identity-protection/credential-guard/). However, there are also [bypasses](https://research.ifcr.dk/pass-the-challenge-defeating-windows-defender-credential-guard-31a892eee22)
- Avoid active sessions and logins with domain administrators outside of domain controllers. In general, domain administrator accounts should only be used to administer the domain itself.
- Implement an appropriate [Privileged Access Model](https://learn.microsoft.com/de-de/security/privileged-access-workstations/privileged-access-access-model) for administrators

### Step 5: Generating a Kerberos Ticket

Using the extracted hash, a so-called Pass-The-Key attack could be executed. For this, the [getTGT.py](http://gettgt.py/) script from Impacket was used to obtain a Kerberos ticket with the hash.

With this ticket, the permissions of a domain administrator and thus the maximum possible privileges in the network were obtained.

Countermeasures:

- Deactivate RC4 key type in Kerberos
- Logging & Alerting

### Step 6: Post Exploitation

With these permissions, any actions in the domain environment of the network were now possible. Using impacket-secretsdump, we conducted a so-called DCSync attack, which provided the hashed credentials of all domain users as well as a plaintext password of the domain administrator.

Additionally, our own domain administrator with all privileges was created. From this position, an attacker with malicious intentions could have, for example, triggered encryption or deletion of all company data.

Countermeasures:

- Logging & Alerting

## About Us

At codecentric, we offer extensive consulting and testing in the field of IT security. Specifically in the area of IT infrastructure, we can assist you with assessments for inventory, penetration tests for verification, or Red/Purple team exercises for training a Blue team. More information can be found [here](https://www.codecentric.de/it-security).

Full control despite virus protection and modern systems – IT infrastructure can only be truly protected through a multi-layered approach.

How to truly protect IT-infrastructure

Full control despite virus protection and modern systems – How to truly protect IT-infrastructure

Recruiterin

Recruiter

In 2024, I embarked on the journey to become a recruiter for an IT Security Consulting team. I thought, “How hard can it be?” I had already been a recruiter for over 10 years, focusing predominantly on software developers, and I imagined my new task would be fairly similar. However, I quickly realized that my established methods wouldn't be as effective in this domain.

**Why?**

IT Security professionals (and particularly DFIR colleagues) are notoriously hard to find, much harder than, let’s say, Kotlin developers. They keep a very low profile on business platforms and the internet in general. In many cases, even the most sophisticated keyword searches fail to uncover their profiles, unless they actively desire to be found. So, what’s the cause?

Firstly, these professionals are acutely aware of the risks associated with personal information exposure and exploitation, given the nature of their work. Secondly, they often distrust the data collection practices of large corporations, fearing the misuse of their information for marketing or political purposes. Finally, publicly displaying their professional information online can inadvertently make them targets for “the bad guys”: hackers, attackers and malicious actors of all sorts.

So, where does this leave the eager recruiter? How do you “catch the good guys”?
###  My learnings

**Proactive Engagement:**
Even with minimal profiles, I initiated contact to gain insights within the industry. While my approach may not have always been highly tailored, I emphasized engaging with wit and curiosity. This allowed me to generate responses from fantastic future candidates and gather valuable industry insights. As much as I appreciate speaking with potential candidates, I am equally thrilled to connect with professionals who may not be looking for a new role but are happy to chat. Over the past year, this strategy has significantly enhanced my understanding of the cybersecurity community in Germany.

**Community Immersion:**
Speaking of the community and their members who often fly under the radar of classic recruitment methods, I found it to be essential to go where they are. Our team members regularly attend and speak at meetups and conferences, which I joined as often as possible to mingle with the crowd. We also exhibit at IT:SA, which has proven to be an outstanding networking opportunity. It goes without saying that this is a relatively indirect and long-term approach. 
While active recruiting efforts are generally unwelcome at dedicated industry events, my presence has allowed me to network organically and build relationships. I’ve also successfully scheduled meetings with prospective candidates at events we both attended. Added benefit: I had colleagues from the IT Security team around to help me make “the pitch”.

**Online Visibility:**
As the saying goes, "The best place to hide a dead body is on the second page of Google search results." Since IT security professionals are so difficult to locate, we wanted to make sure that they could find us. This was a collaborative effort involving leadership, marketing, the IT Security team, and HR.

We launched a dedicated sub-brand homepage for IT security, the team started publishing more blog articles, and I optimized my recruiter profile with relevant keywords. This stronger online presence has been crucial in attracting passive candidates who were quietly looking for their next professional opportunity.

**Employee Referrals:**
People referred by existing employees are far more likely to be hired than applicants coming through any other channels (direct search, job boards, events, etc.). Good people know good people. While they will still take part in the official recruitment process, these candidates have automatically undergone an “informal vetting process”. Team members wouldn’t recommend a new colleague who they don’t believe to have a suitable skillset or be a team fit, right? This approach is even more important for IT security professionals whose networks are often not openly accessible. And yes, we have been successful in hiring new colleagues through team members’ referrals over the last year. 

**Niche Platforms:**
IT Security professionals often have a deep passion for their work that extends far beyond their daily tasks. You'll find them actively involved in organizations like the Chaos Computer Club (CCC) and honing their skills on online platforms such as TryHackMe or Hack The Box – these are essentially online hacking playgrounds and vibrant cybersecurity communities.

Interestingly, some of these platforms allow you to post job roles directly and even anonymously approach members who've indicated they're "open for opportunities." While you won't know the individual's name you're reaching out to, their scores on these platforms can offer valuable insights into their technical skills and areas of expertise. (I haven't personally tried this approach yet, so if you have, I'd love to hear about your experiences!)

These are the most successful strategies I've used over the past year to grow our IT Security team, along with an outlook of what I'm still eager to try in the future. While the core approaches aren't revolutionary, adapting them for the unique challenge of finding IT security specialists was absolutely key.

Do you have any other ideas on how to find and recruit "the good guys"? I'd love to hear them!

Hiring for cybersecurity roles presents unique challenges. Here's why it's so difficult and strategies to overcome the hurdles.

My Learnings on Recruiting IT Security Professionals

How to Catch the Good Guys: My Learnings on Recruiting IT Security Professionals One Year In

IT Consultant

In addition to dominant US providers like AWS, Azure, and GCP, the French company Scaleway now offers a comprehensive serverless computing portfolio.
This includes services for Function as a Service, a lightweight Key/Value Store, and a simple messaging service, providing the basic functionalities for cloud-native serverless computing.
To put this offering to the test, I migrated a sample application to Scaleway, and I can now share my experiences in this post.

---

## Use Case and Test Environment

The application consists of a Single Page Application, a backend with multiple serverless functions for API calls and OAuth authentication, and a Key/Value database for user management.
I originally built the implementation on AWS, where numerous Managed Services were available to me.
Now I looked for an equivalent on Scaleway, and I was able to implement the application with few limitations.
The repositories for both implementations can be found on GitHub.

* [GitHub Repository of the AWS implementation](https://github.com/florianluediger/playlist-cutter-full-stack)
* [GitHub Repository of the Scaleway implementation](https://github.com/florianluediger/playlist-cutter-full-stack-scaleway)

| Feature                             | AWS Service            | Scaleway Service                    |
|:------------------------------------|:-----------------------|:------------------------------------|
| Hosting the Single Page Application | AWS S3                 | Scaleway Object Storage             |
| Managing Subdomains                 | AWS Route53            | Scaleway Domains and DNS            |
| Delivering the Website with SSL/TLS | AWS CloudFront         | Partially covered by Object Storage |
| Creating SSL Certificates           | AWS CertificateManager | -                                   |
| Serverless Functions Backend        | AWS Lambda             | Scaleway Serverless Functions       |
| Consolidating Functions             | AWS ApiGateway         | -                                   |
| Managing External Secrets           | AWS ParameterStore     | Scaleway Secret Manager             |
| Session Management for Users        | AWS DynamoDB           | Managed Database for Redis          |

---

## Positive Experiences

Overall, I really enjoyed working with Scaleway.
The UI is very clean and intuitive, especially if you're used to the cluttered interface of the AWS console.
This allowed me to get a good overview of the services' functionalities just by navigating the website.
I created my application using Infrastructure as Code and the Scaleway Terraform Provider.
This worked well for me and, in my experience, provided clear error messages when something went wrong.

In my opinion, Scaleway sensibly relies on Open Source Software in many places, saving them a lot of work in implementing their own solutions.
For example, logs and metrics are displayed in a Grafana instance transparently integrated into the system, meaning logs are automatically collected and can be accessed directly in the console with a click.
While this means not everything feels as seamlessly integrated as with other providers, it allows Scaleway to focus on other exciting features.

One of these features is the ability to deploy serverless functions, which I extensively tested for my use case.
There's also the option to deploy serverless containers and design communication between services using queues and topics.
Permissions between these services are managed via a simple IAM system.
For me, these are exactly the features I expect from a competitive cloud provider to build cloud-native applications.

---

## Challenges and Obstacles

While implementing my sample application, I encountered some challenges.
This was mainly because my original implementation was tailored to AWS, and Scaleway didn't offer all the features I used.
I'd like to provide a few examples of features you might currently have to do without if you choose Scaleway.

In my AWS implementation, I could split my serverless backend into multiple functions, which I then consolidated with an API Gateway and made available under a single URL using path-based routing.
This isn't possible with Scaleway, as there's no equivalent to the API Gateway, and each function gets its own URL.
Since my backend is quite small, I combined all the code [into one function](https://github.com/florianluediger/playlist-cutter-full-stack-scaleway/blob/main/backend/src/backend-handler.ts) and then evaluated the access paths within the function.
However, for larger applications, this isn't practical, which would require hosting your own service to handle routing.
Scaleway recommends a [solution based on the Kong Gateway](https://github.com/scaleway/serverless-gateway) for this.

The permission system for inter-service communication is also not entirely mature in some areas.
For example, to access the Secrets Manager, I first had to create an API key in the IAM service that received permission for the Secrets Manager via a policy.
I then passed this API key to my serverless function via an environment variable, which has to read this value and use it for direct access to the secret.
With AWS, on the other hand, I can simply assign access to a specific secret to the [Execution Role of a Lambda function via a Policy](https://github.com/florianluediger/playlist-cutter-full-stack/blob/a25e91da5befcd44867033436619fc9393012be4/backend/src/auth/auth.ts#L55).
This eliminates manual key management, meaning no key can be lost or fall into the wrong hands.

As an alternative to AWS CloudFront, Scaleway offers a feature called Edge Services, which can provide public endpoints for buckets and load balancers with caching and SSL/TLS.
While operating the service via the interface works well, creating resources via Terraform caused a crash for me.
This rendered the entire feature unusable in the web console until I removed the corresponding resources with Terraform.
Scaleway Edge Services are currently still advertised as a new feature, so these errors will likely be fixed soon.

Generally, I had the feeling that a lot of work is currently being done on new functions and services, and much is in a state of change.
With the relatively new offering for Serverless Functions, I encountered an obstacle as well when searching the documentation.
For example, the [reference documentation](https://www.scaleway.com/en/docs/serverless-functions/reference-content/functions-handlers/) for the handler function code currently doesn't state exactly what the `event` and `context` objects passed to the function look like or what attributes they provide.
So, you have to piece this information together from examples found online.

---

## Conclusion

Overall, I really enjoyed working with Scaleway, especially because of the intuitively designed web console interface.
It offers an easy entry point, particularly for developers with little experience in cloud technologies, thanks to its slightly reduced feature set and easy use.
While some use cases require more effort than would be the case with the large hyperscalers, there's usually a solution for most problems.
The basic services required for a serverless architecture are present, and there are even some specialized offerings for IoT or machine learning applications.
Personally, I was most bothered by the permission concept, as I'm very used to managing all permissions through Roles and Policies when using AWS and not having to worry about secrets.
However, for customers who want to rely on European solutions and don't require special features, Scaleway represents a sensible alternative to the established US companies in my opinion.

Scaleway Serverless tested: Is the European Offering a viable Alternative to large Hyperscalers? My experience.

Serverless from Europe: My Experience with Scaleway

Serverless from Europe: My Experience with Scaleway as an Alternative to AWS, Azure and GCP

IT Consultant & Developer

Lead API Consultant

*API Discovery refers to the ability to identify, catalog, and document all APIs used within an organisation with the goal of making them discoverable and usable while strengthening governance. There are countless tools that support API discovery. Typically, they are called developer portal, catalog, or marketplace. With this abundance of different names, it's easy to lose track. What should an API discovery tool actually accomplish? And which name is right for which type of tool?*

## Developer Portal

Developer portals provide access to APIs as self-service, seamless onboarding, good documentation, and integration support. Their main target audience is technical, which is also represented by the name.

The typical functions supported by a developer portal are:
- API documentation
- Interactive API exploration and sandboxes
- SDKs, sample code, Bruno / Postman Collections
- Authentication &amp; API key/token management
- Support for development teams

A good developer portal helps development teams understand how to use an API. It reduces the time needed for integration, even during first use. Additionally, it increases the adoption rate for APIs through the self-service offering.

## Catalog
Catalogs organise and manage APIs for better discoverability and consistency. Their main target audience is usually technical and internal to the company, as they provide a complete overview that is often not necessary for external users.

The typical functions supported by a catalog are:
- Centralised API inventory
- Search, filtering &amp; categorisation
- Visualisation of API metadata
- Governance and policy enforcement
- Standardisation of API contracts and dependencies

A good catalog leads to APIs being reused because they are easier to find. This also reduces duplicates and API sprawl. It promotes governance through the enforcement of policies and consistency across team boundaries. Through the centralised API inventory, a catalog also enables standardisation of API contracts and dependencies.

## Marketplace

Marketplaces connect API providers with their consumers and promote monetisation and partnerships. Their target audience is more diverse and includes people with both business and technical focus. Marketplaces are usually offered externally and show only a selected subset of the API landscape.

The typical functions supported by a marketplace are:
- Ratings, reviews, and community engagement
- Billing mechanisms and revenue sharing
- Legal agreements and transparent SLAs
- Onboarding of providers and consumers
- Pricing models for APIs

A good marketplace extends API usage beyond internal teams. It primarily supports the commercialisation and monetisation of APIs. At the same time, it must enable decision-makers to effectively monitor their API usage.

## Consumer Needs

Discovery tools are the window to an organisation's API landscape. The most important stakeholders are the consumers of the APIs, who typically have four needs:
- Discoverability: Which API is right for my use case?
- Onboarding: How can I get started immediately?
- Integration: Is the API stable, reliable, and secure?
- Business alignment: What does using the API cost me?

The presented types of discovery tools focus on different needs:

<style>
  .api-table {
    width: 100%;
    border-collapse: collapse;
    margin: 20px 0;
    border-radius: 8px;
    box-shadow: 0 0 20px rgba(0, 0, 0, 0.1);
    overflow: hidden;
  }
  
  .api-table thead {
    background-color: #007286;
    color: white;
  }
  
  .api-table th {
    padding: 12px 15px;
    text-align: left;
    font-weight: bold;
    text-transform: uppercase;
    font-size: 14px;
    letter-spacing: 0.5px;
  }
  
  .api-table td {
    padding: 12px 15px;
    border-bottom: 1px solid #eee;
  }
  
  .api-table tbody tr:nth-child(even) {
    background-color: #f9f9f9;
  }
  
  .api-table td:first-child {
    font-weight: bold;
    color: #333;
  }
</style>

<table class="api-table">
  <thead>
    <tr>
      <th>Consumer Need</th>
      <th>Developer Portal</th>
      <th>Catalog</th>
      <th>Marketplace</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Discoverability</td>
      <td>❌ Not the primary focus</td>
      <td>✅ API metadata, categorisation, taxonomy</td>
      <td>✅ APIs listed based on pricing or ecosystem fit</td>
    </tr>
    <tr>
      <td>Onboarding</td>
      <td>✅ Tutorials, interactive documentation, SDKs, sandboxes</td>
      <td>❌ Not a core function</td>
      <td>❌ Limited to API descriptions</td>
    </tr>
    <tr>
      <td>Integration</td>
      <td>✅ Self-Service</td>
      <td>❌ Primarily a governance tool</td>
      <td>❌ Pre-built integrations, API contracts</td>
    </tr>
    <tr>
      <td>Business Alignment</td>
      <td>❌ Mostly developer-centric</td>
      <td>✅ Supports API lifecycle governance</td>
      <td>✅ Enables monetisation and partnerships</td>
    </tr>
  </tbody>
</table>

## A Tool for API Owners

In addition to developer portals, catalogs, and marketplaces, API registries are also emerging. Registries manage API artefacts to create transparency throughout their lifecycle. Their main target audience is API owners.

The typical functions supported by a registry are:
- Versioning &amp; change tracking
- Central storage of API definitions
- Schema and dependency detection
- Lifecycle management

A good registry ensures transparency of the API lifecycle. It improves collaboration between teams and provides structured access to all API artefacts. In contrast, Portals, catalogs, and marketplaces focus on the consumption of APIs. The registry is thus the central and authoritative data source for all discovery tools used internally and externally.

![APIAccessChannels.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmb5brkk4ogkd06ug221nqhee)
*The API registry serves as the central storage for API artefacts. From here, APIs are synchronised to various access channels such as developer portals, catalogs, and marketplaces, where they are made available to different target groups of consumers.*

## Conclusion

Different API discovery tools also have different focuses. Depending on whether the audience is purely technical or should include business stakeholders, a different tool should be used. The different tool types also have various tasks. While registries and catalogs tend to regulate the lifecycle of the API and provide an overview of all APIs, developer portals and marketplaces focus on the consumption of APIs.

![DevPortal Quadrants - en.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmb5bot6yodxn06ugxjvm1616)
*Overview of the typical target audience (horizontal axis) and the typical task (vertical axis) of different tool types for API discovery.*


API Discovery with Developer Portals, Catalogs and Marketplaces: Finding the Right Tool for API Consumers

API Developer Portal, Catalog or Marketplace?

[DuckDB](https://duckdb.org/) has rapidly emerged as a popular in-process analytics database. [Dagster](https://dagster.io/), on the other hand, is a modern data orchestration framework that makes it easy to build and manage data pipelines. Combining Dagster with DuckDB allows data engineers to build pipelines where data is stored in DuckDB tables or queried via DuckDB’s SQL engine – all within a Dagster workflow.
This guide will walk you through setting up a new Dagster project from scratch with DuckDB integration. It will demonstrate two practical Dagster assets: one that inserts a Pandas DataFrame into a DuckDB database, and another that reads data from files (CSV) using DuckDB’s SQL capabilities. The goal is to provide a clear, working example that you can use as a foundation for your own projects.

## Basic Setup and Dependencies

**Create a new Dagster project**

I am using [poetry](https://python-poetry.org/) to manage my dependencies. Install these dependencies to be able to follow the next steps: `poetry add dagster dagster-duckdb dagster-webserver pandas`
This leaves us with the project structure below after setting up the dagster project with `dagster project scaffold --name dagster_duckdb_demo`. I added a folder called `data`. It will become necessary in the next section.

```markdown
.
└── dagster_duckdb_demo
	├── dagster_duckdb_demo
	│   ├── __init__.py
	│   ├── assets.py
	│   └── definitions.py
	├── dagster_duckdb_demo_tests
	│   ├── __init__.py
	│   └── test_assets.py
   ├── data
   ├── poetry.lock
   ├── pyproject.toml
   ├── README.md
   ├── setup.cfg
   └── setup.py
```
You should also have DuckDB installed on your machine in order to inspect the database with the CLI.

**Define a DuckDB resource**

To enable the usage of DuckDB in Dagster, a resource must be added. This can be achieved in the `definitions.py` file where you simply add a `DuckDBResource` from the `dagster_duckdb` package and reference the database. I will be using a database file in the `data` folder that was created in the previous step. The database will be created automatically if it does not exist.

```python
# definitions.py

from dagster import Definitions, load_assets_from_modules  
from dagster_duckdb import DuckDBResource  
 
import assets  
 
all_assets = load_assets_from_modules([assets])  
 
defs = Definitions(  
	assets=all_assets,  
	resources={  
    	"duckdb": DuckDBResource(database="data/data.duckdb")  
	}  
)
```

## Creating Assets

Dagster encourages asset abstraction. Here’s how you can write simple read/write assets.

**Writing a table from a pandas DataFrame**

This example will load a pandas Dataframe into DuckDB for later processing. This is only an example to show the usage of python Dataframes directly inside SQL that will be used to fill the table with DuckDB.

```python
# dagster_duckdb_demo/assets/pandas_import.py

import dagster as dg  
import pandas as pd  
from dagster_duckdb import DuckDBResource  
 
 
def source_data() -> pd.DataFrame:  
	return pd.DataFrame({  
    	"user_id": [1, 2, 3],  
    	"event": ["login", "purchase", "logout"],  
    	"timestamp": pd.to_datetime(["2025-05-01", "2025-05-02", "2025-05-03"])  
	})  
 
 
@dg.asset(  
	kinds={"python", "pandas", "duckdb"}  
)  
def pandas_import(context: dg.AssetExecutionContext, duckdb: DuckDBResource) -> dg.MaterializeResult:  
	example_df = source_data()  
 
	with duckdb.get_connection() as conn:  
    	conn.execute("CREATE OR REPLACE TABLE events AS SELECT * FROM example_df")  
    	preview_df = conn.execute("SELECT * FROM events limit 5").fetch_df()  
    	count = conn.execute("SELECT COUNT(1) FROM events").fetchone()[0]  
 
	return dg.MaterializeResult(  
    	metadata={  
        	"row_count": dg.MetadataValue.int(count),  
        	"preview": dg.MetadataValue.md(preview_df.to_markdown(index=False))  
    	}  
	)
```

**Importing Data from CSV**

To show an alternative to the data import, an example CSV file is imported into the same DuckDB database with the following script. The file is directly referenced from the path so it must not be opened or imported before processing. It would also be possible to use a URL that is offering a CSV file.

```python
# dagster_duckdb_demo/assets/csv_import.py

import dagster as dg  
from dagster_duckdb import DuckDBResource  
 
 
@dg.asset(  
	kinds={"python", "duckdb"}  
)  
def csv_import(duckdb: DuckDBResource) -> dg.MaterializeResult:  
	with duckdb.get_connection() as conn:  
    	conn.execute("""  
        	CREATE OR REPLACE TABLE example_data AS
        	SELECT *        	
		    FROM 'data/example.csv'  
    	""")  
 
    	row_count = conn.execute("""  
        	SELECT COUNT(1)        	
		    FROM example_data    	
        """).fetchone()[0]  
 
	return dg.MaterializeResult(  
    	metadata={  
        	"row_count": dg.MetadataValue.int(row_count)  
        }  
	)
```

**Downstream Assets**

To show the usage of downstream assets in Dagster with DuckDB, an additional script will be added. Pay attention to the dependency between the `login_events` and the `pandas_import` asset.

```python
# dagster_duckdb_demo/assets/csv_import.py

import dagster as dg  
from dagster_duckdb import DuckDBResource  
 
 
@dg.asset(  
	kinds={"python", "duckdb"},  
	description="Select login events from events table for further processing",  
	deps=["pandas_import"]  
)  
def login_events(duckdb: DuckDBResource) -> dg.MaterializeResult:  
	with duckdb.get_connection() as conn:  
    	conn.execute("""
            CREATE OR REPLACE TABLE login_events AS
            SELECT *
            FROM events
            WHERE event = 'login'            	
        """)  
    	login_event_count = conn.execute("""
            SELECT COUNT(1)
            FROM login_events
        """).fetchone()[0]  
 
        return dg.MaterializeResult(  
    	    metadata={  
        	    "login_event_count": dg.MetadataValue.int(login_event_count)  
    	    }  
	    )
```

## Updating the Definitions and Materialize

The updated `defitions.py` file now contains the assets from the previous step.

```python
# dagster_duckdb_demo/defintions.py

import dagster as dg  
from dagster_duckdb import DuckDBResource  
 
from .assets import csv_import, login_events, pandas_import  
 
all_assets = dg.load_assets_from_modules([csv_import, login_events, pandas_import])  
 
defs = dg.Definitions(  
	assets=all_assets,  
	resources={  
    	"duckdb": DuckDBResource(database="data/data.duckdb")  
	}  
)
```

Launching the Dagster webserver via `poetry run dagster dev` will now show the following dependency graph:
![dagster+duckdb+article+dependency+graph.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmao36qxm3gcg07uq81w7mlco)

Materializing these assets should show the configured metadata after a successful run for each asset. Inspecting the DuckDB file via the CLI returns the following overview:
![dagster+duckdb+article+duckdb+tables.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmao35wad3j8307umfd46687l)

## Conclusion
As we have now seen, integrating DuckDB into the Dagster workflow is quite simple. Once the resource is defined, it can be used for every asset easily and offers a capable API to directly save Dataframe or CSV files for further processing.
In a next step, dbt could be added for data transformations or the local DuckDB instance could be swapped for a connection to MotherDuck to leverage their Cloud Data Warehouse features.


Learn to integrate DuckDB with Dagster for data pipelines. This guide demonstrates setting up a project, writing pandas data, and importing CSV files using SQL.

Using Dagster with DuckDB

Senior Solution Architect / Head of API Consulting

In many projects, teams create technically functional APIs without focusing on business requirements or future use. Development often still follows a classic pattern: assign a ticket, implement the interface, and close the ticket. What's missing is the perspective of those who will actually use these APIs. This is where API Thinking comes in, as a mindset for consistently designing APIs in a user-centric and strategic way. 

Inspired by [design thinking](https://www.nngroup.com/articles/design-thinking/) and the [design sprint](https://www.thesprintbook.com/the-design-sprint), API Thinking reflects our practical experience. Together with input from [Dr. Martin Kiel](https://www.the-black-frame.de), we developed API Thinking to look beyond technical implementation and treat APIs as consciously designed products with value, purpose, clear responsibilities, and a clearly defined target audience.

## What is API Thinking?

API Thinking challenges you to view APIs not just as technical components for system integration but as part of a broader context. At its core, it focuses on addressing the needs of API consumers from the very beginning. These consumers could be development teams, specialist departments, or external partners. Yes, APIs are interfaces, but they also provide access to business functions, data, and processes. APIs sit at the intersection of technology, technical expertise, and user expectations. They must solve problems and deliver real value. Anyone who designs APIs must understand who will use them, in what context, and what makes usage easy and valuable. This demands design decisions not only on a technical level but also on a strategic level. 

APIs do not exist in a vacuum; they operate within data models, processes, and organisations. API Thinking takes this interdependence seriously, treating APIs as products that teams must develop, maintain, and enhance. It also places responsibility for their quality, usability, and long-term viability firmly in the hands of their creators.

## From thinking to action: The model behind API Thinking

API Thinking doesn’t impose a rigid process. Instead, it offers a model for an iterative approach. A structured framework makes the idea tangible:

![en_api_thinking.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma0q07fegdmc07um5e81egyj)

Start by understanding your stakeholders. Who uses the API? For what purpose? What does a good user experience mean to them? Rather than describing audiences in abstract terms, you gain concrete insights through structured workshops, interviews, or analysis of existing usage patterns. 

Based on this understanding, define which data plays a role, not technically, but in terms of content. What do users really need? How important are quality and timeliness?

Only then should you design the API: Which interaction patterns fit? What level of detail makes sense? How will the interface remain consistent and understandable? 

Implementation follows these considerations and not the other way around. And it doesn’t end there: ideally, stakeholders validate the API at an early stage, teams actively seek feedback, and they feed new insights back into the process. This approach delivers not just a working endpoint, but an API that users can actually use and find valuable.

## Distinction: What API thinking is not 

Many confuse API Thinking with concepts like API First or API Management, but they differ clearly. API Thinking isn’t a method, a toolset, or an architectural principle, it’s a way of thinking. 

While API First means prioritising APIs organisationally from the start, API Thinking provides the content foundation for creating a concrete API. It looks at APIs from a product perspective: Why do we need this API? Who benefits? How should we design it to deliver real value?

API Design First calls for consciously designing APIs before implementing them, aiming for reusability and consistency. But even then, without understanding real users, APIs often end up technically sound but practically irrelevant. 

API Management focuses on operating, monitoring, securing, and scaling APIs. Important, but only after building the API. API Thinking, by contrast, starts much earlier: it questions whether and how an API even makes sense.

## What API thinking means for different roles 

API Thinking operates on multiple levels and impacts more than just developers and architects. 

For development teams, it means not just implementing APIs but as well shaping them. Teams take responsibility for intelligibility, consistency, and maintainability, while actively engaging with users to understand their needs.

For product managers, APIs become visible elements of the value chain with their own users, success metrics, and strategic relevance. APIs cease to be mere technical by-products and become deliberate parts of the product portfolio, capable of contributing measurably to business success.

Architects can apply API Thinking to structure systems more effectively, clarify responsibilities, and reduce complexity. For example, establishing clearly defined technical contracts between domains.

For all business roles, API Thinking with the right mindset opens doors: to partnerships, new digital revenue models, and more efficient processes. The focus shifts from APIs themselves to what they enable.

## From concept to business value

APIs reveal their impact not through technical cleanliness alone but through real-world application. APIs become true business enablers when they accelerate processes, simplify integration, or open new markets. But this only works if users adopt them. Good design makes adoption possible. By understanding user needs, teams build APIs that feel understandable, relevant, and trustworthy. This saves effort, increases adoption, and improves overall product quality. API Thinking makes this connection visible. It links technical interfaces with strategic goals and ensures a consistent focus on the "why". Whether for internal or external users, humans or machines.

## Conclusion

API Thinking isn’t a framework, a template, or a toolbox. It’s a mindset that refuses to see APIs as technical ends in themselves but instead views them as part of a bigger idea: empowering users, creating value, and connecting systems. Those who build APIs merely to meet technical needs waste their potential. Those who understand how and why users engage with APIs build interfaces that work, grow, and remain relevant.

The critical questions when designing APIs aren’t "Which method do we use?" or "Which tool do we choose?" Instead, they are: "Who are we doing this for?", "What problem are we solving?", and "How will our interface stay relevant long-term?"

**API Thinking won’t hand you ready-made answers. But it will help you ask the right questions.**

Learn how user-centred APIs create real added value & drive business success.

API Thinking

## Intro

In a previous&nbsp; [article](https://www.codecentric.de/en/knowledge-hub/blog/access-databricks-unitycatalog-from-duckdb), my colleague Matthias Niehoff demonstrated how duckdb can serve as a viable alternative to Spark for processing data stored in Databricks, specifically by directly accessing the Unity Catalog.

Building upon that, a next step is to investigate the integration of Databricks and Motherduck. This exploration will determine the feasibility and practicality of leveraging Motherduck for querying data stored in the Databricks Unity Catalog, which in this case is set up in Azure, where Databricks is just another easy to set up service.

## Setting up the access

The [uc_catalog](https://github.com/duckdb/uc_catalog) extension for duckdb allows attaching the Unity Catalog as a database in Motherduck. To access the individual Delta Tables inside the Unity Catalog, the *delta* and the *azure* extension are required.

A Personal Access Token (PAT) and the workspace URL for Databricks must be provided so that the uc_catalog extension can access the Unity Catalog. The PAT is used in the Authorization header for calls to the Databricks API. Afterwards, the Unity Catalog can be attached like a regular database in Motherduck.

Access to the Delta Tables inside the Unity Catalog is granted via *temporary table credentials* to allow short-term external data access. In this context, an Azure SAS Token will be generated and utilized as the credential for Databricks. The extension does this automatically for S3 but not for Azure.

To obtain the token manually, the */api/2.0/unity-catalog/temporary-table-credentials* endpoint of the Databricks API must be used. Obtaining the SAS token requires the PAT, the table UUID and the allowed operation (either `READ` or `READ|WRITE`). The [python SDK](https://databricks-sdk-py.readthedocs.io/en/latest/workspace/catalog/temporary_table_credentials.html) also supports this feature. The generated token is based upon the Databricks environment and is tied to the table. It is mandatory that the *EXTERNAL USE SCHEMA* permission is granted on Catalog level.

## Delta Tables in Motherduck

Data can be loaded into Motherduck for further processing by following a sequence of steps. The local duckdb UI was used to connect to the Motherduck instance for this example. We attach to the samples catalog that can be found in any Databricks workspace.

### Connect to motherduck

```sql
ATTACH 'md:';
```

### Add required extensions

```sql
INSTALL uc_catalog;  
LOAD uc_catalog;  
LOAD delta;
```

### Create Unity Catalog secret and Azure secret, attach Unity Catalog as database

```sql
SET azure_transport_option_type = 'curl';
CREATE OR REPLACE SECRET uc_catalog (
    TYPE UC,
    TOKEN '',
    ENDPOINT ''
);
CREATE OR REPLACE SECRET azure (
    TYPE AZURE,
    CONNECTION_STRING 'AccountName=;SharedAccessSignature='
);
ATTACH 'samples' AS samples (TYPE UC_CATALOG);
```

The Azure storage account name is part of the URL that is returned from the Databricks API call. It is the part that is between the @ symbol and the *dfs.core.windows.net* part. It can also be found in the details view for a Catalog item in the Databricks UI.

### Check access

```sql
SHOW ALL TABLES;
```

Following these steps, *SHOW ALL TABLES* should display the Delta Tables from Databricks within the Motherduck UI. Query execution is enabled on the accessible table via the Azure secret. Multiple Delta Tables would require the creation of multiple Azure secrets to store the SAS tokens for each table. They can be [scoped](https://duckdb.org/docs/stable/configuration/secrets_manager#creating-multiple-secrets-for-the-same-service-type) to use them for data access to the corresponding Delta Tables.

Ideally, if the uc_catalog supported handling Azure credentials natively, the temporary table credentials could be refreshed directly by the extension, making the separate Azure secret obsolete.

## Outlook

While initial access to Delta Tables can be established relatively easily, providing a potentially faster alternative for specific analytics tasks, this approach has obvious limitations. The necessity for frequent renewal of short-lived temporary table credentials limits the usability of Motherduck for Databricks. Full support for S3 is already available. GCP and Azure support would require adaptations of the credential handling inside the extension and are open [issues](https://github.com/duckdb/uc_catalog/issues/7) on GitHub.  

![Motherduck_Databricks_Integration.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cm9u1u2u5nba207uo2mh3jh89)

In the end, the *uc_catalog* extension is still a Proof of Concept. I hope the open Azure authorization issue will be addressed to revisit this approach. Then the extension could offer a benefit to load data from Databricks into Motherduck with a small initial overhead. At the moment, the integration requires glue code for the credential handling that could become obsolete and a plain SQL solution could be implemented.

Querying Databricks Delta Tables in Motherduck could become an interesting alternative to Spark to quickly gain insights on your data.

Querying Databricks Delta Tables in Motherduck

Senior Software Engineer

We all grow older. It is simply inevitable. As the saying goes, The only way to not grow old is to die young. Recently, I've completed my 20th year in the development industry. Through academia, consulting, and a stint in product development, I've learned some lessons once and many repeatedly. I'll try and put the most important of them to digital paper here, and I hope you'll be informed (or at least entertained) by them.

# Nothing beats getting your hands dirty.

First and foremost, software development straddles the divide between art, science, and craft. Everyone will emphasize different parts of this chord, but all three tones will ring when you code. Personally, I think each of the three aspects is of almost equal value.   

Each of these three pillars shares one commonality, though: It requires engagement and practice to become good at each of them. You can read a math textbook and know all the theorems - but unless you work out a few proofs yourself, you'll lack the mindset and thinking patterns to apply the lesson. You can watch a hundred tutorials on woodworking, and they will not help you much as your hand clumsily reaches for a knife and digs the blade into the wrong kind of wood for your project.

Coding is no different. That is why I don't particularly like low-code or visual code tools: They remove the hard part too early. That sounds like a grognard's lament at today's youth, but even in my youth, there were attempts at WYSIWYG editors and fancy UML executors. They did not help me. 

Implementing a connection pool by hand (knowing full well it wouldn't ever be as good as the thing a global community had built) helped me. Reading the specs on Java byte code and crafting a class file from first principles on a hex editor helped me. Understanding how AWS elastic beanstalk provisions more primitive AWS resources for its PAAS solution helped me. 

Once you have the skill, by all means, use the tools available to your heart's content. But always remember that the most essential tool is your own knowledge. And, quite honestly, hitting enough rocks on the side of the paved road makes you appreciate the convenience of the road more - especially since now you know why it is the way it is. Frequently, the context of a technology is as important, if not more so, as its features. 

# Learn by teaching

While in university, I made what might have been one of the best choices of my life: I became a tutor for younger students. I thought it would be an easy enough job: Recount material that was still fresh in my mind and get paid for it. 

I did not account for the sheer wickedness of the student's problems. They challenged my understanding in ways I hadn't thought possible, let alone expected to encounter. Things that seemed self-evident were put under a microscope and examined in detail. 

It's the same principle that makes rubber duck debugging work as well as it does: When you force yourself to abandon the things you take for granted, to go every step of the way instead of skipping the "obvious stuff," you sharpen your focus. 

Occasionally, the student beats the master. Something you teach is entirely wrong. I remember reviewing a junior developer's code that seemed horribly sloppy with resources - opening files repeatedly instead of carefully managing their lifetimes. I could have just rejected their pull request and required them to implement my envisioned sharing scheme. I walked over to their desk (this was the Halcyon pre-COVID days) and opened a conversation. 

They were unconvinced and asked for proof that it was as impactful as I claimed. So I set up a small test to benchmark things, proceeded to run it - and found literally no benefit to the lifecycle scheme. If anything, it performed worse. So I dug in my heels and tried to find out what was happening. As it turned out, the kernel was smarter than me, kept the memory map alive, and turned the re-open into an NOP. 

# Everyone is doing their best(!)

Believe it or not, everyone is doing their best. Or at least, that is the working assumption I've come to take on any given day until proven otherwise. That obstructive penny-pincher in your client's purchasing department who doesn't sign off on the tool you desperately need? They are doing their best because the budget for this year has already run out, and it's not even September yet. That product owner who insists things are done in a farcically complex way that makes no sense at all? They are also doing their best since that is what legal wrote down as "non-negotiables."

Technical skill is essential, but it's only part of the job. The other part is knowing and dealing with people. This is the part I sometimes struggle with the most, to be honest. But it is still essential. Knowing whom to talk to and whom to leave alone. Where to spend your limited social capital and how to enable everyone to do their best is not just a management skill - it is a person skill. 

So, while venting is occasionally cathartic and makes you feel heard, remember that anyone you meet is fighting their own battle. They're doing their best, just like you. 

# Hardware is (almost) never the problem

Your mobile phone has thousands of times the processing power that took the Apollo missions to the moon—just a fact. Of course, we blow it on animated emojis and to serve deceptive ads, but it is there. 

Similarly, three decades ago, even the smallest VM we run our backends on would have been close to a mainframe. So when we hit performance bottlenecks, the answer can certainly be "scale up" or "scale wider" if that is cheap. Money trumps efficiency. But when money becomes an issue, since we can't just make the customer buy new phones, it's time to break out the pliers and dig in.

Algorithms beat silicon, and processes beat algorithms. If something is hard, try to find a different way. Don't bash your head against an NP-complete rucksack problem if you can ask the customer to rank their delivery priorities. Don't do diffractive ray-tracing math to display an overlay on your mobile app. 

The Apollo rockets didn't land on the moon on autopilot - the compute wasn't there. Think of processing power as a budget constraint, and you're on your way.

# Trust but verify

A test suite is an extremely revealing thing. Few things illustrate the development team's unconscious fears as much as what they chose to spend time verifying. Take the business-critical, multi-million euro application I recently was tasked with maintaining. Highly complex code, much business logic. It was virtually untested. But what struck me as the worst part was not how little code the team wrote tests for  - but the tests they wrote. 

There was a class called `ListTest`. It primarily served to verify the correct operation of `java.util.ArrayList`. Similar tests were present for a lot of the libraries the team used. The team seemed to think their code was trustworthy, and the library code needed intense scrutiny. 

Trust, but verify. Trust that libraries do their jobs correctly (at least until you find actual bugs). Regardless, give their source code a glance or two as you begin using them. Immerse yourself and figure out the "vibe" of their team; understand how they speak the language. Chances are, they expect you to speak a similar dialect. 

Trust your teammates to do a good job - but not unthinkingly. Insist on code reviews and knowledge sharing. I don't want to invoke the metaphorical bus here. It'll help both of you out, and you might learn something in the act. That goes double for more experienced developers than you - not only are you given a chance to look at someone's work who had more practice than you. When you find weaknesses and questionable tradeoffs, talk to your coworker. More often than you think, they'll be open to a dialogue. Heck, give them a chance to learn by teaching. Don't short-change either of you on these chances.

# It's okay to be greedy 

Generally, greed is not good, no matter what Gordon Gekko wants you to believe. Greed is destructive, often short-sighted and alienating. But in some very niche, very peculiar circumstances, it is not only valid. It is, in fact, vital. The key is to be greedy for the right things: For cultivation of yourself instead of instant gratification. 

## Be greedy for understanding

Say you face a technical issue in one of your projects. The precise nature does not matter as much as it has you stumped. The deadline is approaching, and you know ChatGPT is just... over there. A click away. Your company policy may or may not allow you to use it, but you know if you copied and pasted your code, it'd spit out something resembling a solution.

You could be quick here and do your job without really doing it. You might even go home a few minutes early. That would be greedy in one way. But you could also be greedy in a smarter way. Greed is selfish. Being greedy, you may also put the project lower on your list of priorities. Instead, invest in yourself by digging your heels in and going all the way to understand and solve the issue. 

And the funny part is that this kind of greed does bring dividends. You will not only be less likely to trip over this problem again and waste an afternoon debugging the same problem you had before. You will also learn and solidify your grasp of the technology of your choice. Learn what works in which way, what warts lurk behind unintuitive designs, and maybe most importantly, you'll build confidence in your ability. After all, you did it yourself, not a sum aggregate of the average ability displayed on GitHub.

## Be greedy to reach the mountain

Envision where you want to be early. Do you want to be the chief architect for your company? Do you want to have a "lead developer" credit for a major open-source project? Or do you want the comfort of earning a six-figure salary and indulging occasionally without giving the price much thought? Do you want to retire by 55 on your savings? Is this only your day job, and is poetry your true passion? All these goals are equally okay, provided you actively choose them. But all of them are similarly unlikely to fall into your lap. You'll have to chase them.

And all too often, we have these goals as vexing, distant things that we don't seriously work towards. There's always another year and something more important "right now." A mountain on the horizon that is, at the same time, tempting and seemingly unreachable.  

A few years ago, I hiked along the Great Glen Trail. From one end of the Scottish highlands to the other. And I saw Loch Ness as a distant glimmer on the horizon - then stood on the southern shore. And eventually, I passed Inverness' city limits on the northern shores. How did I do that? One step at a time. 

Take one step at a time, and be mindful of how all your small choices add up. Be bold and greedy; take one step after another, and you will go farther than you expect. Will you reach your mountain? Not necessarily. But unless you start on the road, you most certainly won't.

# Conclusions

So, where is the silver bullet that'll make you a better dev? Not here, I'm afraid. It won't be anywhere - because, like any craft, you learn something new every day. It's been 20 years, and I learned a lot. Imagine what I'll have learned when I'm 64.

Reflection on 20 years of coding in the software industry, personal reflections on the growth mindset.

20 years of coding

Software-Architect

Fullstack Dev

Foreword: \nThis blog is loosely based on a recent project experience.&nbsp;All persons, companies and names are fictitious, as to make them NDA compliant. Any resemblance to a person, existing company or brand is purely coincidental and unintentional.\nFor most people, doing a software architectural review in a few days sounds like nonsense. For us too, to a certain extent, until we had a chance to apply LASR (Lightweight Architecture Software Review) in a recent project.&nbsp;We were extremely restricted in terms of time, the to-be-reviewed system was not simple, and we had a lot of information to process. Yet, using this methodology made it possible for us to provide meaningful insights in a short time, which then could be used by our client for informed decision making.&nbsp;\nLASR truly made the entire Architectural Review process much more flexible and lean, and we believe it is a worthwhile tool to learn about and be able to use. In this article, we’ll tell you about how to use it, and what our experience with it played out.\nChallenge\nLets start by painting the situation at the start of the project assignment.&nbsp;It could be described as a nightmare scenario:&nbsp;\nA customer - lets call them&nbsp;\nRiskInvest\n&nbsp;\nLtd\n. - hires us for an architectural review of a Software Solution - lets call it&nbsp;\nMoneyMaker\n - written by a young company called&nbsp;\nGarageCompany\n.&nbsp;\nWe’re added to multiple meetings over the course of two days, where we will be learning about the architecture, infrastructure and process of this to-be reviewed system.&nbsp;\nAfter these two days, RiskInvest Ltd. tells us they need a justified go- or no-go statement for the acquisition of MoneyMaker and/or the whole GarageCompany,&nbsp;\nby the end of the week.&nbsp;\nBy this point, we've collected enough information to fuel weeks of work, if we were to approach it with traditional review methods such as ATAM, CBAM, etc. ...\nNot an optimal situation. Let us sum up the challenge thus far, in a couple of points:\nWe had very little time\n.\nWe didn’t know what was important to&nbsp;\nRiskInvest Ltd:\n Different organisations have different needs and tolerances regarding software, which can influence the review to a certain degree..&nbsp;\nThere was a lot to look at\n - the architecture of the software we saw was of non-trivial complexity.\nWe were to do the whole process fully remotely\n.\nWhat now?\nThankfully, we found a fitting approach for the problem relatively fast -&nbsp;\nLASR\n!\nIt stands for&nbsp;\nLightweight Approach for Software Review\n, and was devised by the company&nbsp;\nembarc\n. LASR is a relatively new process that we were already somewhat familiar with, but never had a chance to implement in a project in the wild before.\nLASR focuses on iterative, quality-focused analysis, with less set-up time and formalities, which in theory would enable us to get the much-needed statement more quickly. LASR is also very well documented, and developed based on the experience of professionals who had done many, many software reviews before.

We figured it’d be worth a shot, so we went for it.\nAbout LASR\nThere are two “versions” of LASR: \nLASR and LASR+ (depicted below)\n. Due to our time constraint, we focused on applying the simpler version LASR that consists of the first four steps: Lean Mission Statement (1), Evaluation Standard (2), Base-Review (3) and Goal-oriented Analysis (4):\nThe \nfirst step\n focus on understanding \nwhat makes the software\n being reviewed \nspecial\n, in relation to the client, his context and his mission.\nStep two\n focuses on the \nevaluation standard \nof\n top 5 key aspects\n for the success of the system based on quality attributes (DIN/ISO-25010) and defines an \nexpectation level\n for each key aspect.\nWith the \nthird step\n, success-critical risks are identified for the top 5 key aspects as part of the \nbase review\n in a \n“pre-mortem” analysis\n in order to identify possible gaps and set them in relation to expectation levels.\nIn the \nfourth step, target-oriented analyses\n are carried out, as we know them from ATAM. However, we only target key aspects where expectation and actual state are clearly different.\n\nWe will describe how we went about the process together with the client, and what output came out of applying this methodology. Reader beware: specifics on this process are under an NDA as of right now and therefore will be omitted where needed. Pictures used will always use a fictitious scenario.\nWednesday Morning (1): Grab the Lean Mission Statement for \nMoneyMaker\nThe preparations were short and sweet: Open a Miro board with a frame containing a website-icon and PostIt stacks. Once done we invited three members of \nRiskInvest Ltd.\n to your new Miro Board.\nThe most important thing in the first step is to \nlimit yourself to essential statements\n or "claims". This is why LASR suggests the “landing page” metaphor: Capture what it's about as well as possible, at a glance:\n10 minutes\n - RiskInvest Ltd. writes \nstatements\n on PostIt's. The employees are guided by the following questions: \nWhat are the key features or properties of \nMoneyMaker\n?\nWhat makes \nMoneyMaker\n special? What is particularly good?\nWhat requirements do important stakeholders have of \nMoneyMaker\n (“claims”)?\n20-30 minutes \n- similar \nstatements are grouped\n by \nRiskInvest Ltd. \ninto headlines, following short discussion.\n5 minutes\n - \nRiskInvest Ltd.\n \nvotes on 7 -/+ 2 statements\n that absolutely have to be on the landing page.\nEt voilà - after less than an hour the lean mission statement was done!\n\nWednesday Morning (2): Defining an Evaluation Benchmark\nWith a mission statement at hand, we moved on with the next step of the process, which was to find exactly&nbsp;\nhow&nbsp;\nwe should look at the software product, so we can set a certain expectation level, i.e. what \nMoneyMaker\n should be like in an optimal case.\nTo facilitate the discussion, the makers of LASR provide us with a game, which we promptly prepared into the workshop. The base concept for this game is a \nQuality Attribute\n, which are attributes based on the ISO-25010 specifications for software quality.&nbsp;\nWe prepared a card came on our Miro board with the quality objective cards (PNG images) from the \nLASR Community\n supporting material. \nThe \nfirst step\n was to \ndetermine the 5 most important “quality objectives”\n of \nMoneyMaker\n. In the second step, an \nexpectation level\n was then determined for each of the most important quality objectives.\nFor the first step, a frame on which 5 randomly selected quality objectives is arranged. To the right, the remaining quality attributes are arranged in a backlog. Below this, an area remained free for quality objectives that have been discussed and sorted out:\n\n\nThe game was played in the following way:\nA \nRiskInvest Ltd. \nemployee \nselects a quality objective from the backlog\n that has not yet been discussed and places it among the 5 selected quality objectives as a “challenger”. \nRiskInvest Ltd.\n then considers and discusses \nwhether and which\n of the selected quality objectives \nwould be displaced by the “challenger”\n. \nAt the end\n of each round, \none quality objective is put in the "Declined" area\n, regardless of whether it was a “challenger” or an ousted quality objective. \nThe most important \npro and con arguments\n are collected as a PostIt next to the respective quality objectives as documentation of the discussions.\nRiskInvest Ltd.\n then compared - as an optional step - the selected and eliminated quality targets once again in the overview, to see whether the selection made is coherent for \nRiskInvest Ltd.\n overall and eventually reduce the number of selected objects i.e. less than 5.\nOur challenge was to give \nRiskInvest Ltd.\n a good and clear understanding of quality atributes, to keep them focused on attributes important or relevant to the system and the mission statement instead of “pain points” or “goodies”.\n\n\n\nLASR considers 14 quality objectives, meaning there are 9 “challengers” plus a final discussion of 5-10 minutes. You should therefore take between 50 and 100 minutes\n to select the quality objectives\n - i.e. \nbetween 1 and 2 hours with a break\n.\n⁠In the \nsecond step\n, we wanted to \nquantify the expectations of the quality objectives\n and present them clearly in a graphic.\nWe asked the employees of \nRiskInvest Ltd.\n to \nevaluate these quality objectives\n within \n5 minutes\n according to the following scheme by each employee attaching a PostIt with their evaluation (a value between 25 and 100) to the respective quality objective. \n\n\nA 5 minutes time-box is a short time, but the time pressure was initially intended to promote intuitive evaluation in order to be able to focus \nlater\n discussions on evaluations that diverge strongly.\nFinally, \nonly attributes that were rated significantly differently\n \namong team members\n \nwere discussed\n (a good guideline here could be greater than 20% of the average). The mean value was used for all others. We also limited these discussions to an overall 20 minutes.\nThe LASR material also includes an Excel sheet that displays a spider map for max. 5 quality objectives. We entered the results of the assessment and got the following expectation horizon:\n\n\nAt noon we ended up with a lean mission statement for the \nMoneyMaker\n decision, the most important quality objectives and an evaluation of how important they are from the point of view of \nRiskInvest Ltd.\n \nWednesday Afternoon: Base Review\nThe missing building block for a first rough but reliable statement for a decision by R\niskInvest Ltd.\n on \nMoneyMaker\n was now an assessment of how MoneyMaker actually fulfills the expectations of the quality objectives. This required a deeper insight into MoneyMaker (processes, code, deployment, operations, etc.), which we had gained in the previous workshops with the \nGrarageCompany\n. \nLASR proposes a \n“pre-mortem” analysis\n for this purpose: Risks to the success of the use of the software are identified and assessed according to the probability of occurrence and the amount of damage. To do this, we again expanded our Miro Board with the risk cards from the LASR community material:\nIn the first step, potential \nrisks were identified and assigned\n to the relevant quality objectives - \n10 minutes for each risk group\n:\n\nThe next step was to\n assess these risks\n: How likely would they be to materialize? And how high would the damage be? - \n10 minutes per risk\n.\n\nFinally, the risk scores for each quality objective were summed up and subtracted relative to the expected level value. Here is an example where we calculate the actual quality level for the Usability Attribute:\nInitial Expectation Level: 95\nSummed up risk score: 40\nFormula risk value: \n      - (/100 * )\n     95 - (95/100 * 40) = 57\nFor each quality object we calcluated and ⁠entered the risk values into the spider map:\n\n
In the case of the MoneyMaker Usability, major differences between expectations and reality were immediately apparent, and a later, more in-depth analysis would focus on this.\nThe challenge was to keep the discussion of risks in terms of probability of occurrence and impact within the time frame and at a proportionate and pragmatic level. \nThursday Morning - Dig Deeper\nIn the context of the “pre-mortem” analysis discussions, we had already gained an initial overview of MoneyMaker as a software product and decided to invest some limited time in a deeper analysis of the expectation vs. reality gap - which is the next step (and last) in the LASR base method, the target-oriented analysis. Some risks needed a sharper look, in order to raise the confidence of the team in the conclusions we reached to in the day before. This took the form of an actual code dive (bottom up), at times together with the people who worked on the system.\nIn the frontend, we found relatively well-maintained clean code with good test coverage through fully automated testing and did not find an above-average amount of technical debt. The CI/CD process was state of the art (QA gateways such as static code analysis, security scans, etc.) and was automated throughout.\nIn the backend, however, we encountered code of varying quality (test coverage, technical debt, etc.). We could only recognize an inconsistent structuring of the modules or components and found significant differences between architecture and implementation. Neither architecture nor implementations could be recognized as functionally appropriate in random samples and we found the implementations that we looked at more closely to be unnecessarily complex. As an Example, we tried a very simple and quick change to the behavior of a single function of a module in the backend and failed because this would have required modifications to several other code locations (configuration, tests). This meant tight coupling, which means more effort when doing anything with the code.\nStatements from the \nMoneyMaker\n developers confirmed that UI flows could not always be implemented optimally due to the increased complexity in the backend &amp; processes.\nAfter having taken the time to actually look at tangible aspects of the application, we came out of this step with a refined notion of how real the picture of the current status vs. expected status was.\nThursday Afternoon - Summary\nWe made a quick, rough and conservative estimate of the effort required to eliminate the technical debt in the backend of MoneyMaker in order to provide \nRiskInvest Ltd.\n with a basic orientation.\nTogether with \nRiskInvest Ltd.\n we finally discussed the following scenarios:\nAcquire only the rights to \nMoneyMaker\n including code, DevOps etc. and develop our own version of \nMoneyMaker+ 2.0\n on our own, or\nonly take over the rights to \nMoneyMaker\n including code, DevOps etc., organize your own further development and fix technical debts on your own or\ntake over \nGarageCompany\n including \nMoneyMaker\n completely or\ntake over the rights to \nMoneyMaker\n including code, DevOps etc. and commission \nGarageCompany\n with the further development and rectification of technical debts.\nRiskInvest Ltd.\n was convinced by the functionality of \nMoneyMaker\n, but decided against developing its own solution due to the professional and technical risks and did not want to take over the legal succession of \nGarageCompany\n. Ultimately, the rough and conservative estimate of the cost of eliminating the technical debt was to be an important decision-making factor in the negotiations between \nRiskInvest Ltd.\n and \nGarageCompany\n.\nSummary and Conclusion\nGoing through this project challenged our notion that architectural reviews have to be time intensive, and made us much more agile and flexible when critically looking at software. However, it should always be borne in mind that LASR is less aimed at a complete architecture review than at focusing the review on the relevant aspects of the system.\nIn two days, we:\nBroke down what the actual software solution was about;\nFound out what characteristics of the software were the most important to look at;\nIdentified very real risks and managed to estimate them in terms of probability and impact;\nCompiled a report that could directly be used to make an informed decision by management at the client\nBoth us as consultants and the client \nRiskInvest Ltd.\n were satisfied with the results. \nThese results were not extremely specific or in depth, but it was just enough depth in order to get clarity, which is what we ultimately needed. It is also very fun to go through these workshops, which definitely doesn’t hurt!\nWe were very pleased with this framework and highly suggest getting acquainted with it. 
⁠We can recommend \nbuying the book\n, and along with it comes access to a lot of supporting material such as the card decks, fill-in graphs, and so on, which truly help facilitate the entire review process.

Pull off Architecture Reviews at Light-Speed with LASR!

Architecture reviews don't always need to take a month! 
Timing matters, and with LASR, finding critical insights on software takes as little as 2 to 3 days.

Pull off Architecture Reviews at Light Speed with LASR!

Principal IT-Security Consultant

As part of a Red Team assessment, a challenge arose to execute our own code via a DLL. The reason for this scenario was the use of Application Allow Listing software, which blocks the execution of unknown executables. The usual options for loading DLLs, such as rundll32, were heavily monitored by the customer's blue team, so we had to look for other options.\nAfter some trial and error in our labs and analyzing the behavior of certain Windows programs at runtime, it turned out that in a recent Windows 11 (as of March 2025),  some of Microsoft's own programs had a vulnerability - namely Relative Path DLL Hijacking.\nWith a little twist, this vulnerability allows attackers to run (malicious) code through trusted applications although security mechanism like application allow listing or monitoring might be in place.\nThis problem was reported to Microsoft on 21.02.2025 and categorized as "not a security vulnerability" on 07.03.2025. Nevertheless, we are happy to show you in this blog post how you, as a Red Teamer, can use Microsoft programs to load DLLs.\nWhat is Relative Path DLL Hijacking?\nRelative Path DLL Hijacking is a vulnerability that occurs when an application does not load a required DLL using a fixed path but instead uses the standard Windows search order (see graphic below). With this order, an attacker can place a DLL with the searched name in a manipulated directory that the attacker can write to. When the application starts, it loads the DLL and runs the code it contains with the rights of the affected program. \nThe following figure illustrates the search order for DLLs on Windows. Note that some search paths can be manipulated not only by administrators, but also by normal users.\n\n\nAffected Windows Components\nSome components from the system directory C:\Windows\System32 are vulnerable to the described attack if a little trick is used. The secret lies in the DLL search order, specifically in the "Application Path" entry.  To exploit the behavior, an affected component (e.g. calc.exe) is copied from the System32 folder to another folder that can be written to by the attacker:\ncopy C:\Windows\System32\calc.exe C:\Users\Public\\nThe Process Monitor tool can now be used to analyze the start of the process in detail. Filtering the events helps to show only the important information:\nPaths ending with .dll should be included in the output\nResults of events where a file is not found should be included in the output\nAll processes that are not calc.exe should be removed from the output\n\n\nAs you can see, calc.exe tries to load different DLLs from the folder in which it was executed.\n\n\nFor example, an adversary could create a DLL named Windows.Storage.dll and place it in the same directory where calc.exe is run. When calc.exe is started, the hijacked DLL would be loaded and the code it contains would be run. \nThe following sample code opens a message box that says "Hijacked DLL ..." when the DLL is loaded:\n\n\nIf calc.exe is now started and finds the DLL in the same folder, it is loaded and the message box is opened:\n\n\n\nWhy is this behavior still a problem?\nIn this particular case, the affected programs must be placed in a folder together with the malicious DLL and run. This means that the attacker must have taken initial control of the system or otherwise distributed one of the legitimate programs along with its DLL. To the attacker's advantage, the affected applications are digitally signed by Microsoft and are therefore considered trustworthy. This can lead to other security mechanisms being bypassed. Some solutions, such as antivirus software, EDR, and allow listing tools, may initially analyze only the loading process. \nThis vulnerability therefore offers attackers an alternative to the so-called LOLBAS (Living Off The Land Binaries and Scripts). These are native Windows programs and scripts that are usually misused by attackers for hidden actions. Since LOLBAS are usually intensively monitored by security solutions and have a higher risk of detection, relative path DLL hijacking in Windows programs opens up additional opportunities for attackers.\nTimeline of Responsible Disclosure\nDate\nAction\n20.02.2025\nVulnerability discovered in multiple programs\n21.02.2025\nNotification to Microsoft\n25.02.2025\nMicrosoft creates case number and conducts internal analysis\n07.03.2025\nClassified as not a security vulnerability\n12.03.2025\nApproval of blog post by Microsoft\nLinks to further information\n\nhttps://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order\n\n\nhttps://learn.microsoft.com/en-us/sysinternals/downloads/procmon\n\n\nhttps://lolbas-project.github.io/\n\n


Relative Path DLL Hijacking: Leverage legitimate Windows programs as a Red Teamer to run your own code.

Relative path DLL hijacking in Windows programs

IT expertise from developers for developers

CODECENTRIC BLOG

Angular 17 – Eine echte Renaissance?

Für mehr Nachhaltigkeit – CO2 sparen mit Rust

Produktstrategie als Erfolgsgrundlage: Warum du nicht mit deiner Vision starten solltest

Wie als Software-Entwickler sichtbar werden?

How to gain visibility as a software developer?

Charge your APIs Volume 26: Choosing the Right API Development Strategy: A Guide to API Design First vs. Code First Approaches

Agile

Big Data

CI/CD

Cloud

Container

data protection

DevOps

DevSecOps

Digital product developement

Digital Sovereignty

Digitalization

Generative AI

Input-Management

IT-Security

Kubernetes

Microservices

Sustainability

Product management

Software Modernization

Here at codecentric, we embrace an open culture and enjoy sharing our knowledge. Keep diving into our world.

WISSENS-HUB

Der Softwerker Spezial Generative KI

This issue is all about the benefits and potential, but also the risks and limitations, of generative AI in software development & corporate IT.

KNOWLEDGE HUB

The Softwerker Special Generative AI

Drei Personen sitzen am Tisch in einem Meetingraum mit Laptop und besprechen sich.

Services

codecentric weiterhin unter den Top 25 der Lünendonk-Liste 2025

Every year, the renowned B2B market research company Lünendonk & Hossenfelder publishes the list “Leading medium-sized IT consultancies in Germany” - in 2025, codecentric is listed again in the top 25.

In 2025 ist codecentric erneut unter den Top 25 mittelständischen IT-Beratungsunternehmen in der Lünendonk-Liste

NEWS

codecentric remains in the top 25 of the Lünendonk List 2025

Do you have a deep, technical understanding and appreciation for agility and software quality? Then apply to codecentric!

JOBS

Agile Developer and Consultant (f/d/m)

Logo SoftwerkerCast - der IT-Podcast von Techies für Techies

Community

Software development

Culture

SoftwerkerCast

The SoftwerkerCast presents Softwerker knowledge for you to listen to and review.

Events – codecentric mittendrin

Meetups, regulars' tables, hackathons, user groups: codecentric is far more than the sum of our employees and projects.

Events - codecentric in the middle of it all

DISCOVER CODECENTRIC

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digital Products & Solutions

Digital sovereignty

IT Security

Artificial intelligence

Further services ...

How we work

References

Locations

Blog

Knowledge Hub

Careers

About us

News

Contact us

Do you have any questions or would you like to exchange ideas? Happy to help – just enter your contact details.

[ENG] Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

The codecentric blog provides expert knowledge on current IT topics: Agile methods, software architecture, AI, testing and much more. ► Discover now!

Blog: IT knowledge from developers for developers

Aktuelles

Thank you for your request. I will get back to you.

Thank you for your registration. A confirmation email is on its way to you.

This page is a preview. \nClick here\n to exit preview mode.

Sorry, we did not find any matching blog articles to your search. 

Do you still have questions? Just send me a message.

You have questions or want to exchange ideas with me? Gladly - just enter your contact details.

I have read the \nprivacy statement\n of codecentric AG and confirm this by submitting the form.*

Discover exciting further topics and let the codecentric world inspire you.

I hereby consent to the collection and processing of the above data for the purpose of receiving the newsletter of codecentric AG by e-mail. You can revoke your consent at any time by sending an e-mail to datenschutz@codecentric.de, by clicking on the link in the information e-mail itself, or by sending an e-mail to the contact details listed in the \nimprint\n. I have taken note of the \nprivacy policy\n of codecentric AG and confirm this by sending the form.*

Job application form field placeholder 10

Thank you for taking part in our free online IT security check 🙏.

To receive your result, we still need your email address

Karriere Podcast Page Info CTA Paragraph Mobile

Would you like to hear more quotes from our colleagues? What is it like to work in IT consulting at codecentric? Click here for an overview of all culture & career podcasts.

Softwerkercast Podcast Page InfoCTA Paragraph Mobile

Softwerkercast Podcast Page InfoCTA Paragraph

Softwerkercast Podcast Page InfoCTA Title

Softwerkercast Podcast Page InfoCTA Button

Sorry, we couldn't find any results for your search query.

Maybe the popular search entries will help you:

Apply now as [HEADING_TITLE] at codecentric