DEV Community: Lee Clark

The prompt engineer is dead. Good riddance.

Lee Clark — Tue, 08 Jul 2025 11:32:36 +0000

We spent two years teaching people to become AI whisperers, crafting elaborate incantations like medieval alchemists. “You are a helpful assistant with expertise in…” followed by three paragraphs of context, role definitions, and output formatting rules. We made it a bloody art form.

What a waste of everyone’s time.

The entire prompt engineering cottage industry was built on a fundamental flaw: asking humans to speak robot instead of teaching robots to speak human. We convinced ourselves this was sophisticated when it was simply broken design.

I’ve watched this pattern before. Remember when using the web required knowing HTML? When databases needed SQL wizards? When deployment meant server administration certificates? Every transformative technology starts with expert only interfaces, then gradually becomes accessible to actual humans.

AI is finally making that leap, and the prompt engineering crowd isn’t happy about it.

Context is eating prompts

The shift is happening right under our noses. Last month, I asked Claude to review our quarterly metrics. No preamble. No role playing. No “act as a senior business analyst” nonsense. It knew what I meant, found the relevant data, and delivered insights that actually mattered.

Six months ago, that same request would have required a dissertation length prompt explaining our business model, defining our KPIs, and specifying output formats. The difference isn’t just convenience; it’s fundamental accessibility.

This isn’t about models getting “smarter” in some abstract sense. It’s about systems that remember, connect, and infer. Systems that don’t force you to rebuild context from scratch every bloody conversation.

The technical foundation is straightforward: persistent memory across sessions, integration with external data sources, and dramatically improved intent recognition. Nothing revolutionary on its own, but combined they eliminate the need for human prompt gymnastics.

The democratisation nobody talks about

Here’s what the prompt engineering evangelists won’t tell you: their expertise was always a barrier, not a feature. Every “advanced prompting technique” was another wall between ordinary people and useful AI.

When my mam can get better results from ChatGPT than most software engineers could six months ago, that’s not dumbing down technology. That’s technology finally working properly.

The real measure of interface design isn’t how sophisticated the power users can get. It’s how effortlessly newcomers can accomplish what they actually need. We’ve spent too long celebrating complexity instead of results.

This matters beyond individual convenience. Organisations that built their AI strategy around prompt engineering teams are about to discover they’ve optimised for the wrong thing. The companies winning with AI aren’t the ones with the cleverest prompts; they’re the ones integrating context and memory into their workflows.

What this means for builders

If you’re still focused on prompt optimisation, you’re solving yesterday’s problem. The new bottlenecks are orchestration, memory management, and tool integration. These aren’t glamorous, but they’re what separate functional AI systems from party tricks.

The hard problems now live in the infrastructure layer: How do you maintain context across sessions? How do you ground responses in real data? How do you route requests to appropriate tools? How do you balance personalisation with privacy?

These questions matter more than any prompting technique ever will.

This transition also exposes who was building real value versus who was just riding the hype wave. Prompt engineering consultants are already pivoting to “AI workflow design” because the writing’s on the wall.

The bigger picture

We’re approaching the moment when AI becomes genuinely ubiquitous, not because it’s more powerful, but because it’s finally approachable. When tools adapt to users instead of demanding mastery, adoption follows naturally.

This is how technology should evolve: from expert only to universal, from complicated to intuitive, from performative to practical.

The prompt engineer era was necessary scaffolding, but scaffolding gets removed when the building is complete. We’re building something better now: AI that works for everyone, not just the people clever enough to speak its language.

The future belongs to systems that understand context, not users who perfect inputs.

Enhancing CI/CD Lead Times: The Power of Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD)

Lee Clark — Tue, 06 Jun 2023 10:14:36 +0000

Introduction:
In the world of modern software development, where rapid continuous delivery is facilitated by automated CI/CD pipelines, thorough and automated testing is paramount. This article explores how embracing Test-Driven Development (TDD), and Acceptance Test-Driven Development (ATDD) methodologies can significantly reduce lead times in CI/CD pipelines. We will delve into the consequences of lacking test automation, reasons behind its omission, and practical steps to transition towards TDD and ATDD.

The Impact of Neglecting Test Automation:
Failure to automate tests during the development stage can have several detrimental effects on CI/CD lead time, including:

Increased defect rate: Without automated testing, codebases are susceptible to a higher influx of defects and issues, leading to increased debugging time in later stages.
Slower feedback loop: Test automation accelerates the feedback loop between code changes and test results, enabling faster issue identification and resolution. The absence of this loop delays the overall lead time in the CI/CD pipeline.
Reduced confidence in releases: Inadequate or manual testing undermines confidence in the software's quality, resulting in prolonged lead times due to additional manual testing and validation.
Inefficient resource utilisation: Manual testing consumes valuable developer and tester time, restricting the availability of resources for developing new features or addressing existing issues.
Increased merge conflicts: Delaying test automation in the development stage heightens the risk of merge conflicts as multiple developers work on the same codebase. Resolving these conflicts is time-consuming and causes delays in integration, delivery, and deployment.
Decreased stability and reliability: Insufficient test automation during development leads to less stable and reliable software, necessitating additional time and effort to address issues and ensure production readiness.
Inconsistent test environments: Manual testing often lacks consistency across development, staging, and production environments, leading to unexpected issues and pipeline delays.
Hindered collaboration: A lack of test automation hampers visibility into code quality, making it challenging for team members from various disciplines to collaborate effectively and detect issues early.

Why Test Automation is Overlooked:
Despite the undeniable benefits, many development teams overlook test automation due to several reasons:

Lack of awareness or understanding: Some teams may be unaware of the advantages of test automation or lack a comprehensive understanding of its effective implementation in their development process.
Insufficient skills or experience: Test automation demands specialised skills and knowledge that some teams may lack, hindering effective implementation.
Time constraints: The time investment required for developing and maintaining automated tests can deter teams working under tight deadlines who prioritise feature development over test automation.
Limited resources: Test automation tools and infrastructure often require significant investments in terms of cost and resources, posing challenges for organisations with constrained budgets or smaller projects.
Resistance to change: Established workflows and successful existing processes may make teams resistant to adopting new practices, leading to hesitancy in learning new tools and modifying established methods.
Incomplete or rapidly changing requirements: Unclear or frequently changing requirements make it difficult for teams to create meaningful automated tests that need continuous updates.
Overemphasis on manual testing: Some teams rely heavily on manual testing, believing it provides more accurate results. This perception discourages investment in automated tests.
Fear of increased maintenance: Automated tests, like any other code, require maintenance and updates. Teams with limited resources may hesitate due to concerns about additional effort and maintenance requirements.

Striking the Right Balance:
Determining the extent of test automation in the development stage of a CI/CD pipeline relies on several factors, including application complexity, team resources, and project requirements. However, the following guidelines can help strike the right balance:

Unit tests: Developers should strive to automate most, if not all, unit tests during development. These tests execute quickly and provide immediate feedback, catching issues early and minimising defects in the integration stage.
Component and integration tests: Automating component and integration tests is crucial for verifying interactions between different components or services. These tests swiftly identify and resolve issues stemming from component interactions.
Static code analysis: Automating static code analysis checks during development identifies code quality issues, security vulnerabilities, and performance bottlenecks early on.
Code coverage: Aim for high code coverage with automated tests but remember that it is just one measure of test quality. It should be supplemented with other testing strategies.

Maintaining the Balance:
Achieving the right balance between automated and manual testing is pivotal. Automate tests that are repetitive, time-consuming, or prone to human error. Manual testing should focus on exploratory testing, usability testing, and other areas requiring human intuition and judgment.

The Power of Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD):
TDD and ATDD are development methodologies that prioritise automated tests before writing the actual code. They ensure code quality, catch issues early, and foster collaboration between team members.

Test-Driven Development (TDD) follows a short iterative cycle comprising three steps: Write a test, make the test pass, and refactor the code. This methodology helps create clean, maintainable, and bug-free code by catching issues early and refining the code continuously.

Acceptance Test-Driven Development (ATDD) extends TDD by focusing on defining and validating high-level requirements and acceptance criteria before development commences. By involving developers, testers, and business stakeholders, ATDD ensures the application meets user needs. Acceptance tests, written in a human-readable language, serve as guides for implementing the feature, with unit tests reinforcing the implementation.

Hurdles to Overcome:
Transitioning to TDD and ATDD involves overcoming a few challenges:

Mindset shift: Viewing testing as an integral part of development instead of an afterthought requires a change in mindset.
Skill development: TDD and ATDD demand specialised skills in writing effective tests and implementing test automation, necessitating investment in skill development.
Time and resource allocation: Initially, transitioning to TDD and ATDD may seem time-consuming. However, the long-term benefits of improved code quality and reduced debugging time outweigh initial perceptions.
Collaboration and communication: Successful ATDD relies on effective collaboration and communication among developers, testers, and stakeholders, fostering a culture of open communication.
Tooling and infrastructure: Implementing TDD and ATDD may require investing in new tools and modifying existing infrastructure to support test automation and continuous integration.

The Crucial Roles of QA, Security, and Operations Teams:
QA, security, and operations teams play vital roles in TDD and ATDD:

Quality Assurance (QA): QA team members collaborate closely with developers, defining test cases, creating test plans, and providing input on acceptance criteria. They contribute significantly to developing and validating acceptance tests and maintaining test automation infrastructure.
Security: Security professionals identify vulnerabilities and ensure the application adheres to security best practices. They define security-related test cases, embed security into the application, and reduce the risk of vulnerabilities.
Operations: Operations teams collaborate with developers to ensure the application's operational concerns, such as scalability, performance, and maintainability, are addressed. They contribute to a DevOps culture where development and operations teams work together for success.

A Practical Roadmap for Transitioning to TDD and ATDD:
Follow this roadmap to facilitate a smooth transition:

Build awareness and buy-in: Educate the team on the benefits and principles of TDD and ATDD and obtain buy-in from team members and stakeholders.
Provide training and skill development: Conduct workshops, training sessions, or pair programming exercises to develop the necessary skills for effective test writing and test automation.
Start small and iterate: Begin applying TDD and ATDD practices to small, manageable parts of the project or a pilot project.
Foster a culture of collaboration: Establish regular meetings or workshops involving all team members to collaborate on defining requirements and acceptance criteria, fostering open communication and shared responsibility for test creation and maintenance.
Set up necessary tooling and infrastructure: Allocate time and resources to select, set up, and configure tools, ensuring their integration into the development process.
Monitor progress with metrics: Track key metrics like code coverage, test execution time, defect rates, and lead time to monitor progress and identify areas for improvement.
Continuously improve and adapt: Regularly review progress, gather feedback, and adjust as needed.

In summary, TDD and ATDD methodologies, when implemented effectively, contribute to reduced CI/CD lead times by automating tests during development. These practices enhance code quality, minimise defects, and encourage collaboration from the beginning of the development process. By prioritising tests before writing code, teams catch and resolve issues early, resulting in fewer delays during integration, delivery, and deployment stages. Furthermore, TDD and ATDD ensure alignment with user expectations and operational requirements, leading to a smoother and more efficient CI/CD pipeline.

Femtech: What is it?

Lee Clark — Thu, 15 Dec 2022 16:41:43 +0000

Femtech, short for female technology, is a rapidly growing industry focused on the development of technology and products specifically tailored to women's health and wellness. This includes a wide range of applications, from period tracking and fertility monitoring to maternity and menopause support.

The Femtech industry has seen a surge in popularity in recent years, with many women turning to technology for solutions to their health and wellness needs. This trend has also been driven by an increased awareness of women's health issues and the importance of preventative care.

In this blog, I will explore the different types of Femtech apps available, the top trends driving the industry, and the steps involved in developing a women's health app. I will also discuss the challenges and costs associated with creating such an app, and highlight some of the best apps currently on the market.

What is Femtech?

Femtech is a term used to describe technology and products specifically designed for women's health and wellness. This includes a wide range of applications, including period tracking and fertility monitoring, pregnancy and childbirth support, menopause management, and more.

Femtech apps often combine traditional medicine with technology, providing women with accessible and personalised health care solutions. Many Femtech products are based on scientific research and data, and are designed to be user-friendly and intuitive.

Types of Femtech Apps

There are many different types of Femtech apps available, each designed to address a specific health or wellness need. Some of the most common types of Femtech apps include:

Period tracking and fertility monitoring: These apps help women track their menstrual cycles and monitor their fertility, often providing information on ovulation, fertility windows, and pregnancy risks. Some apps also offer personalised recommendations and support for women trying to conceive.
Pregnancy and childbirth support: These apps provide expectant mothers with information, resources, and support throughout their pregnancy and childbirth journey. This can include information on prenatal care, labour and delivery, and postpartum support.
Menopause management: These apps provide women with information and resources for managing the symptoms of menopause, such as hot flashes, mood swings, and sleep problems. Some apps also offer personalised recommendations and support for women experiencing menopause.
Women's health and wellness: These apps focus on overall health and wellness for women, offering resources and support for a wide range of health issues, including mental health, nutrition, and fitness.

Top 3 Trends Driving Femtech

Personalised health care: One of the biggest trends in Femtech is the use of technology to provide personalised health care solutions. This includes using data and algorithms to provide women with customised recommendations and support based on their unique health needs and goals.
Preventative care: Another trend in Femtech is the focus on preventative care and early detection of health issues. Many Femtech apps offer resources and support for women to monitor their health and take steps to prevent potential problems before they arise.
Increased awareness: The growth of the Femtech industry has also been driven by an increased awareness of women's health issues and the importance of preventative care. This has led to more women turning to technology for solutions to their health and wellness needs.

Steps to Develop a Women's Health App

Identify the target market and user needs: The first step in developing a women's health app is to identify the target market and user needs. This can be done through market research and user interviews to understand the specific health and wellness needs of women and how an app can address these needs.
Develop a concept and plan: Once the target market and user needs have been identified, the next step is to develop a concept and plan for the app. This should include a detailed description of the app's features, functionality, and user experience, as well as a roadmap for development.
Assemble a development team: The development of a women's health app will typically require a team of experts in various fields, including software development, design, user experience, and health care. It is important to carefully select team members who have the skills and experience necessary to create a high-quality app.
Create wireframes and prototypes: Once the concept and plan are in place, the next step is to create wireframes and prototypes of the app. This will help the development team understand the user flow and functionality of the app, and make any necessary adjustments before moving into the development phase.
Develop and test the app: The final step in the development process is to build and test the app. This will involve writing the code, designing the user interface, and testing the app to ensure it is user-friendly, stable, and reliable.

What are the Major Difficulties in Women's Health App Creation?

There are several challenges that can arise during the development of a women's health app, including:

Regulations and compliance: Women's health apps are subject to a number of regulations and compliance requirements, such as HIPAA and GDPR, to ensure the privacy and security of user data. This can make it difficult to develop an app that meets all of these requirements.
User privacy and security: Ensuring the privacy and security of user data is a major concern for women's health apps. This requires implementing robust security measures and ensuring that user data is protected from unauthorised access or disclosure.
User engagement and retention: Another challenge is maintaining user engagement and retention over time. This requires providing valuable and relevant content and features that keep users coming back to the app, as well as regular updates and improvements to keep the app fresh and relevant

Cost of Women's Health App Development

The cost of developing a women's health app will vary depending on a number of factors, including the complexity of the app, the size of the development team, and the length of the development process. However, as a general rule, the cost of developing a women's health app can range from £10,000 to £100,000 or more.

Best Apps for Women's Health

There are many excellent women's health apps available on the market, each offering a unique set of features and functionality. Some of the best apps for women's health include:

Clue: This popular period tracking app allows women to track their menstrual cycles, monitor their fertility, and get personalised health insights and recommendations.

Ovia: Ovia offers a range of women's health apps, including fertility tracking, pregnancy and parenting support, and menopause management.

Glow: Glow is a women's health and wellness app that offers resources and support for a wide range of health issues, including mental health, nutrition, and fitness.

Conclusion:

Femtech is a rapidly growing industry that is providing women with accessible and personalised health care solutions through technology. With a focus on personalised care, preventative care, and increased awareness, the Femtech industry is set to continue its growth and provide valuable resources and support for women's health and wellness.

Testing GraphQL

Lee Clark — Fri, 09 Dec 2022 15:59:18 +0000

Testing a GraphQL API can seem intimidating at first, but it's actually quite simple. In this post, we'll go over the basics of testing a GraphQL API using the popular testing library Jest.

First, let's make sure we have Jest installed. If you're using npm, run the following command:

npm install --save-dev jest

Next, let's create a test file for our GraphQL API. In this example, we'll create a file called graphql.test.js in our project's __tests__ directory.

In this file, we'll need to import the request method from the jest-gql library, which is a helper library for testing GraphQL APIs.

import { request } from 'jest-gql';

Next, let's define our GraphQL query. In this example, we'll be testing a simple query that fetches a user's name and email address:

const query = `
  query User($id: ID!) {
    user(id: $id) {
      name
      email
    }
  }
`;

Now, we can write our test. In this example, we'll test that the query returns the expected data for a user with an id of 1:

test('fetches user data', async () => {
  const variables = { id: 1 };
  const { data } = await request(query, variables);

  expect(data.user.name).toEqual('John Doe');
  expect(data.user.email).toEqual('johndoe@example.com');
});

That's it, short but sweet! With just a few lines of code, we've written a test that will verify that our GraphQL API is working as expected.

Of course, there are many other things you can test with Jest, such as the response time, error handling, and more. For more information on testing with Jest, check out the Jest documentation.

Build and publish the components whenever a new change to the source is detected.

Lee Clark — Wed, 06 Jul 2022 23:22:42 +0000

AWS IoT Greengrass V2 services are usually used in an automated framework where deployments of components are provisioned based on specific events. GDK CLI helps be more flexible for creating AWS IoT Greengrass V2 components using Python/Java/Bash. However, automation would be ideal instead of manually provisioning the build and publishing tasks whenever there is any change to the element. This build solution highlights using AWS CodePipeline for building/publishing AWS IoT Greengrass V2 components and reduces development efforts and manual intervention. Furthermore, for continuous integration and continuous deployment (CI/CD), versioning is an important aspect which can be simplified and automated by this build solution.

https://aws.amazon.com/blogs/iot/automating-workflows-for-aws-iot-greengrass-v2-components/